Chat identity does not map to a process: chat_who names and tmux sessions do not correspond

[zaphodis42]

From the 2026-07-27 #pixelagents1 session with 6 concurrent agents.

What happens

$ chat_who
Online: codex, agy, claude-zai, opencode-codex, opencode, claude

$ tmux ls
agentchattr-agy          agentchattr-claude-2   agentchattr-claude-zai
agentchattr-codex        agentchattr-opencode   agentchattr-opencode-2

Six names, six sessions, no reliable correspondence. There are two opencode processes; there is a chat name (opencode-codex) matching no session; the -2 suffixes show slot renaming has already happened more than once.

Why it matters

Coordination is done by @mention. When a coordinator posts "@OpenCode, you are queued behind agy on bin/run-agent", it cannot determine which of the two opencode processes read it, or whether both did.

Two workers acting on one directive is precisely what a write lease exists to prevent — but a lease scopes paths, not identity, so the lease protocol cannot detect this class of collision at all.

It also produced a real near-miss: claude-zai posted two messages issuing overseer directives under the mistaken belief that it held the overseer seat, including "accepting" another agent's evidence. It caught and retracted this itself within minutes and had touched no files — but the failure mode is a second agent exercising apparent authority it does not have.

Suggested fix

wrapper.py already knows the tmux session name it launches into (wrapper_unix.py, session_name). Register it as agent metadata at connect time and surface it in chat_who:

Online:
  claude        (tmux: agentchattr-claude-2,  cwd: /home/dexter/workspace/orkestr8)
  opencode      (tmux: agentchattr-opencode)
  opencode-codex(tmux: agentchattr-opencode-2)

Adding cwd is nearly free at the same point and would have caught a second problem the same day (see the wrapper-cwd issue).

That single line turns "who am I actually talking to" from guesswork into a lookup, and would let a coordinator ask a specific worker to confirm its own session name when granting a lease.

[zaphodis42]

Adding the mechanism, reported first-hand by the agent it happened to (claude-zai, #pixelagents1 msg 266). The original report was a coordinator-side observation; this is the causal chain, and it makes the incident look close to inevitable rather than careless.

The chain

1. The MCP server instructions tell every Anthropic-family instance to use base name claude. Verbatim: "All Anthropic products (Claude Code, claude-cli, etc.) → base: claude". Two Anthropic-family instances were live in the same channel (claude = claude-opus-5, claude-zai = glm-5.2 on the .claude-zai route, launched via claude-zai-launcher.sh).
2. So on first read, the second instance saw messages from "claude" and reasonably concluded they were its own, from a prior session. In its words: "a mistake the instruction actively nudges you toward."
3. The server slot-renamed it silently — claude → claude-zai — without rejecting the send or confirming the new name.
4. chat_send returns only Sent (id=…) — no attributed sender. So a renamed agent has no way to learn its own identity from the API. claude-zai discovered its real name only by reading its own posts back.

Between steps 3 and 4 there is no point at which the agent is told who it is.

What it cost

Two messages issuing coordinator-level directives under a mistaken belief about which seat the agent held — including "accepting" another agent's evidence, which was not its call. It self-detected, retracted both specifically, and had touched no files, so there was no damage. But the failure mode is a second agent exercising apparent authority it does not have, and nothing in the system would have stopped it.

Fixes, cheapest first (the agent's own ranking)

1. chat_send should return the attributed sender, or confirm it on first send. "The mix-up is impossible if message one says 'sent as claude-zai'." This is the smallest change and it closes the loop entirely — the agent finds out at the first thing it does.
2. The wrapper should inject the real slot name into the agent's system prompt — e.g. "You are claude-zai, slot 2; claude is a different instance." Then the agent knows rather than inferring from a generic rule. wrapper.py already knows the slot at launch.
3. UI mitigation: the @claude and @claude-zai pills are adjacent and near-identical in the channel header. Colour or prefix differentiation is a real mitigation for humans and for agents reading the rendered view.

Note on the base-name instruction itself

The instruction is correct for the single-instance case and actively misleading for the multi-instance case, which is the case this project runs in. It already anticipates renaming — "the server renames slot 1" — but tells the agent to discover this reactively, by having a send rejected. In practice the send was not rejected; it was silently reattributed, so the documented discovery path never triggered.

Worth considering whether the instruction should say: do not assume messages from your base name are yours; confirm your attributed identity before acting on channel history.