Claude Code auto mode failing every turn behind a gateway? 2.1.317 fixes gateway 403/422 (upgrade + tests)

Short answer: if you use Claude Code through a third-party gateway or relay (a custom ANTHROPIC_BASE_URL) and every turn fails with 403 or 422 once auto mode is on, upgrade to 2.1.317.

• According to the official Claude Code CHANGELOG, 2.1.317 fixes "auto mode failing every turn when an LLM gateway set as the base URL answers 403 or 422 to its server-side safety check"; a 403 with an apiKeyHelper is unchanged. 2.1.317 was published on npm on November 2, 2026 at 23:57 UTC.
• On the afternoon of November 3 (Beijing time) we simulated a gateway that rejects the safety check with a local proxy: 2.1.316 failed on the first request and on every turn after it; 2.1.317 retried once without the safety-check field and finished the task.
• Connected straight to aicodewith (https://api.aicodewith.ai), auto mode finished the task on both 2.1.316 and 2.1.317. Our API answers the safety-check request with 200, and Claude Code switches to its local classifier.
• Can't upgrade yet? Set CLAUDE_CODE_AUTO_MODE_SERVER=0 so auto mode stops asking the server to check actions. We tested this on 2.1.316 and it works.

Create an API Key and use Claude in Claude Code, Codex and Cursor →

What changed in 2.1.317

Auto mode is a Claude Code permission mode: instead of you approving each action, a classifier checks in the background whether each action is safe. According to the permission modes docs, when ANTHROPIC_BASE_URL points at an LLM gateway or proxy, Claude Code first asks the server to run this check (the server-side classifier) and falls back to a local classifier when the server doesn't check.

The problem is in the server-side step: Claude Code adds a safeguards field and a beta header to the request. Some gateways don't recognise them and answer 403 (refused) or 422 (invalid field). Older versions treated that as an ordinary failed request, so every turn failed.

According to the CHANGELOG, the 2.1.317 entries about auto mode and gateways are:

Earlier releases worked on the same area:

Who runs into this

All three must be true:

1. You use auto mode. According to the docs, it is the starting mode in the terminal and VS Code from 2.1.283.
2. ANTHROPIC_BASE_URL points at a third-party LLM gateway, relay or company proxy.
3. That gateway answers 403 or 422 to requests carrying the safeguards field or the dangerous-tool-use beta header. Typical causes are strict request validation (unknown field → 422) or a security policy (403).

Users signed in to the Anthropic API directly, or behind a gateway that passes unknown fields through, are not affected. See the LLM gateway docs for what a gateway should forward.

What the safety-check request looks like

We put a local proxy between Claude Code and aicodewith that only records requests. The first request of an auto mode session carried this (excerpt):

POST /v1/messages?beta=true
anthropic-beta: claude-code-20250219, ..., dangerous-tool-use-2026-09-03, afk-mode-2026-01-31

"safeguards": [{"type": "dangerous_tool_use",
                "classifier_context": {"v": 1, "permission_mode": "auto", "platform": "linux", ...}}]

When the server doesn't check, later requests drop safeguards. Before each Bash command, Claude Code then sends a separate request to the local classifier model (claude-sonnet-5 by default).

Tests: 2.1.316 vs 2.1.317

Setup: November 3, 2026, 15:12–15:35 Beijing time, Linux, model claude-opus-5-5, an aicodewith key, a fresh config directory for every run. The task asks Claude to write fib.py that prints Fibonacci numbers and run it with python3: one file write and one Bash command that goes through the auto mode check.

claude -p "Create a file fib.py that prints the first 10 Fibonacci numbers, then run it with python3 and tell me the output." \
  --permission-mode auto --model claude-opus-5-5 \
  --output-format json --debug-file ./cc-debug.log

grep -E "server-classifier|API error" ./cc-debug.log

The "simulated gateway" is a rule we added to the local proxy: any request with a safeguards field gets 403 or 422, everything else is forwarded to aicodewith. It reproduces the case in the CHANGELOG; it is not how aicodewith behaves.

The extra turn in the direct 2.1.317 run was Claude running the script a second time to confirm the output, unrelated to the version. Every successful run printed 0, 1, 1, 2, 3, 5, 8, 13, 21, 34.

Direct to aicodewith: both versions work

Our API answers the request with safeguards with 200 but returns no verdict. The debug log shows Claude Code deciding that the server doesn't check and using its local classifier for the rest of the session:

[server-classifier] the platform gave no classification for this request (server_no_result);
  treating that as this deployment's answer: auto mode classifies locally for the rest of
  this session and stops sending the classifier context
[auto-mode] new action being classified: tool=Bash actionChars=26
[Stall] classifier_request_finished tool=Bash stage=xml_s1 outcome=ok durationMs=2727

Each local check of a Bash command took about 2.5–2.7 s. At startup, stderr prints a notice that the current address doesn't support the new server-side classification and that auto mode keeps working; you can ignore it.

2.1.316 behind a gateway that rejects the check: every turn fails

{OLD403}

Note that the 403 is shown as Failed to authenticate, which looks like a wrong key. The key is fine: the same setup works in manual mode.

2.1.317: one retry without the safety-check field

With the same gateway after upgrading, the debug log reads:

[ERROR] API error (attempt 1/11): 403 403 {"type":"error","error":{"type":"permission_error",
        "message":"gateway policy: field safeguards is not allowed"}}
[WARN] [server-classifier] HTTP 403 with no cause Claude Code recognises, on a request that
       carried the dangerous-tool-use beta header; sending it once more without that header
       and the safeguards field, to learn whether they caused the refusal
[WARN] [server-classifier] a request was refused (HTTP 403) and answered when sent again
       without the dangerous-tool-use beta header and the safeguards field. Until Claude Code
       restarts, neither is sent and auto mode does not ask the server to check actions.
       To keep the check, let the gateway pass that header and field, then restart Claude Code.

So when 2.1.317 gets a 403 or 422 it can't explain, it sends the request once more without the dangerous-tool-use beta header and the safeguards field. If that works, it stops asking the server for checks until restart and uses the local classifier. Actions are still checked, just locally. To get server-side checks back, let the gateway pass that header and field, then restart Claude Code.

A 403 with apiKeyHelper still fails

The CHANGELOG says a 403 with an apiKeyHelper is unchanged, and that is what we saw: 2.1.317 retried 11 times and quit after about four minutes.

# 2.1.317 + apiKeyHelper, gateway answers 403 to the safety check
[ERROR] API error (attempt 1/11): 403 ...
...
[ERROR] API error (attempt 10/11): 403 ...
Failed to authenticate. API Error: 403 gateway policy: field safeguards is not allowed
# exit 1 after 248.4 s

With apiKeyHelper, either let the gateway pass safeguards or use CLAUDE_CODE_AUTO_MODE_SERVER=0 (below).

Upgrade to 2.1.317

According to the setup docs, native installs update in the background; npm, Homebrew and WinGet installs need a manual upgrade. With npm, use npm install -g ...@latest, not npm update -g.

# native install (curl -fsSL https://claude.ai/install.sh | bash)
claude update

# npm install
npm install -g @anthropic-ai/claude-code@latest

# Homebrew (the claude-code cask follows the stable channel)
brew upgrade claude-code@latest

# Windows WinGet
winget upgrade Anthropic.ClaudeCode

# check
claude --version
# 2.1.317 (Claude Code)

claude --version should show 2.1.317 or later. The Homebrew claude-code cask follows the stable channel, usually about a week behind latest; use claude-code@latest to get this fix now. In a session, /status shows whether Auto mode server is Enabled.

Set ANTHROPIC_BASE_URL and your key

First create an API key on aicodewith:

Create an API Key for Claude Code →

macOS / Linux:

export ANTHROPIC_BASE_URL="https://api.aicodewith.ai"
export ANTHROPIC_AUTH_TOKEN="YOUR_API_KEY"
claude --permission-mode auto

Windows PowerShell:

$env:ANTHROPIC_BASE_URL = "https://api.aicodewith.ai"
$env:ANTHROPIC_AUTH_TOKEN = "YOUR_API_KEY"
claude --permission-mode auto

To keep it, put it in ~/.claude/settings.json. permissions.defaultMode set to auto only works in user settings, not in a project's .claude/settings.json (per the docs):

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://api.aicodewith.ai",
    "ANTHROPIC_AUTH_TOKEN": "YOUR_API_KEY"
  },
  "permissions": {
    "defaultMode": "auto"
  }
}

