Sessions en arrière-plan de Claude Code et auth MCP : connecte-toi une fois, ça tourne partout.

Q: Comment authentifier des serveurs MCP sur une machine headless ?

Utilise la CLI : claude mcp login et claude mcp logout . Ces commandes gèrent l’auth en dehors de toute session, ce qu’il te faut pour les serveurs et les setups scriptés.

2026-07-16 · 5 min de lecture · par Nabil BA-MOH

Tu lances une session Claude Code en arrière-plan, elle a besoin d’un connecteur cloud, et /mcp refuse de s’ouvrir : « run /mcp from an interactive terminal to authenticate ». Ce message n’est pas un bug, et le contournement est plus simple qu’il n’y paraît. Authentifie-toi une fois dans une session interactive, et chaque session de la machine, au premier plan ou en arrière-plan, réutilise les mêmes identifiants.

Tout ce qui suit vient de sessions en arrière-plan longues que je fais tourner chaque jour, vérifié en juillet 2026.

Pourquoi /mcp refuse en arrière-plan

Depuis Claude Code v2.1.200, le menu de réglages interactif /mcp ne s’ouvre plus dans une session en arrière-plan. La raison est mécanique : les flux OAuth de MCP ouvrent un navigateur et attendent la redirection, et une session en arrière-plan n’a pas de TTY pour piloter ça. Plutôt que de bloquer ou de marcher à moitié, Claude Code te dit maintenant de le faire depuis un terminal interactif.

La restriction est donc réelle, mais elle porte sur le menu, pas sur les identifiants.

Le modèle : un seul magasin d’identifiants, chaque session le lit

Voici la partie facile à rater. Les identifiants MCP et des connecteurs vivent dans un magasin partagé sur la machine, pas à l’intérieur d’une session. Ça te donne un contrat simple :

Authentifie-toi une fois, en interactif. Ouvre une session Claude Code normale, fais le flux OAuth, c’est fait.
Toutes les autres sessions le réutilisent. Les sessions en arrière-plan lisent le même magasin. Elles n’ont jamais besoin de leur propre connexion.
Le renouvellement est automatique. Les jetons d’accès expirés sont renouvelés sans que tu fasses quoi que ce soit. Une version passée a corrigé le seul point rugueux ici : les serveurs MCP OAuth n’exigent plus de réauthentification manuelle après l’échec d’un renouvellement de jeton.
Les setups headless ont un chemin en CLI. claude mcp login <name> et claude mcp logout <name> existent pour les environnements scriptés ou distants où tu veux gérer l’auth en dehors de toute session.

Notre propre preuve : après une seule connexion interactive, des connecteurs cloud (Gmail et Google Calendar) ont continué à répondre depuis une session en arrière-plan, encore et encore, pendant des heures. Zéro demande de réauthentification, zéro surveillance.

Le bug du réveil de veille qui donnait l’impression que tout était cassé

Si tu faisais tourner des sessions en parallèle plus tôt en 2026 et que tu les as vues toutes se déconnecter d’un coup au réveil de ton ordinateur portable, c’était réel : une situation de concurrence (race) sur le magasin d’identifiants partagé. Elle a été corrigée en v2.1.211. Si tu es sur une version plus ancienne et que tu vois des déconnexions en masse au réveil, mets à jour avant d’accuser ton setup.

Règles pratiques pour les agents qui tournent longtemps

Trois règles couvrent presque toutes les pannes que tu verras vraiment :

Un 401 sur l’OAuth Anthropic tue toutes les sessions ; un seul /login les ranime toutes. Si un agent en arrière-plan qui tourne depuis longtemps meurt sur un 401, ouvre n’importe quelle session interactive, lance /login, et les agents en arrière-plan récupèrent les nouveaux identifiants. Pas besoin de les redémarrer un par un avec leur propre auth.
N’utilise jamais claude -p pour vérifier l’état d’un connecteur. Une sonde headless en un coup ne monte pas du tout les connecteurs cloud. Elle te dira que le connecteur manque alors qu’il va très bien. C’est le mauvais instrument, pas un diagnostic.
Les tâches de fond du daemon montent bien les connecteurs. Les sessions en arrière-plan longues ont accès à tous les connecteurs. La différence tient au type de session, pas à « arrière-plan contre premier plan ».

Le principe, en une ligne

Les sessions interactives sont l’endroit où l’auth naît ; les sessions en arrière-plan sont l’endroit où elle sert. Construis ton setup autour de cette séparation et l’auth MCP cesse d’être un sujet.

Ça compte pour nous parce que Klyr s’appuie sur les sessions en arrière-plan : les passes de mémoire et les heartbeats qui gardent à jour ce que sait ton assistant tournent sans surveillance, avec des connecteurs que tu as autorisés une seule fois. Si ton assistant doit continuer à travailler quand tu ne le regardes pas, c’est ce modèle d’auth qui rend ça ennuyeux et fiable. Les tarifs pour les particuliers et les équipes sont sur la page d’accueil.

Tu fais tourner de longues sessions ? Tu voudras aussi le seuil d’auto-compact qui existe vraiment.

FAQ

Pourquoi /mcp affiche « run /mcp from an interactive terminal to authenticate » ?

Depuis Claude Code v2.1.200, le menu de réglages interactif /mcp refuse de s’ouvrir dans les sessions en arrière-plan, parce que l’OAuth a besoin d’un flux dans le navigateur qu’une session en arrière-plan ne peut pas piloter. Authentifie-toi plutôt dans n’importe quelle session interactive ; les sessions en arrière-plan réutilisent le résultat.

Les sessions Claude Code en arrière-plan partagent-elles les identifiants MCP avec les sessions interactives ?

Oui. Les identifiants vivent dans un magasin partagé sur la machine. Connecte-toi une fois en interactif et chaque session, au premier plan ou en arrière-plan, utilise les mêmes identifiants, avec renouvellement automatique des jetons.

Comment authentifier des serveurs MCP sur une machine headless ?

Utilise la CLI : claude mcp login <name> et claude mcp logout <name>. Ces commandes gèrent l’auth en dehors de toute session, ce qu’il te faut pour les serveurs et les setups scriptés.

Mon agent en arrière-plan est mort sur un 401. Je dois tout redémarrer ?

Non. Lance /login dans n’importe quelle session interactive. Le magasin d’identifiants partagé est rafraîchi et les agents en arrière-plan le récupèrent. Une seule connexion ranime tout.

Je peux vérifier l’état des connecteurs avec `claude -p` ?

Non. Les sondes headless en un coup ne montent pas les connecteurs cloud, donc ils ont toujours l’air absents. Seule une vraie session, interactive ou tâche de fond du daemon, reflète l’état réel des connecteurs.

Pourquoi toutes mes sessions en parallèle se sont déconnectées au réveil de mon portable ?

Une situation de concurrence sur le magasin d’identifiants partagé, corrigée dans Claude Code v2.1.211. Mets à jour si tu vois encore des déconnexions en masse au réveil.