Browse legacy identities without a destination and review text before cloning

[loganj]

🤖

Summary

• You can now browse the agents in an old Buzz installation without choosing a destination community first. Browsing only reads the list. It cannot import anything.
• From that list, Clone opens the normal Create agent dialog with the old agent's name and instructions filled in. You can review and edit that text first. Create and start then creates a new identity and starts only that new agent. Clone never imports or starts the old one.

Details

• Browsing without a destination does not keep a pending import. It also cancels any earlier import preview. A real import still needs an explicit Destination community and a new preview.
• Clone copies only the name and resolved instructions. It does not copy the old key, environment values, command arguments, paths, history, or membership. It does not read the old installation's credentials.
• The instructions can contain embedded secrets, so the dialog asks you to review the text.
• Agents that need Repair team import still show that action in this list. Clone is not offered for them.
• Based on Show separate identity cards and prevent duplicate imports #225, which now includes Finish incomplete imported-agent setup with Use here #226.

Screenshots

Captured from the browser test fixture at this PR's head.

Import from another installation lists agents with Clone to this community

Clone opens the create dialog with the copied settings to review

[wesbillman]

Star Lord automated source review (via Wes's account)

Reviewed head 3e1cc1b6d4f6e37f22f65e1677e1eee1cc3cf3e5 against stacked base/merge-base 4ab4fab63462c6bace4f7b88d03aa4e17c37c805.

One actionable finding (P2), detailed inline: update the browser import helper for the renamed accordion so the existing import/recovery journeys can reach their assertions.

I traced all 15 changed files and the supported callers. Destination-free native preview clears any previous pending import and returns no commit token. Clone settings project only the selected identity's name and resolved persona prompt; the dialog reuses fresh-key creation, empty environment defaults, owner authorization, and stopped/start-on-launch-off persistence rather than credential import. Command registration and main-webview capability wiring are present. I found no additional actionable defects in that source pass.

The added Rust and component cases cover the intended browse/clone contracts in source, but were not executed. This was source-only: no tests, builds, app launch, live-library/credential access, or CI query. Native/browser runtime behavior and human acceptance remain unverified. This COMMENT is not an approval or merge authorization.

[wesbillman]

Star Lord automated source review (via Wes's account)

Reviewed head 8e6c7549306bafac9a132a6b01baaff889466ad9 against stacked base 88acd23a85d62357ae6dd4116415586c372d2d5c.

The previous P2 browser-selector finding is fixed. tests/browser/agent-control.spec.mjs:12–18 now uses the actual accordion name, with the existing import/recovery assertions retained. I rechecked the 16-file feature diff and its native IPC, browse/import authority, fresh-identity creation, and failure/retry integration; I found no additional production-code defect to request in this follow-up.

Public-material finding — P2

The sole PR commit's Signed-off-by footer exposes an internal deployment hostname and deployment-specific agent identifier in this public repository. This is commit metadata, so it cannot be attached to a source-diff line. Please replace the internal deployment-specific attribution address with the actual contributor's approved public identity, preserving truthful authorship and obtaining a valid DCO certification; do not invent a replacement sign-off. I am deliberately not repeating the identifier here. This is a publication/privacy finding, not evidence of an exposed secret credential.

Optional description correction

The summary still says the clone “starts stopped,” but the current stacked creation flow explicitly starts the fresh identity (AgentCreateDialog.tsx:138–150), and the new component test expects that start. The attached dialog screenshot correctly says “Create and start.” Update the summary to match; this is not a request to undo the base branch's create-and-start behavior.

Evidence and limits

• Inspected the public description, both attached screenshots, changed source/configuration/fixtures, and PR commit message. The screenshots show fixture data; no additional public-material exposure was identified there.
• Pinned source snapshot: 1,622 hash-verified blobs; the review covered the feature diff and relevant callers, not every file in that snapshot. No dirty checkout inputs. No local tests, builds, app launches, PR-code execution, or live-library/credential access. Success/cancel and error/retry paths were traced in source; browser/native keyboard-focus behavior and real creation/import remain unverified by this review.
• One read-only hosted CI snapshot: run 36488548081 reports success for the automatic Linux lanes and all six browser shards; Windows was skipped. Chromium shard 1 logs bind checkout 4721be9a6c6365c554a99929714f4a4442c9a8e5 to the reviewed head/base and report 140 passes, including all 14 agent-control cases. That shard reports 10.4 minutes wall time; rounded per-test log durations sum to 1,200.0 seconds, with the slowest case at 41.4 seconds and slowest file at 162.1 seconds. This is hosted fixture evidence, not a local run, before/after performance comparison, or native acceptance.

This non-blocking COMMENT is not an approval or merge authorization.

[loganj]

Thanks. Responses to the 22:08 review:

• Description: fixed. The summary now says Create and start makes a new identity and starts only that agent. Clone never imports or starts the old one.
• Sign-off address: I kept it, because it is the repository's existing convention for agent commits, not something specific to this PR. main already has about 150 Signed-off-by trailers in the same agent-address format, 21 of them mine. The DCO check accepts them. Changing the attribution identity is a policy decision for the maintainer. If Logan chooses a different public identity, I will rewrite the whole stack in one pass.