--- title: 'Claude Code Desktop : sessions parallèles, worktrees Git et revue de diff' description: "Claude Code Desktop ajoute à l'agent une sidebar de sessions isolées par worktree, une revue de diff avec commentaires de lignes et un navigateur d'auto-vérification : voici ce que tu gagnes, et ce que le terminal garde pour lui." pubDate: 2026-10-15 family: 'intelligence-artificielle' tags: ['Claude'] heroImage: '/images/claude-code-desktop-sessions-paralleles-worktrees-git-et-revue-de-diff.webp' videoUrl: 'https://www.youtube.com/watch?v=qmogPe_jcyE' faq: - question: 'Faut-il abandonner le terminal pour Claude Code Desktop ?' answer: "Non. Desktop et le CLI exécutent le même moteur : tu peux lancer les deux en parallèle sur la même machine et le même projet, chacun gardant sa propre liste de sessions. Desktop est interactif uniquement et n'expose ni --print ni l'Agent SDK, donc le scripting et l'automatisation restent au terminal : la documentation Anthropic recommande Desktop pour gérer des sessions parallèles d'une seule fenêtre et relire les changements visuellement, et le CLI pour l'automatisation." - question: "Peut-on reprendre une session démarrée dans le terminal à l'intérieur de Desktop ?" answer: "Oui. La commande /desktop lancée dans le terminal sauvegarde la session et l'ouvre dans l'application, puis le CLI se ferme ; elle est disponible sur macOS et Windows x64 avec un abonnement Claude, mais pas avec une clé API ni sur Amazon Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry. Depuis un shell, claude --desktop (Claude Code v2.1.285 ou plus récent) ouvre l'application, et claude --desktop --resume suivi de l'identifiant de session affiché par /status ouvre une session existante. Dans Desktop, /resume liste les sessions lancées depuis le CLI et reprend la même session, pas une copie." - question: 'Desktop et le CLI partagent-ils la configuration ?' answer: "Oui pour l'essentiel : les fichiers CLAUDE.md et CLAUDE.local.md du projet, les serveurs MCP de ~/.claude.json et .mcp.json, les hooks, les skills et les réglages de ~/.claude/settings.json sont lus par les deux. Deux écarts existent : la version de Claude Code embarquée dans l'onglet Code possède son propre numéro de version et n'est pas mise à jour en même temps que la commande claude du terminal, et le CLI autonome ne lit pas claude_desktop_config.json, dont les serveurs MCP alimentent pourtant les sessions locales de Desktop." - question: 'Les sessions Desktop sont-elles isolées les unes des autres ?' answer: "Seulement si tu actives l'option worktree au démarrage d'une session dans un dépôt Git. Sans elle, les sessions partagent le même dossier de travail ; avec elle, chaque session reçoit une copie isolée du projet, placée par défaut dans le dossier .claude/worktrees/ à la racine du projet. Git doit être installé, et un fichier .worktreeinclude à la racine du projet recopie les fichiers ignorés comme .env dans chaque nouveau worktree." - question: "Le navigateur intégré et l'auto-vérification fonctionnent-ils en session SSH ?" answer: "Non. En session SSH, Claude n'a pas accès aux outils du volet navigateur : pour regarder l'application toi-même, la documentation propose de rediriger le port de la machine distante, par exemple avec ssh -N -L 3000:localhost:3000 devbox. L'auto-vérification après chaque édition, elle, est activée par défaut sur les sessions locales et se désactive projet par projet avec autoVerify à false dans .claude/launch.json." --- Claude Code Desktop existe-t-il pour remplacer le terminal ? C'est la question que pose la vidéo, et la réponse tient en une phrase : le terminal n'est pas menacé, il n'est plus le seul endroit où l'agent travaille. Le CLI et l'application de bureau exécutent le même moteur ; ce que Desktop ajoute, c'est une fenêtre pour piloter plusieurs sessions en parallèle, les isoler avec des worktrees Git, relire les diffs ligne par ligne et laisser l'agent vérifier son propre travail dans un navigateur. Deux avertissements avant d'entrer dans le détail. La transcription automatique de la vidéo n'était pas récupérable depuis l'environnement de rédaction : les éléments qui viennent de la vidéo proviennent de sa description officielle, et le reste de la [documentation Anthropic](https://docs.claude.com/en/docs/claude-code/desktop) consultée le 15 octobre 2026. Et aucune commande citée ici n'a été exécutée pour cet article : ce sont des exemples **documentés mais non exécutés**, sans sortie observée. ## Desktop et le CLI, même moteur, deux surfaces Si tu utilises déjà la commande `claude`, tu ne repartiras pas de zéro. La documentation officielle indique que Desktop lance le même moteur avec une interface graphique, que les deux peuvent tourner simultanément sur la même machine, y compris sur le même projet, et que chacun conserve sa propre liste de sessions. La configuration est largement partagée : fichiers `CLAUDE.md` et `CLAUDE.local.md` du projet, serveurs MCP de `~/.claude.json` et `.mcp.json`, hooks, skills et réglages de `~/.claude/settings.json`. Deux écarts à connaître. D'abord, l'onglet Code embarque sa propre copie de Claude Code, avec son propre numéro de version : `/status` l'affiche, et mettre à jour l'application ne met pas à jour la commande `claude` de ton terminal, ni l'inverse. Ensuite, l'application de bureau charge aussi les serveurs MCP de `claude_desktop_config.json` dans ses sessions locales, ce que le CLI autonome ne fait pas — la documentation fournit la commande `claude mcp add-from-claude-desktop` pour les importer. L'application se découpe en trois onglets : **Chat** pour les conversations, **Cowork** pour le travail agentique long et Dispatch, et **Code** pour le développement. Le reste de cet article concerne l'onglet Code. Tu l'installes sur macOS (build universel Intel et Apple Silicon), Windows (x64 et ARM64) ou en bêta sur Linux via apt ou un paquet `.deb` ([guide Linux](https://docs.claude.com/en/docs/claude-code/desktop-linux)). ## Des sessions parallèles, isolées par worktrees Git Chaque conversation de l'onglet Code est une session avec son historique et son dossier de projet. La sidebar les liste et permet d'en faire tourner plusieurs en parallèle ; `Ctrl+Tab` et `Ctrl+Shift+Tab` passent de l'une à l'autre, `Cmd+N` en crée une, et maintenir `Cmd` ou `Ctrl` en cliquant une session l'ouvre à côté de celle qui est déjà active. L'intérêt réel apparaît quand deux agents écrivent dans le même dépôt. Dans un dépôt Git, l'écran de démarrage propose une option **worktree** à côté du nom de branche : la session reçoit alors sa propre copie du projet, décrite dans la [documentation des worktrees](https://docs.claude.com/en/docs/claude-code/worktrees). Par défaut, ces copies vivent dans `/.claude/worktrees/`, et l'emplacement se change dans **Settings > Claude Code** (sessions locales) ou sur la connexion SSH (sessions distantes). Une option **Branch prefix** s'ajoute aux noms de branches créées par Desktop, et un fichier `.worktreeinclude` à la racine du projet recopie les fichiers ignorés comme `.env` dans chaque nouveau worktree. Git doit être installé : sans lui, pas d'isolation. Deux points d'hygiène que la vidéo met en avant et que la documentation confirme. Une session peut en interroger une autre : Claude liste les sessions de l'onglet Code, lit ce qu'elles font et peut leur envoyer un message (« quelle session a touché le refactor d'authentification ? »). Attention au périmètre : il ne voit que les sessions locales, SSH et WSL lancées par l'application — pas les sessions cloud, pas celles du CLI, pas celles de l'extension VS Code — et il ignore la session depuis laquelle tu lui parles. Ensuite, l'archivage supprime le worktree : garde l'habitude de fermer une session depuis la sidebar une fois la pull request fusionnée, ou active **Auto-archive after PR merge or close**. ## Relire ce que l'agent a écrit C'est la partie qui justifie le plus l'interface graphique. Après une modification, un indicateur de statistiques de diff apparaît dans la session, du type `+12 -1`. Un clic ouvre la visionneuse : liste de fichiers à gauche, changements à droite. Tu peux commenter n'importe quelle ligne — le commentaire s'ajoute dans une zone de saisie sous la ligne — puis envoyer tous tes commentaires d'un coup avec `Cmd+Entrée` sur macOS ou `Ctrl+Entrée` sur Windows. Claude lit ces commentaires et produit un nouveau diff à relire. En complément, `/code-review` lancé dans la boîte de prompt fait analyser les changements avant commit. Dans les sessions locales, SSH et WSL, les résultats arrivent sous forme de carte **Code review** groupée par fichier : **Walk through in diff** ouvre la visionneuse et fait défiler les signalements un par un, avec un bouton **Fix this one** sur le signalement situé dans le diff courant, et **Apply fixes** demande à Claude de corriger ceux qui restent ouverts. Le détail de ce que la commande examine se trouve dans la [référence de la revue de code](https://docs.claude.com/en/docs/claude-code/code-review). Vient enfin le suivi de la pull request. Une barre d'état CI s'affiche dans la session et interroge les résultats de checks via le CLI GitHub, `gh`. Deux automatismes s'activent depuis le bouton **CI** : **Auto-fix CI & address comments**, qui laisse Claude lire l'échec, corriger en boucle et traiter les nouveaux commentaires de revue — à condition qu'ils viennent du propriétaire du dépôt, d'un membre de l'organisation, d'un collaborateur ou d'une GitHub App —, et **Auto-merge when ready**, qui fusionne la PR en squash une fois les checks au vert. L'auto-merge doit d'abord être autorisé dans les réglages GitHub du dépôt, sinon Claude ne peut pas fusionner. Tout cela suppose `gh` installé et authentifié sur la machine ; en session SSH, installe-le toi-même sur la machine distante, la documentation précisant que Desktop ne le propose pas dans ce cas. ## Le navigateur intégré et l'auto-vérification Le volet navigateur est ce qui distingue le plus Desktop d'un simple terminal amélioré. Claude démarre ton serveur de développement et ouvre l'application pour vérifier ses propres changements : captures d'écran, inspection du DOM, clics, remplissage de formulaires, puis correction de ce qu'il trouve. Tu peux interagir toi-même avec l'application dans ce volet, ouvrir un onglet sur une documentation externe à côté — `Cmd+Shift+B` sur macOS, `Ctrl+Shift+B` sur Windows — et piloter les serveurs via le menu **Dev servers**. Les détails qui évitent d'y passer une heure : - Claude génère une configuration initiale, stockée dans `.claude/launch.json` à la racine du dossier choisi au démarrage de la session. Si tu utilises `yarn dev` au lieu de `npm run dev`, ou un port précis, c'est ce fichier qu'il faut éditer, avec `runtimeExecutable`, `runtimeArgs`, `port`, `cwd`, `env`, `autoPort` et, pour un script Node lancé directement, `program` et `args`. - L'auto-vérification après chaque édition est active par défaut. Pour la couper projet par projet, ajoute `"autoVerify": false` dans `.claude/launch.json`, ou décoche **Auto-verify changes** dans le menu `⋮` du volet. - Le volet navigateur n'existe pas en session SSH, car Claude n'y dispose pas de ses outils. Pour regarder l'application toi-même, la documentation propose une redirection de port, par exemple `ssh -N -L 3000:localhost:3000 devbox`. - Ne mets pas de secrets dans `env` : ce fichier est commité dans le dépôt. ## Configure ton premier lancement Avant d'envoyer le premier message, quatre choix se font dans la zone de prompt. L'environnement : **Local** sur ta machine, **Cloud** sur l'infrastructure d'Anthropic — la session continue même si tu fermes l'application, et accepte plusieurs dépôts —, **SSH** sur une machine distante, ou **WSL** sous Windows. Le dossier de projet, le modèle, et le mode de permission. Les modes sont les mêmes qu'au CLI, à une exception près : `dontAsk` reste réservé au terminal. **Manual** (`default`) demande avant chaque édition et chaque commande ; **Accept edits** (`acceptEdits`) accepte les éditions de fichiers et les commandes courantes comme `mkdir`, `touch` ou `mv`, mais demande avant les autres commandes ; **Plan** explore et propose un plan sans toucher au code, pour la session en cours ; **Auto** laisse Claude avancer sans sollicitations routinières, un classificateur vérifiant en arrière-plan que les commandes et requêtes réseau correspondent à ta demande — ce mode exige un modèle Opus 4.6 ou ultérieur, Sonnet 4.6 ou ultérieur, Haiku 5.5 ou un modèle Fable ; **Bypass permissions** désactive les demandes, à réserver au bac à sable. Le mode choisi dans le sélecteur est mémorisé par dossier et prend le pas sur `permissions.defaultMode`. Le détail est dans la [référence des modes de permission](https://docs.claude.com/en/docs/claude-code/permission-modes). Le terminal intégré reste à portée de main : le raccourci Ctrl plus accent grave l'ouvre dans le répertoire de travail de la session, avec le même environnement que Claude, donc un `npm test` lancé là voit exactement les fichiers que l'agent édite. Le volet de fichiers permet des retouches ponctuelles, et `Ctrl+O` fait défiler les modes d'affichage — Normal, Thinking, Verbose — quand tu veux suivre le raisonnement ou déboguer une action. Attention à la version : la disposition des volets, le terminal et l'éditeur de fichiers demandent Claude Desktop v1.2581.0 ou ultérieure. ## Passer du terminal à Desktop Trois chemins existent. `/desktop` dans le terminal sauvegarde la session et l'ouvre dans l'application, puis quitte le CLI — macOS et Windows x64, avec un abonnement Claude, et pas avec une clé API ni sur Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry. Depuis un shell, `claude --desktop` ouvre l'application sans démarrer de session terminal (Claude Code v2.1.285 minimum), et `claude --desktop --resume ` rouvre une session précise, l'identifiant étant celui affiché par `/status`. Enfin, `/resume` dans la boîte de prompt de Desktop liste les sessions lancées depuis le CLI. Dans les trois cas, Desktop reprend la même session plutôt qu'une copie : un `claude --resume` en terminal la retrouve ensuite. ## Ce que Desktop ne fait pas encore Le point le plus important pour qui automatise : Desktop est interactif uniquement. `--print` et `--output-format` n'ont pas d'équivalent, l'Agent SDK non plus. Si tu enchaînes des agents dans une CI ou un script, le terminal reste obligatoire, et la documentation le dit explicitement dans son tableau comparatif. Autres limites à connaître avant de basculer : - **Pas d'équipe d'agents** : les agent teams coordonnées du CLI ne sont pas disponibles ; pour du multi-agent dans une session, ce sont les workflows dynamiques qui prennent le relais. - **Pas de complétion inline** : Desktop ne propose pas de suggestions au fil de la frappe, seulement une suggestion de prompt suivant, qui compte dans les limites d'usage de ton offre. - **Fournisseurs tiers** : par défaut, Desktop passe par l'API d'Anthropic. L'utilisation de Bedrock, d'Agent Platform, de Foundry ou d'une passerelle auto-hébergée passe par une configuration dédiée. - **Commandes à dialogue terminal** : `/permissions` répond qu'elle n'est pas disponible dans cet environnement et `/config` ouvre les réglages en ignorant le texte qui suit, comme `/config theme=dark`. - **Contrôle de l'ordinateur** : la fonction qui laisse Claude ouvrir tes applications et piloter l'écran est une preview de recherche sur macOS et Windows, réservée aux offres Pro et Max, désactivée par défaut, et absente des offres Team et Enterprise. Elle ne s'active pas sur Linux. La documentation prévient que la frontière de confiance n'est pas la même que celle du bac à sable Bash, puisque les actions se déroulent sur ton bureau réel. Claude essaie d'ailleurs l'outil le plus précis d'abord : un connecteur, puis Bash, puis Claude in Chrome, puis le simulateur iOS, et le contrôle d'écran en dernier recours. - **Dispatch** : envoyer une tâche depuis ton téléphone pour qu'elle démarre une session Code existe, mais requiert une offre Pro ou Max, et les approbations d'applications y expirent au bout de 30 minutes. ## Erreurs courantes Trois symptômes reviennent dans la [documentation de dépannage](https://docs.claude.com/en/docs/claude-code/desktop) et méritent d'être connus d'avance. Une erreur 403 ou d'authentification dans l'onglet Code se règle le plus souvent en se déconnectant puis en se reconnectant — et si le CLI fonctionne mais pas Desktop, il faut quitter complètement l'application, pas seulement fermer la fenêtre. Si Claude ne trouve pas `npm`, `node` ou un autre outil, l'application de bureau n'hérite pas toujours de ton environnement de shell : sur macOS l'app lit ton profil de shell pour `PATH` et une liste fixe de variables Claude Code, mais pas les autres ; le plus sûr est de déclarer les variables dans l'éditeur d'environnement local du sélecteur, qui les chiffre sur ta machine, ou dans la clé `env` de `~/.claude/settings.json`. Enfin, `Failed to load session` signale le plus souvent un dossier disparu, un dépôt qui réclame Git LFS ou un problème de permissions. Un mot pour finir sur la question de départ. Le terminal n'a pas perdu la partie : il garde le scripting, l'automatisation, les équipes d'agents et une partie de la configuration fine. Desktop apporte ce qui manquait à la ligne de commande — plusieurs sessions dans une seule fenêtre, des volets côte à côte, une revue de diff visuelle et un navigateur pour que l'agent constate lui-même le résultat. La vidéo déroule l'ensemble de ce parcours, de l'interface aux worktrees, et se termine sur cet arbitrage : elle est utile si tu veux voir les deux surfaces à l'œuvre avant de choisir la tienne. ## Pour approfondir **[Guide Claude Code](https://pentiminax.fr/blog/claude-code.md)** Retrouve les guides du site dans un parcours unique : prise en main, coûts et tokens, usages avancés et écosystème. [Explorer le guide Claude Code](https://pentiminax.fr/blog/claude-code.md) ## Questions fréquentes **Faut-il abandonner le terminal pour Claude Code Desktop ?** Non. Desktop et le CLI exécutent le même moteur : tu peux lancer les deux en parallèle sur la même machine et le même projet, chacun gardant sa propre liste de sessions. Desktop est interactif uniquement et n'expose ni --print ni l'Agent SDK, donc le scripting et l'automatisation restent au terminal : la documentation Anthropic recommande Desktop pour gérer des sessions parallèles d'une seule fenêtre et relire les changements visuellement, et le CLI pour l'automatisation. **Peut-on reprendre une session démarrée dans le terminal à l'intérieur de Desktop ?** Oui. La commande /desktop lancée dans le terminal sauvegarde la session et l'ouvre dans l'application, puis le CLI se ferme ; elle est disponible sur macOS et Windows x64 avec un abonnement Claude, mais pas avec une clé API ni sur Amazon Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry. Depuis un shell, claude --desktop (Claude Code v2.1.285 ou plus récent) ouvre l'application, et claude --desktop --resume suivi de l'identifiant de session affiché par /status ouvre une session existante. Dans Desktop, /resume liste les sessions lancées depuis le CLI et reprend la même session, pas une copie. **Desktop et le CLI partagent-ils la configuration ?** Oui pour l'essentiel : les fichiers CLAUDE.md et CLAUDE.local.md du projet, les serveurs MCP de ~/.claude.json et .mcp.json, les hooks, les skills et les réglages de ~/.claude/settings.json sont lus par les deux. Deux écarts existent : la version de Claude Code embarquée dans l'onglet Code possède son propre numéro de version et n'est pas mise à jour en même temps que la commande claude du terminal, et le CLI autonome ne lit pas claude_desktop_config.json, dont les serveurs MCP alimentent pourtant les sessions locales de Desktop. **Les sessions Desktop sont-elles isolées les unes des autres ?** Seulement si tu actives l'option worktree au démarrage d'une session dans un dépôt Git. Sans elle, les sessions partagent le même dossier de travail ; avec elle, chaque session reçoit une copie isolée du projet, placée par défaut dans le dossier .claude/worktrees/ à la racine du projet. Git doit être installé, et un fichier .worktreeinclude à la racine du projet recopie les fichiers ignorés comme .env dans chaque nouveau worktree. **Le navigateur intégré et l'auto-vérification fonctionnent-ils en session SSH ?** Non. En session SSH, Claude n'a pas accès aux outils du volet navigateur : pour regarder l'application toi-même, la documentation propose de rediriger le port de la machine distante, par exemple avec ssh -N -L 3000:localhost:3000 devbox. L'auto-vérification après chaque édition, elle, est activée par défaut sur les sessions locales et se désactive projet par projet avec autoVerify à false dans .claude/launch.json.