Application de bureau

Tirez le meilleur parti de Claude Code Desktop : sessions parallèles avec isolation Git, disposition des volets par glisser-déposer, terminal intégré et éditeur de fichiers, chats latéraux, utilisation informatique, sessions Dispatch depuis votre téléphone, examen visuel des différences, aperçus d'applications, surveillance des PR, connecteurs et configuration d'entreprise.

Dans l'application Claude Desktop, Claude Code correspond à l'onglet Code. L'application propose également le chat et Cowork, qui gère Dispatch et les travaux agentiques plus longs. Cette page est la référence pour l'onglet Code.

Télécharger pour macOS

Build universel pour Intel et Apple Silicon

Télécharger pour Windows

Pour les processeurs x64

Obtenir Claude pour Linux (bêta)

apt ou .deb pour Ubuntu et Debian

Pour Windows ARM64, téléchargez l'installateur ARM64. Sur Linux, installez avec apt ; voir Claude Desktop sur Linux.

Après l'installation, lancez Claude, connectez-vous et cliquez sur l'onglet Code. Pour une présentation de votre première session, consultez le guide Démarrer.

Dans l'onglet Code, chaque conversation est une session : elle a son propre historique de chat et dossier de projet, indépendants de toute autre session. La barre latérale répertorie vos sessions et vous permet d'en exécuter plusieurs en parallèle. Au sein d'une session, vous pouvez :

• Examiner et commenter les différences, puis surveiller la PR résultante via CI
• Prévisualiser votre application en cours d'exécution dans le volet Navigateur tandis que Claude vérifie ses propres modifications, et ouvrir des sites externes à côté
• Regarder Claude exécuter et tester votre application iOS dans le volet iOS Simulator
• Arranger les volets pour le chat, la différence, le navigateur, le terminal et l'éditeur de fichiers côte à côte
• Poser une question latérale qui utilise le contexte de la session sans la dérailler
• Laisser Claude vérifier, envoyer un message ou archiver vos autres sessions
• Connecter des outils externes comme GitHub, Slack et Linear
• Laisser Claude ouvrir des applications et contrôler votre écran
• Exécuter sur votre machine, dans le cloud, ou via SSH

Pour les travaux récurrents planifiés, les raccourcis clavier, ou l'envoi de tâches depuis votre téléphone, consultez les pages et sections liées. Si vous utilisez déjà le CLI basé sur le terminal, consultez la comparaison CLI pour voir ce qui est transféré.

Démarrer une session

Avant d'envoyer votre premier message, choisissez l'environnement, le dossier du projet, le mode de permission et le modèle dans la rangée située sous la zone de prompt :

• Environnement : utilisez le sélecteur d'environnement, premier contrôle de la rangée, pour choisir où Claude s'exécute. Voir configuration de l'environnement.
  • Si une nouvelle session n'affiche aucun sélecteur d'environnement sous la zone de prompt, suivez les étapes de l'ancienne disposition.
• Dossier du projet : cliquez sur le contrôle du dossier du projet, à côté du sélecteur d'environnement, pour choisir le dossier dans lequel Claude travaille.
  • Session cloud : sélectionnez des dépôts au lieu d'un dossier
  • Environnement local ou SSH enregistré : l'environnement contient déjà ses dossiers, la rangée n'affiche donc aucun contrôle de dossier du projet. Pour modifier les dossiers, modifiez l'environnement.
• Mode de permission : utilisez le sélecteur de mode pour choisir le niveau d'autonomie de Claude. Vous pouvez modifier le mode de permission pendant la session.
• Modèle : choisissez un modèle dans le sélecteur de modèle situé vers l'extrémité droite de la rangée. Vous pouvez modifier le modèle pendant la session.

Tapez votre tâche et appuyez sur Entrée pour démarrer. Chaque session suit son propre contexte et les modifications indépendamment.

Travailler avec le code

Donnez à Claude le bon contexte, contrôlez le volume de travail qu'il effectue seul et examinez ce qu'il a modifié.

Utiliser la zone de prompt

Tapez ce que vous voulez que Claude fasse et appuyez sur Entrée pour envoyer. Claude lit vos fichiers de projet, effectue des modifications et exécute des commandes en fonction de votre mode de permission. Vous pouvez rediriger Claude à tout moment : cliquez sur le bouton d'arrêt pour interrompre immédiatement, ou tapez une correction et appuyez sur Entrée pour l'envoyer sans arrêter l'action en cours. Claude lit la correction dès que l'action actuelle se termine et s'ajuste avant son étape suivante.

Le bouton + à côté de la zone de prompt vous donne accès aux pièces jointes de fichiers, skills, connecteurs et plugins.

Accepter un prompt suggéré

Après la réponse de Claude, l'onglet Code peut afficher un prompt suivant suggéré sous forme de texte gris dans la zone de prompt vide. Claude Code génère chaque suggestion à partir de votre conversation grâce à une courte requête en arrière-plan qui est décomptée des limites d'utilisation de votre forfait ou de vos coûts d'API.

• Utiliser la suggestion : appuyez sur Tab ou Flèche droite pour la placer dans la zone de prompt, modifiez-la si vous le souhaitez, puis appuyez sur Entrée pour l'envoyer. Appuyer sur Entrée avant d'accepter la suggestion ne l'envoie pas.
• Rédiger votre propre prompt : commencez à taper. La suggestion s'affiche uniquement tant que la zone de prompt est vide et ne contient aucun fichier joint.

Accédez à Paramètres > Claude Code et désactivez Suggestions de prompts sous Sessions pour arrêter les suggestions dans chaque session à partir de son prochain démarrage ou de sa prochaine reprise.

Ajouter des fichiers et du contexte aux prompts

Pour fournir un fichier à Claude, mentionnez-le avec @ ou joignez-le dans la zone de prompt :

• Mentionner des fichiers avec @ : tapez @ suivi d'un nom de fichier pour ajouter un fichier au contexte de la conversation.
  • Dans une session cloud : @ ne peut lister les fichiers qu'après l'envoi de votre premier message. Si @ n'en liste aucun, envoyez votre premier message sans le fichier, puis mentionnez le fichier avec @ dans votre message suivant.
• Joindre des fichiers : joignez des images, des PDF et d'autres fichiers à votre prompt à partir du bouton + à côté de la zone de prompt, ou glissez-déposez les fichiers directement dans le prompt. Ceci est utile pour partager des captures d'écran de bugs, des maquettes de conception ou des documents de référence.
  • Dans une session WSL : si le menu + affiche Ajouter une image au lieu de Ajouter des fichiers ou des photos, vous ne pouvez joindre que des images. Pour fournir à Claude tout autre fichier du dossier de la session, mentionnez-le avec @.

Choisir un mode de permission

Les modes de permission contrôlent le niveau d'autonomie de Claude pendant une session : s'il demande avant de modifier des fichiers, d'exécuter des commandes ou les deux. Vous pouvez changer de mode de permission à tout moment en utilisant le sélecteur de mode dans la ligne située sous la zone de prompt. Pour approuver chaque modification vous-même, passez à Manuel.

Pour définir un mode par défaut pour les nouvelles sessions locales, ajoutez permissions.defaultMode à votre fichier de paramètres. L'application de bureau lit les mêmes fichiers de paramètres que la CLI. Un mode que vous choisissez dans le sélecteur est mémorisé par dossier et a priorité sur defaultMode pour ce dossier, sauf Plan, qui s'applique à la session actuelle uniquement.

Les versions antérieures de l'onglet Code étiquetaient ces modes Demander les permissions, Accepter automatiquement les modifications et Plan mode.

Le mode de permission dontAsk est disponible uniquement dans la CLI.

[!TIP]

Commencez les tâches complexes en Plan pour que Claude trace une approche avant de faire des modifications. Une fois que vous approuvez le plan, passez à Accepter les modifications ou Manuel pour l'exécuter. Voir explorer d'abord, puis planifier, puis coder pour plus d'informations sur ce workflow.

Les sessions cloud supportent Accepter les modifications, Plan et Auto. Accepter les modifications correspond au mode default : les sessions cloud pré-approuvent les modifications de fichiers, donc le sélecteur affiche Accepter les modifications au lieu de Manuel. Contourner les permissions n'est pas disponible dans les sessions cloud, y compris les sessions dans un environnement auto-hébergé.

Les administrateurs d'entreprise peuvent restreindre les modes de permission disponibles. Voir configuration d'entreprise pour les détails.

Disponibilité du mode auto

Le mode auto est disponible pour tous les utilisateurs sur l'API Anthropic et nécessite Claude Opus 4.6 ou version ultérieure, Sonnet 4.6 ou version ultérieure, Haiku 5.5, ou un modèle Fable. Les administrateurs d'organisation peuvent désactiver le mode auto avec la clé disableAutoMode dans les paramètres gérés.

Dans les déploiements Enterprise qui acheminent Desktop vers Google Cloud's Agent Platform, le mode auto est également disponible par défaut ; voir Mode auto sur Bedrock, Agent Platform ou Foundry pour les modèles supportés.

Aperçu de votre application

Claude peut démarrer un serveur de développement et l'ouvrir dans le volet Navigateur pour vérifier ses modifications. Ceci fonctionne pour les applications web frontend ainsi que les serveurs backend : Claude peut tester les endpoints d'API, afficher les logs du serveur et itérer sur les problèmes qu'il trouve. Dans la plupart des cas, Claude démarre le serveur automatiquement après la modification des fichiers du projet. Vous pouvez également demander à Claude de prévisualiser à tout moment. Par défaut, Claude vérifie automatiquement les modifications après chaque modification.

Dans une session locale, cliquez sur un chemin HTML, PDF ou vidéo dans le chat pour l'ouvrir dans le volet Navigateur.

[!NOTE]

Dans une session SSH, Claude ne peut pas ouvrir votre application dans le volet Navigateur, car il n'y dispose pas des outils du volet. Pour consulter l'application vous-même, transférez son port vers votre ordinateur.

Si le volet Navigateur n'est pas ouvert après que Claude a démarré un serveur dans une session locale, cliquez sur Ouvrir sur la carte du serveur dans le chat.

À partir du volet Navigateur, vous pouvez :

• Interagir avec votre application en cours d'exécution directement dans le volet Navigateur
• Regarder Claude vérifier ses propres modifications automatiquement : il prend des captures d'écran, inspecte le DOM, clique sur les éléments, remplit les formulaires et corrige les problèmes qu'il trouve
• Démarrer ou arrêter les serveurs, ou les arrêter tous à la fois, à partir du menu Serveurs de développement dans l'en-tête du volet Navigateur
• Choisir si le Navigateur conserve les cookies après que vous avez quitté l'application avec Conserver les cookies dans le menu ⋮ du volet Navigateur, afin que vous n'ayez pas à vous reconnecter pendant le développement

Claude crée la configuration initiale du serveur en fonction de votre projet. Si votre application utilise une commande de développement personnalisée, modifiez .claude/launch.json pour correspondre à votre configuration. Voir Configurer les serveurs d'aperçu pour la référence complète.

Pour effacer les données enregistrées du Navigateur, sélectionnez Effacer les données de navigation dans le menu ⋮ du volet Navigateur. Pour désactiver complètement le Navigateur, désactivez Outils du navigateur dans Paramètres > Claude Code.

Parcourir les sites externes

Le volet Navigateur est un navigateur à onglets, vous pouvez donc ouvrir la documentation, les outils de suivi de problèmes ou tout autre site à côté de votre application en cours d'exécution. Pour ouvrir le Navigateur, appuyez sur Cmd+Maj+B sur macOS ou Ctrl+Maj+B sur Windows, ou cliquez sur Navigateur dans la barre de titre de la session. Vous pouvez vous connecter à des sites dans le volet, y compris les flux de connexion popup tels que Google OAuth.

La première fois que vous cliquez sur un lien externe dans le chat, une boîte de dialogue vous demande si les liens s'ouvrent dans le volet Navigateur ou dans votre navigateur par défaut. Pour modifier votre choix plus tard, utilisez Ouvrir les liens dans le navigateur intégré dans le menu ⋮ du volet Navigateur. Cmd-clic sur macOS ou Ctrl-clic sur Windows ouvre un lien directement dans votre navigateur par défaut.

Claude peut lire et interagir avec les pages externes en utilisant les mêmes outils qu'il utilise pour vérifier votre application, avec deux vérifications de sécurité supplémentaires :

• Les classificateurs de sécurité examinent les actions d'écriture de Claude sur les pages externes, telles que cliquer et taper, dans tous les modes de permission. Ce sont les mêmes classificateurs que le mode auto utilise, et quand ils signalent une action, vous obtenez une demande de permission quel que soit le mode.
• Dans les modes de permission autres que Auto et Contourner les permissions, une vérification de liste d'autorisation de domaine s'applique également avant que Claude ne navigue vers un nouveau site.

Approuver les actions de Claude sur un site

La première fois que Claude agit sur un site externe, une carte de permission apparaît et Claude attend votre choix : Autoriser une fois, Toujours autoriser ou Refuser. Autoriser une fois approuve l'action sans rien enregistrer. Toujours autoriser enregistre l'approbation pour ce site sur votre appareil, et vous pouvez la révoquer dans Paramètres. Chaque site a besoin de sa propre approbation, y compris les sous-domaines. Vos serveurs de développement locaux et fichiers de projet n'ont pas besoin d'approbation, donc auto-verify continue de fonctionner sans demandes.

Même sur un site approuvé, Claude n'achètera pas d'articles, ne créera pas de comptes ou ne contournera pas les CAPTCHA sans votre entrée. La navigation dans le volet Navigateur utilise le même modèle de sécurité que l'extension Claude dans Chrome. Voir Utiliser Claude dans Chrome en toute sécurité pour savoir comment Claude gère les sites sensibles et les actions risquées.

Choisir entre le Navigateur et l'extension Chrome

Le volet Navigateur utilise un profil de navigateur propre, séparé de votre navigateur personnel, sans aucune de vos connexions enregistrées ou historique. Utilisez-le pour construire et tester votre application et pour les sites qui n'ont pas besoin de votre identité. Quand vous voulez que Claude agisse en tant que vous dans vos sessions connectées, utilisez l'extension Claude dans Chrome à la place, qui partage l'état de connexion de votre navigateur.

Restreindre la navigation externe pour votre organisation

Le Navigateur suit les mêmes contrôles de liste d'autorisation et de liste de blocage de site que l'extension Claude dans Chrome. Si votre organisation a déjà configuré ces listes pour l'extension, le Navigateur les respecte automatiquement. Les administrateurs peuvent également désactiver les outils de Claude sur les pages externes avec le paramètre géré browserExternalPageTools. Avec les outils désactivés, les utilisateurs peuvent toujours naviguer vers des sites externes ; les outils de Claude ne peuvent pas les lire ou agir sur eux.

Pour désactiver complètement la navigation externe, définissez le paramètre géré disableBrowserExternalNavigation sur true. Ceci bloque toute navigation externe dans le Navigateur, y compris les sites sur la liste d'autorisation de votre organisation ; les serveurs de développement localhost et les aperçus de fichiers continuent de fonctionner. Utilisez browserExternalPageTools pour laisser les utilisateurs continuer à naviguer sur des sites externes sans les outils de Claude, et disableBrowserExternalNavigation pour bloquer les sites externes pour les utilisateurs et Claude.

Examiner les modifications avec la vue diff

Après que Claude a modifié votre code, la vue diff vous permet d'examiner les modifications fichier par fichier avant de créer une pull request. Pour ouvrir la vue diff, cliquez sur le nombre de lignes, comme +12 -1, dans la carte Modifications du panneau de détails de la session. Vous pouvez également cliquer sur Modifications dans la barre de titre de la session.

Pour commenter des lignes spécifiques, cliquez sur n'importe quelle ligne dans le diff pour ouvrir une boîte de commentaire. Tapez votre retour et appuyez sur Entrée pour ajouter le commentaire. Après avoir ajouté des commentaires à plusieurs lignes, soumettez tous les commentaires à la fois :

• macOS : appuyez sur Cmd+Entrée
• Windows : appuyez sur Ctrl+Entrée

Claude lit vos commentaires et effectue les modifications demandées, qui apparaissent comme un nouveau diff que vous pouvez examiner.

Examiner votre code

Pour que Claude examine vos modifications avant que vous ne créiez un commit, saisissez /code-review dans la zone de prompt. Les résultats arrivent dans la conversation lorsque la revue est terminée.

Dans les sessions locales, SSH et WSL, les résultats apparaissent sous la forme d'une carte Revue de code, regroupés par fichier. Utilisez la carte pour y donner suite :

• Cliquez sur Parcourir dans le diff pour ouvrir la vue diff et passer en revue les résultats un par un. Un résultat présent dans le diff actuel apparaît à sa ligne, où vous pouvez cliquer sur Corriger celui-ci ou l'ignorer.
• Cliquez sur Appliquer les corrections pour demander à Claude de corriger les résultats encore ouverts.

Dans n'importe quelle session, vous pouvez également demander à Claude, dans la zone de prompt, de corriger ce que la revue a trouvé. Pour savoir ce que /code-review recherche et les arguments qu'il accepte, voir Faire une revue locale avec /code-review.

Surveiller l'état de la pull request

Pour que Claude corrige les vérifications en échec, ou pour que GitHub fusionne la pull request, activez Correction automatique ou Fusionner une fois prête. Après avoir ouvert une pull request, celle-ci apparaît dans la carte Modifications du panneau de détails de la session avec l'état de ses vérifications CI. Ouvrez le menu ⋮ à côté de son titre :

• Correction automatique : dans une session locale, Claude traite également les nouveaux commentaires de revue laissés par une autre personne que vous. L'auteur du commentaire doit être le propriétaire du dépôt, un membre de l'organisation, un collaborateur ou une GitHub App.
• Fusionner une fois prête : active la fusion automatique de GitHub pour la PR. Dans une session locale, Desktop demande une fusion squash, sauf si la branche de base utilise une file d'attente de fusion.
  • Dans les sessions SSH et WSL : Fusionner une fois prête est désactivé ; activez donc la fusion automatique pour la pull request sur GitHub
  • Si le dépôt n'autorise pas la fusion automatique : Fusionner une fois prête ne s'active pas ; activez donc d'abord la fusion automatique dans les paramètres de votre dépôt GitHub
• Ancienne disposition : une fois que la session a une pull request, cliquez sur CI dans sa barre d'état.

Pour archiver la session automatiquement une fois que la PR est fusionnée ou fermée, activez l'archivage automatique dans Paramètres > Claude Code.

[!NOTE]

La surveillance des PR nécessite que la CLI GitHub (gh) soit installée et authentifiée sur votre machine. Si gh n'est pas installée, Desktop vous invite à l'installer la première fois que vous essayez de créer une PR.

Dans une session SSH, configurez git et gh sur la machine distante avant de cliquer sur Créer une PR, car c'est là que Claude pousse la branche et exécute gh pr create. Installez vous-même gh sur cette machine, car Desktop ne vous invite pas à le faire dans une session SSH. Vérifiez ensuite sur cette machine que git push fonctionne et que gh auth status indique que vous êtes connecté.

Arranger votre espace de travail

L'onglet Code est construit autour de volets que vous pouvez arranger dans n'importe quelle disposition : chat, diff, navigateur, terminal, fichier, plan, tâches et sous-agent, ainsi que le Simulateur iOS sur macOS. Glissez un volet par son en-tête pour le repositionner, ou glissez un bord de volet pour le redimensionner. Appuyez sur Cmd+\ sur macOS ou Ctrl+\ sur Windows pour fermer le volet actif.

Pour ouvrir un autre volet, cliquez sur son bouton icône dans la barre de titre de la session. Survolez chaque bouton pour voir son nom, comme Terminal, Modifications pour la vue diff, Navigateur et Fichiers. Si le volet souhaité n'a pas de bouton dans la barre de titre, sélectionnez-le dans le menu ⋮ à côté des boutons :

• Lorsque la fenêtre est étroite : les boutons qui ne tiennent pas sont déplacés dans le menu
• Pour les volets sans bouton : les volets tels que Tâches en arrière-plan et Plan sont listés dès que la session a quelque chose à afficher dans ces volets

Pour travailler sur plusieurs écrans, extrayez un volet tel que le diff ou le terminal dans sa propre fenêtre, et redockez-le quand vous avez terminé. Claude continue de travailler dans la fenêtre principale.

[!NOTE]

La disposition des volets, le terminal, l'éditeur de fichiers et les modes d'affichage dans cette section nécessitent Claude Desktop v1.2581.0 ou une version ultérieure. Ouvrez Claude > Vérifier les mises à jour… sur macOS ou Aide > Vérifier les mises à jour… sur Windows pour mettre à jour.

Voir les détails de la session

Le panneau des détails de la session est un ensemble de cartes à côté du chat qui indiquent où la session s'exécute, ce qu'elle a modifié, ce qu'elle exécute et son utilisation du contexte. Le panneau apparaît après que vous avez démarré une session, tant que le chat est suffisamment large pour l'afficher.

Masquer ou afficher le panneau des détails de la session

Pour masquer ou afficher le panneau, cliquez sur Masquer le rail de session ou Afficher le rail de session dans la barre de titre de la session, ou dans le menu ⋮ de la barre lorsque la fenêtre est étroite. Si vous ne voyez toujours pas le panneau, vérifiez quelle disposition de l'onglet Code vous avez.

Exécuter les commandes dans le terminal

Le terminal intégré vous permet d'exécuter les commandes aux côtés de votre session sans basculer vers une autre application. Cliquez sur Terminal dans la barre de titre de la session ou appuyez sur Ctrl+` sur macOS ou Windows. Le terminal s'ouvre dans le répertoire de travail de votre session et partage le même environnement que Claude, donc les commandes comme npm test ou git status voient les mêmes fichiers que Claude édite. Pour ouvrir un deuxième onglet de terminal, cliquez sur + dans l'en-tête du volet de terminal ou cliquez avec le bouton droit sur un dossier dans le chat pour choisir Ouvrir dans le terminal.

Si une session WSL n'a pas de terminal, consultez Si le terminal ou les connecteurs ne sont pas disponibles. Le terminal est disponible dans les sessions locales et SSH, avec une limitation sur les machines distantes Windows.

Ouvrir et modifier les fichiers

Pour ouvrir un fichier mentionné par Claude, cliquez sur son chemin dans le chat.

Pour modifier vous-même un fichier, utilisez le volet de fichier :

• Sessions locales : vous pouvez modifier les fichiers situés dans le répertoire de travail de la session, à l'exception de certains fichiers en lecture seule tels que .mcp.json et .claude/settings.json. Pour en modifier un, ouvrez-le dans une autre application.
• Sessions cloud, SSH et WSL : le volet de fichier est en lecture seule, demandez donc à Claude d'effectuer les modifications.

Enregistrer les modifications dans le volet de fichier

Par défaut, vos modifications dans le volet de fichier s'enregistrent automatiquement, donc le volet n'affiche pas de bouton Enregistrer. Pour enregistrer vous-même vos modifications, décochez Enregistrement automatique dans le menu ⋮ du volet. Avec Enregistrement automatique désactivé, cliquez sur Enregistrer après avoir modifié un fichier pour écrire vos modifications, ou sur Annuler pour les annuler.

Si le volet vous avertit que le fichier a changé sur le disque, cliquez sur Remplacer pour écrire vos modifications par-dessus la version sur le disque, ou sur Abandonner pour abandonner vos modifications.

Ouvrir les fichiers dans d'autres applications

Cliquez avec le bouton droit sur n'importe quel chemin de fichier dans le chat, la visionneuse de diff ou le volet de fichier pour ouvrir un menu contextuel :

• Joindre comme contexte : ajouter le fichier à votre prochain prompt
• Ouvrir dans : ouvrir le fichier dans un éditeur installé comme VS Code, Cursor ou Zed
• Afficher dans le Finder sur macOS, Afficher dans l'Explorateur sur Windows : ouvrir le dossier contenant
• Copier : un sous-menu qui copie le Chemin absolu, le Chemin relatif ou le Nom de fichier du fichier

Changer les modes d'affichage

Les modes d'affichage contrôlent le niveau de détail qui apparaît dans la transcription du chat. Pour changer de mode d'affichage, ouvrez le menu de la session à partir du chevron à côté du titre de la session et sélectionnez Vue de la transcription, ou appuyez sur Ctrl+O sur macOS ou Windows pour les parcourir. Le mode réflexion apparaît dans le menu uniquement après que Claude a produit de la réflexion dans la session que vous consultez.

Utilisez Thinking pour suivre le raisonnement de Claude avec les appels d'outils toujours réduits. Utilisez Verbose lors du débogage pour savoir pourquoi Claude a pris une action particulière. Les versions de Claude Desktop antérieures à 1.46388.1 listent également un mode Résumé, et une session toujours définie sur Résumé s'ouvre en Normal une fois que vous mettez à jour.

Raccourcis clavier

Appuyez sur Cmd+/ sur macOS ou Ctrl+/ sur Windows pour voir tous les raccourcis disponibles dans l'onglet Code. Le tableau de cette section indique les touches macOS. Sur Windows et Linux, remplacez ces touches :

• Cmd+Option : appuyez sur Alt
• Cmd+Ctrl : appuyez sur Ctrl+Alt
• Cmd : appuyez sur Ctrl

Le cycle des sessions, le basculement du terminal et le basculement du mode d'affichage utilisent Ctrl sur chaque plateforme.

Ces raccourcis s'appliquent à l'onglet Code. Dans Desktop, Shift+Tab ne parcourt pas les modes de permission comme il le fait dans le mode interactif du terminal.

Vérifier l'utilisation

Pour voir à quel point la fenêtre de contexte de cette session est remplie, identifiez votre disposition de l'onglet Code :

• Disposition actuelle : l'en-tête de la carte Contexte dans le panneau des détails de la session l'indique sous forme de pourcentage. Ouvrez la carte pour voir ce qui utilise la fenêtre, par catégorie.
• Disposition précédente : cliquez sur l'anneau d'utilisation à côté du sélecteur de modèle. Sa fenêtre contextuelle affiche votre utilisation de la fenêtre de contexte.

Quelle que soit la disposition, tapez /context dans la zone de prompt pour afficher dans le chat une répartition par catégorie de la fenêtre de contexte de cette session.

Les deux dispositions comportent l'anneau d'utilisation à côté du sélecteur de modèle. Cliquez dessus pour voir votre utilisation du plan, qui est partagée sur toutes vos surfaces Claude Code.

Laisser Claude utiliser votre ordinateur

L'utilisation informatique permet à Claude d'ouvrir vos applications, de contrôler votre écran et de travailler directement sur votre machine comme vous le feriez. Demandez à Claude d'interagir avec un outil de bureau qui n'a pas de CLI, ou d'automatiser quelque chose qui ne fonctionne que via une GUI. Pour exécuter et tester des applications iOS, Desktop ouvre le volet dédié iOS Simulator au lieu de contrôler votre écran ; le volet fonctionne sans activer l'utilisation informatique.

[!NOTE]

L'utilisation informatique est disponible en research preview sur macOS et Windows et nécessite un plan Pro ou Max. Elle n'est pas disponible sur les plans Team ou Enterprise. L'application Claude Desktop doit être en cours d'exécution. Sur macOS, l'utilisation informatique nécessite macOS 14 ou une version ultérieure.

L'utilisation informatique est désactivée par défaut. Activez-la dans Paramètres avant que Claude puisse contrôler votre écran. Sur macOS, vous devez également accorder les permissions d'Accessibilité et d'Enregistrement d'écran.

Sur macOS, l'utilisation informatique peut également s'exécuter en arrière-plan : Claude travaille dans les applications que vous avez approuvées pendant que vous continuez à travailler.

[!WARNING]

Contrairement à l'outil Bash sandboxé, l'utilisation informatique s'exécute sur votre vrai bureau avec accès à tout ce que vous approuvez. Claude vérifie chaque action et signale les injections de prompt potentielles du contenu à l'écran, mais la limite de confiance est différente. Voir le guide de sécurité de l'utilisation informatique pour les meilleures pratiques.

Quand l'utilisation informatique s'applique

Claude a plusieurs façons d'interagir avec une application ou un service, et l'utilisation informatique est la plus large et la plus lente. Il essaie d'abord l'outil le plus précis :

• Si vous avez un connecteur pour un service, Claude utilise le connecteur.
• Si la tâche est une commande shell, Claude utilise Bash.
• Si la tâche est du travail de navigateur et que vous avez Claude dans Chrome configuré, Claude utilise cela.
• Si la tâche consiste à exécuter ou tester une application iOS, Claude utilise le volet iOS Simulator, qui n'utilise pas le contrôle d'écran.
• Si aucun de ceux-ci ne s'applique, Claude utilise l'utilisation informatique.

Les niveaux d'accès par application renforcent ceci : les navigateurs sont limités à la lecture seule, et les terminaux et IDE à clic uniquement, guidant Claude vers l'outil dédié même quand l'utilisation informatique est active. Le contrôle d'écran est réservé aux choses que rien d'autre ne peut atteindre, comme les applications natives, les panneaux de contrôle matériel, ou les outils propriétaires sans API.

Activer l'utilisation informatique

L'utilisation informatique est désactivée par défaut. Si vous demandez à Claude de faire quelque chose qui en a besoin alors qu'elle est désactivée, Claude vous dit qu'il pourrait faire la tâche si vous activez l'utilisation informatique dans Paramètres.

1. Mettre à jour l'application de bureau

Assurez-vous que vous avez la dernière version de Claude Desktop. Sur macOS et Windows, téléchargez ou mettez à jour sur claude.com/download ; sur Linux, mettez à jour via votre gestionnaire de paquets (instructions). Ensuite, redémarrez l'application.

2. Activer le basculement

Dans l'application de bureau, allez à Paramètres > Cet ordinateur > Système. Sous Utilisation informatique, activez Activer l'utilisation informatique. Sur Windows, le basculement prend effet immédiatement et la configuration est complète. Sur macOS, continuez à l'étape suivante.

Si vous ne voyez pas le basculement, confirmez que vous êtes sur macOS ou Windows avec un plan Pro ou Max, puis mettez à jour et redémarrez l'application.

3. Accorder les permissions macOS

Sur macOS, accordez deux permissions système avant que le basculement prenne effet :

• Accessibilité : permet à Claude de cliquer, taper et faire défiler
• Enregistrement d'écran : permet à Claude de voir ce qui est sur votre écran

La page Paramètres affiche l'état actuel de chaque permission. Si l'une est refusée, cliquez sur le badge pour ouvrir le volet Paramètres système pertinent.

Permissions d'application

La première fois que Claude doit utiliser une application, une invite apparaît dans votre session. Cliquez sur Autoriser pour cette session ou Refuser. Les approbations durent pour la session actuelle, ou 30 minutes dans les sessions générées par Dispatch.

L'invite affiche également quel niveau de contrôle Claude obtient pour cette application. Ces niveaux sont fixés par catégorie d'application et ne peuvent pas être modifiés :

Les applications avec une large portée, comme les terminaux, Finder ou Explorateur de fichiers, et Paramètres système ou Paramètres, affichent un avertissement supplémentaire dans l'invite pour que vous sachiez ce que l'approbation accorde.

La section Utilisation informatique de Paramètres > Cet ordinateur > Système comprend les options suivantes :

• Applications refusées : ajoutez des applications ici pour les rejeter sans demander. Claude peut toujours affecter une application refusée indirectement via des actions dans une application autorisée, mais il ne peut pas interagir directement avec l'application refusée.
• Afficher les applications quand Claude a terminé : tandis que l'utilisation informatique ne s'exécute pas en arrière-plan, Claude masque vos autres fenêtres pendant qu'il travaille pour qu'il n'interagisse qu'avec l'application approuvée. Quand Claude a terminé, les fenêtres masquées sont restaurées sauf si vous désactivez ce paramètre.

Gérer les sessions

Chaque session est une conversation indépendante avec son propre contexte et ses propres modifications. Vous pouvez exécuter plusieurs sessions en parallèle, créer des chats latéraux, laisser Claude vérifier et envoyer des messages à vos autres sessions, envoyer du travail vers le cloud, ou laisser Dispatch démarrer des sessions pour vous depuis votre téléphone.

Travailler en parallèle avec les sessions

Cliquez sur + Nouvelle dans la barre latérale, ou appuyez sur Cmd+N sur macOS ou Ctrl+N sur Windows, pour travailler sur plusieurs tâches en parallèle. Appuyez sur Ctrl+Tab et Ctrl+Shift+Tab pour parcourir les sessions dans la barre latérale.

Vous pouvez également ouvrir une deuxième session à côté de la session actuelle ou dans sa propre fenêtre :

• Côte à côte : maintenez Option sur macOS ou Alt sur Windows et cliquez sur une session dans la barre latérale, ou faites un clic droit sur la session et sélectionnez Ouvrir dans, puis Vue partagée
• Dans sa propre fenêtre : maintenez Cmd sur macOS ou Ctrl sur Windows et cliquez sur une session, ou faites un clic droit sur la session et sélectionnez Ouvrir dans, puis Nouvelle fenêtre

Dans la vue partagée, le volet que vous avez ouvert ou sur lequel vous avez cliqué en dernier a le focus, et l'autre volet est grisé. Pour changer la session qu'affiche un volet, cliquez dans ce volet pour lui donner le focus, puis cliquez sur une session dans la barre latérale. Pour retirer de la vue partagée la session qui a le focus, appuyez sur Cmd+Ctrl+W sur macOS ou Ctrl+Alt+W sur Windows.

Exécuter une session dans son propre worktree

Dans un projet qui est un dépôt Git, activez Worktree avant de démarrer une session pour l'exécuter dans son propre worktree Git, une copie isolée du projet. Par défaut, Worktree est désactivé et Claude travaille directement dans le dossier du projet. Cliquez sur le contrôle du dossier de projet dans la ligne sous la zone de prompt et activez Worktree.

• Avec un environnement enregistré : définissez Worktree lorsque vous créez ou modifiez l'environnement
• Disposition précédente : cochez la case worktree à côté du nom de la branche, au-dessus de la zone de prompt

Les worktrees sont stockés dans <project-root>/.claude/worktrees/ par défaut. Pour les stocker plutôt dans un répertoire personnalisé :

• Sessions locales : définissez Emplacement du worktree dans Paramètres > Claude Code
• Sessions SSH : définissez Dossier du worktree sur la connexion SSH

Vous pouvez également définir un Préfixe de branche dans Paramètres > Claude Code. Desktop l'ajoute au début de chaque nom de branche worktree, ce qui est utile pour garder les branches créées par Claude organisées.

Pour inclure les fichiers ignorés par git comme .env dans les nouveaux worktrees, créez un fichier .worktreeinclude à la racine de votre projet. Voir Ce que les worktrees partagent avec le checkout principal pour savoir où une session worktree lit les paramètres du projet, les hooks et les skills.

[!NOTE]

L'isolation des sessions nécessite Git. La plupart des Macs incluent Git par défaut. Exécutez git --version dans Terminal pour vérifier ; s'il affiche un numéro de version, Git est installé. Si vous rencontrez des erreurs Git, demandez à Claude dans Cowork de vous aider à dépanner votre configuration.

Ajouter des dossiers à une session

Ajoutez des dossiers avant le démarrage de la session ou pendant son exécution :

• Avant le démarrage d'une session locale : ajoutez les dossiers sous Dossiers lorsque vous créez un environnement enregistré ou en modifiez un, puis démarrez la session à partir de cet environnement enregistré.
• Pendant l'exécution d'une session locale ou SSH : cliquez sur + à côté de la zone de prompt et sélectionnez Ajouter un dossier. Claude travaille directement dans ce dossier, sans worktree.

Archiver une session

Avant d'archiver une session dont le worktree contient des modifications non commitées, voir Conserver les modifications non commitées lors de l'archivage d'une session. Pour archiver une session, survolez-la dans la barre latérale, ouvrez son menu et sélectionnez Archiver. La session est déplacée vers vos sessions archivées.

Pour que les sessions s'archivent elles-mêmes quand leur pull request est fusionnée ou fermée, activez Auto-archive après fusion ou fermeture de PR dans Paramètres > Claude Code. Les sessions cloud et les sessions encore en cours d'exécution ne s'archivent pas elles-mêmes.

Conserver les modifications non commitées lors de l'archivage d'une session

Vous pouvez perdre les modifications non commitées du worktree d'une session lors de son archivage ; créez donc d'abord un commit de ce que vous souhaitez conserver :

• Si Desktop vous interroge sur les modifications : sélectionnez Archiver quand même pour les supprimer, ou annulez et créez un commit
• Si les seules modifications sont des fichiers non suivis : créez un commit de ceux que vous souhaitez conserver avant que la pull request ouverte par Claude dans la session ne soit fusionnée, car Desktop peut alors les supprimer sans vous le demander
• Dans tous les autres cas : le worktree reste sur le disque avec ses modifications. Pour une session locale, Desktop supprime les deux environ 30 jours après l'archivage de la session ou sa dernière ouverture, selon la date la plus tardive. Pour conserver les modifications, ouvrez la session depuis l'onglet Archivées et sélectionnez Désarchiver

Organiser et retrouver les sessions

Vous regroupez, triez et retrouvez les sessions à partir d'une icône dans la liste des sessions de la barre latérale :

• Disposition actuelle : survolez un titre de la liste des sessions pour afficher l'icône Grouper et trier, puis cliquez dessus. Pour retrouver les sessions archivées, sélectionnez Tout afficher, la dernière ligne du menu, puis ouvrez l'onglet Archivées.
• Disposition précédente : l'icône Filtrer s'affiche sans survol. Cliquez dessus pour organiser la liste avec Grouper par ou Trier par. Pour afficher les sessions archivées, sélectionnez Statut, puis Archivées.

Pour renommer une session, ouvrez-la et cliquez sur le titre de la session dans la barre de titre.

Vérifier et libérer le contexte

Pour vérifier l'utilisation du contexte, voir Vérifier l'utilisation. Quand le contexte se remplit, Claude résume automatiquement la conversation et continue de travailler. Vous pouvez également taper /compact pour déclencher la compaction plus tôt et libérer de l'espace de contexte. Voir la fenêtre de contexte pour les détails sur le fonctionnement de la compaction.

Être notifié quand une session se termine

L'application de bureau envoie une notification du système d'exploitation quand une session Code termine une tâche et que vous ne visualisez pas actuellement cette session. Pour les sessions qui appartiennent à un projet, vous recevez les notifications du projet à la place.

Poser une question latérale sans dérailler la session

Un chat latéral vous permet de poser une question à Claude qui utilise le contexte de votre session mais n'ajoute rien à la conversation principale. Utilisez-le quand vous voulez comprendre un morceau de code, vérifier une hypothèse ou explorer une idée sans détourner la session de son cours.

Appuyez sur Cmd+; sur macOS ou Ctrl+; sur Windows pour ouvrir un chat latéral, ou tapez /btw dans la zone de prompt. Le chat latéral peut lire tout ce qui se trouve dans le fil principal jusqu'à ce point. Quand vous avez terminé, fermez le chat latéral et continuez la session principale où vous l'aviez laissée.

Les chats latéraux sont disponibles dans les sessions locales, SSH et WSL. L'application de bureau n'enregistre pas les chats latéraux sur le disque, donc vous ne pouvez pas revenir à un après avoir fermé l'application.

Regarder les tâches en arrière-plan

Le volet des tâches affiche le travail en arrière-plan s'exécutant dans la session actuelle : sous-agents, commandes shell en arrière-plan et workflows dynamiques. Dès que la session comporte du travail en arrière-plan, ouvrez le volet avec Tâches en arrière-plan dans le menu ⋮ de la barre de titre.

Cliquez sur n'importe quelle entrée pour voir sa sortie dans le volet du sous-agent ou l'arrêter. Pour voir ce que font les autres sessions, utilisez la barre latérale, ou demandez à Claude de vérifier pour vous.

Travailler entre les sessions

Claude peut lister vos autres sessions de l'onglet Code, lire ce que chacune a fait, et envoyer des messages entre elles. Demandez en langage naturel : « quelle session a touché à la refonte d'authentification ? », « à quelle conclusion la session API est-elle arrivée ? », ou « dites à la session des paiements que le schéma a changé ».

Vous pouvez également demander à Claude de renommer ou d'archiver une session. Par exemple, demandez-lui d'archiver les sessions dont les PR ont fusionné.

À travers cette surface, Claude ne voit que les sessions que l'application de bureau exécute elle-même : locales, SSH et WSL sessions dans l'onglet Code. Claude ne voit pas les sessions cloud, ou les sessions que vous avez démarrées à partir du CLI du terminal ou de l'extension VS Code, même dans les worktrees du même projet, donc avec neuf worktrees de terminal ouverts et deux sessions de bureau, Claude répondant dans l'une d'elles signale l'autre session de bureau. Claude ne liste jamais la session à partir de laquelle vous posez la question. Par défaut, il voit les 20 sessions les plus récemment actives et ignore les sessions archivées sauf si vous les demandez. La messagerie entre sessions permet séparément à Claude d'envoyer des messages à vos autres sessions Claude Code, y compris les sessions de terminal.

Quand Claude envoie un message à une autre session à travers cette surface, Claude Code l'affiche là comme une carte étiquetée avec le titre de la session d'envoi et un lien de retour, donc vous pouvez toujours dire d'où vient un message. Si la session réceptrice est en cours de tâche, Claude Code retient le message et Claude le lit une fois le travail actuel terminé. Le Claude récepteur peut répondre, et Claude Code livre la réponse en retour à travers cette surface. Claude ne peut pas livrer à une session archivée, et vous dit quand un message ne passe pas.

Claude Code applique trois comportements de sécurité entre les sessions :

• Vous voyez une carte d'approbation avant que Claude n'archive une session, sauf en mode auto et en mode Bypass permissions, où Claude peut archiver une session sans carte. Pour que Claude vous le demande, passez en mode Manual.
• Claude Code vérifie chaque message de cette surface par rapport aux contrôles entrants de la session réceptrice, même quand la session réceptrice n'a pas la messagerie entre sessions elle-même. Si vous définissez crossSessionInbound à refuse dans la session réceptrice, Claude Code supprime les messages de cette surface. Claude Code signale le refus à l'application de bureau Claude. Avant v2.1.234, Claude Code supprimait chaque message de cette surface vers une session réceptrice sans messagerie entre sessions.
• Claude Code cite chaque message entrant et l'attribue à la session qui l'a envoyé, et Claude suit toujours les paramètres de permission propres de la session réceptrice quand il agit sur un.

Démarrer une tâche suggérée par Claude

Quand Claude remarque quelque chose qui mérite d'être corrigé en dehors de votre tâche actuelle, il suggère ce travail sous forme de tâche. Dans les sessions locales et SSH sur la disposition actuelle, la suggestion est une carte dans le chat, et ses boutons démarrent la tâche ou la conservent dans cette session :

• Démarrer : démarre la tâche dans une autre session. Par défaut, la tâche s'exécute dans l'environnement de la session actuelle. La carte affiche ensuite l'état de la session démarrée, et la barre latérale liste la session démarrée sous la session actuelle.
• Le faire ici : envoie la tâche à la session actuelle sous forme de message
• Options : examinez ou modifiez des paramètres tels que l'environnement, le modèle, le worktree et les permissions avant de cliquer sur Démarrer
• Tout démarrer : quand la carte liste plusieurs tâches, démarre chaque tâche dans sa propre session sans attendre qu'une tâche se termine avant de démarrer la suivante

Dans les sessions cloud, et dans les sessions locales et SSH sur la disposition précédente, la suggestion est une carte Tâche suggérée. Pour démarrer la tâche à l'endroit qu'indique le bouton principal de la carte, par exemple Envoyer vers le cloud ou Démarrer avec un worktree, cliquez sur ce bouton. Cliquez sur le chevron à côté du bouton principal pour d'autres façons de démarrer la tâche, notamment Le faire ici.

Exécuter les tâches longues dans le cloud

Pour les refactorisations importantes, les suites de tests, les migrations ou autres tâches longues, sélectionnez un environnement sous Cloud dans le sélecteur d'environnement au démarrage d'une session. Les sessions cloud s'exécutent sur l'infrastructure gérée par Anthropic par défaut et continuent même si vous fermez l'application ou arrêtez votre ordinateur. Revenez à tout moment pour voir la progression ou orienter Claude dans une direction différente. Vous pouvez également surveiller les sessions cloud à partir de claude.ai/code ou de l'application Claude mobile.

