Copilot CLI : l'agent GitHub dans le terminal

Copilot CLI est l'agent de GitHub qui travaille dans le terminal : il lit le dépôt, modifie les fichiers, lance des commandes shell et prépare des pull requests, avec le siège Copilot que votre équipe paie peut-être déjà. Il s'installe en une commande. Ce tutoriel porte surtout sur ce qui suit l'installation. L'outil arrive en effet réglé pour un développeur seul devant son écran : mises à jour automatiques, droits accordés au fil de l'eau, bac à sable éteint et aucun plafond de dépense.

Nous avons installé la version 1.0.96 le 16 octobre 2026 sur un de nos serveurs Linux, lu son aide intégrée option par option et confronté chaque réglage à la documentation officielle de GitHub. Nous ne l'avons pas connecté à un compte pour ce test : ce qui se passe après la connexion vient de la documentation, et nous le signalons. Nous recommandons d'écrire, avant la première tâche, ce que l'agent n'a pas le droit de faire, puis de figer sa version et de poser un plafond de crédits. L'outil change presque tous les jours, donc vérifiez chaque option avec copilot help sur votre propre version.

Copilot CLI : ce que fait l'agent et qui y a accès

Copilot CLI est inclus dans tous les plans Copilot, du plan gratuit à Enterprise, selon la page des plans de la documentation GitHub, et il consomme les mêmes crédits IA que le chat et les agents. GitHub l'a déclaré disponible pour tous les abonnés le 25 février 2026, après une préversion publique ouverte en septembre 2025. Il tourne sous Linux, sous macOS et sous Windows, en PowerShell ou dans WSL, d'après la présentation de l'outil.

Concrètement, c'est un agent de code complet. D'après l'annonce de GitHub, en session interactive, vous décrivez une tâche, il lit les fichiers, propose des modifications, exécute des commandes et demande votre accord avant chaque outil capable d'écrire ou d'exécuter. La touche Maj+Tab bascule en mode plan : l'agent pose ses questions et rédige un plan avant de toucher au code. Le mode autopilot enchaîne les étapes sans validation. Le préfixe & ou la commande /delegate confie la tâche à l'agent cloud de GitHub, qui ouvre une pull request en brouillon puis vous demande une relecture, selon la page sur la délégation. Ces fonctions demandent un compte connecté, et nous ne les avons pas testées ici.

Le prix dépend du plan et du modèle. Pro coûte 10 $ par mois, et Business 19 $ par siège avec 1 900 crédits IA par utilisateur et par mois, d'après le détail des plans Copilot. Chaque crédit vaut 0,01 $, selon la page de facturation des modèles, et se consomme au token, à un tarif qui varie beaucoup d'un modèle à l'autre. Nous avons refait ce calcul en détail dans notre article sur le prix des plans Copilot et des crédits IA.

Dans une organisation, un réglage bloque souvent la première prise en main. Si le propriétaire de l'organisation ou l'administrateur de l'entreprise a désactivé Copilot CLI dans les politiques, l'outil refuse de fonctionner, même avec un siège attribué, comme le précise la page d'installation. L'argument en faveur de Copilot CLI est d'ailleurs surtout administratif. Quand le service achats et le délégué à la protection des données ont déjà validé GitHub comme fournisseur, un outil de la même maison évite une nouvelle validation de sous-traitant. La même question se pose dès qu'un projet dépasse l'agent de code et vise des agents IA sur mesure branchés sur vos outils métier : elle se règle avant d'écrire la première ligne.

Installer Copilot CLI et garder la version que vous avez choisie

Copilot CLI s'installe par npm sur tous les systèmes, par Homebrew sous macOS et Linux, par WinGet sous Windows ou par un script, d'après la documentation d'installation. La voie npm demande Node.js 22 ou plus récent :

npm install -g @github/copilot
brew install --cask copilot-cli
winget install GitHub.Copilot

Nous n'avons pas pris la dernière version. Sur nos postes, un paquet n'entre qu'après 72 heures de publication, le temps qu'une version piégée soit repérée et retirée. Le 16 octobre au matin, la 1.0.98 avait moins de deux jours et la 1.0.97 moins de trois : nous avons donc installé la 1.0.96, publiée le 12 octobre. Le rythme de publication rend cette règle utile. Le registre npm compte 200 versions stables du paquet @github/copilot depuis sa création le 25 septembre 2025, et 907 publications en comptant les préversions, d'après la commande npm view @github/copilot time lancée le jour du test.

