[BUG] advisor_20260301 tool type 400 hard-fails every turn in an affected session; model switch does not recover

Summary

In an affected session, every turn hard-fails with:

API Error: Error code: 400 - {'message': "tool type 'advisor_20260301' is not supported for this model"}

The assistant turn produces no output at all. The transcript records a
<synthetic> assistant message whose entire content is the error string.
Once a session enters this state it never recovers: every subsequent user
message, including a bare continue, returns the same 400.

This is not a per-request transient. It is a sticky, session-scoped failure.

Environment

• Claude Code 2.1.212
• macOS 26.7 (darwin), zsh
• VS Code native extension
• Models observed failing: claude-sonnet-5 and claude-opus-5[1m]
• Auto Mode active; managed settings pin Sonnet 5

What I observed

Across four separate sessions in two different project directories:

1. A session originally created several days earlier, then resumed. On

resume the user switched model with /model opus[1m], sent one prompt,
and got the 400. The attachment block on that turn confirms the request
went out as claude-opus-5[1m]. So this is not specific to the
1M-context Sonnet variant, and not fixed by switching model family.

1. A second session in the same directory failed on its very first turn and

on every turn after. It has no successful assistant turn in its
entire transcript. Notably it also failed while merely receiving an
inbound cross-session message from a peer session, so it could not reply
to that message at all.

1. A session in an unrelated project where the code-review skill was the

trigger. The skill could not run, so no automated review happened.

1. A fourth session showing the same first-turn failure pattern.

Impact beyond the error itself

The code-review skill failing has a knock-on effect. In the session where
that happened, the permission classifier then denied gh pr merge with
reason "Merge Without Review", because no automated review had run. So
one API error silently blocked a merge workflow. A user with a
review-before-merge policy is fully blocked, and the surfaced reason
("Merge Without Review") does not point at the real cause.

What does NOT fix it

• Retrying the same turn.
• Sending continue.
• Switching model (/model opus[1m] after the failure started, and a

session that failed while already on claude-opus-5[1m]).

What does work

Starting a fresh session in the same directory works normally. A new
session ran Bash, git, file reads and writes, and multi-tool turns with no
error. This is why the failure looks model-related at first glance but is
not: a healthy session cannot reproduce it, and an affected session cannot
escape it.

Suspected area

advisor_20260301 is a dated/beta tool type. Something appears to attach an
advisor tool definition to the request based on session state that survives
resume, and that tool type is then rejected for the target model. Possibly
related in area to #76189, which also reports advisor behavior keyed to
transcript state, though the symptom there is an "unavailable" result rather
than a hard 400.

Repro

I could not produce a deterministic repro. The correlation I can state from
transcripts is that affected turns carry an attachment block (model identity,
date change, and in one case a remote_session_change entry), and at least
two affected sessions show an atis-latch transcript entry immediately
before the first failure. Sessions are resumed or newly created rather than
long-running when the failure first appears.

Happy to supply sanitized transcript excerpts if that helps narrow it, but
note the raw transcripts contain confidential material I cannot attach.

Expected behavior

Two things:

1. The advisor tool type should not be attached to a request for a model

that does not support it.

1. If it is attached and rejected, the failure should degrade gracefully.

A tool the user never asked for should not take down every turn of a
session with no recovery path and no actionable message.