›_ Claude Code Issues
Claude Code Issues / #96105

[BUG] macOS 12: Desktop app stuck on bundled Claude Code 2.1.260, Opus 5.5 greyed out — yet 2.1.280 lists this app's SDK wrapper (0.3.260) as tested while `stable` (2.1.267) does not

Status Open
Reported on v2.1.280
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 6 comments · opened Sep 22, 2026

Summary

On macOS 12 (Monterey, Intel), the Desktop app's model picker shows Opus 5.5 greyed out with the tooltip "Update Claude to use this model on this computer", while the app's own update check reports "You're using the latest version."

The machine is stranded between two update paths that cannot meet:

  • The Desktop app cannot move forward: the release feed offers 2.2553.13, which does not install on macOS 12.
  • The bundled Claude Code cannot move forward either, because it ships pinned inside the app — and the channel the app follows points at a build that is incompatible with the app's own SDK wrapper.

The standalone CLI on the same machine is on 2.1.280 and offers Opus 5.5 without any problem, which isolates this to the Desktop app's bundled component.

Environment

| | |
|---|---|
| OS | macOS 12.7.6 (Monterey), Intel (x86_64) |
| Claude Desktop | 1.46388.4 (installed 2026-09-05) |
| Bundled Claude Code (running in the Code tab) | 2.1.260 |
| Standalone CLI (~/.local/bin/claude) | 2.1.280 — Opus 5.5 selectable |
| Desktop release feed darwin/x64/RELEASES.json | currentRelease: 2.2553.13 (2026-09-21) — requires a newer macOS |

Evidence

Claude.app/Contents/Resources/app.asar carries a pinned Claude Code manifest:

{"version":"2.1.260","manifest":{"version":"2.1.260","commit":"e51f681183f733dbe9a81bf35921c786ee26dbc6","buildDate":"2026-09-03T19:52:17Z", ...},
 "sdkCompat":{"harnessSchema":1},"baseUrl":"https://downloads.claude.ai/claude-code-releases","sdkWrapperVersion":"0.3.260"}

So the app's wrapper is 0.3.260, harnessSchema 1. Checking the two channel pointers against that wrapper:

| Pointer | Version | sdkCompat.testedWrapperVersions | Compatible with wrapper 0.3.260? |
|---|---|---|---|
| claude-code-releases/stable | 2.1.267 | 0.3.225, 0.3.226, 0.3.227 | no |
| claude-code-releases/latest | 2.1.280 | 0.3.240 … 0.3.259, 0.3.260, 0.3.261, … 0.3.278 | yes |

That is the crux: 2.1.280 explicitly lists this app's wrapper version as tested (same harnessSchema), while the stable build the app follows does not. The app therefore never advances past the 2.1.260 it was shipped with — not because the newer Code build is incompatible with it, but because the only build it is willing to consider is the one that is.

Impact

macOS 12 users are silently cut off from new models (Opus 5.5 today, whatever follows next) in the Desktop app, with no path forward and no actionable message: the picker says "update Claude", and updating Claude answers "you are on the latest version". Nothing in either message reveals that the blocker is a pinned sub-component.

Ask

  1. Let the app accept a Code build whose testedWrapperVersions contains its own sdkWrapperVersion, rather than only the stable pointer — by that rule this machine would take 2.1.280 today.
  2. Or point stable at a wrapper-compatible build.
  3. Failing either, make the tooltip honest for OS-stranded installs ("this model needs Desktop x.y, which requires macOS 13") instead of pointing at an update that does not exist for that machine.

Related

Same class of problem, same platform, earlier this month — the Desktop app's bundled Code being server-pinned while the standalone CLI was fine: #91381, #91309, #91550, #91625, #92401. That round was resolved by a fixed build (changelog: "v2.1.258: Fixed Claude Code failing to launch on macOS 12 (Monterey) from 2.1.255 regression"). This is the same pinning mechanism surfacing as a capability gap rather than a crash.

View original on GitHub ↗

5 Comments

talentsache · 22 days ago

Follow-up: I tested whether this can be worked around locally. It cannot — the pin is authoritative, so the fix has to come from the release side.

What I did. The standalone CLI's binary on this machine is byte-identical to the official artifact the app itself would fetch:

