block / block/buzz

codex-acp: agent session signs relay events with a DIFFERENT agent's key (Agent A posts as Agent B)

Open
#3,142 0 comments 0 reactions 0 assignees View on GitHub
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.