Vue d’ensemble des sandboxes

Les sandboxes sont la colonne vertébrale d’exécution de CodeCourier. Chaque fois qu’un agent de codage IA exécute une tâche, écrit du code ou lance une commande, il le fait à l’intérieur d’une sandbox - une machine virtuelle Linux cloud isolée et éphémère, propulsée par E2B. Cette architecture garantit que l’activité de l’agent est entièrement confinée, reproductible et sécurisée, sans aucun risque pour votre machine locale ou votre infrastructure de production.

Qu’est-ce qu’une sandbox ?

Une sandbox dans CodeCourier est un environnement Linux complet qui s’exécute dans le cloud. Chaque sandbox dispose d’un système de fichiers complet, d’un accès réseau, de capacités d’exécution de processus et d’outils de développement préinstallés. En coulisses, CodeCourier utilise le SDK E2B pour provisionner ces environnements à la demande. Lorsque vous lancez une sandbox, E2B crée une machine virtuelle légère à partir d’un template, y injecte votre configuration (clés API, system prompts, skills, learnings) et confie le contrôle à l’agent de codage IA que vous avez choisi.

Les sandboxes ne sont pas des conteneurs - ce sont de véritables micro-VM avec leur propre noyau, offrant des garanties d’isolation plus fortes que Docker. Cela signifie qu’un agent IA s’exécutant dans une sandbox ne peut pas affecter les autres sandboxes, votre système hôte ni l’environnement d’un autre utilisateur.

Pourquoi les sandboxes sont importantes

Exécuter des agents de codage IA sur votre machine locale présente de réels risques. Un agent disposant d’un accès au système de fichiers peut écraser des fichiers, installer des paquets malveillants ou accéder aux secrets stockés dans votre environnement. En exécutant chaque tâche d’agent à l’intérieur d’une sandbox, CodeCourier élimine entièrement ces risques.

• Sécurité - Chaque sandbox est une micro-VM isolée. Les agents ne peuvent pas s’échapper vers l’hôte, accéder aux autres sandboxes ni lire des fichiers en dehors de leur environnement.
• Reproductibilité - Les sandboxes démarrent depuis un état de template connu. Chaque run commence avec le même environnement de base, rendant les résultats déterministes et débogables.
• Contrôle des ressources - Vous configurez le CPU, la mémoire et le timeout de chaque sandbox. Si un agent s’exécute trop longtemps ou consomme trop de mémoire, la sandbox est arrêtée automatiquement.
• Exécution parallèle - Plusieurs sandboxes peuvent s’exécuter simultanément, chacune travaillant sur une tâche différente. Les étapes de workflow, les sessions d’issue et les sandboxes autonomes fonctionnent toutes de manière indépendante.

Architecture

L’architecture des sandboxes dans CodeCourier comporte trois couches :

Infrastructure E2B

E2B fournit l’infrastructure des machines virtuelles. Lorsque CodeCourier demande une sandbox, E2B provisionne une micro-VM à partir d’un template (par exemple, le template claude pour les sandboxes Claude Code ou le template opencode pour OpenCode). La VM provisionnée inclut un environnement Linux de base avec Node.js, Python, Git et les outils de développement courants préinstallés.

Orchestration Trigger.dev

Les opérations de sandbox de longue durée sont gérées par les tâches de fond Trigger.dev. Lorsqu’un workflow run démarre, Trigger.dev crée la sandbox E2B, exécute les scripts de setup (Git clone, installation des dépendances, injection de configuration), lance la commande de l’agent IA, streame la sortie vers la base de données et gère le nettoyage à la fin ou en cas d’échec.

Base de données Convex

Chaque sandbox possède un enregistrement correspondant dans la base de données Convex qui suit son état. La base de données stocke le statut de la sandbox (creating, running, paused, killed ou error), sa configuration (template, timeout, CPU, mémoire), ses relations avec les runs et workflows, ainsi que des métadonnées comme les URLs de PR, les noms de branche et le statut d’extraction des learnings. Comme Convex est réactif, l’interface du dashboard se met à jour en temps réel lorsque l’état de la sandbox change.

Types de sandboxes

Les sandboxes dans CodeCourier sont créées dans différents contextes, chacun avec des caractéristiques de cycle de vie légèrement différentes :

Sandboxes autonomes

Créées directement depuis la page Sandboxes. Ce sont des environnements interactifs où vous pouvez envoyer des messages à l’agent IA, visualiser la sortie de terminal en streaming et gérer manuellement le cycle de vie de la sandbox. Les sandboxes autonomes sont idéales pour les tâches ad hoc, le débogage et l’exploration.

Sandboxes de workflow run

Créées automatiquement lorsqu’un workflow run s’exécute. Chaque étape du pipeline (designer, checker, optimizer) obtient sa propre sandbox. Ces sandboxes sont gérées par l’orchestrateur de workflow - vous les surveillez généralement via la vue détaillée du run plutôt que via la page Sandboxes.

Sandboxes de session d’issue

Créées pendant les sessions d’issue. Une sandbox de session d’issue exécute un agent IA qui analyse votre repository, explore la codebase et identifie les problèmes ainsi que les améliorations. Les sandboxes de session d’issue fonctionnent indépendamment des workflows.

Sandboxes de session d’issue

Créées pendant les sessions d’analyse d’issue. Ces sandboxes exécutent un agent IA qui passe en revue votre repository GitHub, identifie les issues et améliorations, et produit des cartes d’issue structurées avec des prompts suggérés.

Configuration de la sandbox

Chaque sandbox est créée avec un objet de configuration qui contrôle ses ressources et son comportement :

• Template ID - Quel template E2B utiliser (par exemple, claude, opencode, codex, pi). Détermine l’outil CLI préinstallé et l’environnement de base.
• Timeout - Durée d’exécution maximale, de 1 minute à 4 heures (60 000 à 14 400 000 millisecondes). Si la sandbox dépasse ce timeout, elle est arrêtée automatiquement.
• Mémoire - Allocation de RAM en Mo, entre 256 Mo et 8 192 Mo. Une mémoire plus élevée est nécessaire pour les grandes codebases et les compilations lourdes.
• CPU - Nombre de CPU, entre 1 et 8. Plus de CPU aident aux builds parallèles et à l’exécution des tests.
• Modèle designer - Le modèle IA à utiliser pour les étapes designer (par exemple, claude-opus-4-6, claude-sonnet-4-6).
• Modèle checker - Le modèle IA à utiliser pour les étapes checker (peut différer du modèle designer).
• Thinking effort - Réglages de thinking effort par modèle (par exemple, high, medium, low).

Relation avec les autres fonctionnalités

Les sandboxes sont connectées à presque toutes les fonctionnalités de CodeCourier :

• Workflows utilisent les sandboxes pour exécuter chaque étape.
• Personas définissent la configuration de l’agent injectée dans les sandboxes pendant les workflow runs.
• Sessions d’issue s’exécutent à l’intérieur de sandboxes dédiées.
• Learnings sont extraits de l’historique de messages de la sandbox après l’achèvement.
• Pull requests sont créées à partir de l’état de la branche de la sandbox lorsqu’une sandbox termine son travail.
• Suivi d’usage enregistre le coût de chaque session de sandbox (compute E2B, usage des tokens IA).