Claude Code 2.1.266 gateway recovery: fix “Not signed in” without deleting valid API credentials
Quick answer
Claude Code 2.1.265, published on September 8, 2026, introduced an authentication regression for some LLM gateway and proxy setups. If the undocumented CLAUDE_CODE_USE_GATEWAY variable was present, it could force Cloud gateway sign-in even when the user already had a valid API key, apiKeyHelper, or custom authentication headers. Every request could then fail with Not signed in to the Cloud gateway.
Claude Code 2.1.266 was published roughly three hours later and restores the previous behavior: that variable alone is ignored again, and Anthropic says no configuration change is required. The safest recovery is to preserve your working credentials, upgrade to 2.1.266 or later, and verify the intended authentication route with a read-only canary. Do not delete keys or run a new interactive login merely because 2.1.265 misclassified the route.
Who this is for
This guide is for teams routing Claude Code through an Anthropic-compatible gateway, a corporate proxy, a rotating-key helper, or custom request headers. It is also relevant to CI and headless jobs where an unexpected OAuth prompt becomes an outage.
If your immediate problem is managed MCP delivery rather than model authentication, use the managed MCP headless checklist. This article is only about choosing and proving the model-request credential path.
What changed
Anthropic's documented gateway configuration uses explicit inputs:
| Input | Intended role | Verification evidence |
|---|---|---|
ANTHROPIC_BASE_URL |
Route model requests to an Anthropic-compatible gateway | Request reaches the expected hostname |
ANTHROPIC_AUTH_TOKEN |
Send a bearer token to a gateway | Gateway accepts the Authorization header |
ANTHROPIC_API_KEY |
Send an Anthropic API key as X-Api-Key
|
Direct or gateway request authenticates |
apiKeyHelper |
Generate a rotating credential | Helper exits successfully and refreshes as configured |
ANTHROPIC_CUSTOM_HEADERS |
Add gateway-specific headers | Required headers arrive without being logged |
CLAUDE_CODE_USE_GATEWAY is not part of the public environment-variable reference. Treat it as unsupported implementation detail, not as a durable configuration contract. The 2.1.266 release note specifically says the variable on its own is ignored again.
A secret-safe recovery workflow
1. Capture the failure without capturing credentials
Record the Claude Code version, exact error, execution surface, gateway hostname, and which credential mechanisms are present. Print variable names only:
claude --version
env | awk -F= '/^(ANTHROPIC_|CLAUDE_CODE_USE_GATEWAY)/ {print $1}' | sort
Do not paste environment values, helper output, custom headers, or a full debug trace into a ticket.
2. Confirm the regression boundary
The narrow signature is:
version = 2.1.265
valid API key, apiKeyHelper, or custom auth already configured
CLAUDE_CODE_USE_GATEWAY is present
error = Not signed in to the Cloud gateway
If the version or error differs, do not force this diagnosis. A real gateway policy, expired credential, blocked endpoint, or malformed helper can produce a different authentication failure.
3. Upgrade before changing authentication
Use your existing official Claude Code update path and record the installed result. Because npm installation is deprecated, do not switch package managers during incident recovery. The acceptance target is 2.1.266 or a later release that includes the fix.
4. Run one minimal canary
Use a disposable directory and a prompt that does not require tools:
claude -p "Reply with exactly: gateway-auth-ok" --max-turns 1
Confirm the request reaches the intended gateway, returns once, and does not open or request Cloud gateway login. Never print the request headers to prove this.
5. Test the actual credential route
Run one canary for the path you depend on: bearer token, X-Api-Key, or apiKeyHelper. For a helper, record its exit status and invocation time, not its stdout. For a proxy, record a redacted request ID and destination. Test headless execution separately from an interactive terminal because their credential behavior and environment loading can differ.
6. Promote gradually
Resume one low-risk automation first. Keep a failure counter for authentication errors, a maximum retry limit, and the last accepted response ID. A bad credential loop should stop rather than hammer the gateway or repeatedly invoke a secret helper.
Acceptance matrix
| Scenario | Expected result after 2.1.266 |
|---|---|
| API key plus leftover unsupported flag | Uses the configured API-key route; no Cloud gateway prompt |
apiKeyHelper plus gateway base URL |
Helper supplies the credential and the gateway accepts one request |
| Bearer token through proxy | Request reaches the configured base URL with bearer authentication |
| Real managed Cloud gateway requirement | Still follows the organization's required sign-in policy |
| Invalid or expired credential | Fails honestly; the version upgrade must not hide the auth error |
| CI/headless process | Completes without interactive login or unbounded retries |
Decision tree
Did the failure begin on 2.1.265?
no -> diagnose the documented credential path normally
yes -> does the message say "Not signed in to the Cloud gateway"?
no -> do not assume this regression
yes -> preserve credentials and upgrade to 2.1.266+
canary reaches the intended gateway?
no -> inspect base URL, policy, helper exit, and proxy logs
yes -> restore one automation, then widen gradually
Common mistakes
- Deleting a valid API key before upgrading the affected client.
- Logging helper output or custom headers while collecting incident evidence.
- Treating an undocumented variable as a supported long-term switch.
- Running
/loginand accidentally changing a headless job's credential model. - Testing only an interactive shell while CI loads a different environment.
- Retrying authentication failures indefinitely.
- Assuming every “not signed in” error is the
2.1.265regression.
Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.
FAQ
Must I remove CLAUDE_CODE_USE_GATEWAY?
Anthropic says 2.1.266 ignores the variable when it appears alone and requires no configuration change. Because the variable is undocumented, removing it from configurations you control reduces future ambiguity, but make that a separate reviewed change after recovery.
Should I rotate my API key?
Not solely because of this regression. Rotate it if it was exposed, logged, copied into an unsafe ticket, or rejected for a credential-specific reason.
Does upgrading prove the gateway is healthy?
No. It removes one client regression. You still need a successful request, the expected destination, correct credential route, and bounded retry behavior.
Top comments (0)