Erreur 403 dans Claude Code : région, passerelle, TLS ou connexion ?

Un HTTP 403 dans Claude Code ne prouve pas, à lui seul, que votre compte est bloqué. Utilisez Claude Code 2.1.318 ou une version ultérieure pour bénéficier des correctifs de diagnostic, de passerelles et de certificats décrits ici. Suivez ensuite les vérifications correspondant au message d’erreur plutôt que de vous reconnecter sans cesse.

Les notes de version 2.1.317 distinguent les blocages régionaux ou réseau des échecs d’authentification. Les notes de version 2.1.318 améliorent la gestion des fichiers de certificats défectueux et clarifient les erreurs de sessions enregistrées qui ont expiré. Ces changements aident à identifier les pannes. Ils ne lèvent pas les restrictions d’accès et ne corrigent pas toutes les configurations de passerelles.

Commencez par la version corrigée et une petite requête

Au 2026-11-10, 2.1.318 est la version minimale qui réunit ces correctifs, pas nécessairement la version la plus récente. Chaque correctif est apparu pour la première fois dans les versions ci-dessous.

Symptôme	Première version contenant le correctif correspondant	Première vérification
Un HTTP 403 lié à un blocage régional ou réseau apparaît comme un échec d’authentification	2.1.317	Lisez l’explication du blocage et identifiez le service qui répond
VS Code ouvre l’écran de connexion après un blocage régional ou réseau	2.1.317	Réessayez depuis l’interface VS Code concernée
Auto échoue à chaque tour lorsque la passerelle définie comme Base URL répond 403 ou 422 au contrôle de sécurité	2.1.317	Comparez Manual et Auto ; l’exception du 403 avec apiKeyHelper reste valable
unable to get local issuer certificate apparaît après le renouvellement du certificat racine d’un proxy avec inspection TLS	2.1.317	Vérifiez la chaîne de certificats approuvée et la version du client
Le fichier NODE_EXTRA_CA_CERTS est vide, n’est pas au format PEM ou commence par un certificat endommagé, ce qui fait échouer les connexions	2.1.318	Corrigez le fichier et examinez les avertissements au démarrage
Une passerelle Claude apps gateway obligatoire est inaccessible	2.1.317	Vérifiez le chemin réseau et la confiance accordée au certificat
La session claude.ai enregistrée atteint sa limite de validité	2.1.318	Renouvelez la session active plutôt que de modifier le réseau

Dans Bash, vérifiez le CLI que vous utilisez réellement :

claude --version
claude auth status

La référence du CLI décrit claude auth status comme un rapport sur l’état de l’authentification. Ce résultat renseigne sur l’authentification configurée. Il ne prouve pas que les requêtes au modèle fonctionnent.

Utilisez la méthode de mise à jour prévue pour votre installation. Pour une installation native, exécutez :

claude update
claude --version

Pour une installation via un gestionnaire de paquets ou administrée de façon centralisée, suivez les instructions d’installation et de mise à jour. Vérifiez que la version affichée atteint le minimum requis. Réessayez dans l’interface qui a échoué : un test réussi dans le terminal ne valide pas la connexion depuis VS Code.

Envoyez ensuite une petite requête depuis le même environnement Bash :

claude -p 'Reply with exactly OK. Do not use tools.'

Le résultat attendu est OK, sans erreur de connexion ni d’authentification. Ce test vérifie une requête simple au modèle. Il ne teste pas le mécanisme de contrôle d’Auto et ne valide pas toutes les fonctionnalités.

Un blocage régional ou réseau n’est pas une session expirée

Examinez le réseau ou le motif du refus d’accès lorsque l’erreur signale un blocage. Se réauthentifier n’est pas la première réponse à ce symptôme.

Le journal des modifications de 2.1.317 indique, en traduction :

Correction d’un problème qui présentait un blocage régional ou réseau (HTTP 403) comme un échec d’authentification. L’erreur explique désormais le blocage.