npm install -g --ignore-scripts @github/[email protected]
copilot --version

La page d'installation conseille de réactiver les scripts d'installation quand ignore-scripts=true est posé dans ~/.npmrc, ce qui est notre réglage par défaut. Nous ne l'avons pas fait. La 1.0.96 ne déclare aucun script, et copilot --version a répondu normalement. Le paquet npm n'est qu'un lanceur d'environ 13 Ko, qui démarre le binaire de la plateforme livré dans un paquet séparé. Sur notre serveur Linux, l'installation occupe 177 Mo dans node_modules, puis 201 Mo extraits dans ~/.cache/copilot/pkg au premier lancement. Ce binaire embarque son propre moteur Node.js : son journal indiquait la version 24.20.0, alors que notre serveur fait tourner Node 22.

Reste le réglage qui annule tout ce qui précède : Copilot CLI se met à jour tout seul. L'aide de la 1.0.96 indique que le réglage autoUpdate vaut true par défaut. L'outil télécharge donc les nouvelles versions de lui-même, sauf en intégration continue, où il reconnaît les variables CI, BUILD_NUMBER, RUN_ID ou SYSTEM_COLLECTIONURI. Sur un poste de développeur, la version que vous avez choisie n'est pas forcément celle qui tournera la semaine suivante. Pour la garder, ajoutez export COPILOT_AUTO_UPDATE=false à votre profil de shell, ou lancez l'outil avec --no-auto-update. D'après la description de cette option, l'outil exécute alors la version livrée avec le binaire lancé, même si une version plus récente a déjà été téléchargée.

Se connecter : l'ordre des jetons décide du compte utilisé

Copilot CLI cherche un identifiant dans un ordre fixe et prend le premier qu'il trouve, d'après la page d'authentification. Il lit d'abord la variable COPILOT_GITHUB_TOKEN, puis GH_TOKEN, puis GITHUB_TOKEN, ensuite le jeton OAuth rangé dans le trousseau du système, et en dernier recours le jeton de GitHub CLI obtenu par gh auth token. Lancé sans aucun identifiant, notre binaire a répondu par une erreur qui propose ces trois voies : la commande /login, une de ces variables, ou gh auth login.

Cet ordre tend un piège classique. Beaucoup de développeurs exportent un GITHUB_TOKEN pour un autre usage, un script de déploiement ou un client d'API. Copilot CLI le prend alors avant le compte connecté par /login : la page d'authentification précise qu'une variable d'environnement remplace sans avertissement un jeton OAuth enregistré. Si ce jeton appartient à un autre compte, ou s'il n'a pas le droit d'appeler Copilot, la session échoue ou travaille sous une autre identité. Devant une erreur d'authentification inattendue, lancez d'abord env | grep -E 'COPILOT_GITHUB_TOKEN|GH_TOKEN|GITHUB_TOKEN'.

Selon la même page, en usage interactif, /login ouvre le navigateur, ou propose un code d'appareil quand vous êtes en SSH, dans un conteneur ou en intégration continue. Le jeton est rangé dans le trousseau du système, via libsecret sous Linux. Sans trousseau, l'outil propose de l'écrire en clair dans ~/.copilot/config.json : sur un serveur partagé, refusez et passez par une variable chargée depuis votre gestionnaire de secrets.

En intégration continue, la documentation demande un jeton à portée fine rattaché à un compte personnel, car la permission Copilot Requests n'existe pas sur les jetons d'organisation. Elle indique aussi que les jetons classiques en ghp_ ne sont pas acceptés, et que /logout efface le jeton local sans le révoquer chez GitHub. Pour couper réellement l'accès d'un poste perdu ou d'un prestataire parti, il faut révoquer l'application OAuth correspondante dans les réglages d'applications du compte GitHub.

Régler les permissions de Copilot CLI avant la première tâche

Réglez les permissions de Copilot CLI en ligne de commande avant la première tâche, en commençant par ce qui est interdit : d'après l'aide intégrée, une règle --deny-tool l'emporte toujours sur les autorisations, y compris sur --allow-all-tools. Sans réglage, l'outil demande votre accord avant chaque outil qui écrit ou exécute, et limite l'accès aux fichiers au dossier courant, à ses sous-dossiers et au dossier temporaire du système. Au premier lancement, il demande aussi si vous faites confiance au dossier. La présentation officielle de l'outil déconseille de le lancer depuis votre dossier personnel, et prévient que le cloisonnement des permissions est heuristique : GitHub ne garantit pas que les fichiers situés hors des dossiers de confiance soient protégés.