manifest 2.1.280 / darwin-x64 : size 225565024  sha256 c1d32d87630482250633208ab77855429b24010ae3086a7ff7539b57b93168d4
~/.local/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe
                              : size 225565024  sha256 c1d32d87630482250633208ab77855429b24010ae3086a7ff7539b57b93168d4

So I assembled the version directory the app uses, in exactly the shape it creates itself — claude.app/Contents/MacOS/claude (the verified official binary, Anthropic-signed, Team Q6L2SF6YDW), Contents/Info.plist copied from the 2.1.260 bundle with the version strings bumped, and a .verified file containing the manifest checksum, matching the format the app wrote for 2.1.260.

Result.

| Time | Event |
|---|---|
| 20:06:15 | ~/Library/Application Support/Claude/claude-code/2.1.280/ complete on disk |
| 20:08:36 | Full ⌘Q and relaunch — app spawns claude-code/2.1.260/claude.app/Contents/MacOS/claude |

Repeated across two full restarts. The app does not consider the higher local version at all; it goes straight to the build named in its embedded manifest. There is also no local override: no env var, no key in Local State / config.json / Preferences, nothing in the bundle that reads a version from disk.

Why this matters for the report above: a macOS 12 install is not merely waiting for an update it could obtain another way. It is pinned to 2.1.260 by the app binary, the app cannot be replaced (feed offers 2.2553.13, which needs a newer macOS), and the Code build that is wrapper-compatible (2.1.280, which lists this app's sdkWrapperVersion 0.3.260 as tested) can be neither fetched by the app nor installed by hand. Every path is closed from the user side.

Happy to test a build or a flag if that would help.

talentsache · 22 days ago

One more data point that narrows this down: the gate is enforced server-side, not only in the picker.

I bypassed the model picker entirely and asked the pinned engine to use the model directly:

$ ~/Library/Application\ Support/Claude/claude-code/2.1.260/claude.app/Contents/MacOS/claude \
    -p "reply with one word: OK" --model claude-opus-5-5

"claude-opus-5-5" isn't described by this version's model catalog; update Claude Code, or map it
with behavesAs on a modelPicker row (or modelOverrides, if it is a provider id of a model this
version knows).
[claude-code:unrecognized_model] {"model":"claude-opus-5-5","query_source":"sdk"}
API Error: 400 Claude Code 2.1.260 does not support this model; version 2.1.280 or newer is
required. Run 'claude update', or update the Claude desktop app, then try again.

So the request does leave the machine and the API refuses it on version grounds. behavesAs / modelOverrides are no way around it either — they can only map onto models this build already knows.

That closes the last user-side option and makes the consequence concrete: for a Desktop install that cannot advance its bundled engine, the model is unreachable by any route, and the error text advises exactly the two actions that are unavailable on this machine ("run claude update" — updates the unrelated standalone CLI; "update the Claude desktop app" — the app reports it is already on the latest version it can install).

For completeness on the support question: the documented floor is macOS 13.0+ (Advanced setup → System requirements), so macOS 12 sits below it. Still, 2.1.258 explicitly fixed launching on macOS 12, and the current CLI 2.1.280 runs fine here — so the practical situation is a machine that runs the new build happily via one install path and is locked out of it via the other. If macOS 12 is simply out of support, saying so plainly would be more useful than the current message, which points at two updates that cannot be performed.

marulya · 21 days ago

I have the same issue on Linux Mint. Opus 5.5 is grayed out in Claude Desktop's Code section.

I've updated both claude-cli and Claude Desktop. I can start a Remote Controlled CLI session that uses Opus 5.5, and that works. But the local session in Code doesn't allow Opus 5.5:

$ apt-cache policy claude-desktop
claude-desktop:
  Installed: 2.2553.13
  Candidate: 2.2553.13
  Version table:
 *** 2.2553.13 500
        500 https://downloads.claude.ai/claude-desktop/apt/stable stable/main amd64 Packages
        100 /var/lib/dpkg/status
bnoel-coder · 21 days ago

Has this been resolved yet? Seems like I'm the only person I know that can't use it. Oddly enough, it's available in chat but not code

talentsache · 21 days ago

Not yet.. you can open a terminal and start Claude from there and control it with /remote-control from the desktop app with Opus 5.5 as a workaround

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

This issue appears in the ranked issue list on this topic page, alongside a backlog trend for the whole topic.

Crashes, hangs & freezes →

Browse all Claude Code issue topics →