Claude Code auto mode échoue à chaque tour derrière une passerelle ? La 2.1.317 corrige les 403/422 (mise à jour et tests)

En bref : si vous utilisez Claude Code via une passerelle ou un relais tiers (une ANTHROPIC_BASE_URL personnalisée) et que chaque tour échoue en 403 ou 422 dès que le mode auto est actif, passez à la 2.1.317.

• Selon le CHANGELOG officiel de Claude Code, la 2.1.317 corrige « le mode auto qui échoue à chaque tour quand une passerelle LLM définie comme base URL répond 403 ou 422 à sa vérification de sécurité côté serveur » ; un 403 avec apiKeyHelper reste inchangé. La 2.1.317 a été publiée sur npm le 2 novembre 2026 à 23:57 UTC.
• Le 3 novembre après-midi (heure de Pékin), nous avons simulé avec un proxy local une passerelle qui rejette la vérification : la 2.1.316 échoue dès la première requête puis à chaque tour ; la 2.1.317 réessaie une fois sans le champ de vérification et termine la tâche.
• En connexion directe à aicodewith (https://api.aicodewith.ai), le mode auto a terminé la tâche en 2.1.316 comme en 2.1.317. Notre API répond 200 à la requête de vérification et Claude Code passe à son classifieur local.
• Impossible de mettre à jour tout de suite ? Définissez CLAUDE_CODE_AUTO_MODE_SERVER=0 pour que le mode auto ne demande plus la vérification au serveur. Testé et fonctionnel sur 2.1.316.

Créer une API Key et utiliser Claude dans Claude Code, Codex et Cursor →

Ce qui change dans la 2.1.317

Le mode auto est un mode de permissions de Claude Code : au lieu de valider chaque action vous-même, un classifieur vérifie en arrière-plan si chaque action est sûre. Selon la documentation des modes de permissions, quand ANTHROPIC_BASE_URL pointe vers une passerelle ou un proxy LLM, Claude Code demande d'abord au serveur de faire cette vérification (classifieur côté serveur), et revient au classifieur local si le serveur ne vérifie pas.

Le problème se situe à cette étape : Claude Code ajoute un champ safeguards et un en-tête beta à la requête. Certaines passerelles ne les reconnaissent pas et répondent 403 (refus) ou 422 (champ invalide). Les anciennes versions traitaient cela comme un échec ordinaire, d'où un échec à chaque tour.

Selon le CHANGELOG, les entrées de la 2.1.317 liées au mode auto et aux passerelles sont :

Les versions précédentes touchaient déjà ce sujet :

Qui est concerné

Les trois conditions doivent être réunies :

1. Vous utilisez le mode auto. Selon la documentation, c'est le mode de départ dans le terminal et VS Code depuis la 2.1.283.
2. ANTHROPIC_BASE_URL pointe vers une passerelle LLM tierce, un relais ou un proxy d'entreprise.
3. Cette passerelle répond 403 ou 422 aux requêtes qui portent le champ safeguards ou l'en-tête beta dangerous-tool-use. Causes typiques : validation stricte du corps (champ inconnu → 422) ou politique de sécurité (403).

Les utilisateurs connectés directement à l'API Anthropic, ou derrière une passerelle qui transmet les champs inconnus, ne sont pas concernés. Voir la documentation sur les passerelles LLM.

À quoi ressemble la requête de vérification

Nous avons placé entre Claude Code et aicodewith un proxy local qui se contente d'enregistrer les requêtes. La première requête d'une session en mode auto contenait ceci (extrait) :

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

Quand le serveur ne vérifie pas, les requêtes suivantes n'ont plus safeguards. Avant chaque commande Bash, Claude Code envoie alors une requête séparée au modèle du classifieur local (claude-sonnet-5 par défaut).

Tests : 2.1.316 contre 2.1.317

Conditions : 3 novembre 2026, 15:12–15:35 heure de Pékin, Linux, modèle claude-opus-5-5, une clé aicodewith, un dossier de configuration neuf à chaque essai. La tâche demande à Claude d'écrire fib.py qui affiche la suite de Fibonacci et de l'exécuter avec python3 : une écriture de fichier et une commande Bash qui passe par la vérification du mode 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

La « passerelle simulée » est une règle ajoutée au proxy local : toute requête avec un champ safeguards reçoit 403 ou 422, le reste est transmis à aicodewith. Elle reproduit le cas décrit dans le CHANGELOG ; ce n'est pas le comportement d'aicodewith.

Le tour supplémentaire de l'essai direct en 2.1.317 vient de Claude qui a relancé le script pour confirmer la sortie, sans lien avec la version. Chaque essai réussi a affiché 0, 1, 1, 2, 3, 5, 8, 13, 21, 34.

Direct vers aicodewith : les deux versions fonctionnent

Notre API répond 200 à la requête avec safeguards mais ne renvoie pas de verdict. Le journal de debug montre que Claude Code constate l'absence de vérification serveur et utilise son classifieur local pour le reste de la 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

Chaque vérification locale d'une commande Bash a pris environ 2.5–2.7 s. Au démarrage, stderr affiche un avis indiquant que l'adresse actuelle ne prend pas en charge la nouvelle classification côté serveur et que le mode auto continue de fonctionner ; vous pouvez l'ignorer.

2.1.316 derrière une passerelle qui rejette la vérification : chaque tour échoue

{OLD403}

Le 403 s'affiche comme Failed to authenticate, ce qui fait penser à une mauvaise clé. La clé est bonne : la même configuration fonctionne en mode manuel.

2.1.317 : une nouvelle tentative sans le champ de vérification

Avec la même passerelle après mise à jour, le journal de debug donne :

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

Quand la 2.1.317 reçoit un 403 ou 422 qu'elle ne sait pas expliquer, elle renvoie la requête une fois sans l'en-tête beta dangerous-tool-use ni le champ safeguards. Si cela passe, elle ne demande plus de vérification au serveur jusqu'au redémarrage et utilise le classifieur local. Les actions restent vérifiées, localement. Pour retrouver la vérification serveur, laissez la passerelle transmettre cet en-tête et ce champ, puis redémarrez Claude Code.

Un 403 avec apiKeyHelper échoue toujours

Le CHANGELOG indique qu'un 403 avec apiKeyHelper est inchangé, et c'est ce que nous avons observé : la 2.1.317 a réessayé 11 fois et s'est arrêtée au bout d'environ quatre 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

Avec apiKeyHelper, laissez la passerelle transmettre safeguards, ou utilisez CLAUDE_CODE_AUTO_MODE_SERVER=0 (plus bas).

Mettre à jour vers 2.1.317

Selon la documentation d'installation, l'installation native se met à jour en arrière-plan ; les installations npm, Homebrew et WinGet se mettent à jour à la main. Avec npm, utilisez npm install -g ...@latest, pas 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 doit afficher 2.1.317 ou plus. Le cask Homebrew claude-code suit le canal stable, en général environ une semaine derrière latest ; prenez claude-code@latest pour avoir ce correctif tout de suite. Dans une session, /status indique si Auto mode server est Enabled.

Configurer ANTHROPIC_BASE_URL et la clé

Créez d'abord une clé API sur aicodewith :

Créer une API Key pour Claude Code →

macOS / Linux :

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

Windows PowerShell :

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

Pour la garder, mettez-la dans ~/.claude/settings.json. permissions.defaultMode à auto ne fonctionne que dans les réglages utilisateur, pas dans le .claude/settings.json d'un projet (selon la documentation) :

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

Plus d'options (variables Windows permanentes, modèles) dans Connecter Claude Code à une API tierce.

Activer le mode auto

• Au lancement : claude --permission-mode auto.
• Dans une session : appuyez sur Shift+Tab ; la barre d'état affiche ⏵⏵ auto mode on.
• En non interactif (claude -p) : d'après l'entrée 2.1.302 du CHANGELOG, chez les fournisseurs tiers, sans télémétrie ou sur une installation neuve, la session démarre en default sauf si vous passez --permission-mode auto.
• Pour changer le modèle du classifieur local : CLAUDE_CODE_AUTO_MODE_MODEL (2.1.302+) ; cela ne touche pas la vérification serveur.

Si vous ne pouvez pas encore mettre à jour et que votre passerelle rejette la vérification, désactivez la vérification serveur et gardez seulement le classifieur local :

{SERVER0}

Testé sur 2.1.316 avec les passerelles simulées 403 et 422 : la tâche a abouti les deux fois.

Tableau des erreurs

FAQ

J'utilise aicodewith. Dois-je mettre à jour ?

Dans nos tests, 2.1.316 et 2.1.317 ont fait tourner le mode auto sans problème sur notre API : vous ne rencontrerez pas ce bug. La 2.1.317 contient d'autres correctifs, la mise à jour reste conseillée.

Le mode auto reste-t-il sûr après la 2.1.317 ?

Les actions sont toujours vérifiées. Seule l'étape « demander au serveur » disparaît ; le classifieur local examine chaque action concernée, et nos journaux montrent une vérification locale par commande Bash.

Pourquoi le 403 s'affiche-t-il comme « Failed to authenticate » ?

Les anciennes versions traitaient un 403 reçu sur la vérification du mode auto comme un échec d'authentification. Si votre clé fonctionne, que le mode manuel marche et que le 403 n'apparaît qu'en mode auto, c'est très probablement ce problème.

Comment confirmer qu'il s'agit de ce problème ?

Lancez une fois avec --debug-file et cherchez server-classifier et API error dans le journal. Si l'erreur mentionne safeguards, ou si la 2.1.317 écrit « sending it once more without that header and the safeguards field », la passerelle rejette la vérification.

Codex a-t-il un réglage équivalent ?

Codex contrôle l'exécution des commandes par son bac à sable et sa politique d'approbation ; voir Configurer le bac à sable et /permissions de Codex.

Pour aller plus loin

• Claude Code Monitor : surveiller les logs sur Bedrock et sans télémétrie depuis 2.1.310
• Claude Message Threads : la beta des fils de messages, avec tests
• Connecter Claude Code à une API tierce
• Configurer le bac à sable et /permissions de Codex