[Bug] buzz-acp loses channel sessions on restart and creates duplicate Codex cloud threads

Summary

buzz-acp keeps its channel → ACP session mapping only in process memory. Restarting a managed Codex agent or Buzz Desktop therefore loses that mapping. The next event in the same channel calls session/new; codex-acp maps that request to Codex threadStart, creating another cloud-backed conversation instead of resuming the existing one.

Those conversations appear in the user's personal Codex/ChatGPT history. On an affected macOS installation, Recents contains many separate conversations beginning with:

[Base] You are operating inside the Buzz platform — a Nostr-based messaging platform for human-agent collaboration...

This is distinct from eager pool fan-out (#2631), history isolation (#2660), and session-title plumbing (#2334 / #3028 / agentclientprotocol/codex-acp#338). Those issues can reduce the number of initial sessions, hide them in a separate store, or name them correctly, but none restores channel-session continuity after a process restart.

Environment

Official Buzz Desktop 0.5.7, downloaded from buzz.xyz
macOS, arm64
Managed Codex agents
codex-acp 1.1.10, built from exact PR fix(desktop): kill WebSocket flood and fix Markdown <p><div> nesting #368 head 71d77db55a53c915cd9dce4247271f0c5d5f6054

The network/root changes in codex-acp #368 are unrelated to session creation; the same lifecycle is present in the released adapter path.

Observed behavior

After repeated managed-agent/Desktop starts, the user's Codex/ChatGPT Recents list contains many separate Buzz-created conversations. The conversations are cloud-backed Codex threads, not merely local Buzz Activity rows.

The current title is the shared [Base] prompt because the installed codex-acp does not yet consume Buzz's _meta.sessionTitle; agentclientprotocol/codex-acp#338 addresses that cosmetic naming problem. Correct titles would make the rows readable but would not stop duplicate thread creation.

Source-level cause

At tag desktop-v0.5.7:

crates/buzz-acp/src/pool.rs stores per-channel sessions in SessionState.sessions, an in-memory HashMap<Uuid, String>.
During prompt dispatch, a missing channel entry calls create_session_and_apply_model(...), which calls session_new_full(...) and inserts the returned ID only into that in-memory map.
No persisted channel-session receipt is loaded at harness startup, and the normal restart path does not call session/resume or session/load.
In codex-acp 1.1.10, CodexAcpClient.newSession() calls codexClient.threadStart(...). Both resumeSession() and loadSession() already exist and call threadResume(...), but Buzz does not use them to restore channel continuity after restart.

This behavior is also acknowledged by open Buzz PR #4721, whose body says:

The harness starts a new session after a process restart, so this does not attempt same-session continuity across restarts; that would be a separate resume feature.

Steps to reproduce

Start a Codex-backed managed agent in Buzz Desktop.
Mention it in a channel and let it complete a turn.
Confirm the resulting Codex thread appears in Codex/ChatGPT history.
Stop and restart that same managed agent, or quit and relaunch Buzz Desktop.
Mention the same agent again in the same channel.
Observe that Buzz creates a new Codex thread rather than resuming the previous channel session.
Repeat the restart and observe another new history entry.

Expected behavior

For the same relay, managed-agent identity, and channel, restarting the harness should resume the existing valid ACP/Codex session. A new cloud thread should be created only when:

no prior session exists;
the user explicitly requests rotation;
the adapter does not support resume; or
resume fails validation and Buzz deliberately falls back to a new session.

Actual behavior

The mapping disappears whenever the harness process exits. The next accepted event creates a new cloud-backed Codex conversation, polluting personal history and losing full-session continuity.

Suggested direction

Persist a versioned session receipt keyed by at least relay/community, managed-agent pubkey, and channel ID.
On startup or first use, validate the receipt and call ACP session/resume when the adapter advertises resume support.
Fall back to session/new only when no valid receipt exists or resume fails.
Invalidate persisted receipts on explicit !rotate, agent removal, identity change, or incompatible configuration changes.
Keep history isolation (Isolate Buzz-managed Codex sessions from the user's Codex sidebar and Remote project list #2660 / fix: active community rail, Codex nest isolation, ecosystem docs #2710) and session naming (codex-acp#338) as complementary fixes, not substitutes for continuity.
Add an integration test: complete a channel turn, restart the harness, dispatch another turn in the same channel, and assert the adapter receives session/resume with the original session ID and no second session/new.

Related work

[Bug] Default parallelism 24 eagerly spawns large Codex ACP pools, consuming ~14 GB and flooding Recents #2631 — eager parallel pools consume resources and flood Recents
Isolate Buzz-managed Codex sessions from the user's Codex sidebar and Remote project list #2660 — isolate Buzz-managed sessions from personal Codex/ChatGPT history
fix: active community rail, Codex nest isolation, ecosystem docs #2710 — proposed nested CODEX_HOME isolation
Managed ACP sessions show base prompt as title in Codex (and other harness UIs) #2334 / feat(acp): title agent sessions from the agent and channel name #3028 — Buzz-side session-title plumbing
feat: name Codex threads from session/new _meta.sessionTitle agentclientprotocol/codex-acp#338 — consume _meta.sessionTitle
feat(acp): live per-channel MCP control via session/resume #4480 — demonstrates existing ACP session/resume support for live reconfiguration
fix(acp): persist session identity receipts for both runtimes #4721 — persists identity receipts but explicitly excludes restart continuity

A screenshot of the affected Recents list is available, showing many [Base] You are operating inside the Buzz platform... conversations.

Additional 0.5.7 evidence: every duplicate thread also repeats the full Buzz prompt on every turn

The affected official Buzz Desktop 0.5.7 installation shows that these are not merely duplicate cloud threads with an unfortunate title. Inside each Codex conversation, every Buzz turn begins again with the complete:

[Base]
You are operating inside the Buzz platform...

followed by the Buzz CLI guide and the remaining platform instructions. The same large block appears many times within a single Codex thread.

This matches the 0.5.7 source path:

crates/buzz-acp/src/queue.rs::format_prompt() runs for every dispatched event.
When has_system_prompt_support == false, it prepends [Base], [System], team instructions, agent core memory, and channel canvas to that turn's ordinary user-message blocks.
The current Codex ACP compatibility path takes this legacy framing path, so the static instructions are not installed once at session creation; they are reinserted on every turn.
The dynamic thread-context block can additionally repeat prior channel messages already present in the underlying Codex conversation.

This per-turn amplification is tracked separately in #3242. The relationship is multiplicative:

restart/session-loss bug (#5342)
  → creates multiple cloud-backed Codex threads

legacy repeated-context bug (#3242)
  → fills every one of those threads with repeated full Base/System/context payloads

Fixing restart continuity prevents unnecessary additional threads but does not remove repeated prompt injection inside the resumed thread. Conversely, fixing #3242 reduces per-turn duplication but does not stop new cloud threads after a harness restart. Both fixes are required.

This also has an instruction-authority consequence: on the ACP-v1 compatibility path, text labeled [System] is transported inside an ordinary user prompt; the label does not give it protocol-level system/developer precedence.

No secret values are included in this report. The displayed base prompt names authentication environment variables but does not reveal their values.

Fresh supervised restart evidence with the persistent-prompt candidates

A supervised macOS acceptance of #5386 together with agentclientprotocol/codex-acp#379 reproduced this restart-continuity bug structurally:

main Codex session before restart: 019fe5c1-cb8f-74b0-8e58-b726541d641e
main Codex session after restart: 019fe5de-3f13-77c1-aa0e-a2a07b3eb1dd
the pre-restart rollout remained unchanged;
a completely new main Codex session was created;
apparent memory of a pre-restart token came from Buzz reconstructing DM/channel context, not from resuming the old Codex session.

The test also cleanly separates #5342 from the persistent-prompt work:

the restarted session received the static Buzz Base/System material exactly once as developer instructions;
its ordinary post-restart user prompt contained zero repeated static instructions;
therefore feat(acp): negotiate persistent system prompts #5386/refactor(desktop): standardize UI with shadcn components #379 address static prompt repetition but do not restore channel-session continuity across a Buzz restart.

No identity, credential, or private message content is included in this evidence.

Reduce repeated ACP session context (#5423)

One host-side observation that may make this recoverable without new protocol work: buzz-acp never calls session/load for any runtime, including runtimes that advertise support for it.

Searching the tree at dc2dbfe, session/load, loadSession, and sessionCapabilities appear nowhere in crates/buzz-acp/. The only hits repo-wide are buzz-agent declaring its own floor and unrelated ONNX loading in buzz-voice:

crates/buzz-agent/src/lib.rs:312    "loadSession": false,
crates/buzz-agent/README.md:338     Not load-able. No `session/load`. We advertise `loadSession: false`.

At least one runtime advertises the opposite. From the harness log pasted in #3768:

"agentCapabilities":{"loadSession":true,"promptCapabilities":{"image":true},
"sessionCapabilities":{"fork":{},"list":{},"resume":{}}}

So the in-process mapping is not the only constraint. For an agent that advertises loadSession, the host could persist the channel to session mapping and call session/load on restart instead of session/new.

That does not fix Codex on its own, since codex-acp would need its own support. But the host-side change is a prerequisite either way, and it resolves the duplicate-conversation symptom for any runtime that already advertises the capability. The host reads the initialize response already, so agentCapabilities.loadSession is available at the point the decision gets made.

Reduce repeated ACP session context (block#5423)

@bmbouter

We hit the same root cause with Claude rather than Codex, on always-on server agents instead of Desktop. One more data point for prioritizing session/load support.

Setup: about 15 buzz-acp agents running headless on k3s and in OpenShell sandboxes. Each runs @agentclientprotocol/claude-agent-acp 0.84.0 under buzz-acp built from block/buzz 16eb0b66 (plus a small local --heartbeat-gate patch), with per-thread sessions.

What we see: every image roll, pod reschedule or sandbox move restarts buzz-acp. After that, a reply in any existing thread starts a fresh session that rereads the recent thread messages. The agent answers sensibly, but loses its tool context from earlier in the thread: files it read, commands it ran, decisions it made. On server deployments restarts are routine (we roll images several times a day), so long-running threads lose continuity often. We confirmed it after moving an agent between runtimes: asked in a two-week-old thread, it said plainly that it was a new session.

Why session/load would fix it for us: claude-agent-acp 0.84.0 implements loadSession and advertises loadSession: true in its agent capabilities, and its sessions persist on a volume that survives restarts. A small persisted thread-to-session map in buzz-acp's state dir, plus a session/load attempt before falling back to session/new, would restore continuity. +1 to the approach in the comment above.

Note: this comment was drafted by Claude, an AI assistant, working with Brian Bouterse (@bmbouter) and on his behalf. It is AI generated and human reviewed.

Navigation Menu

Repository navigation

[Bug] buzz-acp loses channel sessions on restart and creates duplicate Codex cloud threads #5342

Summary

Environment

Observed behavior

Source-level cause

Steps to reproduce

Expected behavior

Actual behavior

Suggested direction

Related work

Additional 0.5.7 evidence: every duplicate thread also repeats the full Buzz prompt on every turn

Fresh supervised restart evidence with the persistent-prompt candidates

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug] buzz-acp loses channel sessions on restart and creates duplicate Codex cloud threads #5342

Description

Summary

Environment

Observed behavior

Source-level cause

Steps to reproduce

Expected behavior

Actual behavior

Suggested direction

Related work

Activity

cmyk commented on Aug 8, 2026

Additional 0.5.7 evidence: every duplicate thread also repeats the full Buzz prompt on every turn

cmyk commented on Aug 9, 2026

Fresh supervised restart evidence with the persistent-prompt candidates

SHL0MS commented on Aug 13, 2026

bmbouter commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions