Skip to main content

Cloud Sessions

Les Cloud Sessions permettent d’exécuter la session dans l’environnement hébergé par GitHub plutôt que dans un processus Copilot CLI local. La tâche est réservée dans Mission Control et le copilot-agent côté cloud s’y connecte pour poursuivre le traitement. Les Remote Sessions habituelles exposent, depuis le Web/mobile GitHub, une session qui tourne en local. Si vous souhaitez que l’exécution elle-même ait lieu dans l’environnement hébergé par GitHub, utilisez Cloud Sessions.

Prérequis

  • L’utilisateur dispose des droits Copilot permettant d’utiliser le Cloud Agent
  • Vous pouvez vous authentifier via un token GitHub ou un utilisateur Copilot CLI déjà connecté
  • Si possible, associez des informations de dépôt GitHub
  • La politique d’organisation autorise l’exécution dans le cloud et la consultation à distance

Utilisation de base

Passez CloudSessionOptions à la clé cloud de SessionConfig. Les informations de dépôt sont optionnelles côté type SDK, mais recommandées afin de fournir du contexte à Mission Control et à l’agent cloud.
Vous pouvez aussi passer un tableau.

Quand envoyer le premier prompt

Une Cloud Session s’initialise en deux étapes. session.create renvoie dès que la tâche est réservée dans Mission Control, mais il faut un court délai avant que le copilot-agent cloud se connecte et émette session.start. Pour vous assurer que le premier prompt est bien remis, abonnez-vous aux événements en premier, puis envoyez-le uniquement après avoir constaté un session.start du copilot-agent (via producer).
Dans une application réelle, il est plus simple d’envoyer le prompt côté file d’attente ou traitement asynchrone après confirmation de session.start.

Différences avec les Remote Sessions

Points d’attention

  • Les Cloud Sessions sont soumises aux permissions et aux politiques d’organisation
  • Avec streaming: true, vous recevez des événements temps réel comme assistant.message_delta
  • La gestion des requêtes de permission est identique à celle d’une session standard. Depuis la Facade Laravel, le comportement par défaut est deny-all ; utilisez au besoin PermissionHandler::approveSafety()

Voir aussi

Pour les dernières informations, consultez le dépôt GitHub.
Dernière modification le 13 juillet 2026