[BUG] Session permanently bricked: 400 "Tool reference 'LSP' not found in available tools" after a deferred tool leaves the pool mid-session

Summary

When tool search is active, search results persist tool_reference blocks in session history (inside tool_search_tool_result -> content.tool_references). If a referenced tool later leaves the tool pool mid-session, every subsequent request replays the stale reference and the API rejects the entire request:

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

The session is permanently bricked: every message, including a plain "continue", fails with the same 400. There is no in-product recovery (/compact also fails, since compaction replays the same history).

In our case the vanishing tool is LSP, provided by the rust-analyzer-lsp@claude-plugins-official plugin. It has dropped out of the pool mid-session three times between 2026-07-10 and 2026-07-17, bricking three sessions.

Environment

• Claude Code 2.1.206 (VSCode extension, claude-vscode, agent-sdk/0.3.206), macOS (Darwin 24.6.0)
• rust-analyzer-lsp@claude-plugins-official plugin enabled
• Reviewed the changelog through 2.1.212: no fix listed for this

Timeline of one occurrence (from the session .jsonl, 2026-07-10, times UTC)

1. 16:01:02 - assistant runs tool_search_tool_regex; the stored result references ~23 tools including LSP (so LSP was in the pool at that moment)
2. 16:15:57 - last successful assistant turn (a Bash tool_use running a 94-second cargo test build)
3. 16:17:35, 16:17:54, 16:20:57 - every subsequent request fails with the 400 above

Ruled out during that window: IDE disconnect (an ide_selection event was still recorded at 16:17:49, between two failures), window reload (no new VSCode log session), version change (2.1.206 throughout), local config change. The LSP tool simply left the pool - consistent with the LSP server failing or being deregistered during the heavy cargo build (rust-analyzer contending with cargo on the target dir), or a server-side gate re-evaluation.

The requests pass through a local pass-through proxy whose logs confirm the 400 originates upstream ("Forwarding upstream streaming error status=400" from api.anthropic.com), i.e. it is API-side validation of the replayed history, not client- or proxy-generated.

Expected behavior

The client rebuilds the tools array from current availability on every request, but replays history verbatim. It should sanitize stale tool_reference entries (drop or stub them) when the tool pool no longer contains the referenced tool - the pool-change condition is already detected internally (there is a tengu_deferred_tools_pool_change telemetry event).

Reproduction

1. Start a session with an LSP plugin enabled so LSP is in the deferred tool pool; let the model run a tool search whose stored result references LSP.
2. Cause the LSP server to die/deregister mid-session (e.g. kill the language server), or otherwise remove the tool from the pool.
3. Send any message: 400 Tool reference 'LSP' not found in available tools, permanently, for the rest of the session.

Workarounds

• Manual transcript surgery: in the session .jsonl, remove the stale entry from the tool_search_tool_result block's content.tool_references array. Restores the session.
• ENABLE_TOOL_SEARCH=false prevents references from being stored at all.
• Disabling the LSP plugin removes the flapping tool.