[Bug] advisor tool blocks subagents for 6 minutes, then returns execution_time_exceeded (4 of 4 review agents in one session)

What happens

Inside subagents, the advisor server tool regularly ends with execution_time_exceeded after blocking the agent for six minutes. The agent gets no advice, and the turn has cost six minutes of wall clock for nothing.

In one long session I counted every advisor call in the subagent transcripts:

| Where | Advisor calls | execution_time_exceeded |
|---|---|---|
| Main thread | 3 | 0 |
| Subagents (10 transcripts that called it) | 19 | 4 |

All four failures have the same shape. The gap between the transcript entry before the call and the error entry is 360 s every time:

| Agent kind | Context at the call (input + cache tokens) | Previous entry | Error entry | Gap |
|---|---|---|---|---|
| plan review | 319,525 | 01:50:05.459Z | 01:56:05.966Z | 360.5 s |
| code review | 358,226 | 23:35:54.370Z | 23:41:54.859Z | 360.5 s |
| code review | 320,655 | 03:54:29.866Z | 04:00:30.616Z | 360.8 s |
| code review | 92,032 | 05:39:31.773Z | 05:45:32.140Z | 360.4 s |

The result block as written to the transcript:

{"type":"advisor_tool_result","tool_use_id":"srvtoolu_…","content":{"type":"advisor_tool_result_error","error_code":"execution_time_exceeded"}}

It is not only a large-context problem: the fourth failure happened at 92k tokens. It does follow the kind of work: every review-type agent run in the session hit it (4 of 4 runs: three code reviews and one plan review; 4 of their 7 advisor calls failed, each made right before writing findings), while research and implementation agents did not fail once (0 of 12 calls).

Why it hurts

• Six minutes of dead time per failure, with nothing shown while it runs. Four failures in one session is 24 minutes.
• The agent's own summary then says "advisor pass timed out" and carries on unreviewed, so the caller cannot tell a reviewed result from an unreviewed one unless it reads the text.
• The whole transcript is forwarded and billed for a call that returns nothing.

What I expected

Any of these would fix the practical problem:

1. A way to set the advisor's time limit, or a shorter default with a clear error, so a failure costs seconds and not six minutes.
2. Partial output returned when the limit is hit, if the advisor had produced any.
3. A setting to turn the advisor off for subagents only (the main thread works: 3 of 3 here).
4. A visible status while the call is in flight, including in background agents.

Environment

• Claude Code 2.1.293, Windows 11
• Main model Opus (1M context), "advisorModel": "opus" in settings
• Subagents on claude-opus-5-5, spawned with the Agent tool, running in the background

Related

#68063 reported the same error code and was closed automatically as a duplicate of #56922, which is about token-limit alerts and is itself closed. #67411 covered the advisor latching off after one failure. I found no open issue for the timeout itself.