Le danger vient de la fatigue. Après dix demandes d'accord, on finit par accepter un outil pour toute la session. La documentation prend l'exemple de rm : l'accepter pour la session autorise l'agent à supprimer des fichiers dans tout le dossier courant et ses sous-dossiers. Mieux vaut décider à froid ce qui passe sans question et ce qui ne passe jamais. La configuration de départ que nous recommandons tient en cinq règles :

copilot \
  --allow-tool='shell(git:*)' --deny-tool='shell(git push)' \
  --allow-tool='write' --deny-tool='write(.env)' \
  --deny-tool='shell(rm)'

L'aide de la 1.0.96 précise deux subtilités de syntaxe. Un chemin relatif dans write() vise ce nom de fichier dans n'importe quel dossier. La règle write(.env) bloque donc tous les fichiers .env du projet, ce qui est voulu ici ; seul un chemin absolu vise un fichier précis. Pour les commandes git et gh, l'accord se donne par sous-commande, d'où la paire shell(git:*) et shell(git push). Les options --allow-all et --yolo, elles, valent exactement --allow-all-tools --allow-all-paths --allow-all-urls : elles lèvent aussi la limite des dossiers et des adresses web. Faute de compte connecté, nous n'avons pas vu ces règles bloquer une action réelle : testez votre configuration sur un dépôt d'essai avant de vous y fier.

Le risque le plus sérieux tient à une variable d'environnement. COPILOT_ALLOW_ALL accepte plusieurs valeurs, mais la valeur exacte true va plus loin que les autres, selon l'aide de la 1.0.96. Elle marque aussi le dossier comme digne de confiance sans le demander. La session charge alors ses skills, ses plugins, ses serveurs MCP et ses hooks, y compris des hooks qui lancent des commandes shell. Cloner un dépôt inconnu puis démarrer l'agent avec cette variable revient à exécuter ce que l'auteur du dépôt a prévu. Un fichier du dépôt peut aussi contenir une injection de prompt qui pousse l'agent vers une commande autorisée mais nuisible. Gardez --yolo pour un conteneur que vous jetterez ensuite.

Activer le bac à sable de commandes, surtout sous Linux

Le bac à sable de Copilot CLI est désactivé par défaut, et nous conseillons de l'activer dès le premier jour : sans lui, chaque commande lancée par l'agent dispose exactement des droits de votre compte. L'aide de la version 1.0.96 le dit sans détour : l'agent peut alors lire, écrire et supprimer partout où vous le pouvez, joindre tous les réseaux accessibles depuis la machine et utiliser vos identifiants sans restriction. La commande /sandbox enable pendant une session, ou l'option --sandbox au lancement, l'active. Une politique d'organisation peut aussi l'imposer.

D'après l'aide, l'isolation repose sur Microsoft Execution Containers, une couche qui s'appuie sur le mécanisme natif de chaque système : sandbox-exec sous macOS, bubblewrap sous Linux, des conteneurs de processus sous Windows. Sous Linux, chaque commande tourne dans un espace réseau privé, ce qui impose plusieurs prérequis. L'aide cite bwrap 0.5.0 ou plus récent, slirp4netns, util-linux 2.35 ou plus, iptables et ip6tables avec leurs commandes de restauration, ainsi que l'accès en lecture et en écriture à /dev/net/tun. Notre serveur avait bubblewrap 0.9.0 et util-linux 2.39.3, mais pas slirp4netns. Or l'aide précise que la vérification de compatibilité ne teste que bwrap, sans les autres prérequis : sur une machine incomplète, une commande isolée peut donc échouer au démarrage alors que l'outil a jugé l'hôte compatible. Installez les paquets avant d'activer l'option.

Toujours selon l'aide, une fois activé, le bac à sable limite les fichiers accessibles au dossier de travail, aux dossiers du PATH, au dossier temporaire et à votre profil. Il laisse sortir le réseau par défaut, et fait passer l'authentification de git et de gh par un proxy local qui donne aux commandes des valeurs factices à la place des vrais jetons. Il a deux limites à connaître. Les modifications de fichiers faites par les outils intégrés de l'agent ne passent pas par l'isolation du système : elles suivent la même politique, mais au mieux. Et le bac à sable hérite de votre environnement, si bien qu'une clé comme AWS_ACCESS_KEY_ID reste lisible tant que vous ne l'avez pas déclarée pour le masquage. L'option --secret-env-vars=MA_CLE,AUTRE_CLE retire ces valeurs de l'environnement des commandes et des serveurs MCP, et les masque dans la sortie.

