Un développeur a déporté l’authentification de Claude Code sur un VDS tout en conservant ses projets sur son Mac

En octobre, de nombreux utilisateurs de Claude en Russie et dans les pays voisins ont de nouveau vu leurs comptes tomber les uns après les autres. L’auteur de l’analyse publiée sur Habr a perdu son abonnement Max un jour avant le prélèvement, et l’assistance, comme il l’avait justement supposé, n’aurait rien résolu. Il a acheté un nouvel abonnement et construit une configuration dans laquelle les projets restent sur son Mac, tandis que l’authentification Anthropic et la sortie réseau se trouvent sur un serveur Linux. Il s’agit d’une expérimentation personnelle, et l’auteur souligne lui-même qu’elle ne saurait être considérée comme une procédure universelle.

Pourquoi Remote SSH et un simple proxy n’ont pas suffi

La première idée était la plus évidente : installer Claude Code sur le VDS et s’y connecter avec VS Code Remote SSH. Cela fonctionne, mais les projets présents sur le Mac n’apparaissent pas automatiquement sur le serveur. Il est possible de cloner les dépôts et de mettre en place une synchronisation, mais l’auteur ne voulait pas stocker certains fichiers sur une machine tierce. L’exigence était donc la suivante : Claude Code doit lire et modifier les fichiers sur le Mac, les requêtes au modèle doivent sortir via Linux, et l’authentification doit rester sur Linux.

La deuxième idée — installer un proxy HTTP sur le serveur — n’a pas fonctionné non plus. Un proxy modifie l’itinéraire du trafic, mais ne transmet pas au client Mac l’authentification d’un autre système. Deux composants distincts ont donc été nécessaires. CLIProxyAPI sert de passerelle : il reçoit les requêtes du Claude Code local et contacte Anthropic avec les identifiants stockés sur le serveur. Tinyproxy relaie le reste du trafic du client : recherche web, MCP et autres appels qui, sans cela, partiraient depuis l’adresse du domicile.

Architecture du dispositif

Sur le Mac, settings.json définit ANTHROPIC_BASE_URL vers un port local, HTTP_PROXY et HTTPS_PROXY vers un second port, tandis qu’apiKeyHelper fournit la clé de la passerelle. Les deux ports sont redirigés par un même tunnel SSH vers le serveur, où la passerelle et le proxy n’écoutent que sur 127.0.0.1. Un LaunchAgent établit et relance le tunnel. Le modèle lui-même, bien entendu, calcule la réponse dans le cloud d’Anthropic. La passerelle, le jeton et la sortie réseau restent sur le serveur ; les fichiers, l’agent et l’exécution des outils locaux restent sur le Mac. Seuls les fragments de fichiers sélectionnés par l’agent et les résultats des commandes locales sont envoyés au modèle.

L’auteur a effectué de nombreuses vérifications, car des pièges se présentaient à chaque étape. Il a contrôlé l’adresse IP externe via le proxy, inspecté le binaire de l’extension VS Code et confirmé que les opérations sur les fichiers s’exécutaient bien sur le Mac. Il a également lancé le client avec la passerelle et le proxy indisponibles : aucune réponse de contournement n’est arrivée, uniquement une erreur de connexion.

Là où tout a cassé

Le premier problème concernait systemd. L’importation de l’authentification dans ExecStartPre ne voyait pas la variable d’environnement nécessaire, et le service échouait avant même le démarrage de la passerelle. L’auteur a exécuté l’importation séparément, puis configuré le service pour qu’il lise un fichier auth déjà généré. Le jeton doit être renouvelé manuellement.

Le deuxième problème concernait NO_PROXY. Sans exception pour le loopback, la requête destinée à la passerelle locale passait d’abord par Tinyproxy, et plus rien ne fonctionnait.

Le troisième problème, et le plus instructif, concernait le catalogue des modèles. Le client a sollicité le modèle auxiliaire claude-haiku-5-5, absent du catalogue de CLIProxyAPI 8.0.20, et a reçu l’erreur unknown provider for model. La solution consistait à ajouter une entrée pour ce modèle au catalogue. L’auteur en conclut qu’il faut épingler les versions du client et de la passerelle, puis effectuer les mises à jour de manière délibérée.

Il existe aussi une limitation : après une mise en veille ou une coupure réseau, le tunnel se reconnecte, mais une requête au modèle déjà interrompue ne reprend pas.

Ce qu’il faut en retenir et garder à l’esprit

Ce schéma est utile au-delà du contexte des blocages. Lorsqu’il faut conserver les identifiants et la sortie réseau sur une machine, mais les fichiers et les outils sur une autre, l’architecture « agent local, passerelle derrière un tunnel SSH, proxy séparé » fonctionne. Elle montre également qu’une passerelle API et un proxy réseau répondent à des besoins différents et ne se remplacent pas mutuellement.

Cette approche comporte toutefois d’importantes réserves. L’auteur reconnaît lui-même que la présence d’un VDS ne remplace pas les exigences d’Anthropic concernant la localisation réelle de l’utilisateur et que le fait que la carte bancaire, la carte SIM et le serveur soient associés au même pays ne garantit rien. Il partage également son abonnement avec un ami, ce qui crée une autre zone de risque : services et ports communs sur un même VDS, plusieurs utilisateurs disposant d’un accès root.

Le setup-token est stocké sur le serveur, qui devient ainsi un point critique. Le contournement des restrictions régionales et le partage d’un abonnement peuvent enfreindre les conditions du service, avec le risque de perdre une nouvelle fois le compte. Les équipes devraient réserver cette architecture aux situations où elles disposent d’un accès légitime et ont besoin d’une sortie réseau centralisée, et non l’utiliser pour contourner les règles du fournisseur.

La fin de l’article publié sur Habr s’interrompt pendant l’analyse des subtilités du travail collaboratif ; nous ne disposons donc pas d’une vue complète du fonctionnement de l’accès partagé.