More options (persistent Windows variables, model settings) are in How to connect Claude Code to a third-party API.

Turn on auto mode

• At launch: claude --permission-mode auto.
• In a session: press Shift+Tab; the status bar shows ⏵⏵ auto mode on.
• Non-interactive (claude -p): per the 2.1.302 CHANGELOG entry, on third-party providers, with telemetry off or on a fresh install it starts in default unless you pass --permission-mode auto.
• To change the local classifier model: set CLAUDE_CODE_AUTO_MODE_MODEL (2.1.302+); it does not affect server-side checks.

If you can't upgrade yet and your gateway rejects the check, turn off server-side checks and use only the local classifier:

{SERVER0}

We tested this on 2.1.316 with the simulated 403 and 422 gateways; the task completed both times.

Error reference

FAQ

I use aicodewith. Do I need to upgrade?

In our tests both 2.1.316 and 2.1.317 ran auto mode fine against our API, so you won't hit this bug. 2.1.317 has other fixes, so upgrading is still a good idea.

Is auto mode still safe after 2.1.317 drops the check?

Actions are still checked. Only the "ask the server" step is dropped; the local classifier reviews each action that needs checking, and our logs show one local check per Bash command.

Why is the 403 shown as "Failed to authenticate"?

Older versions treated a 403 on the auto mode safety check as an auth failure. If your key works, manual mode works, and you only get 403 in auto mode, this is most likely the cause.

How do I confirm it's this problem?

Run once with --debug-file and search the log for server-classifier and API error. If the error mentions safeguards, or 2.1.317 logs "sending it once more without that header and the safeguards field", the gateway is rejecting the safety check.

Does Codex have something similar?

Codex controls command execution with its sandbox and approval policy; see Codex sandbox and /permissions setup.

Further reading

• Claude Code Monitor: watching logs on Bedrock and with telemetry off from 2.1.310
• Claude Message Threads: the Messages API thread beta, with tests
• How to connect Claude Code to a third-party API
• Codex sandbox and /permissions setup