Org-restricted Claude models are offered as selectable and silently fall back

[whoisaldo]

On an account whose organization restricts a model, T3 Code offers that model as selectable, runs a different one, and keeps showing the restricted name. In my case, I have a personal Claude Sub, and a Claude Sub with my university (The Org in this case). My University restricts Fable and causes a minor nit: semi silent fallback where it's not obvious it falls back, and imo i think if an org restricts a model it should just grey it out.

Claude Code does not fail a request for a model the org has disallowed. It swaps in the org default and mentions the swap partway through the turn. T3 Code never read that state, so with Fable 5 restricted:

• Fable 5 stayed selectable in every model picker.
• Choosing it ran Opus 5 while the composer and thread still read "Claude Fable 5".
• The only hint was an unknown-subtype error row naming no model, because the CLI sends the substitution as system:informational, which the pinned SDK 0.3.170 does not declare.

Reproduced on CLI 2.1.228, well past the 2.1.169 version gate for Fable 5:

requested   = claude-fable-5
init.model  = claude-opus-5[1m]
answered    = claude-opus-5
notice      = [warning] Model "claude-fable-5" is restricted by your
              organization's settings. Using claude-opus-5[1m] instead.

One thing worth flagging for anyone else looking at this. The obvious signal is wrong. Treating "absent from the SDK init model catalog" as restricted looks correct and is not, because that catalog is the CLI's curated picker list. claude-fable-5 is absent and restricted. claude-opus-4-8 is also absent and runs normally. Keying on absence greys out working models. The reliable signal is modelAccessCache in .claude.json, where Claude Code stores resolved per-model entitlements and greys its own /model rows out from.

I opened #8652 with a fix that reads those entitlements during the existing capabilities probe and disables restricted rows with a reason, plus handling for the informational subtype so the substitution notice stops surfacing as an unknown subtype. Reading fails open, so a missing or malformed cache restricts nothing.

Happy to change the approach or drop it if you would rather solve this a different way. Mostly I wanted the behavior on record, since a silent model swap is easy to miss and hard to attribute when it happens.