Les sessions cloud prennent également en charge plusieurs dépôts. Choisissez les dépôts :

• Disposition actuelle : dans la ligne sous la zone de prompt, une fois que vous avez sélectionné un environnement cloud.
• Disposition précédente : au-dessus de la zone de prompt. Pour ajouter un autre dépôt, cliquez sur + à côté du dépôt sélectionné.

Voir Utiliser Claude Code dans le cloud pour plus d'informations sur le fonctionnement des sessions cloud. Quand un corps de travail nécessite de nombreuses sessions cloud, utilisez un projet : Claude démarre et suit les sessions pour vous à partir d'une seule conversation. Créer un projet en présente les étapes.

[!NOTE]

Une tâche dans une session SSH peut également continuer pendant que Desktop est déconnecté, mais avec un compte Claude, elle peut s'arrêter lorsque son authentification expire.

Continuer sur une autre surface

Pour continuer une session ailleurs, ouvrez le menu de la session à partir du chevron à côté du titre de la session ou à partir de la ligne de la session dans la barre latérale, puis sélectionnez Ouvrir dans :

• Sélectionnez Cloud pour continuer la session en tant que session cloud, votre conversation étant reprise sous forme de résumé. Avant que vous ne confirmiez, la boîte de dialogue indique si vos fichiers sont également déplacés et si cette session est archivée une fois la session cloud prête. Vous ne pouvez pas déplacer ainsi une session qui s'exécute via SSH ou dans WSL.
• Sélectionnez un éditeur installé ou votre gestionnaire de fichiers pour y ouvrir le dossier de la session sur le disque.

Contrôler quelles sessions apparaissent sur vos autres appareils

Une session locale apparaît sur vos autres appareils dès que Remote Control la connecte. Une session connectée apparaît dans la liste des sessions sur claude.ai/code et dans les applications Claude sur les appareils connectés à votre compte claude.ai.

Une session locale se connecte quand vous activez Remote Control pour elle, ou quand elle se connecte automatiquement à son démarrage :

• Vous l'activez pour cette session : avec l'interrupteur Remote Control de la session, ou en tapant /remote-control dans sa zone de prompt.
• Elle se connecte à son démarrage : les nouvelles sessions se connectent automatiquement tant que Connecter les nouvelles sessions à Remote Control est activé dans Paramètres > Claude Code. Si vous n'avez jamais modifié ce paramètre, Desktop suit remoteControlAtStartup dans vos paramètres utilisateur ou vos paramètres gérés, puis la valeur par défaut de votre organisation.

Pour savoir si une session est connectée, vérifiez l'interrupteur Remote Control dans la carte Environnement de son panneau de détails de la session.

Pour que vos sessions n'apparaissent pas sur vos autres appareils, désactivez Remote Control au niveau dont vous avez besoin :

• Une session : désactivez son interrupteur Remote Control. Dans une session qui s'est connectée à son démarrage, taper /remote-control laisse Remote Control activé et affiche Remote Control is already on. This session connected automatically when it started. Cliquez sur Désactiver sur cette ligne pour vous déconnecter.
• Les nouvelles sessions Desktop sur cet ordinateur : désactivez Connecter les nouvelles sessions à Remote Control dans Paramètres > Claude Code. S'il apparaît déjà désactivé, activez-le puis désactivez-le pour que Desktop enregistre votre choix. Une fois enregistré, il a priorité sur remoteControlAtStartup et sur les valeurs par défaut.
• Toute session sur cet ordinateur, y compris le CLI : définissez disableRemoteControl à true dans ~/.claude/settings.json pour empêcher les sessions de se connecter. Une session déjà connectée au moment où vous avez enregistré le fichier reste connectée jusqu'à ce que vous désactiviez Remote Control pour elle.

Pour masquer une session qui apparaît déjà sur vos autres appareils, archivez-la dans Desktop. Desktop archive également la copie Remote Control de la session, qui quitte donc la liste des sessions par défaut sur ces appareils. Pour l'y afficher ou la supprimer, voir Archiver les sessions.

Sessions depuis Dispatch

Dispatch est une conversation persistante avec Claude qui vit dans Cowork. Vous envoyez un message à Dispatch avec une tâche, et il décide comment la gérer.

Une tâche peut devenir une session Code de deux façons : vous en demandez une directement, comme « ouvrir une session Claude Code et corriger le bug de connexion », ou Dispatch décide que la tâche est du travail de développement et en génère une automatiquement. Les tâches qui routent généralement vers Code incluent la correction de bugs, la mise à jour des dépendances, l'exécution de tests ou l'ouverture de pull requests. La recherche, l'édition de documents et le travail sur feuille de calcul restent dans Cowork.

Suivre une session démarrée par Dispatch

La session que Dispatch démarre apparaît dans la barre latérale de l'onglet Code avec vos autres sessions. Avec le regroupement et le tri par défaut de la barre latérale, cherchez la session la plus récente dans le groupe du dossier dans lequel elle s'exécute. Vous recevez une notification push sur votre téléphone quand elle se termine ou a besoin de votre approbation.

Si vous avez l'utilisation informatique activée, les sessions Code générées par Dispatch peuvent l'utiliser aussi. Les approbations d'application dans ces sessions expirent après 30 minutes et re-demandent, plutôt que de durer la session complète comme les sessions Code régulières.

Configurer Dispatch

Pour la configuration, l'appairage et les paramètres Dispatch, voir l'article d'aide Dispatch. Dispatch nécessite un plan Pro ou Max et n'est pas disponible sur les plans Team ou Enterprise.

Dispatch est l'une de plusieurs façons de travailler avec Claude quand vous êtes loin de votre terminal. Pour une comparaison avec les autres options, voir Plateformes et intégrations.

Étendre Claude Code

Connectez les services externes, ajoutez des workflows réutilisables, personnalisez le comportement de Claude et configurez les serveurs d'aperçu. Pour gérer les connecteurs, les skills et les plugins au même endroit, cliquez sur Personnaliser dans la barre latérale. L'onglet Cowork dans l'application de bureau récupère ses skills, plugins et connecteurs à partir de cette configuration Personnaliser, qui se synchronise via votre compte claude.ai, et non à partir du répertoire ~/.claude de la CLI.

Claude Code charge également les skills et les plugins activés pour votre compte claude.ai dans les sessions de terminal où vous vous connectez avec le même compte. Voir Skills synchronisés à partir de claude.ai et Plugins synchronisés à partir de claude.ai.

Connecter les outils externes

Les connecteurs sont des serveurs MCP avec un flux de configuration graphique.

Cliquez sur + à côté de la zone de prompt, avant ou pendant la session, pour ajouter des connecteurs dans une session locale ou SSH avec un compte Claude. Sélectionnez Ajouter des connecteurs pour ouvrir le répertoire des connecteurs. Si le menu affiche plutôt Connecteurs, sélectionnez-le, puis Parcourir les connecteurs.

[!NOTE]

Ces cas sont traités sur d'autres pages :

• Connecteurs est grisé dans une session WSL : voir Si le terminal ou les connecteurs ne sont pas disponibles
• Sessions cloud : voir Comment les connecteurs atteignent Claude Code

Une fois connecté, Claude peut lire votre calendrier, envoyer des messages, créer des problèmes et interagir avec vos outils directement. Vous pouvez demander à Claude quels connecteurs sont configurés dans votre session. Pour gérer ou déconnecter les connecteurs, allez à Paramètres > Connecteurs dans l'application de bureau.

Pour les intégrations non listées dans Connecteurs, ajoutez les serveurs MCP manuellement via fichiers de paramètres. Vous pouvez également créer des connecteurs personnalisés.

Utiliser les skills

Les skills étendent ce que Claude peut faire. Claude les charge automatiquement quand ils sont pertinents, ou vous pouvez en invoquer un directement : tapez / dans la zone de prompt ou cliquez sur le bouton + et sélectionnez Slash commands pour parcourir ce qui est disponible. Ceci inclut les commandes intégrées, vos skills personnalisés, les skills du projet à partir de votre base de code et les skills de tout plugin installé. Sélectionnez-en un et il apparaît en surbrillance dans le champ d'entrée. Tapez votre tâche après et envoyez comme d'habitude.

Vous pouvez envoyer une commande pendant que Claude travaille, de la même manière que tout autre message, et la session revient à l'inactivité une fois que le tour est terminé.

Les sessions locales chargent vos skills personnels à partir de ~/.claude/skills/. Une session SSH lit ~/.claude/skills/ à partir du répertoire personnel de l'hôte distant, et non à partir de votre machine.

Les sessions locales et cloud chargent également les skills activés pour votre compte claude.ai, sauf les sessions locales quand votre organisation définit disableSideloadFlags. Les sessions cloud les chargent à la place de ~/.claude/skills/, comme Skills dans les sessions Cowork et cloud le décrit.

Installer les plugins

Les plugins sont des packages réutilisables qui ajoutent des skills, des agents, des hooks, des serveurs MCP et des configurations LSP à Claude Code. Vous pouvez installer les plugins à partir de l'application de bureau sans utiliser le terminal.

Dans une session locale ou une session SSH, cliquez sur + à côté de la zone de prompt et sélectionnez Ajouter des plugins pour ouvrir le navigateur de plugins. Si le menu affiche plutôt Plugins, sélectionnez-le, puis Parcourir les plugins, ou Gérer les plugins pour activer, désactiver ou désinstaller les plugins.

Vous pouvez limiter les plugins à votre compte utilisateur, un projet spécifique ou local uniquement. Si votre organisation gère les plugins de manière centralisée, ces plugins sont disponibles dans les sessions de bureau de la même manière qu'ils le sont dans la CLI, sauf ceux que l'application de bureau retient sous disableSideloadFlags.

Le navigateur de plugins n'est pas disponible dans les sessions cloud, et les plugins que vous installez à partir de l'application de bureau ne sont pas disponibles pour les sessions cloud. Une session cloud n'installe pas non plus les plugins que le fichier .claude/settings.json du référentiel déclare, comme Ce qui est reporté de votre configuration l'explique. Les plugins ne sont pas disponibles dans les sessions WSL. Pour la référence complète des plugins, y compris la création de vos propres plugins, voir plugins.

Configurer les serveurs d'aperçu

Claude détecte automatiquement votre configuration de serveur de développement et stocke la configuration dans .claude/launch.json à la racine du dossier que vous avez sélectionné au démarrage de la session. L'aperçu utilise ce dossier comme répertoire de travail, donc si vous avez sélectionné un dossier parent, les sous-dossiers avec leurs propres serveurs de développement ne seront pas détectés automatiquement. Pour travailler avec le serveur d'un sous-dossier, soit démarrez une session dans ce dossier directement, soit ajoutez une configuration manuellement.

Pour personnaliser le démarrage de votre serveur, par exemple pour utiliser yarn dev au lieu de npm run dev ou pour modifier le port, modifiez .claude/launch.json. Le fichier supporte JSON avec commentaires.

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "my-app",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "port": 3000
    }
  ]
}

Vous pouvez définir plusieurs configurations pour exécuter différents serveurs à partir du même projet, comme un frontend et une API. Voir les exemples ci-dessous.

Vérification automatique des modifications

Quand autoVerify est activé, Claude vérifie automatiquement les modifications de code après la modification des fichiers. Il prend des captures d'écran, vérifie les erreurs et confirme que les modifications fonctionnent avant de terminer sa réponse.

La vérification automatique est activée par défaut. Désactivez-la par projet en ajoutant "autoVerify": false à .claude/launch.json, ou désactivez Vérification automatique des modifications dans le menu ⋮ du volet Navigateur.

{
  "version": "0.0.1",
  "autoVerify": false,
  "configurations": [
    {
      "name": "my-app",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "port": 3000
    }
  ]
}

Quand désactivée, les outils d'aperçu sont toujours disponibles et vous pouvez demander à Claude de vérifier à tout moment. La vérification automatique la rend automatique après chaque modification.

Champs de configuration

Chaque entrée dans le tableau configurations accepte les champs suivants :

Quand utiliser program vs runtimeExecutable

Utilisez runtimeExecutable avec runtimeArgs pour démarrer un serveur de développement via un gestionnaire de packages. Par exemple, "runtimeExecutable": "npm" avec "runtimeArgs": ["run", "dev"] exécute npm run dev.

Utilisez program quand vous avez un script autonome que vous voulez exécuter avec node directement. Par exemple, "program": "server.js" exécute node server.js. Passez des drapeaux supplémentaires avec args.

Ouvrir l'aperçu à une URL spécifique

Par défaut, l'aperçu ouvre http://localhost:<port>. Définissez url quand votre serveur a besoin d'une adresse différente. Les cas courants sont les serveurs qui nécessitent HTTPS local, les applications qui utilisent des sous-domaines *.localhost et les applications qui vous connectent via une redirection.

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "my-app",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "port": 8443,
      "url": "https://localhost:8443"
    }
  ]
}

Les adresses localhost s'ouvrent directement, exactement comme l'adresse de port par défaut. Ceci inclut localhost, n'importe quel sous-domaine *.localhost, 127.0.0.1 et ::1. Pour la sécurité, une url localhost doit être juste l'origine de votre serveur, sans chemin ni requête. Son port doit correspondre au port de l'entrée. Pour afficher une page spécifique, demandez à Claude de naviguer là-bas après l'ouverture de l'aperçu. Une url localhost avec un chemin, une requête ou un port non correspondant est signalée comme une erreur de configuration qui nomme l'url et affiche la correction.

Pour toute autre adresse, Desktop demande votre permission la première fois que l'aperçu l'ouvre, de la même manière que lorsque vous naviguez vers un nouveau site dans l'aperçu. Les adresses externes peuvent inclure des chemins. Choisissez Toujours autoriser pour ignorer l'invite pour ce site à l'avenir. Les politiques organisationnelles qui restreignent les sites externes dans l'aperçu s'appliquent toujours.

Pour prévisualiser un serveur que vous exécutez déjà vous-même, définissez url sans commande. Claude attache l'aperçu à votre serveur en cours d'exécution au lieu d'en démarrer un :

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "my-app",
      "url": "https://app.localhost:3000"
    }
  ]
}

L'url doit être http ou https, et ne doit pas contenir de nom d'utilisateur ou de mot de passe.

Conflits de port

Le champ autoPort contrôle ce qui se passe quand votre port préféré est déjà utilisé :

• true : Claude trouve et utilise un port libre automatiquement. Approprié pour la plupart des serveurs de développement.
• false : Claude échoue avec une erreur. Utilisez ceci quand votre serveur doit utiliser un port spécifique, comme pour les rappels OAuth ou les listes blanches CORS.
• Non défini (par défaut) : votre serveur obtient le prochain port libre, comme avec true, sauf dans le cas ci-dessous. Avant Claude Desktop v2.37337.0, Claude demande plutôt si le serveur a besoin de ce port exact, puis enregistre votre réponse dans launch.json.

Si votre port préféré est utilisé et que autoPort n'est pas défini, votre serveur reste arrêté lorsque toutes ces conditions sont réunies :

• Vous démarrez le serveur via un script npm, yarn, pnpm ou bun.
• Votre port préféré est codé en dur dans ce script, ou Claude ne peut pas inspecter le script.
• Vous ne passez pas le port dans runtimeArgs.

Dans ce cas, libérez le port, supprimez la valeur codée en dur ou modifiez port pour qu'il corresponde au script. Définir "autoPort": true à la place ne fonctionne que pour un script qui lit PORT.

Faites en sorte que votre serveur lise son port à partir de la variable d'environnement PORT, qui contient le port assigné. Quand Claude déplace votre serveur vers un port différent, il réécrit également une valeur --port ou -p dans runtimeArgs pour qu'elle corresponde.

Exemples

Ces configurations montrent les configurations courantes pour différents types de projets :

Next.js

Cette configuration exécute une application Next.js en utilisant Yarn sur le port 3000 :

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "web",
      "runtimeExecutable": "yarn",
      "runtimeArgs": ["dev"],
      "port": 3000
    }
  ]
}

Plusieurs serveurs

Pour un monorepo avec un serveur frontend et API, définissez plusieurs configurations. Le frontend utilise autoPort: true pour qu'il choisisse un port libre si 3000 est pris, tandis que le serveur API nécessite le port 8080 exactement :

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "frontend",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "dev"],
      "cwd": "apps/web",
      "port": 3000,
      "autoPort": true
    },
    {
      "name": "api",
      "runtimeExecutable": "npm",
      "runtimeArgs": ["run", "start"],
      "cwd": "server",
      "port": 8080,
      "env": { "NODE_ENV": "development" },
      "autoPort": false
    }
  ]
}

Script Node.js

Pour exécuter un script Node.js directement au lieu d'utiliser une commande du gestionnaire de packages, utilisez le champ program :

{
  "version": "0.0.1",
  "configurations": [
    {
      "name": "server",
      "program": "server.js",
      "args": ["--verbose"],
      "port": 4000
    }
  ]
}

Configuration de l'environnement

L'environnement que vous choisissez au démarrage d'une session détermine où Claude s'exécute et comment vous vous connectez :

• Local : s'exécute sur votre machine avec accès direct à vos fichiers
• Cloud : s'exécute sur l'infrastructure gérée par Anthropic par défaut. Les sessions continuent même si vous fermez l'application.
• SSH : s'exécute sur une machine distante à laquelle vous vous connectez via SSH, comme vos propres serveurs, des machines virtuelles cloud ou des conteneurs de développement. Une tâche en cours peut continuer pendant que Desktop est déconnecté, mais avec un compte Claude, elle peut s'arrêter lorsque son authentification expire.
• WSL (Windows) : s'exécute à l'intérieur d'une distribution WSL 2 sur votre machine, en utilisant sa chaîne d'outils Linux et ses chemins natifs

Créer un environnement enregistré

Un environnement enregistré est une entrée du sélecteur d'environnement qui indique où Claude s'exécute, afin que vous puissiez y démarrer des sessions ultérieures. Un environnement local ou SSH contient également les dossiers dans lesquels Claude travaille. Les environnements locaux et SSH enregistrés font partie de la disposition actuelle ; si vous ne les voyez pas, vérifiez quelle disposition vous utilisez et comment obtenir la disposition actuelle.

1. Ouvrir la boîte de dialogue New environment

Ouvrez le sélecteur d'environnement sous la zone de prompt et sélectionnez New environment en bas de son menu.

2. Choisir où Claude s'exécute

Sélectionnez l'onglet Local, SSH ou Cloud et remplissez le formulaire de cet onglet. Dans l'onglet SSH, choisissez une connexion et un dossier sur la machine distante.

3. Enregistrer l'environnement

Sélectionnez Create environment, ou Add environment dans l'onglet Cloud.

Environnements que Desktop crée pour vous

Si le sélecteur d'environnement répertorie des environnements locaux ou SSH que vous n'avez pas créés, c'est Desktop qui les a créés pour vous. La première fois que vous ouvrez l'onglet Code dans la disposition actuelle, Desktop crée jusqu'à huit environnements. Ces environnements proviennent des dossiers locaux et SSH que vous avez le plus utilisés au cours du dernier mois. Vous pouvez les modifier ou les supprimer.

Utiliser, modifier ou supprimer un environnement enregistré

Trouvez l'entrée de l'environnement dans le sélecteur d'environnement :

• Démarrer une session : sélectionnez l'entrée.
• Modifier ou supprimer : survolez l'entrée et cliquez sur l'icône d'engrenage. Pour supprimer un environnement local ou SSH, cliquez sur Delete environment dans Edit environment.
• Archiver des environnements cloud : consultez Archiver un environnement.

Variables d'environnement dans les sessions locales

Pour définir une variable d'environnement pour une session locale, ajoutez-la à un environnement local enregistré, puis démarrez une nouvelle session à partir de cet environnement.

Des variables telles que PATH et CLAUDE_CONFIG_DIR ont leurs propres instructions :

Sous macOS ou Linux, si vous avez déjà défini votre variable avec export dans ~/.zshrc ou ~/.bashrc, consultez Variable exportée absente ou incorrecte dans les commandes que Claude exécute.

Définir des variables d'environnement pour les sessions locales

Ajoutez les variables à un environnement local enregistré et démarrez vos sessions à partir de celui-ci. Desktop définit lui-même certaines variables, comme API_TIMEOUT_MS, et vos sessions reçoivent sa valeur pour celles-ci au lieu de la vôtre.

[!NOTE]

Si votre sélecteur d'environnement se trouve au-dessus de la zone de prompt, vous disposez de l'ancienne disposition, qui ne propose pas d'environnements locaux enregistrés. Utilisez plutôt l'éditeur d'environnement local.

1. Ouvrir le formulaire d'un environnement local

• Pour créer un environnement local enregistré : sélectionnez New environment en bas du menu du sélecteur d'environnement, puis l'onglet Local
• Pour modifier un environnement existant : dans le sélecteur d'environnement, survolez un environnement enregistré sous Local et cliquez sur l'icône en forme d'engrenage pour ouvrir Edit environment

2. Saisir les variables

Sélectionnez Environment variables, saisissez une paire KEY=value par ligne, puis sélectionnez Done.

3. Enregistrer l'environnement

Sélectionnez Create environment ou Save.

Seules les sessions que vous démarrez à partir de cet environnement reçoivent les variables.

Pour définir une variable pour toutes les sessions locales, ajoutez-la à la clé env de votre fichier ~/.claude/settings.json. Claude Code ignore la valeur si cette variable figure déjà dans l'environnement avec lequel Desktop démarre la session. Consultez variables d'environnement pour la liste complète des variables prises en charge.

Définir des variables d'environnement pour les serveurs de développement

Pour fournir un secret à un serveur de développement sans le commiter dans launch.json, définissez-le à l'un de ces emplacements, puis redémarrez Desktop :

• macOS et Linux : exportez-le dans votre profil shell
• Windows : ajoutez-le à vos variables d'environnement utilisateur ou système
• Toute plateforme : enregistrez-le dans l'éditeur d'environnement local, si vous pouvez l'ouvrir

Les serveurs de développement ne reçoivent pas les variables que vous ajoutez à un environnement enregistré ou à ~/.claude/settings.json.

Utiliser l'éditeur d'environnement local

Pour ouvrir l'éditeur d'environnement local, cliquez sur l'icône d'engrenage de l'entrée correspondant à votre propre ordinateur, et non sur celle d'un environnement enregistré :

