Managed Agents: intermittent 400 "does not match any agent.tool_use event" confirming a tool_use on a non-primary session_thread_id

[nadavshohat]

Summary

Using a self-hosted EnvironmentWorker with multiagent enabled, confirming a tool_result for a tool that ran inside a non-primary session_thread_id (a sub-thread) intermittently fails with a 400:

Error code: 400 - invalid_request_error:
`tool_use_id` "sevt_..." does not match any `agent.tool_use` event in this session

The tool itself executes successfully; only the result confirmation is rejected. Because _send_result treats the 400 as fatal (no re-fetch, no retry after SEND_RETRIES), a transient failure becomes a permanent strand: the session sits in requires_action until an external user.interrupt.

Environment

• anthropic==0.112.0
• Self-hosted EnvironmentWorker(...).handle_item(...)
• Multiagent enabled via beta_agent_toolset_20260401 (orchestrator spawns sub-threads)
• The worker only supplies tools; all tool-result posting is done inside the SDK.

What I observe (from session event traces)

• The failing tool_use_ids are agent.tool_use events whose session_thread_id is a sub-thread (sthr_...), not the primary session.
• The failing tools are ordinary toolset tools (bash, read) with evaluated_permission: "allow" — not always_ask.
• It is intermittent: the same tool, in the same sub-thread, with the same permission, sometimes succeeds. It frequently affects the second of two near-simultaneous agent.tool_use blocks issued in one sub-thread turn (the first is confirmed, the second 400s).
• It self-heals ~11 minutes later on a re-drive: a user.tool_result for the same tool_use_id eventually appears, carrying the correct session_thread_id. So the SDK does route to the sub-thread correctly when it succeeds.
• The final pending agent.tool_use in a chain does not self-heal; the session stays in requires_action until interrupted.
• Custom-tool results (agent.custom_tool_use / user.custom_tool_result) are unaffected in the same sessions.

Example trace shape (one session): 6 agent.tool_use but only 4 user.tool_result; all shortfall ids are sub-thread agent.tool_use.

Questions

1. When confirming a tool_use that ran on a non-primary session_thread_id, should the SDK scope the confirmation to that session_thread_id? (It does when it succeeds, so this may be a timing issue rather than a missing field.)
2. Is this a server-side commit-ordering race — the agent.tool_use event not yet matchable when the result is posted — surfaced as a 400?
3. Given a 400 here is often transient, should _send_result re-fetch the session's pending events and retry rather than treating it as fatal? Today a transient race permanently strands the session.

Likely related (TypeScript SDK): anthropics/anthropic-sdk-typescript#1083.

[nadavshohat]

Bumping this for maintainer visibility — still no triage response since it was filed, and it's still the blocker for adopting Managed Agents sub-agents in production.

Confirming it's not fixed in the latest release: I checked every release through 0.116.0 (latest, 2026-07-02) — nothing in 0.113.0–0.116.0 touches this path, and the one adjacent PR (#1750) explicitly scopes itself out of it. So there's no version to move to that resolves this.

Restating the core question, since it looks server-side:

When a tool runs inside a non-primary session_thread_id (sub-agent thread), posting the tool_result intermittently returns 400 invalid_request_error … does not match any agent.tool_use event, even though the tool ran and the same tool succeeds on other attempts. Primary-thread confirmation always returns 200 (see the repro on anthropic-sdk-typescript#1083). It reads like a commit-ordering race: the sub-thread agent.tool_use event isn't yet matchable when the result is posted.

Two things that would unblock adopters:

1. Is a client supposed to be able to confirm a sub-thread tool_use, and if so, is there an ordering/readiness signal we should wait on before posting the result? The current behavior appears to contradict the Managed Agents multi-agent skills doc.
2. Should this specific 400 be retryable? Today the SDK treats HTTP 400 as fatal in the result-send path, so a transient race becomes a permanently stranded session (the final pending tool_use never self-heals; earlier ones re-drive after ~11 min).

Happy to share session IDs or a minimal repro against a test org if it helps triage.