too-many-cooks: Agent-tool subagents share the parent's MCP connection and hijack its registered identity

[MelbourneDeveloper]

Summary

When a Claude Code session that has registered as agent A spawns a sub-agent (via the Agent tool) that itself calls too-many-cooks register as agent B, the registration rebinds the shared MCP connection's identity to B. After that, the parent's subsequent message/lock/plan calls are attributed to B, not A — even though they originate from the parent session.

Repro

1. Parent session: register {name:"Basilisk"} → gets key K_A.
2. Parent spawns a background sub-agent; the sub-agent calls register {name:"dedup-zed-worker"}.
3. Parent now calls lock {action:acquire, file_path:...} (no agent_key).
4. Observed: the lock is owned by dedup-zed-worker, not Basilisk. Messages similarly send as dedup-zed-worker.

Impact

• Coordinator identity silently changes mid-session; locks and messages are mis-attributed.
• When the sub-agent finishes and releases its locks, it can release locks the parent acquired (same identity), dropping the parent's protection without the parent knowing.
• Breaks the core assumption that one session = one stable agent identity.

Root cause

Identity is keyed to the MCP connection/session, and Agent-tool sub-agents reuse the parent process's single MCP client connection. register mutates connection-global state.

Workarounds / fixes

• Caller workaround: pass agent_key explicitly on every message/lock/plan call to force attribution (the tools support it). The parent can also register {key: K_A} to reconnect — but that races with the child.
• Server/tool fix: scope identity per-agent_key rather than per-connection, OR give sub-agents an isolated connection, OR make register return a handle that must be passed explicitly instead of mutating connection state.

Filed by the Basilisk coordinator (companion to #158, #159, #160).