• Sélecteur sous la zone de prompt : survolez l'entrée de votre ordinateur, la première sous Local. Si une icône d'engrenage apparaît, cliquez dessus. Sinon, l'éditeur n'est pas disponible ; définissez donc la variable pour les sessions locales ou les serveurs de développement d'une autre manière.
• Sélecteur au-dessus de la zone de prompt : survolez Local et cliquez sur l'icône d'engrenage

Saisissez une paire KEY=value par ligne et sélectionnez Save changes. Les variables que vous enregistrez ici sont stockées chiffrées sur votre machine. Les sessions locales les reçoivent, à l'exception de toute variable que Desktop définit lui-même, comme API_TIMEOUT_MS. Redémarrez Desktop pour transmettre vos variables aux serveurs de développement.

Variable exportée absente ou incorrecte dans les commandes que Claude exécute

Si une commande que Claude exécute sous macOS ou Linux ne reçoit pas une variable que vous avez définie avec export dans ~/.zshrc ou ~/.bashrc, ou reçoit une valeur incorrecte, essayez ces solutions dans l'ordre :

1. Démarrer une nouvelle session

Demandez à Claude d'exécuter à nouveau la commande.

2. Quitter et rouvrir Desktop

Démarrez ensuite une nouvelle session.

3. Vérifier vos variables enregistrées

Si une commande reçoit une valeur incorrecte, vérifiez si vous avez également défini la variable dans un environnement enregistré ou dans l'éditeur d'environnement local. Si c'est le cas, modifiez-y la valeur et démarrez une nouvelle session.

4. Utiliser un environnement enregistré

Ajoutez la variable à un environnement local enregistré, puis démarrez une nouvelle session à partir de cet environnement. Pour une variable telle que PATH ou CLAUDE_CONFIG_DIR, suivez plutôt ses propres instructions.

Avant la v2.1.304, Claude Code ne transmet pas les variables exportées aux commandes : vérifiez donc quelle version la session exécute.

Variables d'environnement que Desktop définit lui-même

Si vous définissez API_TIMEOUT_MS ou ANTHROPIC_BASE_URL et que rien n'a changé dans vos sessions locales, c'est parce que Desktop définit lui-même ces variables, entre autres. Une session locale reçoit la valeur de Desktop, que vous ayez défini la vôtre dans votre profil shell, dans vos variables utilisateur ou système Windows, dans l'éditeur d'environnement local ou dans un environnement enregistré. Déplacer la vôtre dans un fichier de paramètres n'aide pas, car Claude Code ignore cette valeur dans une session locale.

• API_TIMEOUT_MS : une session locale reçoit 900000, soit 15 minutes. Pour un délai d'expiration plus long, installez la CLI Claude Code et utilisez-la à la place de Desktop. Définissez la variable dans votre shell et exécutez claude dans votre terminal.
• ANTHROPIC_BASE_URL : une session locale reçoit l'hôte de l'API d'Anthropic lorsque vous êtes connecté avec un compte Claude. Pour utiliser une passerelle, configurez plutôt la configuration d'inférence tierce de Desktop.

Désactiver la réflexion étendue

La réflexion étendue est activée par défaut, ce qui améliore les performances sur les tâches de raisonnement complexes, mais consomme des tokens supplémentaires. Pour la désactiver, définissez MAX_THINKING_TOKENS sur 0 dans un environnement local enregistré ou dans l'éditeur d'environnement local. La réflexion est alors désactivée sur l'API Anthropic, sauf sur Opus 5.5, Sonnet 5.5, Haiku 5.5 et les modèles Fable, qui utilisent toujours la réflexion étendue.

Sur Opus 5, sélectionnez également un niveau d'effort high ou inférieur avant de démarrer la session. Dans la disposition actuelle, ouvrez le sélecteur de modèle et sélectionnez un niveau sous Effort. Si vous avez démarré la session à un niveau supérieur, démarrez-en une nouvelle au niveau high ou inférieur.

Budgets de réflexion fixes

Sur les modèles avec raisonnement adaptatif, Claude Code ignore le nombre lui-même dans une valeur MAX_THINKING_TOKENS positive, car le raisonnement adaptatif contrôle la profondeur de la réflexion à la place. Sur Opus 4.6 et Sonnet 4.6, définissez CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING à 1 pour utiliser un budget de réflexion fixe ; les modèles Fable, Sonnet 5 et versions ultérieures, Haiku 5.5, et Opus 4.7 et versions ultérieures utilisent toujours le raisonnement adaptatif et n'ont pas de mode de budget fixe.

Sessions locales sur les appareils gérés

Si l'entrée de votre ordinateur est grisée dans le sélecteur d'environnement, avec l'info-bulle Disabled by your organization, votre administrateur a désactivé les sessions locales. Sur Windows, l'entrée WSL, dont la disponibilité sur les appareils gérés est régie séparément, est grisée de la même manière.

Les nouvelles sessions utilisent par défaut la première connexion SSH si une connexion est configurée. Si vous essayez de poursuivre une session locale existante, Desktop affiche un message indiquant que les sessions locales ne sont pas disponibles sur cet appareil. Les environnements locaux enregistrés affichent cette erreur lorsque vous en sélectionnez un : Couldn’t switch environments: the Local environment isn’t available anymore. Choisissez plutôt un environnement SSH ou cloud, ou contactez votre équipe informatique.

Sessions cloud

Les sessions cloud continuent en arrière-plan même si vous fermez l'application. L'utilisation compte vers les limites de votre plan d'abonnement sans frais de calcul séparés.

Pour ajouter, modifier ou archiver un environnement cloud, ouvrez le sélecteur d'environnement :

• Ajouter un environnement : sélectionnez New environment en bas du menu du sélecteur, puis l'onglet Cloud de la boîte de dialogue New environment
• Modifier ou archiver l'un de vos propres environnements : survolez-le et cliquez sur l'icône d'engrenage

Voir Configurer les environnements cloud pour les détails sur la configuration de l'accès réseau et des variables d'environnement.

Sessions SSH

Les sessions SSH vous permettent d'exécuter Claude Code sur une machine distante tout en utilisant l'application de bureau comme votre interface. Ceci est utile pour travailler avec des bases de code qui vivent sur des machines virtuelles cloud, des conteneurs de développement ou des serveurs avec du matériel ou des dépendances spécifiques.

[!NOTE]

Si vous utilisez Desktop avec un fournisseur tiers, les sessions SSH nécessitent leur propre configuration. Voir SSH remote sessions in Claude Desktop on 3P.

Ajoutez une connexion SSH dans la boîte de dialogue New environment, puis démarrez une session sur cette connexion. Si une nouvelle session n'a pas de sélecteur d'environnement sous la zone de prompt, vous disposez de l'ancienne disposition. Consultez Vérifier quelle disposition vous avez.

1. Ouvrir la boîte de dialogue New environment

Avant de démarrer une session, ouvrez le sélecteur d'environnement sous la zone de prompt et sélectionnez New environment en bas de son menu.

2. Ajouter la connexion

Dans l'onglet SSH de la boîte de dialogue New environment, ouvrez la liste Host, sélectionnez Add SSH connection… et renseignez les détails de la connexion :

• Name : un libellé convivial pour cette connexion.
• SSH host : user@hostname ou un hôte défini dans ~/.ssh/config.
• SSH port : vaut 22 par défaut s'il est laissé vide, ou utilise le port de votre configuration SSH.
• SSH key (optional) : chemin vers votre clé privée, comme ~/.ssh/id_ed25519. Laissez vide pour utiliser votre configuration SSH ou votre agent SSH.
• Worktree folder : un dossier sur la machine distante, comme ~/worktrees, dans lequel les nouvelles sessions créent leurs worktrees. Laissez vide pour utiliser la valeur par défaut de la machine distante.

Sélectionnez ensuite Add SSH connection.

3. Démarrer une session sur la connexion

Sélectionnez un dossier sur la machine distante et cliquez sur Create environment. Vous conservez la machine et le dossier ensemble sous forme d'environnement enregistré pour les sessions ultérieures. Desktop le sélectionne pour la nouvelle session ; saisissez donc votre tâche et appuyez sur Entrée.

La machine distante peut exécuter Linux, macOS ou Windows. Desktop installe Claude Code sur la machine distante automatiquement la première fois que vous vous connectez. Une fois connecté, les sessions SSH supportent les modes de permission, les connecteurs, les plugins et les serveurs MCP.

Exigences de la machine distante pour les sessions SSH

Une machine distante Linux ou macOS nécessite un processeur pris en charge, un serveur SSH avec SFTP, un dossier d'installation qui n'est pas monté en noexec, un shell fonctionnel et un accès réseau. Vérifiez chaque exigence avant de vous connecter, ou lorsqu'une connexion échoue après votre authentification :

• Système : un processeur x86_64 ou arm64. La machine doit également satisfaire la configuration système requise de Claude Code. Sur Linux, Claude Code nécessite glibc 2.17 ou une version ultérieure, ou musl. Pour savoir laquelle la machine possède, exécutez ldd --version sur celle-ci. Sur une distribution basée sur musl comme Alpine Linux, installez également les paquets dont Claude Code a besoin.
• SFTP : le serveur SSH doit proposer le sous-système SFTP, qu'une ligne Subsystem sftp dans son sshd_config active. Pour vérifier, connectez-vous au même hôte et au même port avec sftp dans un terminal sur votre ordinateur. Un serveur fonctionnel affiche l'invite sftp>.
• Sessions par connexion : Desktop sur macOS et Linux ouvre plusieurs sessions sur une même connexion SSH. Si le sshd_config du serveur définit MaxSessions 1, augmentez cette valeur, par exemple à la valeur par défaut d'OpenSSH, 10.
• Dossier d'installation : Desktop installe un programme auxiliaire et Claude Code sous ~/.claude/remote/ dans votre répertoire personnel. Il les exécute depuis cet emplacement, donc ce dossier ne peut pas se trouver sur un système de fichiers monté en noexec. Prévoyez environ 1 Go d'espace disque dans le répertoire personnel de chaque utilisateur qui se connecte. Pour savoir ce que contient ce dossier, voir Fichiers et processus sur la machine distante.
• Shell : le shell défini pour votre compte sur la machine distante doit exécuter les commandes envoyées via SSH, comme le font Bash, Zsh et sh
• Réseau : Claude Code s'exécute sur la machine distante et effectue ses requêtes réseau depuis celle-ci ; la machine a donc besoin de l'accès réseau requis par Claude Code. Si la machine ne peut pas télécharger Claude Code, Desktop le télécharge sur votre ordinateur et le transfère. Les autres requêtes de Claude Code partent toujours de la machine distante. Sur une machine distante Linux, si ces requêtes nécessitent un proxy, définissez-le pour les sessions SSH.

Définir un proxy ou un certificat CA pour les sessions SSH

Si une machine distante Linux accède à internet via un proxy ou a besoin d'un certificat CA, ajoutez les variables de proxy et de CA sous env dans ~/.claude/settings.json sur cette machine. Ajoutez-les même si vous les exportez déjà dans ~/.profile, ~/.bash_profile, ~/.zprofile ou ~/.zshrc sur cette machine.

Une session SSH ne les récupère pas depuis ces fichiers, même lorsque claude dans un terminal sur cette machine le fait. La session peut alors se bloquer, ou afficher The connection from … to the API failed ou Authentication failed, et se reconnecter n'y change rien.

1. Ajouter les variables

Pour le fichier CA, utilisez NODE_EXTRA_CA_CERTS, car Claude Code ne fait pas confiance à une CA provenant de SSL_CERT_FILE dans ~/.claude/settings.json. Cet exemple définit un proxy et un fichier CA :

{
  "env": {
    "HTTPS_PROXY": "http://proxy.example.com:8080",
    "NODE_EXTRA_CA_CERTS": "/etc/ssl/certs/example-ca.pem"
  }
}

2. Renvoyer votre message

Renvoyez votre message, car une variable que vous ajoutez ou modifiez dans ce fichier prend effet en quelques secondes. Démarrez une nouvelle session si l'échec persiste.

Trouver une variable de proxy ou de CA définie ailleurs sur la machine distante

Vérifiez si la machine distante Linux définit la variable de proxy ou de CA ailleurs, car les sessions utilisent cette valeur et ignorent celle de tout fichier de paramètres :

1. Lister les variables que la machine distante définit

Dans un terminal sur votre ordinateur, exécutez ssh devbox env, avec votre propre hôte.

2. Modifier la variable là où elle est définie

Si la liste contient la variable, modifiez-la dans le fichier qui la définit, comme ~/.zshenv, /etc/environment ou ~/.bashrc sur la machine distante.

3. Transmettre la nouvelle valeur aux sessions

Redémarrez la machine distante, ou quittez Desktop et mettez fin aux processus du programme auxiliaire, comme dans les deux premières étapes pour supprimer le programme auxiliaire. Faites-le lorsqu'aucune tâche n'est en cours, car l'une ou l'autre méthode interrompt le travail de Claude.

Utiliser votre configuration SSH sur macOS et Linux

Sur macOS et Linux, Desktop se connecte en exécutant le client OpenSSH sur votre ordinateur ; il utilise donc votre ~/.ssh/config. La connexion via le client OpenSSH nécessite Claude Desktop v1.37937.0 ou une version ultérieure. Saisissez un nom Host de ce fichier dans le champ Hôte SSH pour utiliser les paramètres de son entrée, comme HostName, User, IdentityFile, CertificateFile, ProxyJump et ProxyCommand.

Avant d'ajouter la connexion, vérifiez le client et l'entrée dans un terminal sur votre ordinateur :

• Version du client : exécutez ssh -V. Le client doit être OpenSSH 7.6 ou une version ultérieure.
• Entrée : exécutez ssh avec le nom Host, comme ssh devbox. Si cela échoue, corrigez d'abord l'entrée.

Vous pouvez laisser les champs Port SSH et Clé SSH (facultatif) vides. Si vous en renseignez un, Desktop l'utilise avec l'entrée :

• Port SSH : une valeur ici remplace le Port de l'entrée
• Clé SSH (facultatif) : Desktop propose le fichier de clé que vous choisissez en plus de l'IdentityFile de l'entrée et des clés de votre agent SSH

Atteindre une machine derrière un hôte de rebond

Pour atteindre une machine derrière un hôte de rebond, également appelé bastion, définissez ProxyJump ou ProxyCommand dans l'entrée. L'entrée suivante atteint devbox.internal.example.com via bastion.example.com :

Host devbox
  HostName devbox.internal.example.com
  User alice
  ProxyJump bastion.example.com

Saisissez devbox dans le champ Hôte SSH.

Si votre administrateur restreint les hôtes SSH, l'hôte de rebond doit également figurer dans la liste. Exécutez ssh -G bastion.example.com dans un terminal sur votre ordinateur et demandez-lui d'autoriser le hostname affiché.

Atteindre un conteneur sur une machine distante

Pour exécuter une session à l'intérieur d'un conteneur qui ne publie aucun port SSH, atteignez-le avec un ProxyCommand, car Desktop n'exécute pas le RemoteCommand de l'entrée à laquelle vous vous connectez. Si votre entrée utilise RemoteCommand pour entrer dans le conteneur, la session s'exécute sur la machine à laquelle l'entrée se connecte, et non dans le conteneur.

1. Ajouter l'entrée

Ajoutez l'entrée suivante à la fin de votre ~/.ssh/config, ou juste au-dessus de votre première entrée Host * si vous en avez une. Remplacez le conteneur Docker devbox, son utilisateur dev et la machine build.example.com par les vôtres. La commande de l'entrée démarre un serveur SSH à l'intérieur du conteneur pour chaque connexion :

Host devbox-container
  User dev
  ProxyCommand ssh build.example.com docker exec -i devbox /usr/sbin/sshd -i

2. Préparer le conteneur

• Installez le serveur OpenSSH, avec une clé d'hôte qui reste identique lorsque vous reconstruisez l'image ou recréez le conteneur
• Donnez au compte nommé dans User un moyen de se connecter, comme un fichier authorized_keys
• Vérifiez que le conteneur satisfait les exigences de la machine distante

3. Vérifier la liste d'autorisation

Si votre administrateur restreint les hôtes SSH, exécutez ssh -G devbox-container dans un terminal sur votre ordinateur. Demandez-lui d'autoriser le hostname que la commande affiche, ici devbox-container, dans sshHostAllowlist. Lorsqu'il autorise ce nom, il autorise tout ce à quoi le ProxyCommand de votre entrée se connecte.

4. Tester l'entrée, puis se connecter

Exécutez ssh devbox-container dans un terminal sur votre ordinateur. Corrigez ce que la commande signale, et exécutez-la à nouveau jusqu'à ce qu'elle ouvre un shell dans le conteneur sans rien vous demander :

• Si ssh demande un mot de passe, une phrase secrète ou un code : passez à une méthode de connexion qui fonctionne sans invite, comme une clé détenue par votre agent SSH
• Si ssh signale Cannot execute command-line and remote command. ou Bad packet length : retirez RemoteCommand et RequestTTY de votre entrée pour build.example.com. Ensuite, ssh build.example.com dans un terminal sur votre ordinateur ouvre un shell sur cette machine, et non dans le conteneur.
• Si ssh signale Connection closed by UNKNOWN port 65535 : exécutez ssh build.example.com docker exec devbox /usr/sbin/sshd -t dans le même terminal.
  • Si elle affiche Missing privilege separation directory: /run/sshd, créez ce dossier dans le conteneur.
  • Si elle affiche no hostkeys available et que le conteneur possède des clés d'hôte, ajoutez -u root après exec dans cette commande et dans l'entrée.

Saisissez ensuite devbox-container dans le champ Hôte SSH.

Utiliser des variables de votre shell dans un ProxyCommand

Pour utiliser une variable d'environnement qui vous est propre dans une commande ProxyCommand ou Match exec, exportez-la dans un fichier de démarrage du shell, comme ~/.zshrc, puis quittez et rouvrez Desktop. Au démarrage, Desktop lit ce que votre shell de connexion exporte, et conserve ces valeurs jusqu'à ce que vous le quittiez.

Cela nécessite Claude Desktop v2.37337.0 ou une version ultérieure et une commande env qui accepte -0, ce que vous pouvez vérifier en exécutant env -0 dans un terminal sur votre ordinateur.

[!NOTE]

Si votre shell définit des identifiants AWS temporaires, fournissez un profil à l'AWS CLI au lieu d'exporter des variables AWS_*.

Utiliser des identifiants AWS dans un ProxyCommand

Si vous définissez des identifiants AWS temporaires dans un fichier de démarrage du shell, un ProxyCommand qui exécute l'AWS CLI peut se connecter dans un terminal et échouer dans Desktop. Lorsque votre shell exporte AWS_SESSION_TOKEN, AWS_SECURITY_TOKEN ou AWS_CREDENTIAL_EXPIRATION, ssh et votre ProxyCommand dans Desktop ne récupèrent ni les identifiants AWS du shell, ni AWS_REGION, ni AWS_PROFILE.

Si l'AWS CLI n'a aucune autre source pour une région ou des identifiants, elle échoue avec You must specify a region ou Unable to locate credentials. Pour vous connecter depuis Desktop, fournissez à l'AWS CLI un profil qu'elle lit depuis ~/.aws/config :

1. Ajouter un profil avec une région et une source d'identifiants

Cet exemple ajoute un profil nommé corp qui obtient ses identifiants d'un programme auxiliaire :

[profile corp]
region = us-east-1
credential_process = /full/path/to/your-credential-helper

• region : indiquez la région AWS des machines auxquelles vous vous connectez
• credential_process : indiquez le chemin complet d'un programme qui affiche des identifiants au format JSON documenté par AWS. Choisissez un programme qui ne nécessite aucune saisie de votre part, car l'AWS CLI l'exécute à chaque connexion, y compris lors des reconnexions pendant votre absence.
• IAM Identity Center : ajoutez les paramètres IAM Identity Center du profil à la place de credential_process. Exécutez aws sso login --profile corp dans un terminal avant de vous connecter, et à nouveau lorsque cette authentification expire.

2. Nommer le profil dans le ProxyCommand

Cet exemple ajoute --profile à la commande documentée par AWS pour Session Manager :

Host i-*
  ProxyCommand sh -c "aws ssm start-session --profile corp --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

3. Se reconnecter

Exécutez ssh avec l'hôte dans un terminal pour confirmer que l'entrée s'y connecte toujours, puis connectez-vous depuis Desktop.

Augmenter le délai d'expiration de la connexion SSH

Si votre configuration SSH ne définit aucun ConnectTimeout pour l'hôte, Desktop accorde 30 secondes à ssh pour se connecter. Via un hôte de rebond ou un ProxyCommand, ce délai inclut le temps nécessaire à l'établissement de la route. Si votre route a besoin de plus de temps, ajoutez une valeur plus élevée à l'entrée :

Host devbox
  HostName devbox.internal.example.com
  User alice
  ProxyJump bastion.example.com
  ConnectTimeout 120

ssh utilise la première valeur qu'il trouve pour un hôte ; placez donc l'entrée au-dessus de toute entrée Host * qui définit ConnectTimeout. Pour confirmer, exécutez ssh -G devbox dans un terminal sur votre ordinateur. Sa sortie inclut connecttimeout 120. Après avoir modifié la valeur, quittez et rouvrez Desktop.

Si la machine distante elle-même attend une approbation sur votre téléphone, approuvez dans les 45 secondes, quel que soit le ConnectTimeout que vous définissez. Vous ne pouvez pas augmenter cette limite, car Desktop définit lui-même ServerAliveInterval et ServerAliveCountMax, et ssh ferme alors une connexion pendant laquelle la machine distante n'envoie rien pendant aussi longtemps. Si c'est plutôt un hôte de rebond ou un ProxyCommand qui vous attend, augmentez ConnectTimeout dans l'entrée de la machine distante pour couvrir ce délai.

Corriger un bloc Match host que seul Desktop applique

Si Desktop utilise un paramètre que ssh devbox dans un terminal n'utilise pas, recherchez un bloc Match host au-dessus de la ligne HostName de l'entrée. Dans un terminal, ssh lit un bloc situé à cet endroit avant la ligne HostName ; il compare donc le bloc avec devbox. Desktop transmet à ssh la valeur HostName sur la ligne de commande ; ssh compare donc le bloc avec cette valeur.

