Isolate Buzz-managed Codex sessions from the user's Codex sidebar and Remote project list #2660

Activity

1. chessing234 commented on Jul 24, 2026

   

   chessing234

   on Jul 24, 2026

   Contributor

   More actions

   #2705
2. chessing234 commented on Jul 24, 2026

   

   chessing234

   on Jul 24, 2026

   Contributor

   More actions

   Fixed in #2710
3. chessing234 commented on Jul 24, 2026

   

   chessing234

   on Jul 24, 2026

   Contributor

   More actions

   Fixed in the open PR — managed Codex agents use nest CODEX_HOME.
4. Dirtywater97 commented on Jul 26, 2026

   

   Dirtywater97

   on Jul 26, 2026

   More actions

   Confirming this on Windows 11, and adding a wrinkle the original report does not cover: because Buzz sets no CODEX_HOME of its own, managed agents do not just land in the user's personal Codex home — they land in whatever Codex home happens to be inherited from the launching environment. On this machine that produced pollution in two separate stores.

   Environment

   • Windows 11 Pro 26200
   • codex-cli 0.145.0
   • @agentclientprotocol/codex-acp 1.1.7
   • 4 managed agents, Codex-backed until 25 Jul

   Store 1 — the user's personal Codex home

   C:\Users\matt\.codex\sessions — 33 rollout files stamped originator: buzz-acp, cwd: C:\Users\matt\.buzz:

   2026-07-24   4
   2026-07-25  29
   

   These interleave with the user's own Codex Desktop and codex-tui sessions in the same directory and the same picker.

   Store 2 — a different tool's Codex home

   %APPDATA%\orca\codex-runtime-home\home\sessions — 39 more originator: buzz-acp files, same cwd: C:\Users\matt\.buzz:

   2026-07-24   6
   2026-07-25  33
   

   That directory belongs to a different application, which isolates its own Codex runs by setting CODEX_HOME to a private folder. Buzz agent transcripts ended up inside it anyway, mixed in with 61 codex-tui and 61 Codex Desktop sessions belonging to that tool.

   Why this matters beyond sidebar noise

   The existing report frames this as Buzz sessions showing up where the user does not want them. The inheritance behaviour makes it sharper:

   1. The destination is non-deterministic. It depends on how Buzz Desktop was launched. The same install wrote to two different homes on two different days, with no user-visible setting involved.
   2. It crosses application boundaries. Buzz conversation content was written into another vendor's private state directory. That is a worse outcome than "cluttered sidebar," and no amount of user configuration in Buzz prevents it, because there is no setting to configure.
   3. The isolation pattern is proven and cheap. The other tool on this machine solves the identical problem with one environment variable at spawn — 169 sessions, zero leakage into ~/.codex. This is not a speculative design.

   On the fix

   #2710 has been open since 24 Jul with no review. The CODEX_HOME-at-spawn approach in that PR is the right shape and would have prevented both stores above. Worth noting for whoever picks it up: the fix needs to set CODEX_HOME explicitly rather than only defaulting when unset, since the failure mode here is an inherited value, not a missing one.

   Cleanup on the user side required identifying rollout files by their originator: buzz-acp stamp and archiving them individually — there is no built-in way to separate managed-agent sessions from personal ones once they are interleaved. Worth considering whether managed sessions should carry something more discoverable than an originator string.
