### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? All attempts to use Opus 5.5 (`claude-opus-5-5`) in the current stable release of Claude Code fail deterministically with the following error message: ``

[BUG] Opus 5.5 requires unstable release of Claude Code

Status Open

Reported on v2.1.275

Maintainer reply None cached

Activity 4 comments · opened Sep 22, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

All attempts to use Opus 5.5 (claude-opus-5-5) in the current stable release of Claude Code fail deterministically with the following error message:

❯ /model claude-opus-5-5
  ⎿  API error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Claude Code 2.1.275 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.","details":{"error_code":"claude_code_version_too_old"}},"request_id":"req_011CfK2o3XeCrKAFyfBPTJHd"}

What Should Happen?

Opus 5.5 requests should succeed in the current stable release of Claude Code. As of this moment, that is 2.1.267:

❯ date; npm view @anthropic-ai/claude-code dist-tags.stable
Tue Sep 22 14:37:53 CDT 2026
2.1.267

Error Messages/Logs

❯ /model claude-opus-5-5
  ⎿  API error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"Claude Code 2.1.275 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.","details":{"error_code":"claude_code_version_too_old"}},"request_id":"req_011CfK2o3XeCrKAFyfBPTJHd"}

Steps to Reproduce

claude install stable
claude --model claude-opus-5-5 --print 'what is your knowledge cutoff?'
observe the following error message and a non-zero exit code:

[claude-code:unrecognized_model] {"model":"claude-opus-5-5","query_source":"sdk"}
API Error: 400 Claude Code 2.1.267 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.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.267

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_

View original on GitHub ↗

4 Comments

knksmith57 · 22 days ago

This is another unique manifestation of #91345, this time for Opus 5.5 rather than Fable 5.1.

nijave · 19 days ago

Unclear what side-effects this might have, but this is what Fable came up with

nick@nick-desktop:~/$ CLAUDE_CODE_ATTRIBUTION_HEADER=0 ANTHROPIC_CUSTOM_HEADERS="User-Agent: claude-cli/2.1.280 (external, cli)" claude --version
2.1.274 (Claude Code)

nick@nick-desktop:~/.$ CLAUDE_CODE_ATTRIBUTION_HEADER=0 ANTHROPIC_CUSTOM_HEADERS="User-Agent: claude-cli/2.1.280 (external, cli)" claude --model claude-opus-5-5 -p 'ping'
Pong. What would you like to work on?

The first one prevents the Claude Code version from being injected in the prompt, the second (as the name implies) lies about its version in the User Agent.

The most reasonable thing I can come up with is Anthropic is trying to ensure Opus 5.5 uses the "right" Claude Code system prompt. Different models and versions have different system prompts bundled into Claude Code. However, you can always use --system-prompt to override the system prompt of any model to whatever you want.

UTKARSH698 · 17 days ago

Adding a Claude Desktop data point, since this thread is mostly CLI-side. The desktop app is affected too, and it's arguably worse there because the user has no way to clear the version floor themselves.

The desktop app does not use the CLI on your PATH — it runs its own bundled copy.

On my install (Windows 11, desktop app 2.9939.2):

PATH CLI  (npm)        : 2.1.282   <- above the 2.1.280 floor
Desktop bundled CLI    : 2.1.111   <- far below the floor

The bundled binary is the one that actually serves desktop sessions — it's pointed at by CLAUDE_CODE_EXECPATH:

CLAUDE_CODE_EXECPATH=<data-dir>\claude-code\2.1.111\claude.exe

So the failure mode from a user's perspective is: run claude update / update the npm package, see 2.1.282, and still not be able to select Opus 5.5 in the desktop app — because the desktop app never consults that install. The error message's advice ("Run claude update, or update the Claude desktop app") is misleading in this case: updating the npm CLI has no effect on the desktop app, and the desktop app was already on its current version while still shipping a 2.1.111 CLI.

This is a version gate, not an entitlement problem. GET /v1/models for the same account returns 200 and includes claude-opus-5-5 in the list, so the account has access. The model is simply refused for clients below the floor.

Confirmed the floor is the only blocker: invoking the same model through the PATH CLI (2.1.282) on the same account works normally, while the desktop app on the same machine cannot offer it.

Also worth flagging for anyone hitting this: npm dist-tags currently has

stable: 2.1.274      <- BELOW the 2.1.280 floor
latest: 2.1.283

so installing the stable tag is not sufficient — which matches this issue's title.

Suggested fixes, in rough priority order:

Have the desktop app refresh its bundled CLI (or surface its bundled CLI version in the UI / /status, so the mismatch is at least visible).
Make claude_code_version_too_old report the version of the client that actually issued the request, rather than generic update advice — right now it points users at an install that isn't in play.
Promote a build at or above the floor to stable.

UTKARSH698 · 16 days ago

Follow-up to my earlier comment: I found the actual root cause on my machine, and it is not simply that the desktop app ships an old CLI. Posting in case others on Windows hit the same thing.

The desktop app does auto-update its CLI, but the update was silently failing. From the desktop app's main.log (%LOCALAPPDATA%\Claude\Logs\main.log):

[CCD] Initialized with version 2.1.281
[CCD] Download attempt 1/3 failed at mkdir (ENOENT) [Error: ENOENT: no such file or directory, mkdir '<APPDATA>\Claude\claude-code\2.1.281']
[CCD] All download attempts failed
[CCD] Falling back to installed version: 2.1.111

Cause: I had relocated the app's data directory to another drive by making %APPDATA%\Claude an NTFS junction to D:\Claude. With that in place, the (MSIX-packaged) app could read files and write to existing files through the junction, but every mkdir under it failed with ENOENT. Since each CLI version is installed into a new claude-code\<version>\ folder, every update attempt failed (I found attempts for 2.1.275, 2.1.280 and 2.1.281 in the log), and the app kept falling back to the last CLI it had installed before the junction existed. The same failure also hit git-shadow and skill downloads.

Fix: make %APPDATA%\Claude a real directory again and, if disk space requires it, junction only large subfolders (for me, vm_bundles) out to the other drive. After restarting, the app downloaded 2.1.281 on its own, logged Using Claude Code binary at: ...\claude-code\2.1.281\claude.exe, and Opus 5.5 now works in the desktop app.

How to tell if you're affected: search main.log for Falling back to installed version or failed at mkdir (ENOENT). If the fallback version is below 2.1.280, Opus 5.5 will be refused, even on the latest desktop build.

This is probably worth handling in the app itself: the CLI download failure is only visible in the log, and the user just sees the generic claude_code_version_too_old message. Surfacing "CLI update failed: could not create directory" in the UI would have saved a lot of debugging.