Pour vérifier, exécutez ssh -G dans un terminal sur votre ordinateur avec les valeurs HostName et User de l'entrée sur la ligne de commande, comme le fait Desktop :

ssh -G -o HostName=devbox.internal.example.com -l alice devbox

Comparez la sortie avec celle de ssh -G devbox. Si les paramètres du bloc, comme proxycommand, n'apparaissent que dans la première sortie, le bloc ne prend effet que dans Desktop. Pour que Desktop l'ignore aussi, ajoutez !originalhost devbox à sa ligne Match :

Match host *.internal.example.com !originalhost devbox

Pour confirmer, exécutez à nouveau la première commande. Les paramètres du bloc n'apparaissent plus dans sa sortie.

Paramètres de redirection que Desktop laisse désactivés

Sur sa connexion à la machine distante, Desktop laisse ForwardAgent, ForwardX11, LocalForward, RemoteForward, DynamicForward et Tunnel désactivés, même lorsque votre configuration SSH les active. Dans le terminal ou une commande !, attendez-vous à ce que vos paramètres de redirection ne s'appliquent que parfois, car Desktop peut y démarrer un ssh distinct qui les suit.

• Pour atteindre un port sur la machine distante : redirigez-le vous-même
• Pour utiliser vos propres clés depuis la machine distante : configurez des identifiants sur la machine distante elle-même, par exemple pour git push

Pour empêcher Desktop de rediriger votre agent SSH ou un port, exécutez ssh -G devbox dans un terminal sur votre ordinateur. Exécutez-la ensuite à nouveau comme Desktop peut l'exécuter, avec les valeurs hostname et user qu'elle affiche, comme dans ssh -G -o HostName=devbox.internal.example.com -l alice devbox. La seconde sortie peut afficher des paramètres d'un bloc Match que la première ignore.

Recherchez dans les deux sorties une ligne forwardagent qui indique autre chose que no, ainsi que des lignes commençant par localforward, remoteforward ou dynamicforward. Si vous en trouvez une, supprimez ce paramètre de votre configuration SSH. Faites de même pour un hôte que votre ProxyCommand atteint avec ssh.

Atteindre un port sur la machine distante

Pour ouvrir un serveur qui s'exécute sur la machine distante, comme un serveur de développement sur le port 3000, redirigez le port vous-même. Dans un terminal sur votre ordinateur, exécutez ssh avec -L et l'hôte auquel vous vous connectez, comme devbox :

ssh -N -L 3000:localhost:3000 devbox

Si vous avez renseigné Port SSH ou Clé SSH (facultatif) sur la connexion, ajoutez -p ou -i avec la même valeur. Laissez cette commande s'exécuter, et ouvrez http://localhost:3000 dans un navigateur sur votre ordinateur pour atteindre le port 3000 de la machine distante. Si ssh affiche open failed: administratively prohibited, demandez à l'administrateur de la machine d'autoriser la redirection TCP, contrôlée par AllowTcpForwarding dans le sshd_config du serveur SSH.

Machines distantes Windows

Une machine distante Windows nécessite Claude Desktop v2.31226.0 ou une version ultérieure.

Utilisez le serveur OpenSSH de Microsoft. La machine peut être x64 ou ARM64. Le shell que démarre le serveur SSH peut être cmd.exe, Windows PowerShell 5.1 ou Git Bash.

Les machines distantes Windows sont moins testées que les machines Linux. Essayez votre propre travail dessus avant de vous y fier.

Attendez-vous notamment à ces limites sur une machine distante Windows :

• Terminal : le terminal ne s'ouvre pas dans une session dont le dossier est un chemin Windows, comme C:/projects/app
• Sandbox : Claude Code s'y exécute sur Windows natif, où il exécute les commandes hors sandbox. Voir où le sandbox s'exécute.
• Plugins : Desktop ne copie pas un plugin qui contient un nom de fichier ou de dossier que Windows ne peut pas stocker, comme un nom avec :. La session liste les plugins que Desktop a laissés de côté.
• Serveurs MCP : sur certaines machines distantes Windows, les appels de Claude aux serveurs MCP de claude_desktop_config.json passent par Desktop ; Claude ne peut donc pas appeler leurs outils pendant que Desktop est déconnecté. Avant Claude Desktop v2.37337.0, cela vaut pour toutes les machines distantes Windows.
• Worktrees : les worktrees vont dans <project-root>/.claude/worktrees/. Si vous choisissez un autre dossier, Desktop l'ignore.
• Messages précédents : si le shell du serveur SSH est cmd.exe ou Windows PowerShell, vous devrez peut-être vous connecter avant de voir les messages précédents d'une session
• Forks : si le shell du serveur SSH est cmd.exe ou Windows PowerShell, vous ne pouvez forker une session qu'à son premier message
• Exécution pendant la déconnexion : une tâche continue de s'exécuter pendant que Desktop est déconnecté uniquement si le serveur SSH permet à un programme de survivre à la connexion qui l'a démarré. Pour le savoir, testez la machine distante.
• Processus résiduels : après la fin d'une session, vérifiez sur la machine les programmes que Claude Code a démarrés, car ils peuvent continuer à s'exécuter. Le programme auxiliaire d'arrière-plan que Desktop installe ne s'arrête pas de lui-même sur cette machine.

Garder une tâche en cours d'exécution pendant que Desktop est déconnecté

Si votre ordinateur se met en veille, si vous perdez le réseau ou si vous quittez Desktop, la tâche continue jusqu'à ce qu'elle se termine, ait besoin de vous ou atteigne l'une des limites. Fermer le capot compte comme une mise en veille. Un redémarrage de Desktop ou de votre ordinateur, y compris pour une mise à jour, compte comme le fait de quitter Desktop.

Claude Code s'exécute en tant que processus sur la machine distante, sous un programme auxiliaire d'arrière-plan que Desktop y installe ; il n'a donc pas besoin de votre connexion SSH pour continuer à s'exécuter. Le comportement décrit dans cette section nécessite Claude Desktop v2.31226.0 ou une version ultérieure.

[!WARNING]

Si vous vous connectez à Desktop avec un compte Claude, ne comptez pas sur une tâche pour s'exécuter toute la nuit. Desktop renouvelle cette authentification pour la tâche uniquement tant que Desktop est en cours d'exécution et connecté ; l'authentification de la tâche peut donc expirer après votre déconnexion, et la tâche s'arrête alors. Le temps restant au moment de votre déconnexion varie, et il peut n'être que de quelques minutes.

Le travail effectué jusque-là reste sur la machine distante, et vous pouvez reprendre avec un message à votre retour.

Si la tâche doit s'exécuter toute la nuit :

• Gardez votre ordinateur éveillé et en ligne, avec le capot ouvert et Desktop en cours d'exécution
• Utilisez une méthode de connexion qui fonctionne sans invite, comme une clé détenue par votre agent SSH, pour la machine distante et pour tout hôte de rebond sur le chemin. Desktop peut alors se reconnecter de lui-même après une coupure.

Pour une tâche qui doit s'exécuter pendant que votre ordinateur est en veille ou éteint, démarrez plutôt une session cloud.

• Après une mise en veille ou une perte réseau : vous récupérez la tâche en cours si le processus s'exécute toujours et si Desktop peut se connecter sans invite. Sinon, envoyez un message.
• Après avoir quitté l'application : la tâche continue de s'exécuter, mais vous la perdez lorsque la session s'ouvre à nouveau, sauf si Desktop peut rejoindre son processus. Vérifiez quand Desktop peut rejoindre le processus avant de quitter. Si vous avez perdu la tâche, envoyez un message pour continuer.

Lorsque vous revenez et que la tâche n'est pas terminée, recherchez une indication que Desktop ne peut pas se reconnecter, une erreur d'authentification ou une demande en attente :

• Desktop ne peut pas se reconnecter : la session indique pourquoi, et une notification peut aussi l'indiquer. Desktop peut avoir besoin que vous vous connectiez.
• Erreur d'authentification : le jeton de connexion ou les identifiants ont peut-être expiré. Avec un compte Claude, envoyez un message pour continuer. Avec un fournisseur tiers, voir SSH remote sessions in Claude Desktop on 3P.
• Demande en attente : répondez-y
• Aucun de ces cas : envoyez un message pour continuer

Préparer une tâche longue

• Mettez à jour d'abord : mettez à jour Desktop avant de démarrer une tâche longue. Sur macOS et Windows, Desktop peut redémarrer de lui-même pour installer une mise à jour qu'il a téléchargée. Ce redémarrage attend pendant que Claude travaille sur une tâche SSH. Sur macOS avec un compte Claude, par défaut, le redémarrage peut quand même avoir lieu une fois que la mise à jour a attendu 72 heures.
• Ne quittez pas l'application sur Windows, ni avant la v2.42304.0 avec un fournisseur tiers : dans ces cas, quitter l'application vous fait perdre la tâche en cours, alors laissez Desktop ouvert pendant la tâche. Dans tous les autres cas, consultez ce que vous récupérez avant de quitter.
• Réduisez les demandes : choisissez un mode de permission, des règles ou des hooks qui font que la tâche vous attend moins souvent
• Vérifiez l'hôte de rebond : si votre hôte de rebond demande une authentification, par exemple une notification push sur un téléphone, passez à une méthode de connexion qui fonctionne sans invite. Sinon, Desktop peut envoyer une nouvelle notification push à chaque tentative de reconnexion.
• Testez la machine distante : démarrez une tâche courte, quittez Desktop pendant que la tâche s'exécute encore, et rouvrez la session bien après le moment où la tâche devrait être terminée. Si la tâche n'est pas terminée et que la session n'affiche aucune erreur d'authentification, vérifiez sur la machine distante ce qui peut mettre fin à une tâche.
• Gardez les commandes hors du terminal de Desktop : si la machine distante déconnecte les terminaux inactifs, exécutez vos propres commandes depuis une connexion SSH en dehors de Desktop

Limites pendant que Desktop est déconnecté

Une tâche que vous laissez s'exécuter peut se terminer lorsque son authentification expire, lorsque la machine distante y met fin, ou lorsque le programme auxiliaire s'arrête ou est remplacé :

• Jeton de connexion ou identifiants : avec un compte Claude, la tâche s'arrête avec une erreur d'authentification lorsque le jeton expire. Avec un fournisseur tiers, il en va de même pour des identifiants qui expirent, comme ceux issus de l'authentification unique ou d'un credential helper. Voir SSH remote sessions in Claude Desktop on 3P. Avec un compte Claude, gardez Desktop en cours d'exécution et connecté afin qu'il puisse renouveler l'authentification.
• La machine distante : si la machine distante redémarre, ou met fin à vos processus lorsque votre connexion SSH se ferme, la tâche en cours se termine. Rien ne la redémarre pendant que Desktop est déconnecté. Les machines Linux où le KillUserProcesses de systemd-logind vaut yes et s'applique à votre utilisateur mettent fin à vos processus de cette manière. Pour y garder une tâche en cours d'exécution, demandez à l'administrateur d'exempter votre utilisateur, par exemple avec KillExcludeUsers.
• Terminaux inactifs : certaines machines distantes Linux déconnectent un terminal dans lequel personne ne tape pendant une durée définie (StopIdleSessionSec de systemd-logind). Avec Desktop sur macOS ou Linux, le terminal d'une session et les commandes ! partagent par défaut la connexion SSH de Desktop. Cette déconnexion met alors fin à la connexion pendant que Desktop est connecté, et la tâche en cours peut se terminer avec elle. Fermer le panneau du terminal ne l'empêche pas ; gardez donc les commandes hors de ce terminal.
• Mises à jour de Desktop : si une mise à jour apporte un nouveau programme auxiliaire, Desktop remplace le programme auxiliaire sur la machine distante lors d'une connexion ultérieure, ce qui peut mettre fin à une tâche encore en cours
• Absences prolongées : sur une machine distante Linux ou macOS, si Desktop ne se connecte pas pendant 30 jours, le programme auxiliaire s'arrête et met fin à chaque processus Claude Code qui s'exécute sous lui. Connectez-vous avant cette échéance.

Les modifications de fichiers et certains outils peuvent échouer pendant que Desktop est déconnecté. Si la tâche en a besoin, gardez Desktop connecté :

• Worktrees : dans une session qui utilise un worktree, Desktop vérifie chaque modification de fichier avant que Claude ne l'effectue. Pendant que Desktop est déconnecté, chaque modification attend environ 30 secondes puis échoue. Les commandes shell s'exécutent toujours. Sur une machine distante Linux ou macOS, les modifications peuvent continuer à fonctionner. En cas de doute, démarrez la session sans worktree.
• Restrictions de dossiers : si votre organisation restreint les dossiers que les sessions peuvent utiliser, Desktop vérifie chaque lecture, recherche et modification de fichier, avec ou sans worktree. Pendant que Desktop est déconnecté, chacune attend jusqu'à 10 minutes puis échoue.
• Connecteurs : les connecteurs et les autres outils fournis par Desktop passent par Desktop ; pendant qu'il est déconnecté, chaque appel échoue donc après environ 30 secondes
• Workflows : Desktop vérifie chaque nouveau workflow avant son démarrage ; pendant que Desktop est déconnecté, un nouveau workflow attend donc jusqu'à 10 minutes puis échoue
• Serveurs MCP : les serveurs MCP que Claude Code démarre sur la machine distante ne passent pas par Desktop ; Claude peut donc toujours appeler leurs outils. Les serveurs de claude_desktop_config.json en font partie uniquement si Desktop n'utilise pas son client SSH intégré. Sinon, et sur certaines machines distantes Windows, Claude ne peut pas appeler leurs outils pendant que Desktop est déconnecté.

Quand les modifications dans un worktree continuent de fonctionner

Sur une machine distante Linux ou macOS, la vérification ne passe pas par Desktop ; les modifications à l'intérieur du worktree continuent donc de fonctionner pendant que Desktop est déconnecté. Avant Claude Desktop v2.37337.0, cela vaut uniquement sur une machine distante Linux.

Les modifications échouent encore dans certains cas, notamment ceux-ci :

• Client SSH intégré : Desktop l'utilise, par exemple dans une installation Microsoft Store, sur un ordinateur Windows sans OpenSSH 9.4 ou version ultérieure de Microsoft, ou par défaut sur Windows avec un fournisseur tiers
• Emplacement du dépôt : le dépôt est votre répertoire personnel, un dossier au-dessus de celui-ci, ou ~/.claude
• Chemins macOS : sur une machine distante macOS, le dépôt se trouve sous /Volumes, ou un nom de dossier dans le chemin du dépôt ou du worktree contient un ~ ou un caractère non ASCII
• Restrictions de dossiers : votre organisation restreint les dossiers que les sessions peuvent utiliser
• Lanceur d'entreprise : avant Claude Desktop v2.37337.0, vous vous connectez avec un compte Claude, et votre organisation démarre Claude Code sur la machine distante via un lanceur d'entreprise

Une session sans worktree n'est soumise à aucune vérification de ce type, sauf si votre organisation restreint les dossiers que les sessions peuvent utiliser.

Gérer les demandes qui arrivent pendant votre absence

Si Claude a besoin de votre approbation ou vous pose une question pendant que Desktop est déconnecté, Claude attend sur la machine distante. L'attente n'a pas de limite de temps propre. Lorsque Desktop rejoint le processus, il vous affiche la demande. Si Desktop démarre plutôt un nouveau processus, vous perdez la demande.

Si une demande qui vous attendait a disparu à votre retour, l'une des causes possibles est que Desktop a redémarré de lui-même, par exemple pour installer une mise à jour. Vous ne conservez une demande après un redémarrage que si Desktop peut rejoindre le processus, donc vérifiez quand Desktop peut rejoindre le processus avant de laisser une tâche s'exécuter.

Si vous perdez une demande, envoyez un message pour continuer.

Pour réduire la fréquence à laquelle une tâche s'arrête pour vous attendre, et pour en recevoir des nouvelles pendant votre absence, configurez l'un de ces éléments avant de partir :

• Mode auto : choisissez le mode auto s'il vous est disponible. Après des blocages répétés, la question vous est à nouveau posée.
• Règles d'autorisation : dans votre fichier de paramètres utilisateur sur la machine distante, ~/.claude/settings.json, ajoutez des règles d'autorisation pour les commandes dont la tâche a besoin. Si votre organisation n'accepte les règles de permission que depuis les paramètres gérés, demandez à votre administrateur de les ajouter aux paramètres gérés qui atteignent la machine distante. Pour les règles d'autorisation dans le .claude/settings.json d'un projet, voir Règles d'autorisation du projet et confiance de l'espace de travail.
• Un hook qui répond : configurez un hook PermissionRequest dans ~/.claude/settings.json sur la machine distante pour autoriser ou refuser les demandes à votre place
• Un hook qui vous alerte : configurez un hook Notification avec le matcher permission_prompt dans le même fichier pour vous envoyer un message lorsqu'une demande est en attente
• Un hook qui vous prévient quand Claude a terminé : configurez un hook Stop dans le même fichier pour vous envoyer un message lorsque Claude a fini de répondre. Il ne s'exécute pas lorsqu'une erreur d'API met fin au tour. Pour ce cas, configurez un hook StopFailure.

Si votre organisation n'exécute que des hooks gérés, demandez à votre administrateur d'ajouter le hook aux paramètres gérés qui atteignent la machine distante.

Claude Code n'approuve automatiquement quelques actions dans aucun mode de permission, y compris Bypass permissions. Selon le mode de permission, Claude Code refuse une telle action ou vous la demande, et la tâche attend alors votre réponse.

Se reconnecter après une mise en veille ou une perte réseau

Si Desktop ne s'est pas reconnecté à votre retour, envoyez un message dans la session. Desktop se reconnecte de lui-même uniquement lorsqu'il peut se connecter sans invite, par exemple avec une clé détenue par votre agent SSH.

• Mot de passe mémorisé : un mot de passe que vous laissez Desktop mémoriser fonctionne aussi sans invite, mais pour une absence prolongée, préférez une clé détenue par votre agent SSH. Si les connexions avec ce mot de passe s'interrompent ou se bloquent, Desktop peut cesser de se reconnecter et vous attendre.
• Toute autre invite : si la machine distante demande autre chose, comme un code à usage unique, vous pouvez recevoir une notification sur votre ordinateur. Cliquez sur la notification, ou envoyez un message dans la session, et Desktop affiche l'invite.

Si un hôte de rebond demande une authentification, si la panne est longue, si une sortie manque ou si le processus a disparu

• Hôte de rebond, les notifications push s'arrêtent pendant votre absence : cela peut se produire avec Desktop sur macOS ou Linux lorsque personne ne répond à l'authentification d'un hôte de rebond, par exemple une notification push sur un téléphone. Desktop cesse alors de se reconnecter tant que personne n'est devant votre ordinateur. Lorsque vous déverrouillez ou utilisez l'ordinateur, vous pouvez recevoir une nouvelle notification push, car Desktop peut réessayer. Après trois tentatives sans réponse, il attend que vous réessayiez ou envoyiez un message.
• Hôte de rebond, les notifications push continuent : lorsque Desktop ne peut pas savoir que personne ne répond, comme avec Desktop sur Windows, il continue d'essayer tant qu'il a un processus à rejoindre, que ce processus s'exécute encore ou non. Vous pouvez recevoir une nouvelle notification push à chaque tentative. Pour mettre fin aux tentatives, quittez Desktop, ce qui peut vous faire perdre la tâche en cours.
• Panne longue : Desktop ralentit à environ une tentative toutes les cinq minutes. Pour vous reconnecter plus tôt, réessayez dans la session ou envoyez un message, que Desktop transmet une fois connecté.
• Sortie manquante : pendant que Desktop est déconnecté, le programme auxiliaire conserve la sortie Claude Code la plus récente de chaque session dans un tampon de 16 Mio et supprime la sortie plus ancienne. Après la reconnexion de Desktop, la session peut afficher Loading recent output from <host>…. Si Desktop ne peut pas charger toute la sortie, vous voyez la ligne Some output produced while you were disconnected may be missing here. Cette ligne ne signifie pas que la tâche s'est arrêtée.
• Processus disparu : le processus s'est terminé pendant que Desktop était déconnecté, comme lorsque la machine distante redémarre. Desktop peut alors en démarrer un nouveau à partir de l'historique enregistré de la conversation et demander à Claude de poursuivre la tâche. Si la tâche reste arrêtée, envoyez un message. Avec un fournisseur tiers, passez à Claude Desktop v2.42304.0 ou version ultérieure, car les versions antérieures ne poursuivent jamais la tâche d'elles-mêmes.

Rouvrir une session après avoir quitté Desktop

Après avoir quitté Desktop, la tâche continue de s'exécuter sur la machine distante, mais elle s'arrête lorsque la session s'ouvre à nouveau, sauf si Desktop peut rejoindre son processus. Pendant que Desktop est fermé, la tâche s'exécute jusqu'à ce qu'elle se termine, ait besoin de vous ou atteigne l'une des limites.

• Desktop sur Windows : vous ne récupérez pas la tâche en cours, car Desktop ne rejoint jamais le processus après avoir été quitté. Ne redémarrez Desktop que lorsque vous pensez que la tâche est terminée, car la session peut s'ouvrir au démarrage de Desktop.
• Fournisseur tiers, tâche démarrée dans une version antérieure : si vous avez démarré la tâche dans une version de Desktop antérieure à la v2.42304.0, vous ne la récupérez pas non plus sur macOS ou Linux. Ne redémarrez Desktop que lorsque vous pensez que la tâche est terminée.
• Toute autre tâche, avec Desktop sur macOS ou Linux : démarrez Desktop et ouvrez la session, et la tâche se poursuit si Desktop rejoint le processus. Il ne peut pas toujours le rejoindre, par exemple après certaines mises à jour de Desktop, donc mettez à jour avant une tâche longue.

Lorsque Desktop ne peut pas rejoindre le processus, vous perdez également toute approbation ou question qui vous attendait. Si la tâche ne se poursuit pas d'elle-même, envoyez un message, et Claude continue à partir de l'historique enregistré de la conversation.

Pour les déploiements tiers, voir SSH remote sessions in Claude Desktop on 3P.

[!WARNING]