5. Dirtywater97 commented on Jul 26, 2026

   

   Dirtywater97

   on Jul 26, 2026

   More actions

   Correction to my comment above — I need to retract the cross-application claim. It was my analysis error, not a Buzz behaviour.

   I reported managed-agent sessions appearing in two separate Codex homes. They are not two sets of files. Comparing them properly:

   • 33 of the 39 sessions share the same session_id, same byte content, same mtime/ctime, and same inode across both paths (st_nlink == 2, matching st_ino).

   The second directory is hardlinked to the user's real Codex home on this machine. One file, two directory entries. Buzz wrote to one location; the other path surfaces the same data by construction.

   The corrected finding:

   Managed-agent rollout files written:   39   (24 Jul: 6, 25 Jul: 33)
   Distinct files on disk:                39
   Codex homes actually written to:        1   (the user's personal ~/.codex)
   

   So please disregard the "crosses application boundaries" framing and the "72 files" figure in my earlier comment. Buzz did not write into another vendor's private state directory.

   What still stands, and is the actual reported bug:

   • Windows 11, codex-cli 0.145.0, codex-acp 1.1.7
   • 39 rollout files stamped originator: buzz-acp, cwd: C:\Users\matt\.buzz, interleaved with the user's own Codex Desktop and codex-tui sessions in the same picker
   • Separating them required filtering on the originator stamp and archiving individually; there is no built-in way to distinguish managed-agent sessions from personal ones

   My note on #2710 about setting CODEX_HOME unconditionally rather than only-when-unset was also predicated on the inheritance theory. That theory is unsupported by the evidence here — I have withdrawn it on the PR as well. Treat the nest-home approach in that PR as sound as written.

   Apologies for the noise on a report that was already accurate without it.
6. chessing234

   added 2 commits that reference this issue on Jul 29, 2026

   fix(desktop): isolate managed Codex sessions under the Buzz nest

   ...

   This issue will close once commit 49e178d is merged into the 'main' branch.

   49e178d

   fix(desktop): isolate managed Codex sessions under the Buzz nest

   ...

   This issue will close once commit 0be6a3d is merged into the 'main' branch.

   0be6a3d
7. GeneralJah215 commented on Aug 13, 2026

   

   GeneralJah215

   on Aug 13, 2026

   More actions

   Second independent Windows 11 confirmation, plus evidence the same gap applies to
   the Claude runtime — and a question about the two open PRs at the bottom.

   Provenance. First line of a session file found in the personal Codex history:

   {"type":"session_meta","payload":{"cwd":"C:\\Users\\james\\.buzz",
    "originator":"buzz-acp","cli_version":"0.145.0","source":"vscode", ...}}

   originator: buzz-acp is a per-file stamp, so attribution here is exact rather
   than inferred. Volume on this install: 178 files written under ~/.codex in a
   3-hour window with ~30 agents registered. The operator has been archiving them
   by hand out of their own chat list.

   Spawn path on this machine is %APPDATA%\Buzz\node-tools\codex-acp.cmd, a
   generated npm shim exec'ing
   node_modules/@agentclientprotocol/codex-acp/dist/index.js. Neither it nor its
   sibling claude-agent-acp.cmd mentions CODEX_HOME.

   Where the gap is in main

   CODEX_HOME appears twice, both read-only, in
   desktop/src-tauri/src/managed_agents/config_bridge/codex.rs — codex_config_path()
   reads the desktop's own env to render the user's config panel. It is never
   written to a child.

   spawn_agent_child in desktop/src-tauri/src/managed_agents/runtime.rs sets
   around forty child env vars and no agent-home var; the child otherwise inherits
   the parent env. The hook that would naturally carry it,
   default_agent_env() in crates/buzz-acp/src/config.rs, returns &[] for
   Codex — only Hermes has an entry today.

   The Claude runtime has the same shape. No CLAUDE_CONFIG_DIR is set at spawn
   either. On this machine ~/.claude/projects/C--Users-james--buzz/ — the slug for
   the Buzz agent cwd — holds 119 entries, 122 MB, sitting among 17 project
   folders of genuinely personal history. Sampled contents are unambiguously
   managed-agent turns ([Context] Scope: thread / Channel: ... / buzz messages send --reply-to ...). #4611 would close that side; flagging it here
   so the two are not solved in isolation. Caveat: unlike Codex there is no
   originator stamp on the Claude side, so I can confirm the directory is
   predominantly agent-authored but not that every file is.

   A workaround exists and is worth documenting even before a fix lands.
   CODEX_HOME is not in RESERVED_ENV_KEYS, and user env vars are written last in
   spawn_agent_child — the code comment says "Writing it last lets user-provided
   values win over every Buzz-set env written above". So CODEX_HOME can be set
   today through the persona / agent env-vars UI. It is undocumented, and it is the
   difference between a supported knob and a happy accident, which is worth
   clarifying either way.

   On the remedy — it is not a one-liner, and the PRs may already know this.
   CODEX_HOME roots auth.json, config.toml and the MCP/provider config, not
   just sessions/. Pointing it at an empty directory leaves every existing
   Codex-backed agent logged out and stripped of its provider config, failing in a
   way that reads as an auth bug rather than a migration step. On this install the
   user's config.toml carries a local MCP server, thirteen plugins and a project
   list — all of which have to arrive in the new home or agents quietly lose their
   tools rather than erroring.

   Worth deciding explicitly: how auth.json is seeded and refreshed when the user
   re-runs codex login against their personal home; whether the config panel in
   config_bridge/codex.rs keeps reading the personal home (now inaccurate) or
   follows the agent's; per-install vs per-agent granularity; and migration, since a
   spawn-time fix moves nothing already written. The originator: buzz-acp stamp
   makes a documented cleanup query easy for the Codex side.

   Scope of the claim, stated precisely. Established: agent transcripts are
   written into the operator's personal Codex and Claude stores, and those
   transcripts contain channel context, thread history and tool output. Not
   established: any data leaving the machine. Both stores here sit on a non-synced
   local drive. The concern is that the destination is a store users reasonably
   treat as personal and may later sync, share, or point another tool at — not that
   anything has been exfiltrated.

   The question. #2710 and #2711 both appear to implement this and have been
   open without review since 24 July. Is either the direction you want? If one is
   close, that seems more useful than another patch from outside. Happy to test
   either against this setup — 30 agents, Windows 11, both Codex and Claude runtimes
   — and report back, if a build or a branch is easier for you than a review round.