La même version corrige séparément l’ouverture de l’écran de connexion de VS Code dans cette situation. Aucune de ces entrées n’affirme que la mise à jour autorise une requête bloquée.

Lancez Claude Code et exécutez /status. Vérifiez la route active et l’origine des identifiants à l’aide des instructions de connexion à une passerelle. Avant d’examiner le compte, déterminez si la requête va directement à Anthropic ou à la passerelle configurée.

Sur un réseau d’entreprise, demandez au service informatique de vérifier les paramètres de proxy utilisés par le processus concerné. Cela inclut HTTPS_PROXY et HTTP_PROXY, décrits dans le guide de configuration réseau. Si le blocage régional est confirmé, vérifiez la disponibilité du service auprès du fournisseur plutôt que de renouveler les identifiants à répétition.

Conservez le corps de la réponse, le nom d’hôte de destination, l’horodatage et l’identifiant de requête, lorsqu’il est disponible. N’envoyez pas de copie complète de l’environnement, d’identifiants secrets ou de prompts complets dans un ticket d’assistance.

Un avis explicite de suspension du compte relève de l’assistance aux comptes. La référence des erreurs d’Anthropic décrit cette situation comme un compte suspendu. Une autre possibilité est l’absence d’accès au modèle demandé. Le guide d’installation et d’authentification documente des erreurs 403 après une authentification réussie lorsque le compte ne peut pas utiliser ce modèle.

Pour vérifier, envoyez une autre petite requête par la route prévue et approuvée. Si elle renvoie encore 403, utilisez l’explication actuelle et les journaux du fournisseur pour identifier le motif du refus. Ne concluez pas à un blocage du compte à partir du seul code d’état.

Auto échoue à chaque tour via une passerelle

Examinez le contrôle de sécurité lorsque Manual fonctionne, mais qu’Auto échoue systématiquement via la même passerelle. Le correctif de 2.1.317 a un périmètre précis. Traduction de l’entrée :

Correction de l’échec d’Auto à chaque tour lorsqu’une passerelle LLM définie comme URL de base répond 403 ou 422 au contrôle de sécurité côté serveur. Le comportement d’un 403 avec apiKeyHelper reste inchangé.

Cette exception compte. Un 403 lorsque apiKeyHelper est actif n’est pas couvert par ce changement. Demandez au responsable de la passerelle de vérifier les identifiants et le mécanisme d’autorisation sans exposer les secrets renvoyés par cet utilitaire.

Le guide de compatibilité des passerelles mentionne une valeur anthropic-beta et un champ de requête safeguards pour le contrôle côté serveur. Le rejet de cette fonctionnalité ne s’analyse pas comme le rejet d’un identifiant. Le code d’état ne permet pas, à lui seul, de savoir lequel s’est produit.

Comparez deux sessions dans une copie de travail d’un dépôt Git de confiance. Gardez le même modèle, le même endpoint, les mêmes identifiants et la même tâche.

Lancez claude --permission-mode default. Demandez à Claude d’exécuter git status --short avec Bash et d’en rapporter le résultat sans modifier de fichiers. Approuvez la demande d’autorisation si elle apparaît.

Quittez cette session, puis lancez claude --permission-mode auto et répétez la tâche. Confirmez que le mode demandé est actif à l’aide des commandes de gestion des modes d’autorisation. Une session qui n’est pas passée en Auto ne permet pas de valider ce mode.

Si seule la session Auto échoue, retrouvez la requête en échec dans les journaux de la passerelle. Demandez à son opérateur d’examiner le refus en suivant le guide de compatibilité. Cette comparaison réduit le champ de recherche. Elle ne prouve pas quelle règle précise de la passerelle a provoqué l’échec.

Avec l’accord de votre administrateur, vous pouvez temporairement utiliser les requêtes du classificateur de Claude Code à la place du contrôle côté serveur :

CLAUDE_CODE_AUTO_MODE_SERVER=0 claude --permission-mode auto