Ce que Copilot CLI charge sans qu'on le lui demande

Au démarrage, Copilot CLI lit tous les fichiers d'instructions qu'il trouve et les combine, y compris ceux écrits pour d'autres agents. La page sur les instructions personnalisées liste .github/copilot-instructions.md, les fichiers .github/instructions/*.instructions.md, AGENTS.md, CLAUDE.md, .claude/CLAUDE.md et GEMINI.md, cherchés à la racine du dépôt, dans le dossier courant et dans les dossiers intermédiaires. S'y ajoutent vos fichiers personnels sous ~/.copilot/. La documentation ne fixe aucun ordre de priorité entre ces fichiers et se contente de conseiller d'éviter les consignes contradictoires.

Pour une équipe qui utilise déjà Claude Code, le CLAUDE.md existant sert donc tel quel, sans copie. Mais l'outil ne fusionne que les copies identiques, et nous l'avons mesuré avec la sous-commande copilot instruction list, qui affiche les sources qu'une session chargerait. Dans un dossier d'essai, un AGENTS.md identique à l'octet au CLAUDE.md apparaît comme une seule source, « AGENTS.md + CLAUDE.md ». Le même fichier précédé de deux lignes d'en-tête apparaît comme deux sources distinctes. Or notre propre outillage produit exactement ce cas dans un de nos monorepos : AGENTS.md y est généré depuis CLAUDE.md, avec un en-tête qui indique sa source. Copilot CLI y chargerait donc deux fois les mêmes consignes. Sur un autre dépôt, notre AGENTS.md n'est qu'un renvoi de quelques lignes vers CLAUDE.md, ce qui règle la question. D'après l'aide, l'option --no-custom-instructions coupe le chargement de ces fichiers, et copilot init analyse le code avec des outils en lecture seule pour générer un premier .github/copilot-instructions.md. Cette dernière commande appelle un modèle, et nous ne l'avons pas lancée.

Les serveurs MCP suivent la même logique d'accumulation. L'aide de la 1.0.96 cite deux serveurs intégrés et actifs, celui de GitHub, limité par défaut à un sous-ensemble d'outils choisi pour le terminal, et un second nommé githubiq. Vos propres serveurs se déclarent dans ~/.copilot/mcp-config.json ou par la commande /mcp add. Si vous découvrez le protocole MCP, retenez qu'un serveur ajouté donne de nouveaux outils à l'agent, donc de nouvelles permissions à régler avec les mêmes règles --allow-tool et --deny-tool. L'option --disable-builtin-mcps coupe les serveurs intégrés, ce qui sert pour un essai qui ne doit rien lire sur GitHub.

Copilot CLI en script : mode -p, plafond de crédits et choix du modèle

En script ou en intégration continue, Copilot CLI se lance avec -p suivi de la consigne, travaille, puis rend la main. L'aide de la version 1.0.96 précise que --allow-all-tools est requis dans ce mode, puisque personne n'est là pour valider. Les règles --deny-tool deviennent alors la seule barrière, et elles restent prioritaires même face à cette option. Ajoutez -s pour ne garder que la réponse de l'agent, ou --output-format json pour un flux JSON, un objet par ligne :

copilot -p "Corrige le test qui échoue dans tests/facture.test.ts" \
  --allow-all-tools --deny-tool='shell(git push)' --deny-tool='write(.env)' \
  --max-ai-credits 300 --usage-output-file usage.json -s

Le plafond --max-ai-credits est la protection la plus utile de ce mode, et il est facultatif : l'aide de la 1.0.96 indique qu'aucune limite de session n'est posée par défaut. Son minimum est de 30 crédits d'après la même aide, soit 0,30 $. L'aide précise qu'il s'agit d'un plafond souple : la consommation n'est connue qu'au retour de chaque appel au modèle, donc un appel peut dépasser la limite avant que l'outil bloque le suivant. Avec 300 crédits, une exécution coûte au plus 3 $ environ, plus le dépassement du dernier appel. Les sous-agents partagent le plafond de la session principale, et le compactage de l'historique le consomme aussi. En mode autopilot, l'agent s'arrête par défaut après 5 messages de relance automatique, une valeur réglable par --max-autopilot-continues. L'option --usage-output-file écrit les statistiques finales de consommation en JSON, ce qui permet de suivre le coût réel d'une tâche répétée.

