[Docs] Advisor tool is not inherited by background subagents, contradicting the advisor docs

Additional datapoint — cannot reproduce the background-only gap on v2.1.209 (macOS), plus a confounder worth noting

Environment: Claude Code v2.1.209 (desktop app session), macOS (Darwin 25.5.0), main model Fable 5, advisorModel: "fable" in settings.json, subagents forced to Sonnet 5 via CLAUDE_CODE_SUBAGENT_MODEL=sonnet, subagent_type: general-purpose. All probes were minimal "call advisor() exactly once and report the verbatim result" agents.

Results from one session today (times relative):

| When | Caller | run_in_background | Result |
|---|---|---|---|
| T0 | Sonnet 5 subagent | false | ❌ The advisor tool is unavailable. Do not try to use it again. |
| T0 +5 min | Fable 5 main loop | — | ❌ identical verbatim error |
| T0 +~1 h | Sonnet 5 subagent | false | ✅ advisor responded with guidance |
| T0 +~1 h | Sonnet 5 subagent | true | ✅ advisor responded with guidance |
| T0 +~1 h | Sonnet 5 subagent | true | ✅ advisor responded with guidance |
| T0 +~1 h | Sonnet 5 subagent | true | ✅ advisor responded with guidance |

Two observations:

1. Background subagents did receive a working advisor here (3/3), contemporaneous with a foreground success — so on 2.1.209 I can't reproduce the background-vs-foreground split this issue describes. I don't see anything advisor-related in the 2.1.207–2.1.209 changelog, so either it was fixed without a note, or the failure mode isn't strictly background-vs-foreground.

1. The same generic "unavailable" string also fires for what looks like transient server-side unavailability. In the earlier window, a foreground subagent AND the Fable 5 main loop both got the identical error within minutes of each other (both pairings valid per the docs: Fable main + fable advisor; Sonnet 5 subagent + fable advisor). An hour later everything worked with zero config changes. The main loop remained latched off for the rest of the session after its single failure, matching #67411.

Given (2), the background/foreground correlation in the original report may be confounded by when the probes ran — the error string gives no way to distinguish "tool not inherited" from "server-side failure latched off". +1 to the ask in #67411 to surface the underlying error cause; that would make this issue directly diagnosable.

Follow-up from the original reporter's setup — a fresh Windows datapoint now supports @iam1412's confounder theory

Environment: Claude Code v2.1.207, same machine/config as the original report (Windows 11 native, PowerShell, main model Fable 5, advisor fable, subscription auth). All probes below ran in one continuously running session, within ~3 minutes of each other:

| When | Caller | run_in_background | Result |
|---|---|---|---|
| T0 | Fable 5 main loop | — | ❌ The advisor tool is unavailable. Do not try to use it again. |
| T0 +1 min | Sonnet 5 subagent | false | ✅ advisor responded (confirmed it received the subagent transcript) |
| T0 +3 min | Sonnet 5 subagent | true | ✅ advisor responded |
| T0 +10 min | Opus 4.8 subagent (real workload, valid pairing) | true | ❌ reported the advisor as unavailable when it tried to escalate |

Additional context: the main loop's advisor first failed early in this session (~24 h before T0) and has returned the identical verbatim error on every retry since — including the T0 retry above, seconds before both subagent successes. So the advisor backend was demonstrably reachable while the main loop stayed dead. That is consistent with the per-conversation latch described in #67411, and not with server-wide unavailability (and the latch survives context compaction, apparently for the lifetime of the session).

Two takeaways:

1. I can no longer reproduce my own original background-only gap on v2.1.207 — a background subagent inherited a working advisor while the main loop was latched off, and ten minutes later another background subagent (valid pairing) failed again. Availability flip-flops across probes within one session regardless of run_in_background. Combined with the v2.1.209/macOS results above, the background-vs-foreground split in my original report was most likely confounded by when the probes ran: the early probes hit a transient failure, latched, and the session state persisted.
2. What remains actionable is exactly the ask in #67411: the generic error string conflates "not inherited / pairing invalid" with "transient failure, now latched off", and the latch never retries. Surfacing the underlying cause and/or retrying after a cooldown would make both issues directly diagnosable.

From the original report's perspective this issue likely reduces to #67411 — leaving it to the maintainers whether to fold it in or keep it open for a docs clarification.

Cross-linking #78471, which proposes a --advisor <model> launch flag for claude / claude agents. That would give background/dispatched sessions an advisor at dispatch time, directly addressing the non-inheritance described here.

Concrete case that hit this: an autonomous session wanted to dispatch several Sonnet workers each with an Opus advisor attached (cheap executor + strong advisor at decision boundaries). Because the advisor isn't inherited by background subagents and there's no launch flag to set one, the only workaround was to run a stronger executor throughout and review manually — which defeats the cost saving the advisor pattern exists for. A --advisor flag would be the CLI-level fix for the gap documented in this issue.