Tant que le processus Claude Code d'une conversation s'exécute encore, n'exécutez pas claude --resume pour celle-ci sur la machine distante. Claude Code ne vous en empêche pas, et les deux processus écrivent alors dans la même conversation. En cas de doute, ajoutez --fork-session, qui continue dans une copie de la conversation, mais les deux processus travaillent toujours sur les mêmes fichiers.

Choisir l'emplacement des worktrees des sessions SSH

Sauf si votre organisation restreint les dossiers que les sessions peuvent utiliser, les nouvelles sessions SSH créent leurs worktrees dans le premier de ces emplacements qui est défini :

1. Dossier des worktrees sur la connexion SSH
2. worktree.location dans ~/.claude/settings.json sur la machine distante
3. <project-root>/.claude/worktrees/, la valeur par défaut

Chaque projet obtient son propre sous-dossier dans le dossier que vous définissez ; ainsi, avec ~/worktrees, le chemin d'un worktree est ~/worktrees/<project>-<id>/<worktree-name>. Si le dossier que vous définissez se trouve à l'intérieur du projet, Desktop l'ignore pour ce projet et utilise la valeur par défaut. Sur une machine distante Windows, Desktop utilise toujours la valeur par défaut.

Définir le dossier des worktrees sur une connexion existante

Définissez Worktree folder dans les paramètres d'une connexion que vous avez ajoutée précédemment ou d'une connexion gérée par votre organisation. Ce champ nécessite Claude Desktop v1.44121.0 ou une version ultérieure. Si votre organisation restreint les dossiers que les sessions peuvent utiliser, Desktop masque ce champ et conserve les worktrees à l'intérieur du projet.

1. Trouver la connexion

Ouvrez le sélecteur d'environnement et trouvez la connexion sous SSH.

2. Ouvrir les paramètres de la connexion

Survolez la connexion et cliquez sur l'icône d'engrenage. Si la boîte de dialogue qui s'ouvre affiche Edit connection… à côté de Host, sélectionnez Edit connection….

3. Définir le dossier

Dans Worktree folder, saisissez un dossier sur la machine distante, comme ~/worktrees, et sélectionnez Save changes.

Fichiers et processus sur la machine distante

Desktop installe un programme auxiliaire et Claude Code sous ~/.claude/remote/ dans le répertoire personnel de chaque utilisateur qui se connecte à une machine distante Linux ou macOS. Le programme auxiliaire n'écoute sur aucun port réseau, mais Claude Code et les programmes qu'il démarre, comme les serveurs MCP et les serveurs de développement, peuvent le faire.

Pour lister les processus d'un utilisateur, exécutez pgrep -fl "$HOME/.claude/remote/" sur la machine distante en tant que cet utilisateur, ou avec le répertoire personnel de l'utilisateur à la place de $HOME :

• Programme auxiliaire : un ou plusieurs processus server pour chaque ordinateur qui se connecte
• Claude Code : les processus que le programme auxiliaire démarre pour les sessions de l'utilisateur, chacun à partir d'un fichier nommé d'après sa version, comme 2.1.295-…

Desktop atteint le programme auxiliaire via la connexion SSH de l'utilisateur, par le socket Unix rpc.sock situé dans le dossier du programme auxiliaire sous ~/.claude/remote/run/. Hormis root, les autres utilisateurs de la machine ne peuvent pas se connecter à ce socket, car il a le mode 600 et son dossier a le mode 700.

Pour savoir quand le programme auxiliaire s'arrête de lui-même, voir Limites pendant que Desktop est déconnecté.

Pour supprimer le programme auxiliaire et Claude Code pour un utilisateur :

1. Quitter Desktop

Quittez Desktop sur chaque ordinateur depuis lequel l'utilisateur se connecte. Desktop réinstalle les deux programmes lors de sa prochaine connexion, et il peut se reconnecter de lui-même.

2. Mettre fin aux processus

Connecté en tant que cet utilisateur sur la machine distante, exécutez kill avec l'ID de chaque processus Claude Code que pgrep liste. Une fois ceux-ci disparus de la liste, exécutez kill avec l'ID de chaque processus server. Si vous mettez d'abord fin à un processus server, une commande que Claude Code exécute peut continuer à s'exécuter.

Listez ensuite les processus restants de l'utilisateur, par exemple avec ps -u "$(id -un)" -f, et mettez fin à ceux que vous reconnaissez comme démarrés par Claude Code. Les programmes qu'il a laissés en arrière-plan peuvent continuer à s'exécuter après sa fin, sans figurer dans la liste pgrep.

3. Supprimer le dossier

Supprimez ~/.claude/remote/. Pour supprimer les fichiers propres à Claude Code dans ~/.claude/ et ~/.claude.json, voir Supprimer les fichiers de configuration.

Mettre fin au processus d'une session

Pour terminer le processus Claude Code d'une session, archivez la session dans Desktop pendant que Desktop est connecté à la machine distante. Le processus continue de s'exécuter une fois sa tâche terminée et après que vous avez quitté Desktop.

Avant d'archiver une session dont le worktree contient des modifications non commitées, consultez Conserver les modifications non commitées lors de l'archivage d'une session.

Voir sous quel utilisateur les processus s'exécutent

Le programme auxiliaire et Claude Code s'exécutent en tant qu'utilisateur avec lequel Desktop se connecte via SSH. Leur installation et leur démarrage ne nécessitent pas sudo. Pour vérifier l'utilisateur, exécutez ps -o user= -p sur la machine distante avec un ID de processus que pgrep liste.

Les programmes que Claude Code démarre, comme les commandes shell et les serveurs MCP, démarrent également en tant que cet utilisateur. Examinez les droits de cet utilisateur sur la machine distante, y compris ses règles sudo, comme vous le feriez pour une personne qui y exécute des commandes.

Voir qui s'est connecté à la machine distante

Pour savoir qui s'est connecté à une machine distante, lisez le log du serveur SSH sur cette machine, où une connexion depuis Desktop ressemble à une connexion depuis un terminal. Avec Desktop sur macOS ou Linux, attendez-vous à une entrée chaque fois que Desktop se connecte, et non à une entrée par session.

Vous ne trouverez pas les connexions SSH de Desktop dans les métriques et événements de Claude Code. Pour savoir à partir de ceux-ci sur quelle machine distante une session SSH s'est exécutée, consultez Attribuer la télémétrie aux sessions SSH de Desktop. Pour l'historique que Desktop conserve lui-même de ses connexions, consultez Obtenir les logs de Desktop pour un problème SSH.

Connexions qui se ferment avant l'authentification

Si le log du serveur SSH affiche des connexions qui se ferment avant toute authentification, il peut s'agir de tests du port SSH effectués par Desktop. Desktop teste si une machine répond, par exemple après l'échec d'une connexion à celle-ci. Il ouvre une connexion au port et la ferme aussitôt, sans rien envoyer. Attendez-vous à un test ou à plusieurs à la suite, par exemple huit en environ deux minutes.

Si rien ne bannit ni ne refuse des adresses pour de telles connexions, vous n'avez rien à faire concernant les tests de Desktop. Si une adresse depuis laquelle Desktop se connecte est refusée ou bannie, vérifiez si le serveur SSH lui-même refuse l'adresse et si fail2ban comptabilise les tests de Desktop.

Reconnaître un test dans le log du serveur SSH

Comparez les lignes de votre log avec celles qu'un serveur OpenSSH sur Linux écrit pour un test au LogLevel par défaut, dans la ligne correspondant à la version de votre serveur. Vous pouvez voir à la place les lignes de la dernière colonne si le message d'accueil du serveur arrive avant que Desktop ne ferme la connexion :

D'autres programmes qui ouvrent le port et le ferment peuvent laisser les mêmes lignes. Lorsqu'une ligne contient une adresse, vérifiez qu'il s'agit de celle depuis laquelle un ordinateur équipé de Desktop se connecte.

Les lignes des versions 8.0 à 8.2 ne contiennent pas d'adresse. Pour en obtenir une, définissez LogLevel VERBOSE dans sshd_config et exécutez sshd -T | grep -i loglevel en tant que root. S'il affiche loglevel VERBOSE, rechargez le serveur SSH. Recherchez ensuite une ligne contenant Connection from 203.0.113.7 port 51234 avant la ligne du test.

Vérifier si le serveur SSH lui-même refuse l'adresse

Si des connexions sont refusées depuis une adresse partagée par de nombreux ordinateurs équipés de Desktop, recherchez dans le log du serveur SSH une ligne qui se termine comme celle-ci :

drop connection #0 from [203.0.113.7]:51234 on [192.0.2.10]:22 penalty: connections without attempting authentication

Avec le LogLevel par défaut, OpenSSH 9.8 et versions ultérieures peuvent écrire une telle ligne lorsqu'ils refusent une adresse pour des connexions fermées sans tentative d'authentification, comme le font les tests de Desktop. Avec les paramètres par défaut, vous ne voyez pas une telle ligne après seulement quelques tests.

Pour empêcher le refus, définissez PerSourcePenaltyExemptList dans sshd_config sur les adresses depuis lesquelles les personnes se connectent, par exemple PerSourcePenaltyExemptList 203.0.113.7. Le serveur n'applique alors aucune de ses pénalités à ces adresses, y compris celles pour les échecs d'authentification. Pour vérifier le fichier, exécutez sshd -T | grep -i persourcepenalt en tant que root. S'il affiche votre liste, rechargez le serveur SSH.

Vérifier si fail2ban comptabilise les tests de Desktop

Si fail2ban 0.10.5 ou ultérieur a banni une adresse depuis laquelle Desktop se connecte, trouvez le mode de votre jail dans jail.conf, jail.local ou sous jail.d/ :

• Une ligne filter qui nomme un mode entre crochets, comme filter = sshd[mode=aggressive] : utilisez ce mode.
• Uniquement la ligne filter d'origine, avec [mode=%(mode)s] : utilisez la ligne mode, ou normal s'il n'y en a pas.

Si le mode est normal, fail2ban ne comptabilise pas les lignes des tests de Desktop, recherchez donc une autre cause au bannissement.

Pour un autre mode, copiez les lignes de votre propre log dans un fichier sur la machine distante. Copiez chaque ligne en entier, de sa date jusqu'à sa fin, ainsi que les deux lignes lorsqu'un test en laisse deux. Exécutez-y fail2ban-regex avec le fichier et le mode de votre jail, par exemple aggressive :

fail2ban-regex -o ip lines.log "sshd[mode=aggressive]"

Pour chaque échec que fail2ban comptabilise, la commande affiche l'adresse sur une ligne distincte, comme 203.0.113.7. Dans ce cas, empêchez un bannissement. Si elle n'affiche rien, fail2ban ne comptabilise aucune de ces lignes dans ce mode, recherchez donc une autre cause au bannissement.

Empêcher un bannissement par fail2ban

Pour empêcher fail2ban de bannir une adresse à cause des tests de Desktop, modifiez l'un des deux paramètres de la jail, chacun ayant un coût :

• mode : définissez-le sur normal partout où votre jail le définit, dans une ligne mode ou entre les crochets d'une ligne comme filter = sshd[mode=aggressive]. Vous renoncez à tous les décomptes que seuls les autres modes effectuent, par exemple ceux des clients qui se connectent et repartent sans tenter de s'authentifier.
• ignoreip : définissez-le sur les adresses depuis lesquelles les personnes se connectent, par exemple ignoreip = 203.0.113.7. fail2ban ne comptabilise alors rien depuis ces adresses, y compris les échecs d'authentification.

Utiliser les serveurs MCP configurés sur la machine distante

Pour utiliser un serveur MCP de ~/.claude.json ou du .mcp.json d'un projet dans une session SSH, configurez-le dans ces fichiers sur la machine distante. Claude Code y démarre leurs serveurs stdio ; installez donc sur la machine distante les commandes que ces serveurs exécutent. Pour les serveurs de claude_desktop_config.json, voir Limites pendant que Desktop est déconnecté.

Ouvrir une session SSH à partir d'un lien

Un lien claude://code/new ouvre la page de nouvelle session de Desktop, et il peut désigner une connexion SSH. Placez un tel lien dans un runbook, un tableau de bord ou une page wiki pour ouvrir Desktop configuré pour la bonne machine et le bon dossier. Pour les plateformes qui suppriment ces liens, voir Le lien s'affiche en texte brut au lieu d'être cliquable.

Les liens SSH nécessitent Claude Desktop v2.110.0 ou une version ultérieure.

Le lien suivant désigne l'utilisateur dev sur build.example.com, le port 2222 et le dossier /srv/payments, et renseigne un prompt :

claude://code/new?ssh_host=dev%40build.example.com&ssh_port=2222&ssh_folder=/srv/payments&q=Investigate%20the%20failed%20deploy

Un lien SSH accepte ces paramètres, et seul ssh_host est obligatoire :

Un alias de ~/.ssh/config ne fonctionne comme ssh_host que pour les personnes qui possèdent cette entrée. Pour correspondre à une connexion que les personnes possèdent déjà, donnez au lien le même utilisateur, le même hôte et le même port que cette connexion.

Lorsque vous ouvrez le lien, Desktop vous demande de confirmer avant de sélectionner la connexion :

• Une connexion que vous possédez déjà : si l'hôte, l'utilisateur et le port correspondent à l'une de vos connexions, Desktop vous demande s'il faut l'utiliser, et vous affiche le nom et l'hôte de la connexion, ainsi que le dossier si le lien en désigne un.
• Une nouvelle connexion : sinon, Desktop ouvre la boîte de dialogue d'ajout d'une connexion SSH. Lorsque vous ajoutez la connexion, Desktop vous demande s'il faut se connecter avant d'enregistrer quoi que ce soit, et vous affiche l'hôte provenant du lien, ainsi que le port et le dossier si le lien les désigne.

Tant que vous n'avez pas confirmé, Desktop n'enregistre pas l'hôte, le port ou le dossier provenant du lien, et ne sélectionne ni n'ouvre de connexion avec eux. Si une connexion SSH est déjà sélectionnée, la page de nouvelle session peut toujours s'y connecter d'elle-même, comme elle le fait sans lien, même lorsque le lien désigne le même hôte. Un lien ne peut pas transporter de fichier de clé, de mot de passe ou de commande.

N'importe qui peut écrire un lien, alors vérifiez ce qu'il a renseigné :

• Avant de confirmer : vérifiez l'hôte et le dossier.
• Avant d'envoyer : vérifiez le prompt et l'environnement sélectionné.

Desktop renseigne le prompt à l'ouverture du lien, à la place de tout texte que vous n'avez pas envoyé, et ne l'envoie jamais à votre place. Il traite le prompt comme du texte brut, de sorte qu'un / ou un ! en début de texte et une mention de fichier @ n'agissent pas comme une commande ou une mention. Si vous annulez, le prompt reste dans la zone et l'environnement que vous aviez sélectionné ne change pas.

Un lien ne contourne pas sshHostAllowlist. Desktop vérifie la liste d'autorisation lors de la connexion.

Si le lien ouvre Desktop sans boîte de dialogue concernant la connexion, recherchez l'une de ces causes :

• Vous êtes déconnecté : connectez-vous, puis ouvrez à nouveau le lien.
• Une autre boîte de dialogue est ouverte : fermez-la, puis ouvrez à nouveau le lien.
• Le lien n'est pas valide : Desktop affiche un message indiquant ce qu'il faut corriger, et ne renseigne pas le prompt.
• Desktop est antérieur à v2.110.0 : les versions antérieures ignorent les paramètres SSH et ouvrent la page de nouvelle session avec uniquement le prompt.
• Les sessions SSH sont désactivées : si votre administrateur définit la liste d'autorisation sur un tableau vide, Desktop refuse les liens SSH.

Créer une connexion SSH à partir d'une commande

Si un outil en ligne de commande crée vos machines distantes à la demande, ajoutez sa commande à sshHostCommands dans ~/.claude/settings.json. Le sélecteur d'environnement affiche alors un élément nommé d'après votre entrée, tel que Create Dev box. Lorsque vous le sélectionnez, Desktop exécute la commande sur votre ordinateur, enregistre l'hôte que la commande affiche en tant que connexion SSH, puis se connecte.

[!NOTE]

Les connexions à partir d'une commande nécessitent Claude Desktop v3.6556.0 ou une version ultérieure sur macOS ou Linux, avec une connexion via un compte Claude. Les administrateurs peuvent distribuer des commandes à une équipe.

Chaque entrée correspond à une connexion, avec un seul hôte à la fois. Desktop n'exécute la commande que lorsque vous créez la connexion ou remplacez son hôte, et non à chaque connexion. Pour conserver deux machines à la fois, ajoutez une deuxième entrée.

[!WARNING]

Desktop n'arrête ni ne supprime les machines. Chacune des suivantes continue de fonctionner, et peut continuer à coûter de l'argent, jusqu'à ce que vous la supprimiez avec votre outil :

• Un hôte que vous avez remplacé
• L'hôte d'une entrée que vous avez retirée du fichier, ou dont vous avez modifié l'id
• Une machine que votre commande a créée sans que Desktop enregistre son hôte, par exemple dans ces cas :
  • La commande échoue ou dépasse le délai imparti
  • Desktop ne peut pas utiliser l'hôte affiché, une autre connexion l'utilise déjà, ou votre organisation ne l'autorise pas
  • Pendant l'exécution de la commande, vous l'annulez, retirez son entrée, modifiez son command ou son id, ou quittez Desktop

L'exemple suivant ajoute une connexion nommée Dev box. Si le fichier n'existe pas, créez-le. S'il contient déjà des paramètres, ajoutez la clé à côté d'eux. La commande acme-dev create représente votre propre outil, et ~/project est le dossier que Desktop sélectionne sur chaque machine créée par votre commande :

{
  "sshHostCommands": [
    {
      "id": "devbox",
      "name": "Dev box",
      "command": "acme-dev create",
      "startDirectory": "~/project"
    }
  ]
}

Chaque entrée accepte ces champs, et id, name et command sont obligatoires :

Pour modifier ou supprimer la connexion, modifiez son entrée dans le fichier, car la boîte de dialogue de connexion SSH de l'application ne s'ouvre pas pour elle. Vous n'avez pas besoin de redémarrer Desktop après avoir modifié le fichier. Si l'entrée n'apparaît pas ou si vous ne pouvez pas la sélectionner, consultez Si une commande est absente ou grisée.

Écrire la commande

Desktop démarre le programme directement, sans shell ni terminal :

• Programme : écrivez son nom, ou son chemin complet à partir de /, sans espaces. Desktop recherche un nom seul dans le PATH exporté par votre shell de connexion. Les chemins relatifs tels que ./acme-dev, les chemins qui commencent par ~, ainsi que les alias et fonctions du shell ne fonctionnent pas.
• Arguments : séparez les arguments simples par des espaces. La commande ne peut contenir que des espaces, des lettres ASCII, des chiffres et les caractères +,-./:=@_~, et aucun mot ne peut commencer par ~.
• Scripts : si la commande nécessite autre chose, comme des guillemets, des pipes, des variables ou une URL contenant ? ou &, placez-la dans un script. Rendez le script exécutable, commencez-le par une ligne #! et définissez command sur son chemin complet, tel que /Users/you/bin/make-devbox. Sur macOS, gardez le script hors des dossiers Documents, Bureau et Téléchargements, où macOS peut le bloquer.
• Entrée : le programme ne reçoit aucune entrée ni aucun terminal, il ne peut donc pas vous y poser de question. Si votre outil vous connecte via un navigateur ou une invite, connectez-vous d'abord depuis un terminal, puis à nouveau chaque fois que cette connexion expire.
• Environnement : le programme s'exécute dans votre répertoire personnel avec les variables exportées par votre shell de connexion. Desktop les lit au démarrage, comme il le fait pour un ProxyCommand, quittez et rouvrez donc Desktop après les avoir modifiées.
• Limite de temps : Desktop arrête un programme encore en cours d'exécution après 10 minutes. Le message de progression de Desktop n'affiche pas la sortie du programme. Pour arrêter le programme plus tôt, sélectionnez Cancel à côté de ce message.

Le programme doit se terminer avec le code 0 et n'afficher que l'hôte sur la sortie standard, sous l'une de ces deux formes :

• Une ligne : host ou user@host, écrit comme pour ssh_host dans un lien SSH. Pour indiquer un port, utilisez la forme JSON.
• Un objet JSON : sshHost, et éventuellement un sshPort numérique et un startDirectory qui remplace celui de l'entrée, tel que {"sshHost": "dev@devbox-1234.example.com", "sshPort": 2222}

Pour voir la sortie que Desktop lit, exécutez la commande dans un terminal sans entrée et avec la sortie standard redirigée vers un fichier :

acme-dev create < /dev/null > host.txt

Le fichier doit contenir uniquement l'hôte. Lorsque vous effectuez ce test, votre outil crée également une machine, supprimez-la donc ensuite avec votre outil.

Si votre outil affiche d'autres lignes avant l'hôte, comme des messages de progression, encapsulez-le dans un script qui n'affiche que l'hôte. Le script suivant affiche la dernière ligne de la sortie de votre outil. Si votre outil échoue, le script se termine avec le même code, afin que Desktop signale l'échec :

#!/bin/bash
out=$(mktemp) || exit
trap 'rm -f "$out"' EXIT
acme-dev create > "$out" || exit
tail -n 1 "$out"

Si la commande échoue, View details dans le message de Desktop affiche la dernière ligne que la commande a écrite sur la sortie d'erreur standard, le cas échéant.

Se connecter à un nouvel hôte

Répondez à deux questions la première fois que vous vous connectez à chaque nouvel hôte :

• Clé d'hôte : avec la vérification des clés d'hôte par défaut d'OpenSSH, vérifiez l'empreinte de la clé, puis choisissez de vous connecter ou non. Pour éviter la question, faites en sorte que votre commande ajoute la clé à ~/.ssh/known_hosts avant d'afficher l'hôte, en utilisant une clé que votre outil a obtenue lors de la création de la machine. Pour un port autre que 22, cette ligne commence par [host]:port. Si votre outil réutilise des noms d'hôte, supprimez également la ligne de l'ancienne clé.
• Dossier : choisissez si vous faites confiance au dossier que vous y ouvrez

Laissez la vérification des clés d'hôte activée pour ces hôtes et conservez un fichier known_hosts pour eux. Si StrictHostKeyChecking vaut no ou accept-new et que UserKnownHostsFile vaut aussi /dev/null ou none, rien n'enregistre la clé. Lorsque votre outil réutilise ensuite un nom, vous pouvez vous connecter à une autre machine sans avertissement.

