codex-acp: agent session signs relay events with a DIFFERENT agent's key (Agent A posts as Agent B)
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
## Summary
An agent running on the **Codex harness** composes and sends its own replies, but the resulting relay events are **signed with a different managed agent's key** — in our case, agent "Snoop" (Codex harness) consistently published under agent "Wrench"'s pubkey (Wrench runs on the Claude harness on the same machine). The agent-store config binds each agent to its own key correctly; the wrong key appears at **runtime provisioning** of the Codex harness session.
This is an identity-integrity issue: with owner-attested identities, Agent A silently publishing as Agent B breaks the audit trail the identity system exists to provide.
## Environment
- Buzz Desktop **v0.4.24**, macOS arm64 (Block-hosted community, communities.buzz.xyz)
- codex-acp **1.1.5** (bundled `@openai/codex` codex-cli **0.144.6**)
- Affected agent: Codex harness, model `gpt-5.6-sol`
- Bystander agent: Claude harness, running simultaneously, same machine
## Evidence chain (verified end-to-end)
1. Mention posted to Agent A ("Snoop", pubkey `90f3e24c…`) in a channel.
2. Agent A's **own Codex session rollout log** shows it composing the reply and sending it via the CLI:
- `[AGENT MSG] "I'm using the Buzz CLI skill to reply in the exact triggering thread…"`
- `[TOOL CALL] buzz messages send --channel … --reply-to …`
- `[TOOL OUT] {"accepted":true,"event_id":"78285c710b4b93c98…"}`
3. That exact event on the relay (`78285c71…`) is signed by **Agent B's pubkey** (`8492a961…`, "Wrench") — not Agent A's.
4. `managed-agents.json` binds Agent A to its **own** identity (its auth_tag matches Agent A's historical posts). Config is correct.
5. Inspecting the running harness process environment showed it carried **Agent B's** `BUZZ_PRIVATE_KEY` / `BUZZ_AUTH_TAG` — i.e. the Codex session was provisioned with the wrong agent's signing identity.
## Controls (why we're confident it's the Codex-harness path)
- Same machine, same community: agents on **Claude** harness and **Goose** harness all sign correctly as themselves.
- The affected agent itself previously ran on the Claude harness and signed correctly for days (extensive history under `90f3e24c…`). The mis-signing began exactly at the switch to the Codex harness.
- Recreating the agent and running it on the **Goose** harness → signs correctly with its own (new) key immediately.
- Not model-related: the session runs `gpt-5.6-sol` fine (reasoning, tool calls, `task_complete`).
## Secondary bug (same integration, likely worth its
Contributor guide
Research direction
Start at Codex harness runtime provisioning and inspect how managed-agents.json values become the session's BUZZ_PRIVATE_KEY and BUZZ_AUTH_TAG. Reproduce with two simultaneous agents, then verify that the relay event's signing key matches the provisioned agent identity rather than the bystander; the issue's evidence chain provides the expected comparison.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authentication, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 42/100