[Bug] Advisor returns "unavailable" deterministically when the request contains ToolSearch-loaded deferred tools — tiny context, both Fable 5 and Opus 4.8 executors (distinct from #67609's size threshold)

Summary

The server-side advisor tool returns advisor_tool_result_error with error_code: "unavailable" deterministically whenever the session has loaded any deferred tool via ToolSearch before the advisor call. Without a ToolSearch load, the identical configuration succeeds. It reproduces at tiny context (a single small tool schema loaded), on both claude-fable-5 and claude-opus-4-8 executors — so this is distinct from #67609's transcript-size threshold and not a model-pairing problem.

Since stock Claude Code loads deferred built-ins (WebFetch, ExitPlanMode, …) via ToolSearch routinely, in practice the advisor dies early in most real sessions.

Environment

• Claude Code 2.1.200 (native installer), Windows 11 Home 10.0.26200
• Subscription auth (OAuth), first-party Anthropic API
• "advisorModel": "fable"; executors tested: claude-fable-5 and claude-opus-4-8 (both documented-valid pairings per the advisor-tool docs compatibility table)
• CLAUDE_CODE_DISABLE_ADVISOR_TOOL not set

Deterministic repro (headless)

# succeeds
claude -p "Call the advisor tool exactly once, then report the result." --model claude-fable-5

# fails
claude -p "1) Call ToolSearch with query select:WebFetch (do not call WebFetch). 2) Call the advisor tool exactly once. 3) Report the result." --model claude-fable-5

2×2 matrix, all four runs launched in parallel on 2026-07-03 ~11:27Z from the same machine and settings:

| Executor | ToolSearch load first? | Advisor result | Advisor round trip |
|---|---|---|---|
| claude-fable-5 | no | ✅ consult succeeds (advisor_redacted_result) | ~32s |
| claude-fable-5 | yes (select:WebFetch, tool never called) | ❌ unavailable | ~6.5s |
| claude-opus-4-8 | no | ✅ consult succeeds | ~24s |
| claude-opus-4-8 | yes | ❌ unavailable | ~4.4s |

Server-side correlation IDs (verbatim from transcripts, timestamps UTC):

• Failing, fable executor: srvtoolu_01D9Upqg6dAGS5i5AsQJ5MUq — server_tool_use emitted 2026-07-03T11:27:04.227Z; advisor_tool_result_error {"error_code": "unavailable"} at 11:27:10.751Z
• Failing, opus executor: srvtoolu_01NSBaZHMEAwJgX3B5B32SyL — emitted 2026-07-03T11:26:59.426Z; error at 11:27:03.801Z
• Passing, fable: srvtoolu_019CHoRtyp1neesvqAVRidPJ (result 11:27:30.950Z); passing, opus: srvtoolu_01F8EQjr1qXEyNmXbYXd4MvW (result 11:27:20.694Z)

The srvtoolu_ IDs show the API executed the server tool in all four cases; the failure is a server-side rejection, not a client registration problem. The ~4–7s failing round trip (vs ~24–32s for a successful consult) suggests the advisor sub-inference dies immediately.

Additional observations

• Same behavior from subagents inside interactive sessions: a fresh Fable or Sonnet subagent's advisor call succeeds; after the subagent loads any deferred tool via ToolSearch (reproduced with built-in WebFetch and with a claude.ai-connector MCP tool), the advisor returns unavailable.
• anthropic-beta headers are identical between passing and failing requests (both include advisor-tool-2026-03-01 and advanced-tool-use-2025-11-20), so the trigger is the request-body tool composition after a deferred-tool load.
• Client debug log (claude --debug) is clean on failing calls: healthy registration at startup ([AdvisorTool] Server-side tool enabled), normal dispatch, zero [ERROR]/[WARN] — the failure is entirely in-band in the response payload. Repeated calls each produce a fresh server round trip on 2.1.200 (no client-side latch observed — offered as a contrast datapoint to #67411, not a refutation).
• We also see intermittent unavailable failures in sessions that never used ToolSearch, correlated with transcript growth and large deferred-tool manifests (claude.ai Remote Control connectors + plugins). Those are consistent with #67609's size threshold; we claim no second cause here — this report is scoped to the deterministic ToolSearch trigger, which reproduces at tiny context.
• The [1m] suffix is unrelated for Fable executors (Fable is natively 1M; the suffix adds no context-1m beta header).

Expected per docs

The advisor-tool documentation (platform.claude.com → Agents and tools → Advisor tool) documents no such restriction:

• "The advisor tool composes with other server-side and client-side tools" — its feature-interaction table covers batch processing, token counting, context editing, and pause_turn; there is no tool-search or deferred-loading caveat. Observed behavior contradicts documented behavior.
• Possible mechanism: the advisor "receives the executor's full transcript as quoted context … That transcript includes your system prompt, the tool definitions, the prior turns and tool results." A ToolSearch result block / late-loaded tool definition that the advisor-side transcript-quoting pass can't handle would produce exactly this fast in-band death.
• unavailable is documented as the catch-all ("any other advisor failure"), while prompt_too_long exists as a distinct code — so this is not a size overflow being surfaced correctly.

Either the combination should work as documented, or the client should surface the conflict (e.g. the "Advisor unavailable" line explaining it) instead of the advisor silently dying for every session that touches ToolSearch.

Related issues

• #67609 — same error code on Fable, but transcript-size-triggered (>~100K); this one fails at tiny context. Possibly the same server-side rejection class.
• #67411 — client-side latch + error-code flattening; on 2.1.200 we observe no latch (each call round-trips fresh).
• #66784 / #67903 — pairing-caused unavailable; both pairings here are documented-valid and succeed absent ToolSearch.
• #73019 — same symptom, no repro details.
• #73128 — /advisor mid-session rebinding no-op; matches our side observations, but a separate client issue.