[Bug] Code review subagent spawns subagents

The "was convinced it was the top-level Claude Code process" behavior is a known failure mode in nested subagent spawns. When a subagent uses the Agent tool itself, it inherits a context that includes the same harness scaffolding as the top-level session -- including system prompts that describe "you are Claude Code" without qualification -- so the spawned subagent has no clean signal that it is a worker, not the root session.

A few things that might help:

On the token exhaustion -> zombie state: the subagent remaining in the list after the parent account hit its limit, and the "Task is not running (status: completed)" error on Stop Task, suggests the lifecycle state machine did not handle the quota-exhaustion path cleanly. The task completed (from the subagent's perspective -- it finished what it could before running out) but the parent could not receive the completion event because it was also quota-limited. Worth flagging the specific version (2.1.212) in the bug title since this may be a regression.

On the recursive spawn: you might be able to work around this until Anthropic fixes the harness-identity injection by adding a CLAUDE.md or system prompt note like "You are a subagent. Do not spawn further subagents unless explicitly instructed." It is a workaround, not a fix, but it can reduce the depth of accidental recursion.

The deeper fix probably requires the harness to inject a subagent-depth counter and a default rule that prevents recursion past depth 1 unless explicitly overridden per task.

This looks like two separate state problems interacting: subagent identity/depth is not explicit enough, and completed/quota-exhausted child state is not reconciled cleanly into the parent list.

For recursive review agents, I would want every child to carry parent id, depth, allowed delegation flag, purpose, model/profile, token/quota state, and terminal condition. The default for a code-review subagent should likely be no further subagent spawning unless the parent task explicitly grants it. For the zombie list case, Stop Task should be reading a terminal child record and showing completed/failed/quota-exhausted/orphaned instead of trying to stop a run that is already terminal.

I maintain Better Agent (https://github.com/ofekron/better-agent), where worker identity, parent routing, and terminal-state reconciliation are core pieces of multi-agent visibility. If useful, a star helps other agent-runtime builders find the project.

The identity confusion piece is the part worth pulling on. If a subagent starts convinced it is the top-level process, that explains the recursive spawning -- it thought it was the orchestrator and acted like it. The question is what signal (or absence of signal) caused that confusion: missing system prompt context, an incorrect CLAUDE_SUBAGENT env variable, or something in how the subagent's initial context was assembled.

The clean-exit / stop-task inconsistency you hit at the end (completed status but still requiring Stop Task) is a different failure mode but possibly related: if the subagent's lifecycle events were mis-attributed to the parent session (similar to the session_id inheritance issue in #76727), the task state machine could have landed in an inconsistent state.

A few questions that might help narrow it down:

• Did the subagent get a distinct session_id in its hook payloads, or was it carrying the parent's?
• Was the /code-review agent invoked with an explicit Agent tool call or via the sub-agent shorthand?
• The token-exhaustion context you mention -- was there a compaction event mid-session before the subagent was spawned?

The "completed but not stoppable" behavior sounds like it could reproduce in isolation. If you can repro it without the prior token-reset event it would help separate the state management bug from any token-accounting side effects.