Managed-agent UI updates visible persona record but runtime launches stale identity-backed duplicate

[JAFairweather]

Summary

Buzz Desktop can persist two records for one logical managed agent: a visible persona record with no agent pubkey and a hidden identity-backed record with the agent pubkey. Editing access settings in the only agent card shown by the UI updates the visible record, but the runtime continues to launch from the stale identity-backed record.

This makes the UI report Only me while the effective process still runs an old allowlist. A Desktop reboot preserves the split. It can also leave the agent stopped after reboot when the hidden identity-backed record has start_on_app_launch=false.

Environment

• Buzz Desktop: 0.5.3
• macOS
• Managed local Codex agents using buzz-acp

Steps to reproduce

1. Have a managed agent whose persisted state contains both:
   • a persona record with pubkey: ""; and
   • an identity-backed record with the agent's public key.
2. In Desktop, open the only visible card for that logical agent.
3. Set Who can talk to this agent to Only me and save.
4. Inspect the persisted records and the next buzz-acp starting log line.
5. Reboot Desktop and inspect the records/processes again.

Actual behavior

For Kerouac, the save produced this sequence:

• 20:54:08Z: the visible non-identity record was updated to respond_to: "owner-only".
• 20:54:12Z: Desktop updated/restarted the hidden identity-backed record, but it remained respond_to: "allowlist" with one allowed public key.
• The runtime launch line at 20:54:12Z reported respond_to=allowlist(1).

Sanitized persisted state:

[
  {
    "name": "Kerouac",
    "pubkey": "",
    "respond_to": "owner-only",
    "respond_to_allowlist": [],
    "start_on_app_launch": false,
    "updated_at": "2026-08-03T20:54:08.508674+00:00"
  },
  {
    "name": "Kerouac",
    "pubkey": "eb586b1e…",
    "respond_to": "allowlist",
    "respond_to_allowlist": ["0a8e0720…"],
    "start_on_app_launch": false,
    "last_started_at": "2026-08-03T20:54:12.316207+00:00",
    "updated_at": "2026-08-03T21:05:53.048151+00:00"
  }
]

After reboot at approximately 21:06Z:

• My Dude restarted with effective owner-only.
• waggle restarted with effective owner-only.
• Neil restarted with the stale effective allowlist(3), despite the visible record having been reset to owner-only.
• Dennis did not restart; its hidden identity-backed record remained allowlist(1) and start_on_app_launch=false.
• Kerouac did not restart; its hidden identity-backed record remained allowlist(1) and start_on_app_launch=false.
• The process table contained exactly three buzz-acp processes, matching My Dude, waggle, and Neil.

The mismatch is user-visible operationally: a message accepted by three sibling agents was rejected before wake/model dispatch for Kerouac because its effective hidden record still excluded the sender.

Expected behavior

• One canonical persisted record should represent each logical identity-backed managed agent.
• Changes made in the visible Desktop card should update the record used to launch the runtime.
• Access-policy and start-on-launch settings shown in the UI should match effective runtime settings after save and reboot.
• If legacy duplicate records exist, Desktop should reconcile/migrate them deterministically rather than continuing to launch stale configuration.

Additional notes

• Repeated UI saves and a full Desktop reboot did not repair the state.
• No configuration files were hand-edited.
• No Buzz core changes or local patches were installed.
• Auth tags and private material are intentionally omitted.

[JAFairweather]

Correction after tracing the current source model:

The keyless record and keyed record are not accidental duplicates. The source intentionally stores:

• a keyless, slug-addressed agent definition; and
• one or more keyed agent instances minted from that definition.

Definition behavioral defaults (respond_to, allowlist, parallelism) are explicitly copied to an instance at mint time only. Existing linked instances retain their spawn-time snapshot. Relevant source comments state that these fields are “copied onto instances at mint time only” and that spawn re-snapshot does not touch them.

This narrows the bug:

1. The Desktop surface presented the definition as the only visible Kerouac configuration, without clearly distinguishing it from the existing keyed Kerouac instance.
2. Saving Only me correctly updated the definition record, but did not update the already-minted instance that the runtime launches.
3. The keyed instance remained difficult or impossible to reach through the visible management surface, so the user could neither see nor change its effective allowlist(1) snapshot.
4. The same UI/model ambiguity applies to start_on_app_launch: the visible definition has this bookkeeping field false by construction, while the keyed instance owns the effective runtime setting.

The expected behavior should therefore not require collapsing definition and instance into one record. A valid fix could instead:

• clearly show definition defaults separately from each existing instance's effective settings;
• route “Who can talk to this agent?” edits made from an instance card to update_managed_agent for the keyed pubkey;
• expose each keyed instance's start/stop and start-on-launch controls; and
• warn that changing definition defaults affects future instances only when that is the intended action.

All timestamped runtime evidence in the original report remains valid. The interpretation “two records should be one canonical record” was incorrect and is superseded by this comment.