Sessions

Une session correspond à une exécution de l’agent Vibe Code sur un projet : un environnement isolé créé pour la tâche, la boucle d’agent qui effectue le travail, et la branche ou pull request générée à la fin. Cette page explique comment les sessions démarrent, ce qui se passe à l’intérieur et ce qui est conservé une fois terminées.

Démarrage des sessions

Démarrage des sessions

Une session peut débuter par l’un des trois points d’entrée suivants :

  • Depuis l’interface web : cliquez sur Nouvelle session dans un projet. Voir le guide de démarrage / Web.
  • Depuis le Vibe CLI : précédez un prompt de & pour l’envoyer vers une session cloud. Voir le guide de démarrage / CLI.
  • En téléportant une session CLI active : lancez /teleport dans la session locale active. La même session se poursuit alors dans le cloud, avec l’historique et l’état de la branche conservés.
Astuce

Teleport est la solution la plus propre pour quitter une session locale devenue trop longue pour votre machine. La sandbox cloud prend le relais avec le même historique et la même branche. Voir Téléportation du CLI vers le web.

Une fois la session créée, son cycle de vie reste identique quel que soit le point d’entrée.

Création de la sandbox

Création de la sandbox

Lorsqu’une session est initiée, Vibe Code Web crée un sandbox cloud isolée pour cet usage. Cet environnement est dédié à la session : aucun élément d’autres sessions ou d’autres utilisateurs n’y sera exécuté.

La sandbox dispose :

  • d’un shell restreint ;
  • d’un accès aux dépôts GitHub sélectionnés (lecture et écriture, via votre token d’accès utilisateur) ;
  • d’une politique d’accès sortant réseau. Voir Environnement sandbox.

La sandbox est supprimée à la fin de la session.

Note

Cette section décrit la sandbox du point de vue de la session. Pour connaître les composants en fonctionnement et leur comportement, voir Environnement sandbox.

Clonage des dépôts

Clonage des dépôts

L’agent clone les dépôts sélectionnés pour le projet, sur la branche choisie lors de la création de la session. Un projet peut inclure un ou plusieurs dépôts issus d’un même propriétaire GitHub. Le clonage utilise le token d’accès utilisateur de l’application GitHub Mistral : toutes les opérations Git (commit, branche, push) sont ainsi attribuées à votre compte.

Boucle de l’agent

Boucle de l’agent

À l’intérieur de la sandbox, l’agent exécute une boucle :

  1. Lit les fichiers liés à votre prompt.
  2. Planifie l’action suivante.
  3. Modifie le code ou exécute une commande (shell, tests, build).
  4. Rend compte dans la vue de la session (commandes, fichiers modifiés, résultats intermédiaires).
  5. Demande des précisions si nécessaire, puis attend votre réponse.
Schéma du déroulement de la boucle agent Vibe Code, en cinq étapes (Lire, Planifier, Agir, Rapporter, Demander) reliées dans une boucle vers Lire
i
Information

La boucle se poursuit jusqu’à ce qu’une limite soit atteinte, que la tâche soit naturellement terminée, ou que l’agent ait besoin d’une réponse. Voir Limites et cycle de vie pour plus de détails.

Ce qui s’affiche pendant une session

Ce qui s’affiche pendant une session

La vue de session présente :

ÉlémentDescription
Flux d’activitéCommandes exécutées par l’agent, avec les résultats, dans l’ordre chronologique.
Modifications de fichiersListe des fichiers modifiés pendant la session.
État de la brancheBranche sur laquelle l’agent effectue ses commits.
Pull requestUne fois ouverte par l’agent, un lien direct vers la pull request GitHub.
Champ d’entréePour répondre aux questions ou envoyer un nouveau prompt.

Le flux d’activité sert de journal d’audit : chaque commande ou modification de fichier est visible tant que la session reste active.

Astuce

Vibe Code Web permet de suivre les progrès de la session et d’ouvrir la branche ou la pull request produite. L’examen du code, les commentaires, les vérifications requises et la fusion se font dans GitHub.

Résultat : branche et pull request

Résultat : branche et pull request

À la fin de la session, le résultat est matérialisé par :

  • Une branche sur le dépôt cible, avec les commits de l’agent ;
  • Une pull request ouverte contre la branche de base, avec un descriptif du travail effectué.

C’est à vous de relire, compléter, fusionner ou refermer la pull request selon votre workflow habituel GitHub. Les protections de branches, relectures requises, règles CODEOWNERS et vérifications de statut s’appliquent normalement.

Itération après une pull request

Itération après une pull request

La création de la pull request ne clôt pas automatiquement la session. Tant que la session et la sandbox restent actifs, vous pouvez envoyer des instructions complémentaires :

  • Saisir un nouveau prompt dans la vue de session ;
  • Coller un commentaire de relecteur et demander à l’agent d’y répondre ;
  • Coller le résultat d’un CI en échec et demander une correction à l’agent.

L’agent réutilise le même sandbox et la même branche : le contexte de la session est donc préservé d’une itération à l’autre.

Avertissement

Une fois la sandbox supprimée, la session ne peut pas être reprise. Pour continuer, ouvrez une nouvelle session.