Authentification et dossiers de confiance

5.3 Authentification et configuration

Authentification

Copilot CLI doit savoir qui tu es et vérifier que ton compte a accès à Copilot. GitHub documente deux familles de méthodes : l’OAuth pour l’usage interactif, et les jetons pour l’automatisation.

Usage interactif : OAuth. C’est la méthode par défaut. Depuis une session, la commande est /login ; depuis le terminal, copilot login.

copilot login

L’OAuth a deux déroulements, choisis automatiquement selon l’environnement :

• le flux navigateur : le CLI ouvre le navigateur pour autoriser la connexion. C’est le défaut sur un terminal local ;
• le flux code d’appareil : le CLI affiche un code à saisir dans le navigateur. C’est le défaut sur un terminal distant (SSH, Codespaces, dev container) ou en CI, où le navigateur ne peut pas joindre le CLI.

On peut forcer l’un ou l’autre :

copilot login --device-code

Automatisation : jeton dans une variable d’environnement. Pour un script ou un pipeline, le CLI lit un jeton dans COPILOT_GITHUB_TOKEN, GH_TOKEN ou GITHUB_TOKEN. Un jeton fine-grained doit appartenir à un compte personnel et avoir la permission « Copilot Requests ». Les jetons classiques (ghp_) ne sont pas pris en charge.

L’ordre d’examen des identifiants est : COPILOT_GITHUB_TOKEN, GH_TOKEN, GITHUB_TOKEN, puis le jeton OAuth stocké, puis, en dernier recours, le jeton de GitHub CLI (gh auth token). Une variable d’environnement prend donc le pas, sans avertissement, sur un jeton OAuth déjà stocké.

Pour l’examen, retiens la logique plutôt que l’ordre exact : interactif = OAuth ; automatisation = jeton avec la bonne permission ; GitHub CLI = repli ; et dans tous les cas, l’organisation peut bloquer l’usage du CLI par une policy.

Configuration locale

GitHub documente un répertoire de configuration ~/.copilot, qui stocke des éléments comme la configuration, les données de session et les personnalisations de Copilot CLI. (docs.github.com)

Tu n’as pas besoin de connaître tous les fichiers internes pour l’examen. Mais tu dois comprendre que :

Copilot CLI possède une configuration locale.

Trusted directories

C’est un point très important.

Quand tu lances Copilot CLI dans un dossier, il peut demander si tu fais confiance au dossier.

Pourquoi ?

Parce que Copilot CLI peut potentiellement :

• lire des fichiers ;
• modifier des fichiers ;
• exécuter des commandes ;
• travailler dans le dossier courant et ses sous-dossiers.

GitHub précise qu’au démarrage, Copilot CLI demande de confirmer que tu fais confiance aux fichiers du dossier, car pendant la session il peut lire, modifier et exécuter des fichiers dans ce dossier. (docs.github.com)

Options typiques de trust

Quand Copilot demande si tu fais confiance au dossier, tu peux choisir une option du style :

Yes, proceed

Pour faire confiance seulement pour cette session.

Yes, and remember this folder

Pour mémoriser ce dossier comme trusted.

No, exit

Pour quitter.

GitHub recommande de ne choisir l’option “remember this folder” que si tu es sûr que ce dossier restera sûr pour les futures sessions. (docs.github.com)

Pourquoi c’est important ?

Parce qu’un dossier peut contenir :

• scripts malveillants ;
• fichiers générés ;
• dépendances non fiables ;
• hooks ;
• secrets ;
• données sensibles ;
• code téléchargé depuis Internet.

Faire confiance à un dossier n’est donc pas anodin.

Copilot CLI asks whether you trust the current folder. Why?

Because Copilot CLI may read, modify, and execute files in that folder during the session.