Sessions

Une session est une branche Git et un environnement isolé dans lequel l’agent travaille.

Une session est une unité de travail de l’agent. Beeuni crée une branche Git et lui provisionne un environnement isolé. L’identifiant de session, le nom de la branche et l’identifiant de l’environnement isolé sont identiques.

État

En pratique, une session passe par l’un de 4 états.

La base de données définit 3 autres valeurs (queued, branching, completed). Beeuni ne les attribue pas aux sessions pour le moment.

Arrêt, reprise et arrêt automatique en cas d’inactivité

Vous pouvez arrêter une session vous-même. La reprise réactive le même environnement isolé, avec le même système de fichiers et la même identité d’exécution. Seuls les processus en cours et la mémoire sont réinitialisés. La conversation harness standard reste associée à la session.

Beeuni arrête également automatiquement les sessions inactives :

• Après 15 minutes d’inactivité pour une session normale ou une exécution déclenchée.
• Après 2 minutes d’inactivité pour une session de travail démarrée par une autre session.

Un tour d’agent en cours empêche l’arrêt. La tâche de maintenance s’exécute toutes les 5 minutes. Un arrêt automatique normal survient donc environ 15 à 20 minutes après la fin du tour dans le terminal.

Un tour qui attend une personne n’effectue aucun travail : l’agent a posé une question ou demande l’autorisation d’utiliser un outil. Après que Beeuni a détecté l’attente pour la première fois, ce tour conserve l’ordinateur pendant 2 heures maximum. Lors d’une exécution déclenchée ou planifiée, personne ne reçoit la demande et la limite est de 30 minutes. Beeuni met alors fin au tour et arrête l’ordinateur. Envoyez un message pour continuer. Un appel au modèle ou une page de session ouverte compte comme une activité et prolonge l’utilisation de l’ordinateur comme d’habitude.

Une page de session que vous utilisez maintient la session active. Elle est considérée comme utilisée si l’onglet est visible et que vous avez cliqué, saisi du texte, fait défiler ou interagi avec la page au cours des 10 dernières minutes, et uniquement si vous êtes autorisé à démarrer des sessions dans le projet. Un onglet laissé ouvert sans interaction cesse d’être pris en compte après 10 minutes ; la session s’arrête donc environ 15 à 20 minutes plus tard. L’onglet ouvert d’un lecteur en lecture seule ne maintient jamais la session active. La page utilisée seule maintient une session active pendant 2 heures maximum après le dernier tour de l’agent ; un nouveau message démarre un tour et réinitialise cette limite.

Ce que l’arrêt et la suppression préservent

L’arrêt et la reprise préservent l’identité et le système de fichiers de l’environnement isolé. La suppression détruit l’environnement isolé. Git est le seul enregistrement durable : le travail validé et envoyé par l’agent est conservé ; tout le reste est perdu.

Libellés

Un libellé catégorise une session : bug, customer: eu, worker. Ouvrez le menu ⋯ d’une session et choisissez Edit labels. Le filtre Labels dans la liste des sessions affiche uniquement les sessions portant tous les libellés sélectionnés. Les libellés sont libres, de 1 à 64 caractères, et limités à 20 par session.

Les agents et les scripts peuvent aussi définir des libellés : beeuni sessions new --label worker, beeuni sessions update --label needs-review (dans une session, sans identifiant, le libellé est appliqué à cette session), ou labels dans l’API et le SDK. Une session comporte également un objet libre metadata pour vos propres clés — consultez SDK sessions.

Environnement d’exécution

Une session utilise un seul harnais, harness standard ou harness expérimental. Consultez Harnais. Beeuni enregistre l’agent et le modèle sélectionnés au démarrage de la session. Une session en cours conserve son harnais jusqu’à son redémarrage ou sa reprise.

Accès aux sessions

Une session est privée et accessible uniquement à la personne qui l’a créée. Le propriétaire ouvre Session access et choisit l’une des 3 options.

Toute personne ayant accès peut lire la conversation et la poursuivre.

