¿Claude Code auto mode falla en cada turno detrás de un gateway? La 2.1.317 corrige los 403/422 (actualización y pruebas)

En resumen: si usas Claude Code a través de un gateway o relay de terceros (una ANTHROPIC_BASE_URL propia) y, con el modo auto activado, cada turno falla con 403 o 422, actualiza a la 2.1.317.

• Según el CHANGELOG oficial de Claude Code, la 2.1.317 corrige «el modo auto que fallaba en cada turno cuando un gateway LLM configurado como base URL responde 403 o 422 a su comprobación de seguridad del servidor»; un 403 con apiKeyHelper no cambia. La 2.1.317 se publicó en npm el 2 de noviembre de 2026 a las 23:57 UTC.
• La tarde del 3 de noviembre (hora de Pekín) simulamos con un proxy local un gateway que rechaza la comprobación: la 2.1.316 falló en la primera petición y en cada turno siguiente; la 2.1.317 reintentó una vez sin el campo de comprobación y terminó la tarea.
• Conectado directamente a aicodewith (https://api.aicodewith.ai), el modo auto terminó la tarea tanto en 2.1.316 como en 2.1.317. Nuestra API responde 200 a la petición de comprobación y Claude Code pasa a su clasificador local.
• ¿No puedes actualizar todavía? Define CLAUDE_CODE_AUTO_MODE_SERVER=0 para que el modo auto deje de pedir la comprobación al servidor. Lo probamos en 2.1.316 y funciona.

Crear una API Key y usar Claude en Claude Code, Codex y Cursor →

Qué cambia en la 2.1.317

El modo auto es un modo de permisos de Claude Code: en lugar de aprobar tú cada acción, un clasificador comprueba en segundo plano si cada acción es segura. Según la documentación de modos de permisos, cuando ANTHROPIC_BASE_URL apunta a un gateway o proxy LLM, Claude Code primero pide al servidor esa comprobación (clasificador del servidor) y vuelve al clasificador local si el servidor no comprueba.

El problema está en ese paso: Claude Code añade a la petición un campo safeguards y una cabecera beta. Algunos gateways no los reconocen y responden 403 (rechazo) o 422 (campo no válido). Las versiones anteriores lo trataban como un fallo normal, así que fallaba cada turno.

Según el CHANGELOG, las entradas de la 2.1.317 sobre el modo auto y los gateways son:

Las versiones anteriores ya trabajaban en esta zona:

A quién afecta

Deben cumplirse las tres condiciones:

1. Usas el modo auto. Según la documentación, es el modo inicial en la terminal y VS Code desde la 2.1.283.
2. ANTHROPIC_BASE_URL apunta a un gateway LLM de terceros, un relay o un proxy de empresa.
3. Ese gateway responde 403 o 422 a las peticiones con el campo safeguards o la cabecera beta dangerous-tool-use. Causas típicas: validación estricta del cuerpo (campo desconocido → 422) o una política de seguridad (403).

Si inicias sesión directamente en la API de Anthropic, o tu gateway reenvía los campos desconocidos, no te afecta. Consulta la documentación de gateways LLM.

Cómo es la petición de comprobación

Pusimos entre Claude Code y aicodewith un proxy local que solo registra las peticiones. La primera petición de una sesión en modo auto llevaba esto (extracto):

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", ...}}]

Cuando el servidor no comprueba, las peticiones siguientes ya no llevan safeguards. Antes de cada comando Bash, Claude Code envía entonces una petición aparte al modelo del clasificador local (claude-sonnet-5 por defecto).

Pruebas: 2.1.316 frente a 2.1.317

Entorno: 3 de noviembre de 2026, 15:12–15:35 hora de Pekín, Linux, modelo claude-opus-5-5, una clave de aicodewith, un directorio de configuración nuevo en cada ejecución. La tarea pide a Claude escribir fib.py, que imprime la serie de Fibonacci, y ejecutarlo con python3: una escritura de archivo y un comando Bash que pasa por la comprobación del modo auto.

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

El «gateway simulado» es una regla que añadimos al proxy local: toda petición con el campo safeguards recibe 403 o 422, y el resto se reenvía a aicodewith. Reproduce el caso descrito en el CHANGELOG; no es el comportamiento de aicodewith.

El turno extra en la ejecución directa con 2.1.317 se debe a que Claude ejecutó el script otra vez para confirmar la salida; no tiene que ver con la versión. Todas las ejecuciones con éxito imprimieron 0, 1, 1, 2, 3, 5, 8, 13, 21, 34.

Directo a aicodewith: las dos versiones funcionan

Nuestra API responde 200 a la petición con safeguards, pero no devuelve veredicto. El log de debug muestra que Claude Code concluye que el servidor no comprueba y usa su clasificador local el resto de la sesión:

[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

Cada comprobación local de un comando Bash tardó unos 2.5–2.7 s. Al arrancar, stderr muestra un aviso de que la dirección actual no admite la nueva clasificación del servidor y de que el modo auto sigue funcionando; puedes ignorarlo.

2.1.316 detrás de un gateway que rechaza la comprobación: falla cada turno

{OLD403}

El 403 aparece como Failed to authenticate, lo que parece una clave incorrecta. La clave está bien: la misma configuración funciona en modo manual.

2.1.317: un reintento sin el campo de comprobación

Con el mismo gateway tras actualizar, el log de debug dice:

[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.

Es decir, cuando la 2.1.317 recibe un 403 o 422 que no sabe explicar, reenvía la petición una vez sin la cabecera beta dangerous-tool-use ni el campo safeguards. Si funciona, deja de pedir comprobaciones al servidor hasta reiniciar y usa el clasificador local. Las acciones se siguen comprobando, solo que en local. Para recuperar la comprobación del servidor, deja que el gateway pase esa cabecera y ese campo y reinicia Claude Code.

Un 403 con apiKeyHelper sigue fallando

El CHANGELOG dice que un 403 con apiKeyHelper no cambia, y eso vimos: la 2.1.317 reintentó 11 veces y salió con error tras unos cuatro minutos.

# 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

Con apiKeyHelper, deja que el gateway pase safeguards o usa CLAUDE_CODE_AUTO_MODE_SERVER=0 (más abajo).

Actualizar a 2.1.317

Según la documentación de instalación, la instalación nativa se actualiza en segundo plano; las instalaciones con npm, Homebrew y WinGet se actualizan a mano. Con npm usa npm install -g ...@latest, no 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 debe mostrar 2.1.317 o superior. El cask de Homebrew claude-code sigue el canal stable, normalmente una semana por detrás de latest; usa claude-code@latest para tener ya esta corrección. Dentro de una sesión, /status muestra si Auto mode server está en Enabled.

Configurar ANTHROPIC_BASE_URL y la clave

Primero crea una clave de API en aicodewith:

Crear una API Key para Claude Code →

macOS / Linux:

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

Windows PowerShell:

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

Para dejarlo fijo, ponlo en ~/.claude/settings.json. permissions.defaultMode en auto solo funciona en la configuración de usuario, no en el .claude/settings.json de un proyecto (según la documentación):

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

Más opciones (variables permanentes en Windows, modelos) en Cómo conectar Claude Code a una API de terceros.

Activar el modo auto

• Al iniciar: claude --permission-mode auto.
• En una sesión: pulsa Shift+Tab; la barra de estado muestra ⏵⏵ auto mode on.
• No interactivo (claude -p): según la entrada 2.1.302 del CHANGELOG, con proveedores de terceros, sin telemetría o en una instalación nueva empieza en default salvo que pases --permission-mode auto.
• Para cambiar el modelo del clasificador local: CLAUDE_CODE_AUTO_MODE_MODEL (2.1.302+); no afecta a la comprobación del servidor.

Si aún no puedes actualizar y tu gateway rechaza la comprobación, desactiva la comprobación del servidor y usa solo el clasificador local:

{SERVER0}

Lo probamos en 2.1.316 con los gateways simulados de 403 y 422: la tarea terminó en ambos casos.

Tabla de errores

Preguntas frecuentes

Uso aicodewith. ¿Tengo que actualizar?

En nuestras pruebas, 2.1.316 y 2.1.317 ejecutaron el modo auto sin problemas contra nuestra API, así que no te encontrarás este fallo. La 2.1.317 trae otras correcciones, así que conviene actualizar igualmente.

¿Sigue siendo seguro el modo auto después de la 2.1.317?

Las acciones se siguen comprobando. Solo desaparece el paso de «pedir al servidor»; el clasificador local revisa cada acción que lo necesita, y nuestros logs muestran una comprobación local por cada comando Bash.

¿Por qué el 403 aparece como «Failed to authenticate»?

Las versiones anteriores trataban un 403 en la comprobación del modo auto como fallo de autenticación. Si tu clave funciona, el modo manual va bien y el 403 solo aparece en modo auto, casi seguro es este problema.

¿Cómo confirmo que es este problema?

Ejecuta una vez con --debug-file y busca server-classifier y API error en el log. Si el error menciona safeguards, o la 2.1.317 escribe «sending it once more without that header and the safeguards field», el gateway está rechazando la comprobación.

¿Codex tiene algo parecido?

Codex controla la ejecución de comandos con su sandbox y su política de aprobación; consulta Configurar el sandbox y /permissions de Codex.

Más lecturas

• Claude Code Monitor: vigilar logs en Bedrock y sin telemetría desde 2.1.310
• Claude Message Threads: la beta de hilos de mensajes, con pruebas
• Cómo conectar Claude Code a una API de terceros
• Configurar el sandbox y /permissions de Codex