La référence des variables d’environnement documente ce réglage. Il change l’endroit où le contrôle a lieu ; il ne désactive pas la vérification des autorisations. Le classificateur continue d’envoyer des requêtes au modèle. Examinez leur consommation et leur latence avant de conserver ce réglage.

Si cette session fonctionne alors qu’Auto sans ce réglage échoue, examinez la compatibilité avec le contrôle côté serveur. Si les deux échouent, examinez l’erreur d’identifiants, de modèle ou de passerelle indiquée. Ne présumez pas que ce correctif s’applique.

Pour les différences de facturation, consultez la facturation du classificateur côté serveur et le comportement de repli. Les requêtes distinctes du classificateur ne constituent pas une solution hors ligne ni nécessairement gratuite.

Corrigez la confiance dans les certificats, pas l’authentification

Traitez unable to get local issuer certificate comme un problème de confiance dans les certificats. Cette panne se situe à un autre niveau qu’une réponse HTTP concernant l’autorisation.

Le journal des modifications de 2.1.317 indique, en traduction :

Correction des requêtes API échouant avec “unable to get local issuer certificate” derrière certains proxies avec inspection TLS après le renouvellement d’un certificat racine.

Ce correctif couvre le problème de renouvellement décrit. Il ne signifie pas que toutes les erreurs de certificat d’émetteur ont cette cause.

Confirmez d’abord la version du client. Demandez ensuite au service informatique si le certificat racine du proxy a changé et quel ensemble de certificats d’autorités de certification le client doit accepter. Utilisez un fichier PEM approuvé plutôt qu’un certificat copié depuis une source non vérifiée.

Si votre environnement exige un ensemble de certificats personnalisé, enregistrez le fichier fourni par le service informatique dans $HOME/company-ca.pem. Lancez un nouveau processus Claude Code depuis le même shell Bash :

export NODE_EXTRA_CA_CERTS="$HOME/company-ca.pem"
claude -p 'Reply with exactly OK. Do not use tools.'

Cette procédure suit la configuration documentée des CA personnalisées. Le chemin de l’exemple est un nom de fichier local que vous choisissez. Les certificats doivent provenir de votre organisation.

Le test est réussi si la requête aboutit sans erreur de certificat d’émetteur. Si elle échoue encore, demandez au service informatique de vérifier le fichier fourni et la chaîne de certificats présentée via le proxy.

Ne définissez pas NODE_TLS_REJECT_UNAUTHORIZED=0. Les instructions d’Anthropic sur les erreurs de certificats avertissent que ce réglage désactive la validation des certificats.

Fichiers NODE_EXTRA_CA_CERTS vides ou endommagés

Utilisez 2.1.318 ou une version ultérieure lorsque le fichier de CA supplémentaires est lui-même mal formé. Son journal des modifications indique, en traduction :

Correction de l’échec de toutes les connexions lorsque le fichier NODE_EXTRA_CA_CERTS est vide, n’est pas au format PEM ou commence par un certificat endommagé. Les certificats lisibles sont désormais utilisés, avec un avertissement sur stderr.

Examinez les avertissements en plus du résultat final de la connexion. Le correctif utilise les certificats lisibles. Il ne répare pas le fichier et ne fournit pas un certificat manquant dont votre proxy a besoin.

Remplacez le fichier vide ou endommagé par le fichier PEM approuvé. Supprimez un réglage involontaire de NODE_EXTRA_CA_CERTS seulement après avoir confirmé que l’environnement n’en a pas besoin. Lancez ensuite un nouveau processus et répétez la petite requête.

Si une requête aboutit, mais que l’avertissement sur le fichier de certificats persiste, corrigez ce fichier avant de considérer la configuration comme terminée.

Une passerelle Claude apps gateway obligatoire est inaccessible

Rétablissez la connexion à la passerelle obligatoire avant de modifier une authentification qui fonctionne. L’entrée de 2.1.317 indique, en traduction :

