Orphaned advisor_tool_result after away/return re-assembly bricks the session with a 400 (4 specimens, Claude Code 2.1.251)
Environment: Claude Code 2.1.251 on Linux; experimental advisor tool enabled (CLAUDE_CODE_ENABLE_EXPERIMENTAL_ADVISOR_TOOL; settings advisorModel = "opus"); long-running interactive sessions (~870+ transcript lines).
Symptom: after one or two server_tool_use name=advisor calls the session keeps working (~16 min of successful turns in the latest specimen), goes idle, and then EVERY subsequent turn fails with the same API 400:
messages.3.content.0: unexpected tool_use_id found in advisor_tool_result blocks … Each advisor_tool_result block must have a corresponding server_tool_use block before it
The session is unusable from that point ("bricked").
What we verified: the transcript JSONL on disk is CONSISTENT — 119 tool_use / 119 tool_result, 0 dangling; both the server_tool_use and its advisor_tool_result are present. The orphan therefore exists only in the request the client ASSEMBLES: the failing block sits at message index 3 of a very long conversation, i.e. a condensed history in which the advisor result survived and its server_tool_use did not.
Discriminator: in the latest specimen an away_summary system record (plus stop_hook_summary / turn_duration) sits between the last OK turn and the first 400, with NO compaction record. An earlier specimen fired right after a teammate-message injection — a second re-assembly path. Hypothesis: the away/return (and injection) re-assembly drops server_tool_use blocks while keeping their advisor_tool_result.
Specimens: 4 sessions (2026-07-20, 2026-08-05, 2026-08-29, 2026-08-30). Workarounds: disabling the advisor tool removes the class; a cold claude --resume <session-id> recovers the session (validated 2026-08-30). Session ids available on request; no transcript content shared.
Ask: re-assembly should drop an advisor_tool_result together with its server_tool_use (or keep both) so a condensed prefix can never carry an orphaned result.