Une session partagée utilise les clés partagées. Une fois partagée, une session utilise uniquement les clés de fournisseur partagées avec l’ensemble du projet, jamais les clés personnelles d’un utilisateur ni sa connexion ChatGPT. Si son modèle utilisait vos propres clés, le partage le fait basculer vers les clés du projet pour ce fournisseur. Si aucune clé partagée du projet ne permet d’exécuter le modèle, le partage est refusé et la session reste privée. Consultez Clés de fournisseur et accès des membres.

Seul le propriétaire peut modifier ces paramètres. Un responsable de projet qui n’a pas créé la session peut l’ouvrir si elle est partagée avec lui, et peut l’arrêter, la redémarrer ou la supprimer. Il ne peut pas modifier la liste des personnes autorisées à l’ouvrir. Partager une session avec un responsable ne lui transfère pas sa liste d’accès.

Un type de session n’a pas de propriétaire humain : celles créées par un déclencheur, qui s’exécutent sous l’identité de l’agent du déclencheur. Elles sont gérées par les responsables de projet. Définissez la politique pour toutes ces sessions sur le déclencheur lui-même, sous Session access — l’enregistrement met également à jour les sessions déjà créées par ce déclencheur.

Les administrateurs peuvent ouvrir toutes les sessions

Le propriétaire d’un compte peut autoriser les propriétaires de compte et les administrateurs à ouvrir toutes les sessions du compte, y compris celles que les membres gardent privées. Activez cette option sous Account → Settings → Security → Admins can open every session. Elle est désactivée par défaut.

• Seul un propriétaire de compte peut modifier ce paramètre. Un administrateur voit l’interrupteur, mais ne peut pas l’actionner. Aucun administrateur ne peut donc s’accorder l’accès au travail de tout le monde.
• Les administrateurs trouvent ces sessions sur la page Sessions du projet. La barre latérale ne répertorie toujours que les sessions que vous avez démarrées ou qui sont partagées avec vous.
• L’accès est complet. Un administrateur peut ouvrir et lire la session, puis la poursuivre, comme pour une session partagée avec l’ensemble du projet.
• Les membres en sont informés. Tant que l’option est activée, la boîte de dialogue Session access indique que les propriétaires et les administrateurs peuvent ouvrir toutes les sessions.
• Toutes les actions sont consignées. Chaque activation ou désactivation est enregistrée sous la forme iam.session_oversight.enable ou iam.session_oversight.disable, et chaque session ouverte par un administrateur grâce à cette option sous la forme project.admin_oversight_session_read (au plus une fois par administrateur et par session toutes les heures).
• Les jetons d’agent et d’environnement isolé n’obtiennent jamais cet accès, même si un administrateur les a lancés.

Trouver une session par propriétaire ou par accès

La page Sessions du projet affiche le propriétaire et l’accès de chaque session sur sa ligne : l’avatar et le nom du propriétaire (You pour vos propres sessions), puis une icône indiquant qui peut l’ouvrir : un cadenas pour Only the owner, des personnes pour Specific people, un globe pour Whole project.

Ouvrez Filter sur la page Sessions pour affiner la liste :

• Owner — une entrée par personne, avec un nombre.
• Access — Only the owner, Specific people ou Whole project.
• Grouping → Owner — une section par personne, la vôtre en premier.

Les filtres se combinent avec Status, Source et la recherche. Reset les efface tous.

Partager un aperçu

Vous pouvez partager l’aperçu en direct d’une session à l’aide d’un lien public, en mode consultation seule ou interactif. Seul le propriétaire de la session peut créer ce lien, pour la même raison : il ne nécessite aucune authentification, donc toute personne disposant de l’URL peut lire la session sans se connecter. Un responsable de projet peut répertorier et révoquer les liens d’une session sans en être propriétaire — la révocation ne fait que supprimer l’accès.

Pour consulter l’énumération complète des états, les variables d’environnement injectées et les points de terminaison du démon, consultez Environnement d’exécution. Pour savoir comment une session choisit son agent, consultez Agents. Pour les sessions démarrées par une planification ou un webhook, consultez Déclencheurs. Pour intégrer le travail d’une session à la branche par défaut, consultez Demandes de modification.