Amélioration de l’erreur au démarrage lorsqu’une passerelle Claude apps gateway obligatoire est inaccessible. Elle désigne désormais le réseau plutôt que l’authentification et précise lorsque le certificat TLS de la passerelle ne peut pas être vérifié.

Cette entrée concerne une passerelle Claude apps gateway obligatoire. Ne l’appliquez pas automatiquement à tous les endpoints tiers configurés dans ANTHROPIC_BASE_URL.

Transmettez à l’administrateur de la passerelle le nom d’hôte concerné et l’erreur débarrassée des données sensibles. Demandez-lui de vérifier l’accessibilité du service, DNS, la politique du proxy et la confiance dans le certificat. Si le message signale un problème de vérification du certificat, suivez les vérifications des CA plutôt que de réinitialiser les identifiants.

La vérification se fait en deux étapes : Claude Code doit démarrer sans l’erreur de passerelle, puis terminer la petite requête au modèle. Une erreur d’authentification qui apparaît ensuite constitue un autre problème à examiner.

Renouvelez la session seulement si cet identifiant a expiré

Renouvelez la session claude.ai enregistrée lorsque l’erreur indique son expiration. Les notes de version 2.1.318 distinguent ce cas du blocage réseau. Traduction :

Correction de l’échec d’authentification lorsqu’une session claude.ai enregistrée atteint sa limite de validité. Le message l’indique désormais et, dans claude -p, cite claude auth login et claude setup-token.

Pour un usage interactif qui doit utiliser votre session claude.ai, exécutez ces commandes dans Bash :

claude auth login
claude auth status
claude -p 'Reply with exactly OK. Do not use tools.'

Terminez l’authentification avant de vérifier l’état et d’envoyer la requête. Le résultat attendu est l’état d’authentification prévu, suivi d’une réponse réussie.

La version cite aussi claude setup-token pour rétablir l’accès dans un environnement non interactif. Suivez les instructions d’authentification adaptées à cet usage plutôt que d’insérer un jeton dans un script.

Un identifiant émis par une passerelle doit être rétabli auprès de son émetteur. Vous connecter à claude.ai ne permet pas de tester cet identifiant. Si la session renouvelée produit encore une erreur de région, de réseau ou de passerelle, revenez aux vérifications correspondantes plutôt que de recommencer l’authentification.

Vérifiez ANTHROPIC_BASE_URL et l’identifiant actif

Vérifiez la route depuis la session qui échoue avant de modifier d’autres réglages. Le guide de connexion recommande /status pour examiner la valeur effective de Base URL et l’origine de l’identifiant.

Utilisez l’adresse de base compatible avec Anthropic documentée par la passerelle. Le guide du protocole associe ANTHROPIC_BASE_URL au format Anthropic Messages et à /v1/messages. Ne copiez pas une URL compatible avec OpenAI dans cette configuration sans vérifier le protocole. Le guide de dépannage de Base URL et des endpoints explique cette différence.

Choisissez la variable d’authentification selon l’en-tête exigé par la passerelle. Anthropic documente ANTHROPIC_AUTH_TOKEN pour l’en-tête Authorization: Bearer et ANTHROPIC_API_KEY pour X-Api-Key. Suivez les instructions de la passerelle plutôt que de placer le même identifiant dans toutes les variables disponibles.

Pour une connexion existante à l’API BetterToken, ses instructions pour Claude Code utilisent https://bettertoken.ai, sans /v1, et ANTHROPIC_AUTH_TOKEN. Au 2026-11-10, son catalogue répertorie claude-sonnet-5-5. Il s’agit d’un accès API distinct, pas d’un abonnement Claude ni d’une garantie de compatibilité avec toutes les fonctionnalités de Claude Code.

Si la route effective diffère de la configuration prévue, suivez la procédure de vérification du fournisseur actif dans Claude Code. Retrouvez une petite requête dans les journaux du fournisseur prévu, puis répétez l’opération précise qui avait échoué. Une réponse simple suffit pour vérifier une connexion de base. Un incident en mode Auto exige aussi que la comparaison avec Auto réussisse.