Bug Description

After restoring a session that involved transfer_task (sub-agent delegation), all subsequent prompts fail with:

all models failed: error receiving from stream: POST "https://ai-backend-service-stage.docker.com/proxy/v1/messages?beta=true": 400 Bad Request
{"type":"error","error":{"type":"invalid_request_error","message":"messages.26.content.0: unexpected `tool_use_id` found in `tool_result` blocks: tooluse_PDwaDa9qmwIyg9WUMFXlez. Each `tool_result` block must have a corresponding `tool_use` block in the previous message."}}

This is a recurrence of #1644. The root cause identified in #1738 (PersistentRuntime writing sub-agent streaming messages to the parent session) was never fixed.

Root Cause Analysis

There are two layers of bugs. The first corrupts the session state, and the second fails to protect against the corruption.

Layer 1: PersistentRuntime persists sub-agent streaming messages to parent session (#1738 — still unfixed)

In pkg/runtime/persistent_runtime.go, the handleEvent method skips persistence for sub-sessions:

if sess.IsSubSession() {
    return
}

However, sess is always the parent session. When handleTaskTransfer runs a sub-agent via r.RunStream(ctx, child), the child's streaming events (AgentChoiceEvent, AgentChoiceReasoningEvent) are forwarded to the parent's event channel. Since the parent is not a sub-session, the guard does not trigger, and persistStreamingContent writes the sub-agent's assistant messages directly into the parent session's session_items.

After a task transfer, the parent session's database state looks like:

position | agent_name       | role      | notes
---------|------------------|-----------|----------------------------------
N        | root             | assistant | has transfer_task tool_use (ID: X)
N+1      | sub-agent        | assistant | ← ORPHAN: written by streaming persistence
N+2      | sub-agent        | assistant | ← ORPHAN: written by streaming persistence
...
N+k      | (subsession)     |           | sub-session reference
N+k+1    | root             | tool      | tool_result for transfer_task (ID: X)

On session restore, GetMessages() includes all message items (skipping sub-session items). The parent session now contains sub-agent assistant messages with their own tool_use blocks that have no corresponding tool_result messages in the parent context.

Layer 2: Beta converter lacks orphan tool_result protection

The non-beta convertMessages (client.go) has a pendingAssistantToolUse flag that only includes tool_result user messages when they immediately follow an assistant message with tool_use blocks. Orphan tool results are silently dropped.

The beta convertBetaMessages (beta_converter.go) has no such guard. Every tool role message is unconditionally converted and sent to the API. When the corrupted session history contains orphan sub-agent tool_use/tool_result pairs, they pass straight through to Anthropic.

Layer 2b: Forward-only sequencing validation

validateSequencing (client.go) only checks the forward direction: each assistant tool_use must have a matching tool_result in the next user message. It does not check the reverse: each tool_result must reference a tool_use in the immediately preceding assistant message. So orphan tool_result blocks pass validation.

Layer 2c: repairSequencing can worsen partial tool_result mismatches

When an assistant message has tool_use IDs {A, B} and the next user message only has tool_result for A, repairSequencing inserts a synthetic user message with tool_result for B between the assistant and the existing user message:

assistant(tool_use: A, B)
synthetic_user(tool_result: B)   ← inserted by repair
user(tool_result: A)             ← A's "previous message" is now synthetic_user, not assistant → ERROR

Steps to Reproduce

1. Configure a multi-agent setup with transfer_task / sub_agents
2. Start a session and trigger a task transfer to a sub-agent
3. Let the sub-agent execute tool calls and complete
4. End the session
5. Restore the session with --session <id>
6. Send any new prompt

Expected Behavior

Restored sessions should work correctly. Sub-agent messages should only exist in the sub-session, not in the parent session.

Affected Code

Suggested Fixes

1. persistent_runtime.go: Filter AgentChoiceEvent / AgentChoiceReasoningEvent by comparing e.AgentName against the parent session's current agent, or add a SessionID field to streaming events and filter by session ID.
2. beta_converter.go: Add pendingAssistantToolUse guard matching the non-beta convertMessages behavior.
3. client.go validateSequencing: Add reverse validation — check that every tool_result references a tool_use in the immediately preceding assistant message.
4. client.go repairSequencing: When partial tool_results exist, merge synthetic tool_results into the existing next user message instead of inserting a separate synthetic message before it.

Related Issues

• unexpected tool_use_id found in tool_result blocks #1644 — same error, closed without identifying the PersistentRuntime root cause
• PersistentRuntime writes sub-agent streaming messages to parent session, corrupting conversation history #1738 — correctly identified the PersistentRuntime corruption, closed but fix was never applied

Environment

• OS: macOS (arm64)
• Version: built from main (HEAD at v1.30.1)
• Session ID: 17cebf40-7cdb-4463-936d-916feedc2d4e
• Agents definition: multi-agent setup with sub_agents and transfer_task