Session stuck in permanent "advisor tool unavailable" state; mid-session /advisor reports success but does not recover it

Summary

An interactive session got stuck in a permanent "advisor tool unavailable" state for its entire lifetime (4 advisor calls over ~3 hours, all returning the canned error), while freshly started sessions with byte-identical configuration attach the advisor and consult it successfully. Mid-session /advisor reported "Advisor set to Fable 5" but did not recover the tool, although the docs (https://code.claude.com/docs/en/advisor) say the /advisor command can "set or change the advisor mid-session."

Environment

• Claude Code 2.1.205 (native install), Arch Linux, zsh
• Main model: claude-opus-4-8[1m] (Opus 4.8, 1M context)
• advisorModel: "fable" — present in the project's .claude/settings.local.json before session start (file mtime predates the session by ~4h)
• Fable 5 access confirmed — Fable 5 runs fine as the main model in the same session
• Anthropic API (subscription); no ANTHROPIC_BASE_URL / gateway override
• The affected session started ~11 minutes after auto-updating the binary 2.1.204 → 2.1.205 (process confirmed running the 2.1.205 binary via /proc/<pid>/exe)

What happened (timeline, single interactive session)

1. Session starts at 14:39 on 2.1.205; the advisor tool is present in the model's toolset.
2. First advisor call (~15:00): The advisor tool is unavailable. Do not try to use it again.
3. User switches main model mid-session: /model → "Set model to Fable 5 and saved as your default" (a Fable main + Fable advisor is the documented valid pairing). Advisor call: same canned error.
4. User runs /advisor → "Advisor set to Fable 5" (also written to user settings.json). Advisor call: same canned error.
5. ~3h after the first failure (all config paths since verified working, see below): same canned error.

The failure is sticky — once the session marks the advisor unavailable, nothing re-probes it: not /model, not /advisor (which reports success), not time.

Not reproducible in fresh sessions — probe matrix

All probes run headless (claude -p) on the same machine, same 2.1.205 binary, same day:

| Probe | Advisor config path | Main model | Result |
|---|---|---|---|
| A | --advisor fable flag | claude-opus-4-8 | ✅ advisor consulted OK |
| B | --advisor fable flag | claude-opus-4-8[1m] | ✅ advisor consulted OK |
| C | saved settings (user + project scope) | claude-opus-4-8[1m], same repo cwd | ✅ advisor consulted OK |
| D | project-scope-only .claude/settings.local.json (advisorModel removed from user settings for the probe) | claude-opus-4-8[1m], same repo cwd | ✅ advisor consulted OK |

Probe prompt: Call the advisor tool exactly once. Then reply with exactly one word: ADVISOR_OK if it returned advice text, or ADVISOR_UNAVAILABLE if the tool errored or is not available.

So the [1m] model-ID variant, the config scope, the fable alias, version skew, and Fable 5 access are all ruled out. All settings files were also validated against the documented schema (strict JSON, recognized keys, well-formed hooks/permissions); configuration is exonerated by probes C/D, which loaded the exact same files and succeeded.

Expected behavior

• A transient advisor-attach failure at session start should be retried at some point — at minimum when the user explicitly runs /advisor mid-session.
• If the advisor genuinely cannot be (re)attached to the current session, /advisor should say so instead of reporting "Advisor set to Fable 5" while the tool remains dead.

Actual behavior

A one-time attach failure (root cause unknown; possibly transient, occurring shortly after a binary auto-update) permanently disables the advisor for the session, every subsequent call returns the canned "unavailable" error, and /advisor claims success without recovering it.

Notes

• The initial attach failure has not reproduced since, so this report is primarily about the sticky dead state + misleading mid-session /advisor success, which were directly observed and are deterministic within the affected session.
• Happy to provide session IDs / timestamps privately if useful.