Remplacer l'hôte

Une fois que Dev box a un hôte, le sélecteur affiche Dev box parmi vos connexions SSH, et Create Dev box devient Replace Dev box's host. Si cet élément ne figure pas dans la liste, regardez sous More.

Sélectionnez-le lorsque la machine a disparu ou que vous en voulez une nouvelle. Sur la page de nouvelle session, le message indiquant que Desktop ne peut pas joindre l'hôte le propose également. Desktop exécute à nouveau la commande, et les nouvelles sessions utilisent le nouvel hôte.

• Un nouvel hôte : l'élément est grisé pendant 10 minutes après l'enregistrement d'un hôte par Desktop, car une nouvelle machine peut mettre un certain temps à démarrer. Tant qu'un nouvel hôte ne répond pas, la page de nouvelle session continue d'essayer de se connecter pendant ces 10 minutes.
• Sessions sur l'ancien hôte : elles y restent, et Desktop ne se connecte pas à cet hôte à moins que vous ne le rajoutiez. Pour poursuivre l'une d'elles, ouvrez la session et sélectionnez Add SSH connection. Desktop remplit l'ancien hôte. Enregistrez-le comme une connexion à part entière.

Distribuer des commandes à votre équipe

Pour fournir une connexion à votre équipe, définissez sshHostCommands dans le fichier de paramètres gérés de Claude Code ou dans la stratégie MDM de chaque ordinateur, et non dans la propre stratégie de gestion des appareils de l'application de bureau. Les utilisateurs voient vos entrées à côté des leurs, et l'application n'offre aucun moyen de modifier ou de supprimer une entrée, qu'elle soit la leur ou la vôtre.

Le fichier de paramètres gérés suivant fournit aux utilisateurs une connexion nommée Dev box et désactive leurs propres entrées, ainsi que les hooks Claude Code des paramètres utilisateur, projet et locaux :

{
  "sshHostCommands": [
    {
      "id": "acme-devbox",
      "name": "Dev box",
      "command": "/usr/local/bin/acme-dev create"
    }
  ],
  "strictPluginOnlyCustomization": ["hooks"]
}

Avant de déployer la clé, réglez chacun de ces points :

• Où placer la clé : si votre stratégie MDM pour Claude Code définit déjà une clé de stratégie, placez-la là. Sinon, placez-la dans le fichier de paramètres gérés. Par défaut, une telle stratégie l'emporte sur le fichier, et Desktop ignore alors les entrées du fichier. Définissez-la sur l'ordinateur même là où des paramètres gérés par le serveur s'appliquent : Desktop y ignore la clé, ainsi que dans les paramètres de projet et locaux.
• L'id : si l'entrée sshHostCommands d'un utilisateur a votre id, seule la vôtre fonctionne. Si une autre connexion SSH l'a, comme une connexion dans les sshConfigs d'un utilisateur, votre entrée est grisée. Choisissez un id que les utilisateurs sont peu susceptibles de choisir.
• Le programme : indiquez son chemin complet, car Desktop recherche un nom seul dans le PATH propre à chaque utilisateur. Le programme s'exécute en tant qu'utilisateur, avec les variables exportées par son shell de connexion.
• Les entrées des utilisateurs : Desktop traite l'entrée d'un utilisateur comme un hook, car tous deux exécutent un programme sur l'ordinateur. Pour n'autoriser que vos entrées, définissez strictPluginOnlyCustomization sur ["hooks"], ou ajoutez "hooks" à sa liste. Vous bloquez également les hooks Claude Code des paramètres utilisateur, projet et locaux, sans possibilité de les conserver. Si vous définissez plutôt cette clé ou allowManagedHooksOnly sur true, vous bloquez davantage, comme l'indique l'entrée de chaque clé.
• Toutes les entrées : pour désactiver également vos entrées, définissez disableAllHooks dans les paramètres gérés. Si vous définissez disableDesktopLocalSessions, ou un sshHostAllowlist qui n'autorise aucun hôte, le sélecteur n'affiche aucun élément Create ni Replace.
• Où les verrous comptent : pour ces entrées, Desktop lit allowManagedHooksOnly, strictPluginOnlyCustomization et disableAllHooks dans les paramètres gérés par le serveur ainsi que dans le fichier ou la stratégie propre à l'ordinateur, et applique le résultat le plus strict. Toutes les entrées restent grisées jusqu'à ce que Desktop ait vérifié claude.ai pour les paramètres gérés par le serveur, même si votre organisation n'en a aucun.
• Hôtes autorisés : si vous définissez sshHostAllowlist, assurez-vous qu'un motif correspond à chaque nom d'hôte affiché par votre outil, et omettez user@ du motif. Desktop ne vérifie le nom affiché qu'après l'exécution de la commande : une machine refusée par la liste existe donc déjà, et l'utilisateur doit la supprimer avec votre outil. À chaque connexion, le HostName résolu doit également correspondre.

Après avoir déployé la clé, redémarrez Desktop sur un ordinateur de test. Dans le sélecteur d'environnement de l'onglet Code, regardez sous SSH, ou dans la ligne unique SSH. Votre entrée apparaît sous forme d'élément Create, ou d'élément grisé qui indique la raison lorsque vous le survolez. S'il est absent, vérifiez où vous avez placé la clé, puis les cas décrits dans Si une commande est absente ou grisée.

Si une commande est absente ou grisée

Le sélecteur d'environnement n'affiche aucun élément Create ni Replace dans ces cas :

• Le fichier : ~/.claude/settings.json contient du JSON non valide ou une valeur rejetée par le schéma, vous avez mal orthographié la clé, ou vous l'avez placée dans les paramètres d'un projet. Corrigez le fichier.
• Plateforme et compte : vous utilisez Windows, ou un fournisseur tiers au lieu d'un compte Claude. Ajoutez vous-même chaque hôte en tant que connexion SSH.
• Les paramètres de votre organisation : votre administrateur a désactivé les sessions locales ou les sessions SSH. Demandez-lui si vous pouvez utiliser des commandes.
• Pas de programme ssh : Desktop n'a pas pu démarrer le client OpenSSH sur votre ordinateur. Installez-le, ou demandez à votre administrateur de l'autoriser, puis redémarrez Desktop.

Une entrée que vous ne pouvez pas sélectionner est grisée. Survolez-la pour en voir la raison :

• Une erreur dans l'entrée : corrigez le champ ou la commande que le message désigne. Si l'id est déjà utilisé, attribuez-en un autre à l'entrée.
• Un fichier de paramètres défectueux : tant que votre propre fichier de paramètres est défectueux, les entrées de votre administrateur peuvent être grisées, avec un message qui désigne le fichier. Corrigez le fichier.
• Un nouvel hôte : vous pouvez remplacer un hôte une fois qu'il a 10 minutes.
• Les hooks sont désactivés ou restreints : vos propres entrées ne fonctionnent que là où vos propres hooks peuvent s'exécuter. Retirez disableAllHooks de vos paramètres, ou adressez-vous à votre administrateur.
• Les paramètres sont encore en cours de chargement : toutes les entrées sont grisées jusqu'à ce que Desktop ait chargé les paramètres gérés par le serveur de votre organisation, généralement quelques secondes après le lancement. Si les entrées restent grisées, vérifiez votre connexion à claude.ai.

Pré-configurer les connexions SSH pour votre équipe

Les administrateurs peuvent distribuer des connexions SSH aux membres de l'équipe en définissant sshConfigs dans les paramètres gérés.

• Ce que voient les utilisateurs : les connexions définies de cette manière apparaissent automatiquement dans le sélecteur d'environnement de chaque utilisateur.
• Ce que les utilisateurs peuvent modifier : les utilisateurs peuvent sélectionner une connexion gérée et définir leur propre Worktree folder pour celle-ci. Ils ne peuvent ni modifier ses autres champs ni la supprimer dans l'application.

L'exemple suivant pré-configure une seule connexion :

{
  "sshConfigs": [
    {
      "id": "shared-dev-vm",
      "name": "Shared Dev VM",
      "sshHost": "user@dev.example.com",
      "sshPort": 22,
      "sshIdentityFile": "~/.ssh/id_ed25519"
    }
  ]
}

Chaque entrée nécessite id, name et sshHost. Les champs sshPort et sshIdentityFile sont optionnels. Les utilisateurs peuvent également ajouter sshConfigs à leur propre ~/.claude/settings.json.

Si vous omettez user@ dans sshHost, Desktop se connecte en tant que User que le fichier ~/.ssh/config de chaque développeur définit pour l'hôte, ou à défaut en tant que son nom d'utilisateur sur son propre ordinateur.

Restreindre les hôtes SSH auxquels les utilisateurs peuvent se connecter

Les administrateurs peuvent limiter les sessions SSH de Desktop à un ensemble approuvé d'hôtes en définissant sshHostAllowlist dans les paramètres gérés. Lorsqu'il est défini, les utilisateurs ne peuvent se connecter qu'à des hôtes dont le nom d'hôte résolu correspond à l'un des modèles. Définissez-le sur un tableau vide pour désactiver les sessions SSH. L'entrée de référence sshHostAllowlist indique comment un tableau vide se combine avec les listes d'autres sources gérées.

L'exemple suivant autorise les connexions à n'importe quel hôte sous devboxes.example.com et à un seul hôte bastion nommé :

{
  "sshHostAllowlist": ["*.devboxes.example.com", "bastion.example.com"]
}

[!WARNING]

Si votre organisation fournit des paramètres gérés par le serveur, définissez sshHostAllowlist à cet endroit. Par défaut, Desktop lit la clé uniquement à partir de la source gérée la mieux classée qui fournit une clé de politique. Si cette source laisse la clé non définie, Desktop ignore une liste figurant dans une politique MDM ou un fichier de paramètres gérés moins bien classé et traite la clé comme non définie. Desktop n'affiche aucun avertissement.

Conservez également la même liste sur la machine de chaque utilisateur, dans la politique MDM ou le fichier de paramètres gérés le mieux classé sur celle-ci. Desktop récupère les paramètres gérés par le serveur au lancement et n'en conserve aucune copie en cache ; ainsi, tant qu'une récupération n'a pas réussi, c'est la liste de la machine qui s'applique.

Les motifs ne sont pas sensibles à la casse. * correspond à n'importe quel hôte, et *.example.com correspond à example.com et à n'importe quel sous-domaine. Tout le reste est une correspondance exacte. La vérification porte sur le nom d'hôte après résolution de ~/.ssh/config via ssh -G : un alias Host est donc autorisé tant que son HostName résolu correspond. Les hôtes de rebond d'une session doivent également correspondre.

sshHostAllowlist est lu uniquement à partir des paramètres gérés ; les valeurs dans les paramètres utilisateur ou projet sont ignorées. Seule l'application Claude Desktop honore ce paramètre ; la CLI Claude Code et les extensions IDE ne le lisent pas, et il ne restreint pas les commandes ssh exécutées via l'outil Bash. Il gouverne les hôtes auxquels l'application Desktop se connecte, pas la sortie réseau, donc associez-le aux contrôles réseau ou zero-trust de votre organisation si vous avez besoin d'une limite stricte.

Autoriser les hôtes de rebond

Ajoutez chaque hôte de rebond que Desktop vérifie à sshHostAllowlist, par son propre HostName résolu. Ajoutez les hôtes de rebond avant que les utilisateurs ne passent à Claude Desktop v3.1623.0 ou une version ultérieure, sinon ils ne pourront pas se connecter par leur intermédiaire.

[!WARNING]

La liste ne comporte qu'un seul type d'entrée : les utilisateurs peuvent donc également démarrer une session sur n'importe quel hôte que vous y inscrivez. N'inscrivez que des hôtes de rebond sur lesquels vous autoriseriez aussi les utilisateurs à exécuter des sessions.

Desktop vérifie les hôtes de rebond figurant dans le ProxyJump que le ~/.ssh/config de l'utilisateur définit pour l'hôte de la session, ou dans un ProxyCommand écrit sous la forme ssh -W %h:%p <host>. Si l'un des hôtes vérifiés ne figure pas dans la liste lorsque Desktop connecte ou reconnecte une session, la connexion échoue. Lorsqu'un utilisateur démarre une session ou envoie un message, les détails de l'erreur indiquent le HostName de cet hôte de rebond, qui est le nom à ajouter :

SSH host "bastion.example.com" is not allowed by your organization's managed settings. It is a jump host on the way to "devbox".

Si le message indique managed settings on this computer, ajoutez le nom à la liste sur l'ordinateur de l'utilisateur. S'il manque plusieurs hôtes de rebond, l'erreur les nomme un par un. Pour trouver tous les noms avant que les utilisateurs ne fassent la mise à jour, utilisez un terminal sur l'ordinateur d'un utilisateur :

1. Trouver la route

Exécutez ssh -G avec un hôte auquel les utilisateurs se connectent, par exemple ssh -G devbox. Recherchez une ligne proxyjump, ou une ligne proxycommand écrite sous la forme ssh -W %h:%p <host>. La commande compte toujours avec l'une des options -l, -p, -J, -q, -v, -N, -T, -x ou -a, et les hôtes qui suivent -J sont également des hôtes de rebond. Si une ligne proxycommand exécute un programme autre que ssh, n'ajoutez rien pour celle-ci.

2. Rechercher chaque hôte de rebond

Exécutez ssh -G avec chaque hôte de rebond de cette ligne, sans :port, et notez le hostname qu'il affiche. Si la sortie du premier hôte de rebond de cette ligne contient une ligne de l'un ou l'autre type, répétez cette étape avec celle-ci. Ignorez une telle ligne dans la sortie d'un hôte de rebond ultérieur.

3. Ajouter les noms

Ajoutez chaque nom d'hôte, ou un caractère générique qui le couvre, à sshHostAllowlist dans chaque source gérée où vous définissez une liste. Demandez ensuite aux utilisateurs de quitter et de rouvrir Desktop, car il récupère les paramètres gérés par le serveur au lancement.

Désactiver les sessions locales et distribuer des connexions SSH

Pour désactiver les sessions locales et limiter les sessions SSH aux hôtes de votre choix, déployez ensemble disableDesktopLocalSessions, sshConfigs et sshHostAllowlist.

[!NOTE]

Cette configuration s'adresse aux utilisateurs qui se connectent avec un compte Claude. Avec un fournisseur tiers, les sessions SSH sont désactivées par défaut, et définir sshHostAllowlist peut les activer. Lisez SSH remote sessions in Claude Desktop on 3P avant de déployer ces clés.

L'exemple suivant désactive les sessions locales, ajoute une connexion et limite les sessions SSH à l'hôte de cette connexion :

{
  "disableDesktopLocalSessions": true,
  "sshConfigs": [
    {
      "id": "shared-dev-vm",
      "name": "Shared Dev VM",
      "sshHost": "dev.example.com"
    }
  ],
  "sshHostAllowlist": ["dev.example.com"]
}

Les clés s'appliquent à l'application de bureau. Elles ne modifient pas les autres façons d'exécuter Claude Code, comme la CLI, Cowork et les sessions cloud :

• La CLI : aucune des clés n'empêche un développeur d'exécuter la CLI Claude Code sur son propre ordinateur
• Cowork : aucune des clés ne s'applique aux sessions Cowork ni aux tâches planifiées Cowork
• Sessions cloud : aucune des clés ne modifie la disponibilité des sessions cloud. Pour les désactiver, utilisez le paramètre Sessions cloud sous Contrôles de la console d'administration.

Lorsque vous adaptez l'exemple, vérifiez les noms d'hôte, la version de Desktop et les permissions du fichier :

• Noms d'hôte : assurez-vous qu'un motif de sshHostAllowlist correspond au nom d'hôte de chaque entrée sshConfigs, sans user@, sinon les développeurs ne pourront pas s'y connecter. Ajoutez également un motif correspondant à chaque hôte de rebond que Desktop vérifie sur le chemin. Pour savoir comment Desktop fait correspondre un nom d'hôte, consultez Restreindre les hôtes SSH auxquels les utilisateurs peuvent se connecter.
• Version : disableDesktopLocalSessions nécessite Claude Desktop v1.37937.0 ou une version ultérieure
• Permissions du fichier : assurez-vous que le compte de chaque développeur sur l'ordinateur peut lire le fichier de paramètres gérés. Desktop n'applique pas les clés d'un fichier que le compte ne peut pas lire, et Claude Code démarre également sans elles.

Placez les trois clés dans une seule source gérée, la mieux classée de celles que vous fournissez. Si vous fournissez des paramètres gérés par le serveur, conservez également une copie des trois clés dans la politique MDM ou le fichier de paramètres gérés le mieux classé sur chaque ordinateur. Desktop récupère les paramètres gérés par le serveur au lancement, et la copie présente sur l'ordinateur s'applique tant qu'une récupération n'a pas réussi.

Pour confirmer que les paramètres s'appliquent, vérifiez l'ordinateur d'un développeur :

1. Vérifier le sélecteur d'environnement

Quittez et rouvrez Desktop, puis ouvrez le sélecteur d'environnement. Les paramètres sont appliqués s'il affiche :

• L'entrée correspondant à cet ordinateur, en grisé
• Shared Dev VM sous SSH. Si elle n'y figure pas, cliquez sur l'unique ligne SSH, ou sur More à la fin du groupe.

Si l'entrée correspondant à l'ordinateur est toujours disponible, recherchez ces causes :

• Version de Desktop : mettez à jour Desktop s'il est antérieur à la v1.37937.0.
• Fichier de paramètres gérés : assurez-vous que le fichier est un JSON valide.
• Source gérée : assurez-vous que l'ordinateur lit la source gérée qui contient les clés.

2. Ajouter un hôte absent de la liste d'autorisation

Ajoutez une connexion SSH avec un nom d'hôte qui ne figure pas dans la liste d'autorisation, comme other.example.com. Desktop enregistre la connexion mais refuse de s'y connecter, et indique que les paramètres de votre organisation n'autorisent pas la connexion.

Configuration d'entreprise

Les organisations sur les plans Team ou Enterprise peuvent gérer le comportement de l'application de bureau via les contrôles de la console d'administration, les fichiers de paramètres gérés et les politiques de gestion des appareils.

Contrôles de la console d'administration

Ces paramètres sont configurés via la console de paramètres d'administration :

• Desktop : contrôlez si les utilisateurs de votre organisation peuvent accéder à Claude Code dans l'application de bureau
• Sessions cloud : activez ou désactivez les sessions cloud pour votre organisation
• Remote Control : activez ou désactivez Remote Control pour votre organisation

Dans les organisations Enterprise pour lesquelles HIPAA est activé, le bouton Desktop est désactivé par défaut et un Owner peut l'activer. L'application de la configuration HIPAA le désactive, même s'il était activé, de sorte qu'un Owner doit le réactiver ensuite. Sessions cloud et Remote Control sont également désactivés par défaut, et un Owner ne peut pas les activer une fois que la configuration HIPAA est appliquée à l'organisation.

[!NOTE]

Le formulaire OpenTelemetry pour Cowork sous Monitoring dans les paramètres de données et de confidentialité de la console d'administration s'applique uniquement aux sessions Cowork. Dans une session Cowork sur cette machine, l'application de bureau transmet ce collecteur à Claude Code en tant que variables d'environnement OTEL_*, de sorte que le formulaire prend effet même si Claude Code dans cette session ne récupère jamais les paramètres de la console d'administration.

Pour exporter la télémétrie à partir des sessions de l'onglet Code, définissez CLAUDE_CODE_ENABLE_TELEMETRY et les variables OTEL_* dans le bloc env de vos paramètres gérés Claude Code, comme indiqué dans configuration de l'administrateur pour la surveillance. Les sessions locales, cloud et SSH lisent chacune les paramètres gérés à partir de sources différentes. Pour les hôtes qu'une session cloud peut atteindre, voir accès réseau. Pour le service.name que les sessions de l'onglet Code signalent, voir informations de service.

Pour savoir sur quelle machine distante une session SSH s'est exécutée, voir Attribuer la télémétrie aux sessions SSH de Desktop.

Paramètres gérés

Les paramètres gérés remplacent les paramètres du projet et de l'utilisateur et s'appliquent aux sessions Claude Code dans Desktop. Vous pouvez définir ces clés dans le fichier paramètres gérés de votre organisation ou les pousser à distance via la console d'administration, sauf indication contraire dans la ligne d'une clé.

Les paramètres gérés qui atteignent une session Desktop dépendent de l'endroit où cette session s'exécute. Les restrictions de modèle telles que availableModels sont appliquées dans les sessions Claude Code de Desktop de la même manière que dans le CLI du terminal ; voir couverture de surface.

• Sessions locales sur cette machine : un fichier de paramètres gérés déployé sur le disque s'applique. Les paramètres gérés poussés à distance via la console d'administration atteignent également ces sessions sur l'API d'Anthropic lorsque la session s'authentifie avec une connexion éligible, en suivant la même priorité des paramètres que le CLI du terminal.
• Sessions cloud : reçoivent les paramètres gérés par le serveur ; les fichiers déployés sur l'appareil ne les atteignent pas, car ils s'exécutent sur des machines virtuelles gérées par Anthropic. Les sessions acheminées vers un environnement auto-hébergé lisent également le fichier de paramètres gérés dans l'image du runner. Comment Claude Code combine les sources gérées indique quand ce fichier s'applique.
• Sessions SSH : la session lit le fichier de paramètres gérés à partir de l'hôte distant. Desktop lui-même lit sshConfigs, sshHostAllowlist, disableSshSavedPasswords et disableDesktopLocalSessions sur la machine locale. Si vous fournissez plus d'une source gérée, il les lit à partir d'une seule par défaut.
• Sessions Cowork : dans une session Cowork sur cette machine, Claude Code ne récupère jamais les paramètres de la console d'administration, même lorsque l'utilisateur se connecte avec un compte Team ou Enterprise, et lit la politique déployée sur la machine sauf si votre configuration Claude Desktop définit requireCoworkFullVmSandbox. Les sessions Cowork distantes ne reçoivent ni l'une ni l'autre. Voir où et quand une politique s'applique pour savoir quels fichiers d'appareil atteignent Cowork, et règles de permission MCP pour savoir comment les règles Bash et WebFetch s'appliquent aux outils de Cowork.

