[BUG] Session permanently dead-locks with "400 Tool reference 'TaskCreate' not found" — agent-teams dynamic tools captured in a tool_search_tool_result snapshot

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

A session becomes permanently unusable: every user message returns the same API error and no assistant turn can complete.

API Error: 400 Tool reference 'TaskCreate' not found in available tools

This is the same underlying failure as https://github.com/anthropics/claude-code/issues/79970 (WaitForMcpServers), but with a different source of the transient tool: the agent-teams plugin's dynamic tools.

Root cause, traced from the session transcript:

1. The session spawned an agent team (agent-teams plugin), so the team's dynamic tools — TaskCreate, TaskUpdate, TaskList, TaskGet, TeamCreate, TeamDelete, SendMessage — were advertised in the request's tools while the team was live.
2. During the session the assistant issued a deferred-tool search (tool_search_tool_regex). The resulting tool_search_tool_result was written into the transcript with a snapshot of the entire tool catalog as content.tool_references — including the team tools (and, as in #79970, tools that don't match the search regex at all).
3. The team's tools are lifecycle-scoped: once the team is torn down — or the session is exited and --resumed, or a usage limit is hit mid-run and the session is resumed on another account — those tools are no longer advertised.
4. A tool_search_tool_result is immutable transcript history. On every subsequent request the API re-validates the whole conversation, finds a tool_reference to TaskCreate that is no longer in the advertised tool set, and rejects the entire request with a 400. The session is poisoned permanently.

Notably, removing the actual tool_use blocks that called TaskCreate does NOT fix it — I renamed every team-tool tool_use in the main transcript and all 19 subagent transcripts and the 400 persisted. The surviving dangling reference lives only in the tool_search_tool_result snapshot's content.tool_references. Removing those entries and resuming clears the error with full context intact — confirming the snapshot is the sole cause (identical to #79970).

What Should Happen?

A completed session must never become permanently un-loadable. Either:

• a tool_search_tool_result should not persist lifecycle-scoped/dynamic tools (agent-teams tools, MCP-startup tools) into its result snapshot, or
• on every request the harness should reconcile persisted tool_references against the current tool set — re-advertising or stripping now-absent tools so the API never sees a dangling reference.

Error Messages/Logs

API Error: 400 Tool reference 'TaskCreate' not found in available tools
Error during compaction: API Error: 400 Tool reference 'TaskCreate' not found in available tools

/compact also fails, because compaction re-sends the same poisoned history.

Steps to Reproduce

1. Install the agent-teams plugin. Spawn a team (/agent-teams:team-spawn or a team command) so TaskCreate/TaskUpdate/SendMessage are advertised.
2. During the session, take an action that triggers a deferred-tool search (tool_search_tool_regex) while the team tools are advertised. The resulting tool_search_tool_result records a content.tool_references list that includes TaskCreate (and the full catalog, not just regex matches).
3. Stop the team tools from being advertised — end the team, or (as happened here) hit the usage limit mid-run, exit, switch accounts, and claude --resume.
4. Every subsequent turn fails with 400 Tool reference 'TaskCreate' not found in available tools, permanently. continue, /compact, re-spawning the team, and a fresh --resume all reproduce it.

Confirming evidence in the JSONL (~/.claude/projects/<project>/<session-id>.jsonl): the tool_search_tool_result block's content.tool_references contains {"type":"tool_reference","tool_name":"TaskCreate"}. The earliest turn containing it succeeds; all later turns 400.

Environment

• Claude Model: Multiple (session spanned Fable 5 and Opus 4.8 — model switching does not clear it)
• Is this a regression?: I don't know
• Claude Code Version: 2.1.217 (Claude Code)
• Platform: Claude subscription (Max) — manifested after hitting a session usage limit, switching accounts, and resuming
• Operating System: macOS
• Terminal/Shell: running inside a Claude Code session-manager wrapper (Lanes); reproducible from a plain claude --resume as well

Additional Information

Workaround for an already-poisoned session (keeps context): with the session closed, edit its transcript JSONL and remove every team-tool entry (TaskCreate/TaskUpdate/SendMessage/etc.) from each tool_search_tool_result's content.tool_references, then claude --resume <session-id>. Editing the tool_use blocks is not sufficient — the dangling reference is in the tool-search snapshot, not the calls.

Confirmed working: applying exactly this workaround (stripping the team-tool entries from the tool_search_tool_result snapshots) fully recovered a live poisoned session — it resumed with complete context and is now back in active use. This also pins the snapshot as the definitive single point of failure.

Same reconciliation gap as https://github.com/anthropics/claude-code/issues/79970; recommend fixing both together. The secondary observation there also applies here: tool_search_tool_regex returns the entire tool catalog rather than only regex matches, which is what pulls transient/dynamic tools into the persisted snapshot in the first place.