Le choix du modèle pèse plus que tout le reste. Dans la grille de prix publiée par GitHub, un million de tokens produits coûte 2 $ avec GPT-5 mini, 10 $ avec Claude Sonnet 5.5, 20 $ avec Claude Opus 5.5 et 50 $ avec GPT-6 Astra. D'après l'aide, le sélecteur /model affiche ces tarifs avant de changer, et /usage donne la consommation de la session en cours. Pour corriger un test ou monter une dépendance de version, un petit modèle suffit souvent ; gardez les grands modèles pour les tâches de conception.

Faut-il pour autant adopter Copilot CLI ? Notre recommandation dépend de ce que vous payez déjà. Si votre organisation est sur Copilot Business, commencez par lui : le siège est payé, la gouvernance passe par les politiques GitHub que votre administrateur connaît, et l'agent cloud prend le relais des tâches longues. Sans contrat Copilot, nous restons sur notre méthode avec Claude Code, ses hooks, ses skills et MCP, que nous utilisons au quotidien. Gemini CLI se défend pour une équipe déjà engagée sur Google Cloud. Copilot CLI lisant aussi les fichiers CLAUDE.md et GEMINI.md, un essai croisé coûte peu sur un dépôt déjà équipé, à condition de vérifier par copilot instruction list ce qu'il charge.

Questions fréquentes sur Copilot CLI

Copilot CLI est-il gratuit ?

Le plan gratuit de Copilot inclut Copilot CLI, avec une allocation limitée pour le chat et les agents, d'après la page des plans de GitHub. Elle permet de découvrir l'outil. Pour un usage quotidien, comptez le plan Pro à 10 $ par mois ou un siège Business à 19 $ par mois. Dans tous les cas, Copilot CLI consomme des crédits IA au token, au tarif du modèle choisi, comme le chat et les autres agents.

Pourquoi Copilot CLI refuse-t-il de démarrer dans mon organisation ?

Vérifiez trois points, dans cet ordre. L'administrateur a peut-être désactivé la politique Copilot CLI de l'organisation ou de l'entreprise, et l'outil refuse alors de fonctionner même avec un siège attribué. Un jeton classique en ghp_ a pu être exporté dans une variable, or il n'est pas accepté. Enfin, une variable GITHUB_TOKEN prévue pour un autre outil passe devant votre connexion par /login. Vérifiez votre environnement avant de contacter l'administrateur.

Peut-on utiliser Copilot CLI avec un modèle local ?

Oui, en mode BYOK. D'après l'aide de la 1.0.96, la variable COPILOT_PROVIDER_BASE_URL pointe vers un serveur compatible OpenAI, comme Ollama ou vLLM, et la connexion à GitHub n'est alors plus requise. Le modèle doit gérer l'appel d'outils et la diffusion en continu, et la présentation de Copilot CLI recommande au moins 128 000 tokens de contexte. Avec COPILOT_OFFLINE=true, l'outil coupe aussi la télémétrie, le serveur MCP de GitHub et la mise à jour automatique.

Copilot CLI envoie-t-il mon code à GitHub ?

Sans fournisseur personnel, vos consignes et le contexte lu dans le dépôt partent vers le modèle choisi, par les services de Copilot. L'exclusion de contenu, qui empêche Copilot d'utiliser certains fichiers, s'applique aux comptes Business et Enterprise, selon la présentation officielle de l'outil. Le mode hors ligne ne garantit une coupure totale qu'avec un fournisseur local : un fournisseur distant reçoit toujours les consignes et le code envoyé en contexte, précise la page d'authentification.

Comment reprendre une session Copilot CLI interrompue ?

D'après l'aide de la 1.0.96, la commande copilot --continue rouvre la dernière session locale fermée. Avec copilot --resume seul, l'outil propose la liste des sessions enregistrées ; avec un identifiant ou un nom, il reprend directement la session visée. Pour retrouver facilement une tâche, nommez la session dès le départ avec --name. La page sur les instructions précise que les fichiers d'instructions modifiés entre-temps ne sont pris en compte qu'à l'ouverture ou à la reprise d'une session.