Dans les sessions locales et SSH, l'application de bureau fournit les connecteurs claude.ai connectés de chaque utilisateur à Claude Code directement. Aucun paramètre MCP ou managed-mcp.json n'atteint ces connecteurs, quelle que soit la source de paramètres ou l'emplacement du fichier que vous utilisez. Pour bloquer les outils d'un connecteur dans ces sessions, utilisez les contrôles des outils de connecteur de votre organisation. Comment les connecteurs atteignent Claude Code montre quels paramètres gouvernent les connecteurs dans chaque type de session.

permissions.disableBypassPermissionsMode et disableAutoMode fonctionnent également dans les paramètres utilisateur et projet, mais les placer dans les paramètres gérés empêche les utilisateurs de les remplacer.

Pour les clés de permission, de plugin et de livraison que seule une source gérée peut définir, voir Clés que seuls les paramètres gérés peuvent définir.

Politiques de gestion des appareils

Les équipes informatiques peuvent gérer l'application de bureau via MDM sur macOS, la politique de groupe sur Windows ou un fichier de politique sur Linux. Les politiques disponibles incluent l'activation ou la désactivation de la fonctionnalité Claude Code, le contrôle des mises à jour automatiques sur macOS et Windows, et la définition d'une URL de déploiement personnalisée.

• macOS : configurez via le domaine de préférence com.anthropic.claudefordesktop en utilisant des outils comme Jamf ou Kandji
• Windows : configurez via le registre à SOFTWARE\Policies\Claude
• Linux : configurez via un fichier appartenant à root à l'emplacement /etc/claude-desktop/managed-settings.json, qui contient les clés de politique sous forme d'objet JSON. Desktop refuse le fichier si quelqu'un d'autre que root peut écrire dans celui-ci ou dans son dossier. Il s'agit d'un fichier différent du fichier de paramètres gérés de Claude Code.

Exigences d'accès réseau

Desktop charge son code d'application et le contenu utilisateur à partir des hôtes CDN d'Anthropic.

anthropic.com
*.anthropic.com
claude.ai
*.claude.ai
claude.com
*.claude.com
claude.app
*.claude.app
*.claudeusercontent.com
*.claudemcpcontent.com

Le trafic est HTTPS sur le port 443 sauf si vous configurez un port personnalisé pour OTLP, une passerelle LLM ou un serveur MCP.

Pour les serveurs proxy, les autorités de certificats personnalisées, mTLS et les domaines dont le CLI autonome a besoin, voir configuration réseau.

Pour réduire le nombre de caractères génériques du pare-feu, autorisez plutôt ces hôtes Anthropic. Certains sous-domaines sont générés dynamiquement et doivent rester des caractères génériques.

anthropic.com
api.anthropic.com
a-api.anthropic.com
a-cdn.anthropic.com
s-cdn.anthropic.com
assets-proxy.anthropic.com
claude.ai
a.claude.ai
assets.claude.ai
downloads.claude.ai
*.livepreview.claude.ai
claude.com
platform.claude.com
sso.claude.com
*.livepreview.claude.app
*.claudeusercontent.com
*.claudemcpcontent.com

Si votre organisation a activé la liste d'autorisation IP pour Claude, acheminez bridge.claudeusercontent.com via le même proxy de sortie que claude.ai et api.anthropic.com. Si vous ne pouvez pas l'acheminer de cette façon, ajoutez l'adresse de sortie que votre proxy utilise pour cet hôte à la liste d'autorisation IP de votre organisation, mais uniquement lorsque cette adresse est dédiée à votre organisation : une plage de sortie de proxy partagée admet également les autres clients du fournisseur de proxy.

Anthropic vérifie les connexions à cet hôte par rapport à la liste d'autorisation IP de votre organisation en utilisant l'adresse à partir de laquelle elles arrivent. Si votre proxy envoie le trafic pour cela via une adresse qui ne figure pas sur cette liste d'autorisation, Claude dans Chrome et d'autres fonctionnalités qui se connectent via le pont cessent de fonctionner tandis que le reste de l'application continue de fonctionner.

Un artefact qui charge une police de caractères à partir de Google Fonts demande également fonts.googleapis.com et fonts.gstatic.com. Les deux hôtes sont optionnels. Si vous les bloquez, les artefacts s'affichent dans les polices de secours. Bloquez avec un rejet rapide plutôt qu'une suppression silencieuse pour que la requête de police échoue immédiatement au lieu de retarder le premier rendu de la page.

Les artefacts peuvent également charger des bibliothèques JavaScript, telles que React ou un package de graphiques, à partir de cdnjs.cloudflare.com, cdn.jsdelivr.net, cdn.tailwindcss.com, code.jquery.com et unpkg.com, et d'aucun autre hôte externe. Si vous bloquez ces hôtes, les parties d'un artefact qui dépendent d'une bibliothèque ne fonctionnent pas, et contrairement à une police bloquée, une bibliothèque bloquée n'a pas de solution de repli. Bloquez avec un rejet rapide ici aussi, pour qu'une requête de bibliothèque bloquée échoue immédiatement plutôt que de rester suspendue jusqu'à l'expiration du délai.

Authentification et SSO

Les organisations Team et Enterprise peuvent exiger SSO pour tous les utilisateurs. Voir authentification pour les détails au niveau du plan et Configuration de SSO pour la configuration SAML ; la configuration OIDC est couverte dans le Guide de l'administrateur Claude Enterprise.

Gestion des données

Claude Code traite votre code localement dans les sessions locales, ou dans les sessions cloud sur l'infrastructure gérée par Anthropic, sauf si votre organisation les achemine vers un environnement auto-hébergé. Les sessions cloud, y compris dans un environnement auto-hébergé, envoient les conversations et le contexte du code à l'API d'Anthropic pour le traitement ; les sessions locales et SSH les envoient au fournisseur de modèle que votre déploiement configure, l'API d'Anthropic par défaut. Voir gestion des données pour les détails sur la rétention des données, la confidentialité et la conformité.

Déploiement

Desktop peut être distribué via les outils de déploiement d'entreprise :

• macOS : distribuez via MDM comme Jamf ou Kandji en utilisant l'installateur .dmg
• Windows : déployez via le package MSIX. Voir Déployer Claude Desktop pour Windows pour les options de déploiement d'entreprise, y compris l'installation silencieuse

Pour les domaines à ajouter à la liste d'autorisation de votre pare-feu, voir exigences d'accès réseau ci-dessus. Pour les paramètres de proxy, les autorités de certificats personnalisées et les passerelles LLM, voir configuration réseau.

Pour la référence complète de la configuration d'entreprise, voir le guide de configuration d'entreprise.

Venant de la CLI ?

Si vous utilisez déjà la CLI Claude Code, Desktop exécute le même moteur sous-jacent avec une interface graphique. Vous pouvez exécuter les deux simultanément sur la même machine, même sur le même projet. Chacun conserve sa propre liste de sessions, et vous pouvez amener une session CLI dans Desktop. Ils partagent la configuration et la mémoire du projet via les fichiers CLAUDE.md.

Pour déplacer une session CLI dans Desktop, exécutez /desktop dans le terminal. Claude enregistre votre session et l'ouvre dans l'application de bureau, puis quitte la CLI. Cette commande est disponible sur macOS et Windows x64 quand vous êtes connecté avec un abonnement Claude. Elle n'est pas disponible avec l'authentification par clé API ou sur Amazon Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry.

Depuis votre shell, claude --desktop ouvre Desktop directement sans démarrer une session terminal. Cela nécessite Claude Code v2.1.285 ou ultérieur et a les mêmes exigences de plateforme et de connexion que /desktop. Sans autres arguments, il ouvre Desktop dans le répertoire courant. Pour ouvrir une session CLI existante dans Desktop, ajoutez --continue pour la conversation la plus récente dans ce répertoire, ou --resume avec l'ID de session que /status affiche :

claude --desktop --resume <session-id>

Claude Code affiche Opening session <session-id> in Claude Desktop, la session s'ouvre dans l'application, et la commande se termine. Un nom de session ne fonctionne pas à la place de l'ID. Claude Code ne déplace pas une session qui est ouverte dans un autre terminal ou qui s'exécute toujours en arrière-plan. Si Claude Desktop n'est pas installé, la commande affiche un lien de téléchargement et se termine.

Vous pouvez également reprendre une session CLI depuis Desktop avec /resume. La commande est disponible dans les sessions locales, pas dans les sessions SSH, WSL ou cloud.

Pour continuer une session terminal dans Desktop :

1. Fermez la session dans le terminal.
2. Dans la zone de saisie de Desktop, tapez /resume. Desktop affiche les sessions que vous avez démarrées à partir de la CLI sur cet ordinateur. Recherchez par titre, dossier ou branche, et prévisualisez où chacune s'est arrêtée.
3. Sélectionnez la session. Elle continue dans l'application avec sa conversation complète et son contexte.

Desktop continue la même session plutôt qu'une copie, donc claude --resume dans le terminal la trouve toujours après.

[!TIP]

Quand utiliser Desktop vs CLI : utilisez Desktop quand vous voulez gérer les sessions parallèles dans une fenêtre, arranger les volets côte à côte ou examiner les modifications visuellement. Utilisez la CLI quand vous avez besoin de scripts, d'automatisation ou préférez un workflow terminal.

Équivalents des flags CLI

Ce tableau montre l'équivalent de l'application de bureau pour les flags CLI courants. Les flags non listés n'ont pas d'équivalent de bureau car ils sont conçus pour les scripts ou l'automatisation.

Configuration partagée

Desktop et CLI lisent les mêmes fichiers de configuration, donc votre configuration se transfère :

• Les fichiers CLAUDE.md et CLAUDE.local.md dans votre projet sont utilisés par les deux
• Les serveurs MCP configurés dans ~/.claude.json ou .mcp.json fonctionnent dans les deux
• Les hooks et skills définis dans les paramètres s'appliquent aux deux
• Les paramètres dans ~/.claude.json et ~/.claude/settings.json sont partagés. Les règles de permission, les outils autorisés et d'autres paramètres dans settings.json s'appliquent aux sessions Desktop.
• Modèles : les mêmes modèles sont disponibles dans les deux. Dans Desktop, sélectionnez le modèle à partir du sélecteur de modèle dans la ligne sous la zone de saisie. Vous pouvez modifier le modèle pendant la session à partir du même sélecteur.

Serveurs MCP de l'application de chat Claude Desktop

L'application Desktop charge les serveurs MCP de claude_desktop_config.json dans les sessions de l'onglet Code local, aux côtés des serveurs de ~/.claude.json et .mcp.json. Un serveur défini dans claude_desktop_config.json est disponible à la fois dans la surface de chat Desktop et dans les sessions de l'onglet Code local.

Si vous définissez le même nom de serveur dans claude_desktop_config.json et dans ~/.claude.json ou .mcp.json, l'onglet Code dans les sessions locales se connecte une fois et utilise la définition claude_desktop_config.json.

L'application réachemine également les serveurs stdio de ~/.claude.json vers la CLI intégrée dans les sessions locales. Quand le niveau supérieur de ~/.claude.json (portée utilisateur) et .mcp.json définissent le même nom de serveur stdio, l'onglet Code utilise la définition ~/.claude.json, s'écartant de la hiérarchie de portée CLI.

[!NOTE]

La CLI autonome ne lit pas claude_desktop_config.json. Sur macOS et WSL, exécutez claude mcp add-from-claude-desktop pour copier ces serveurs dans ~/.claude.json. Voir Importer les serveurs MCP de Claude Desktop pour le flux d'importation et les options de portée.

Comparaison des fonctionnalités

Ce tableau compare les capacités principales entre la CLI et Desktop. Pour une liste complète des flags CLI, voir la référence CLI.

Ce qui n'est pas disponible dans Desktop

Les fonctionnalités suivantes ne sont pas disponibles dans Desktop, sauf indication contraire :

• Fournisseurs tiers : Desktop se connecte à l'API d'Anthropic par défaut. Pour router Desktop via une passerelle, ou pour exécuter l'onglet Code sur Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry ou une passerelle LLM auto-hébergée, suivez les liens dans la ligne Fournisseurs tiers.
• Linux (bêta) : l'utilisation informatique n'est pas encore disponible dans l'application de bureau Linux. Voir Claude Desktop sur Linux.
• Suggestions de code en ligne : Desktop ne fournit pas de suggestions de style autocomplétion. Il fonctionne via des prompts conversationnels et des modifications de code explicites, et peut suggérer votre prochain prompt après la réponse de Claude.
• Équipes d'agents : les équipes coordonnées, où Claude en tant que chef d'équipe assigne des tâches aux coéquipiers à partir d'une liste de tâches partagée, sont disponibles dans la CLI, pas dans Desktop. Pour le travail multi-agents dans une seule session, utilisez les workflows dynamiques, qui s'exécutent dans Desktop ; Claude peut également envoyer des messages et gérer vos autres sessions directement.
• Commandes de dialogue terminal : les commandes intégrées qui ouvrent un panneau interactif dans le terminal se comportent différemment dans l'onglet Code. Modifiez les fichiers de paramètres directement pour gérer les règles de permission et la configuration, ou exécutez les commandes à partir de la CLI autonome.
  • Les commandes sans forme d'argument, telles que /permissions, répondent avec isn't available in this environment.
  • /config ouvre Paramètres > Claude Code.

Dépannage

Les sections ci-dessous couvrent les problèmes spécifiques à l'application de bureau. Pour les erreurs API d'exécution qui apparaissent dans le chat comme API Error: 500, 529 Overloaded, 429 ou Prompt is too long, voir la référence des erreurs.

Vérifier votre version

Pour voir quelle version de l'application de bureau vous exécutez :

• macOS : cliquez sur Claude dans la barre de menu, puis À propos de Claude
• Windows : cliquez sur Aide, puis À propos de Claude

Cliquez sur le numéro de version pour le copier dans votre presse-papiers.

Version de Claude Code dans l'onglet Code

Pour voir quelle version de Claude Code une session exécute, tapez /status dans une session locale de l'onglet Code et lisez la ligne Claude Code, qui affiche une version telle que 2.1.286.

Pour obtenir une version plus récente pour les sessions locales, ouvrez Claude > Rechercher les mises à jour… sur macOS ou Aide > Rechercher les mises à jour… sur Windows, puis démarrez une nouvelle session.

Dans une session locale, l'onglet Code exécute sa propre copie de Claude Code, qui possède son propre numéro de version. L'application de bureau télécharge et met à jour cette copie ; elle peut donc différer de la commande claude de votre terminal, et la mise à jour de l'une ne met pas à jour l'autre.

Vérifier quelle disposition vous utilisez

Si une nouvelle session n'affiche pas de sélecteur d'environnement sous la zone de prompt, vous disposez de l'ancienne disposition :

• Desktop antérieur à v2.37337.0 : mettez à jour pour obtenir la disposition actuelle. Sélectionnez Claude > Rechercher les mises à jour… sur macOS ou Aide > Rechercher les mises à jour… sur Windows.
• Fournisseur tiers avec des sessions sur votre ordinateur : la disposition actuelle nécessite Claude Desktop v3.1623.0 ou une version ultérieure ; vérifiez donc votre version. Pour mettre à jour, sélectionnez Claude > Rechercher les mises à jour… sur macOS ou Aide > Rechercher les mises à jour… sur Windows. Si votre organisation désactive les mises à jour automatiques, Rechercher les mises à jour… est masqué ; demandez donc à votre administrateur la v3.1623.0 ou une version ultérieure.
• Fournisseur tiers avec des sessions sur l'infrastructure de votre organisation : lorsque votre organisation exécute les sessions sur sa propre infrastructure plutôt que sur votre ordinateur, Desktop conserve l'ancienne disposition, et la mise à jour ne modifie pas la disposition. Si vous ne savez pas où s'exécutent vos sessions, demandez à votre administrateur.

Dans l'ancienne disposition, choisissez l'environnement et le dossier du projet au-dessus de la zone de prompt, et le mode de permission et le modèle dans la ligne située en dessous. L'ancienne disposition ne propose ni le panneau des détails de session ni les environnements locaux et SSH enregistrés.

Erreurs 403 ou d'authentification dans l'onglet Code

Si vous voyez Error 403: Forbidden ou d'autres défaillances d'authentification lors de l'utilisation de l'onglet Code :

1. Déconnectez-vous et reconnectez-vous à partir du menu de l'application. C'est le correctif le plus courant.
2. Vérifiez que vous avez un abonnement payant actif : Pro, Max, Team ou Enterprise.
3. Si la CLI fonctionne mais Desktop ne fonctionne pas, quittez complètement l'application de bureau, pas seulement fermez la fenêtre, puis rouvrez et reconnectez-vous.
4. Vérifiez votre connexion Internet et vos paramètres de proxy.

Écran blanc ou bloqué au lancement

Si l'application s'ouvre mais affiche un écran blanc ou ne répond pas :

1. Redémarrez l'application.
2. Vérifiez les mises à jour en attente. Sur macOS et Windows, l'application se met à jour automatiquement au lancement ; sur Linux, mettez à jour via apt comme décrit dans Claude Desktop sur Linux.
3. Sur un réseau géré, confirmez que votre pare-feu autorise les hôtes CDN dans les exigences d'accès réseau.
4. Sur Windows, vérifiez l'Observateur d'événements pour les journaux de crash sous Journaux Windows → Application.

« Impossible de charger la session »

Si vous voyez Failed to load session, le dossier sélectionné peut ne plus exister, un référentiel Git peut nécessiter Git LFS qui n'est pas installé, ou les permissions de fichier peuvent empêcher l'accès. Essayez de sélectionner un dossier différent ou redémarrez l'application.

Session ne trouvant pas les outils installés

Si Claude ne peut pas trouver des outils comme npm, node ou d'autres commandes CLI, vérifiez que les outils fonctionnent dans votre terminal régulier, vérifiez que votre profil shell configure correctement PATH et redémarrez l'application de bureau pour recharger les variables d'environnement.

Erreurs Git et Git LFS

Les sessions qui s'exécutent dans leur propre worktree ont besoin de Git. Si vous voyez « Git is required », installez Git, ou Git pour Windows sur Windows, et réessayez. Sur Windows, les versions de Claude Desktop antérieures à 1.49585.0 demandaient Git avant de démarrer une session locale ; si vous voyez cette invite et n'utilisez pas de worktrees, mettez à jour l'application.

Si vous voyez « Git LFS is required by this repository but is not installed », installez Git LFS à partir de git-lfs.com, exécutez git lfs install et redémarrez l'application.

Les serveurs MCP ne fonctionnent pas sur Windows

Si les bascules du serveur MCP ne répondent pas ou que les serveurs ne se connectent pas sur Windows, vérifiez que le serveur est correctement configuré dans vos paramètres, redémarrez l'application, vérifiez que le processus du serveur s'exécute dans le Gestionnaire des tâches et examinez les journaux du serveur pour les erreurs de connexion.

La connexion SSH échoue après que vous vous êtes connecté

Repérez dans ce tableau le titre de la carte, ou le code qui termine le message d'erreur, puis suivez les indications de la dernière colonne. Pour voir le message, sélectionnez View details sur la carte d'échec.

Pour tout autre message, consultez les exigences de la machine distante.

Obtenir les journaux de Desktop pour un problème SSH

Vous obtenez ssh.log, l'enregistrement par Desktop de ses connexions SSH, dans un fichier zip des journaux de Desktop que vous enregistrez depuis le menu Aide. Pour l'enregistrer, ouvrez Aide > Dépannage et sélectionnez l'élément correspondant à votre système :

• macOS : Afficher les journaux dans le Finder
• Windows : Afficher les journaux dans l'Explorateur de fichiers
• Linux : Afficher les journaux dans le gestionnaire de fichiers

Parcourez les fichiers avant de les envoyer, car ils peuvent inclure des noms et d'autres détails de votre environnement. <host> et <user> représentent des noms que Desktop a remplacés. Desktop ne remplace pas tous les noms, et un nom d'hôte ou d'utilisateur SSH peut encore apparaître tel quel. Si vous envoyez le fichier zip à quelqu'un, indiquez-lui quel hôte a échoué et à quel moment, car les journaux peuvent ne pas le nommer.

Le fichier zip ne contient pas le journal du programme auxiliaire que Desktop installe sur la machine distante. Pour obtenir également ce journal, copiez remote-server.log depuis le dossier du programme auxiliaire sous ~/.claude/remote/run/ dans le répertoire personnel de l'utilisateur qui s'est connecté. Parcourez également ce fichier avant de l'envoyer.

L'application ne veut pas quitter

• macOS : appuyez sur Cmd+Q. Si l'application ne répond pas, utilisez Forcer à quitter avec Cmd+Option+Esc, sélectionnez Claude et cliquez sur Forcer à quitter.
• Windows : utilisez le Gestionnaire des tâches avec Ctrl+Maj+Esc pour terminer le processus Claude.

Problèmes spécifiques à Windows

• PATH non mis à jour après l'installation : ouvrez une nouvelle fenêtre de terminal. Les mises à jour PATH s'appliquent uniquement aux nouvelles sessions de terminal.
• Erreur d'installation simultanée : si vous voyez une erreur concernant une autre installation en cours mais qu'il n'y en a pas, essayez d'exécuter l'installateur en tant qu'administrateur.

« La branche n'existe pas encore » lors de l'ouverture dans la CLI

Les sessions cloud peuvent créer des branches qui n'existent pas sur votre machine locale. Cliquez sur le nom de la branche dans la session et sélectionnez Copy branch name, puis récupérez-la localement :

git fetch origin <branch-name>
git checkout <branch-name>

Toujours bloqué ?

• Ouvrez Aide → Obtenir de l'aide dans l'application de bureau, ou visitez le centre de support Claude directement
• Pour les problèmes qui se reproduisent également dans la CLI autonome claude, recherchez ou signalez un bug sur GitHub Issues

Lors du signalement d'un problème, incluez la version de votre application de bureau, votre système d'exploitation, le message d'erreur exact et les journaux pertinents. Sur macOS, vérifiez Console.app. Sur Windows, vérifiez Observateur d'événements → Journaux Windows → Application. Examinez les extraits de journal avant de les publier sur un problème public ; ils peuvent inclure des chemins de fichiers et d'autres détails de votre environnement.