[BUG] tmux/pane-backed teammates have no agent_id/agent_type in hook payloads — indistinguishable from the main agent (re-file of #54785, still present on 2.1.233)

What happened

Hook events fired by tmux/pane-backed teammates carry no agent identity. On v2.1.233, a tmux teammate's PreToolUse stdin contains exactly:

cwd, effort, hook_event_name, permission_mode, session_id, tool_input, tool_name, tool_use_id, transcript_path

— no agent_id, no agent_type, no team or parent identity of any kind. The payload is structurally indistinguishable from a user-launched main session.

This is asymmetric with every other agent transport since v2.1.69 shipped agent_id/agent_type on subagent hook events (#14859, closed as shipped):

| Agent | identity in hook payload |
|---|---|
| In-process subagent (Task tool) | ✅ agent_id + agent_type |
| In-process teammate (named agent) | ✅ agent_id = member@team |
| Worker fork | ✅ agent_id + agent_type: "fork" |
| Main agent | (absent by design — absence means main) |
| tmux/pane teammate | ❌ nothing |

Because "no agent_id" is the de-facto contract for "this is the main agent", the missing field is worse than an inconvenience: tmux teammates positively identify as the main agent to every hook. Policy hooks that treat the main agent differently (in our case: forcing long Bash calls to background for the main agent only) silently misapply main-agent rules to tmux teammates, and nothing in the payload allows a workaround.

Repro (v2.1.233)

1. Project with teammateMode: "tmux" and a PreToolUse hook that dumps its raw stdin to a file
2. Launch a lead inside tmux, have it spawn a teammate, teammate runs any Bash command
3. Inspect the dump for the teammate's tool call: no agent_id, no agent_type

Verified twice independently on 2.1.233 (latest at time of writing), Ubuntu Linux.

Expected

The same contract as in-process teammates: agent_id (e.g. name@team) and agent_type on hook events fired by tmux-backed teammates.

Context

Re-file of #54785, which was bot-closed as not_planned for inactivity (2026-05-31) and locked (2026-08-01) — the close message asks to file a new issue if still relevant. It is. Related: #82665, where TeammateIdle events fired for worker-fork idles have the same no-identity problem.

🤖 Filed by Claude (Fable 5) on Clément's behalf — repro design, live verification on 2.1.233, and write-up by Claude. (Co)-Authored-By Claude <noreply@anthropic.com>