Exécuter Codex ou un agent de codage dans un bac à sable sécurisé

Exécutez un agent de codage dans un bac à sable en lui donnant un espace de travail de dépôt délimité, un chemin d'exécution de terminal contrôlé, des permissions de fichier explicites, des polices de réeau et d'instalation de paquets, des secrets isolés, des journaux de commandes, des artéfacts, et un chemin d'appobation clair pour les modicications à haut risque avant la fusion ou le déploiement. Ce modèle fonctionne que l'agent soit de type Codex, connecté à un IDE, déclenché par CI, ou intégré dans votre propre plateforme développeur : le modèe peut planier et éditer, mais le bac à sable décde ce qu'il peut toucher, ce qu'il peut exécuter, ce qu'il peut récupérer, et quelles preuves un réviseur reçoit.

Qu'est-ce qu'un bac à sable d'agent de codage?

Un bac à sable d'agent de codage est un environnement d'exécution isolé dans lequel un système d'IA peut inspecter du code, modier des fichies, exécuter des commandes de terminal, installer des dépendances lorsque la politque le permet, lancer des tests, démarrer des serveurs de prévisualisation, et renvoyer un diff révisable sans avoir un accès large à la machine du développeur ou à l'environnement de production.

Le changement important est que le bac à sable n'est pas simplement un enveloppe de chat autour d'un modèe. C'est la frontière opérationnelle pour le travail. Le modèe propose des actions; le bac à sable enforce l'espace de travail, les outils, les permissions et la traçabilité.

Pour un simple assistant de codage, un checkout local et un copier-coller manuel peuvent sufre. Pour un agent qui peut exécuter des commandes ou continuer pendant de nombreuses étapes, vous avez besoins de frontières plus fortes:

• Un espace de travail dédié pour chaque tâche ou session.
• Un état de dépôt et une branche connus.
• Une interface d'exécution de commandes avec des approbations pour les opérations risquées.
• Une politique d'instalation de paquets pour npm, pip, cargo, apt, et outils similaires.
• Des règles de sortie réseau pour les registries, la documentation, les API, et l'accès aux prévisualisations.
• Des secrets étendus à la tâche et cachés des journaux dans la mesure du possible.
• Des stdout, stderr, codes de sortie, modicications de fichies, artéfacts générés, et URLs de prévisualisation capturés.
• Une porte de révision avant fusion, déploiement ou publication externe.

C'est pourquoi “exécuter Codex dans un bac à sable” doit être compris comme un modèle d'infrastructure, pas seulement une habitude locale de CLI. Codex CLI lui-même est documenté comme un agent de codage qui fonctionne à travers un workflow de terminal, et l'environnement d'exécution environnant devient le plan de contrôe lorsque vous l'opérez pour une équipe, un système CI ou un workflow produit. Le modèle d'agent Codex propriétaire de Novita rend maintenant ce modèle concret à l'intérieur de Novita Sandbox au lieu de le laisser comme une possibilité conceptuelle.

Architecture du bac à sable d'agent de codage

L'architecture la plus propre sépare la boucle du modèe de la frontière d'exécution:

Couche	Responsabilité	Questions à répondre
Interface agent	Transforme l'intention utilisateur en plans, éditions de fichies, appels d'outils et résumés de révision	Quel modèe ou agent de codage est utilisé? Comment les prompts, le contexte et les schémas d'outils sont-ils gérés?
Gestionnaire d'espace de travail	Crée le bac à sable, fait le checkout du dépôt, définit la branche et monte les fichies autorisés	Chaque tâche est-elle isolée? Le commit de base est-il connu? L'espace de travail peut-il être réinitialisé?
Exécuteur de terminal	Exécute les commandes approuvées et retourne les résultats à l'agent	Quelles commandes sont autorisées automatiquement, nécessitent une approbation ou sont bloquées?
Couche de politique	Contrôle la portée du systèmes de fichiers, les secrets, la sortie réseau, les instalations de paquets, les limites d'exécution et le nettoyage	L'agent peut-il récupérer des paquets? Peut-il appeler l'internet public? Peut-il lire des identifiants?
Couche de preuve	Stocke les journaux, les diffs, les résultats de tests, les prévisualisations et les artéfacts	Un réviseur peut-il reconstruire ce qui s'est passé sans faire confiance au résumé du modèe?
Porte de révision	Exige une étape humaine ou d'automation de confiance avant fusion, publication ou déploiement	Qui approuve les modifications à haut risque? Quels contrôles doivent d'abord passer?

En pratique, une plateforme unique peut combiner plusieurs de ces couches. L'architecture importe toujours car elle maintient les choix de produit honnêtes. Si un outil donne à un agent un terminal mais ne peut pas montrer les journaux de commandes, les diffs de fichies ou la politique de sortie, il peut être pratique pour le prototypage mais mince pour une révision en production.

Comment l'accès au terminal devrait-il fonctionner dans un bac à sable d'agent de codage?

Le terminal est l'endroit où un agent de codage devient opérationnellement utile et opérationnellement risqué. Il peut exécuter des tests, construire des actifs, inspecter des fichies générés, démarrer des serveurs locaux et diagnostiquer des échecs. Il peut également supprimer des fichies, fuiter des variables d'environnement, exécuter des scripts d'instalation inattendus ou consommer de grandes ressources de calcul.

Un bon modèe de terminal a trois parties.

Primo, définissez des classes de commandes. Les commandes de lecture seule et sûres comme ls, sed, rg, git diff, et les commandes de statut de test peuvent souvent s'exécuter automatiquement. Les commandes de construction et de test comme npm test, pytest, cargo test, et npm run build peuvent être autorisées avec des délais. Les commandes destructives ou à impact externe comme rm -rf, git push, gh pr merge, les CLI de déploiemnt, la publication de paquets, la prinie de données, la mutation de ressoures cloud devraient nécessiter une approbation explicite ou être complètement bloquées.

Deuxièmement, stramez les résultats avec structure. L'agent et le réviseur devraient voir la commande, le répertoire de travail, l'heure de début, le code de sortie, stdout, stderr, l'état de dépassement de délai et la politique de troncature de sortie. Une capture d'écran d'un terminal ne sut pas; le système devrait préserver des journaux lisibles par machine.

Troisièmement, gérez les sessions de longue durée délibérément. Les agents de codage ont souvent besoin d'un serveur de dev en arrière-plan, d'un watcher, d'un processus d'automatisation de navigateur ou d'une stack de test d'intégration. Traitez les processus de longue durée comme des ressoures avec des handles: démarrez-les, stramez les journaux, exposez seulement le port de prévisualisation requis, et arrêtez-les pendant le nettoyage. Ne laissez pas un processus d'arrière-plan devenir un effet secondaire non suivi d'une session de chat.

Isolation du dépôt et contrôle de branche pour les modifications des agents

L'état du dépôt est l'épine dorsale d'un workflow d'agent de codage révisable. L'agent ne devrait pas travailler dans un dossier ambigu avec des modifications locales inconnues à moins que l'utilisateur n'ait explicitement choisi ce mode.

Pour les workflows d'équipe, commencez chaque tâche à partir d'une URL de dépôt connue, d'une branche de base et d'un SHA de commit. Créez une branche de tâche ou un espace de travail détaché. Gardez les modifications utilisateur séparées des modifications d'agent, et capturez le diff exact avant révision. Si le bac à sable supporte des sessions persistantes, persistez l'espace de travail intentionnellement; ne comptez pas sur l'état accidentel du processus.

Le modèle par défaut ressemble à ceci:

1. Créez un espace de travail isolé pour tâche-123.
2. Faites le checkout du dépôt à main@<sha_de_base>.
3. Créez la branche agent/tâche-123.
4. Exécutez l'instalation des dépendances selon la politique.
5. Laissez l'agent inspecter, éditer, tester et itérer.
6. Capturez le diff git, la sortie des tests, les artéfacts générés et l'URL de prévisualisation.
7. Ouvrez une pull request ou remettez le patch à un réviseur humain.
8. Détruisez ou archivez l'espace de travail selon la politique de rétention.

Le détail clé est l'étape 6. Un agent de codage utile ne dit pas simplement “j'ai corrigé cela.” Il retourne les fichies modifiés, pourquoi chaque modification existe, quelle validation a été exécutée, ce qui a échoué et ce qui reste non vérifié.

Politique de commandes, de paquets et de réseau pour les agents de codage en bac à sable

Les installations de paquets sont l'une des parties les plus difciles du sandboxing d'agent de codage. De nombreuses tâches réelles nécessitent des dépendances. De nombreux incidents de chaîne d'approvisionnement commencent également par la récupération de dépendances, des scripts post-instalation ou des binaires opaques.

Une politique pratique n'est pas “n'installez jamais de paquets.” C'est “installez des paquets seulement via des chemins connus, avec journaux et portée.”

Contrôle	Implémentation pratique
Gestionnaires de paquets	Décidez quels gestionnaires de paquets sont disponibles par langage et type de dépôt.
Accès au registre	Autorisez les registres approuvés; bloquez les sources de paquets arbitraires lorsque la tâche ne les nécessite pas.
Fichiers de verrouillage	Préférez les fichiers de verrouillage existants et les commandes d'installation reproductibles.
Scripts post-instalation	Décidez si les scripts de cycle de vie peuvent s'exécuter automatiquement ou nécessitent une approbation.
Paquets système	Traitez les installations de paquets apt, brew et OS comme plus risquées que les installations de dépendances de projet.
Caches	Utilisez des caches de paquets contrôlés lorsque vous avez besoin de vitesse et de reproductibilité.
Journaux	Stockez les noms de paquets, versions, URLs de registre, sommes de contrôle lorsque disponibles, et la sortie install.

La politique réseau devrait être tout aussi explicite. Un agent de codage peut avoir besoin de lire la documentation publique, d'appeler une API de staging, de télécharger un paquet ou d'exposer une prévisualisation locale. Ceux-ci sont diférents d'un accès internet non restreint. Séparez les récupérations de paquets sortants, la navigation web, les appels API, la livraison de webhooks et l'accès entrant de prévisualisation. Si votre produit traite des données ou du code sensibles, demandez si le DNS, les journaux de proxy et les miroirs de registre sont couverts par la même politique que le trafic HTTP.

Secrets, journaux et pistes d'audit pour les espaces de travail des agents

Les secrets doivent être étendus à la plus petite surface utile. Un agent de codage n'a normalement pas besoin d'identifiants de production. Il peut avoir besoin d'un jeton Git en lecture seule, d'un jeton de registre de paquets, d'une clé API de staging ou d'un jeton de déploiement de prévisualisation. Chacun doit être étendu à la tâche, limité dans le temps si possible, et indisponible pour les commandes qui ne le nécessitent pas.

Évitez de placer des secrets dans des fichiers que l'agent peut lire sauf si la tâche le nécessite vraiment. Préférez un accès négocié: le bac à sable peut effectuer une opération, mais le modèle ne voit pas l'identifiant brut. Lorsque des variables d'environnement sont nécessaires, les journaux doivent masquer les motifs de secrets connus, et les artéfacts du réviseur ne doivent pas inclure de vidages complets de l'environnement.

Pour les pistes d'audit, stockez plus que le patch final:

• Demande utilisateur et métadonnées de tâche.
• URL du dépôt, commit de base, branche, et commit ou diff final.
• Commandes demandées, approuvées, bloquées et exécutées.
• Sorties de commandes, codes de sortie et délais d'attente.
• Lectures et écrutures de fichiers lorsque la plateforme peut les capturer.
• Enregistrements réseau et de récupération de paquets au niveau que votre politique supporte.
• URLs de prévisualisation et chemins d'artéfacts générés.
• Approbations humaines et décisions de fusion.

Ce n'est pas de la bureaucratie. C'est ainsi qu'un réviseur distingue un correctif réel d'une histoire plausible.

Diffs, prévisualisations et portes de révision avant fusion

Le résultat le plus utile d'un agent de codage est un ensemble de modifications révisables. Cela signifie que le bac à sable devrait produire les mêmes artéfacts qu'un ingénieur attentif attendrait d'une pull request:

• Un diff ciblé.
• Des tests ou des commandes de construction qui ont été exécutés.
• Les échecs qui persistent.
• Des captures d'écran, URLs de prévisualisation ou fichies téléchargeables lorsque l'interface utilisateur ou les actifs générés ont changé.
• Une brève explication du changement de comportement prévu.

Gardez la fusion ou le déploiement final derrière une porte contrôlée par l'humain, sauf si votre organisation a construit une politique d'automation de confiance distincte pour ce dépôt et ce niveau de risque exacts. La révision humaine est particulièrement importante lorsque les modifications touchent l'authentification, la facturation, l'accès aux données, les appels réseau, l'infrastructure, les versions de dépendances, les migrations générées ou le contenu visible par l'utilisateur.

La gestion des prévisualisations mérite sa propre règle: exposez seulement le service et le port nécessaires à la révision. Un bac à sable qui démarre une application web doit donner aux réviseurs une URL de prévisualisation étendue, pas un accès réseau large dans l'espace de travail.

Stratégie de nettoyage et de réinitialisation pour les sessions d'agent de longue durée

Chaque bac à sable a besoin d'un cycle de vie. Sans un, l'infrastructure d'agent de codage de longue durée devient un tas d'espaces de travail obsolètes, de journaux fuiteés et de processus encore en cours.

Pour les tâches courtes, un modèle éphémère fonctionne bien: créez un bac à sable, exécutez la tâche, extrayez les artéfacts, puis détruisez-le. Pour les tâches plus grandes, la persistence peut être précieuse: l'agent peut avoir besoin de marquer une pause, d'attendre une révision, de reprendre à partir de la même branche ou de garder un serveur de dev en cours pendant une session de révision. La persistence doit être une fonctionnalité produit explicite avec une date d'expiration, un propriétaire et des règles de rétention.

Définissez le nettoyage pour:

• Processus en arrière-plan et ports ouverts.
• Fichier temporaires et sorties de construction.
• Caches de paquets et archives téléchargées.
• Secrets étendus aux tâches.
• Journaux et artéfacts.
• Branches ou arbres de travail qui ont été remplacés.

La réinitialisation est tout aussi importante. Un réviseur doit pouvoir re-exécuter la validation de l'agent à partir du commit de base ou de la branche finale. Si le résultat ne fonctionne qu'à cause d'un état invisible dans une session de longue durée, le workflow est difficile à croire.

Où se situe Novita Agent Sandbox dans ce workflow

Novita Agent Sandbox est conçu pour l'infrastructure d'agents où l'exécution de code, l'automatisation de navigateur, les workflows de type “utilisation d'ordinateur”, l'analyse de données, les évaluations et les workflows d'agent plus longs ont besoin d'un environnement d'exécution isolé. La documentation de Novita Agent Sandbox décrit le produit comme un environement étatique pour exécuter des charges de travail d'agent, avec des chemins SDK et CLI pour travailler avec le cycle de vie du bac à sable, les fichies, les commandes, les sessions de navigateur et les primitives de workflow associés. Novita documente également maintenant un modèle d'agent Codex propriétaire, ce qui importe car cela transforme l'idée “exécuter Codex dans un bac à sable” en un workflow publié avec des détails de configuration concrets.

Pour les équipes qui utilisent déjà les API de modèes Novita AI, une couche de bac à sable peut réduire l'écart entre l'inférence du modèe et l'exécution d'action. Le modèe peut raisonner, appeler des outils et planifier des modifications de code; le bac à sable peut fournir l'espace de travail isolé où ces actions sont exécutées, journálisées, prévisualisées et révisées.

Ce que le modèle Codex propriétaire change en pratique

Le nouveau modèle Codex ne supprime pas le besoin de politique, mais il clarifie la manière dont un workflow Codex orienté production se map sur les contrôles décits plus tôt dans cet article.

• codex exec vous donne un mode d'exécution non interactif qui convient mieux aux tâches en file d'attente, aux orchestrateurs d'agent et à l'exécution de tâches révisables qu'une session terminal purement interactive.
• --full-auto n'a de sens que lorsque le bac à sable lui-même est la frontière d'approbation de confiance. En d'autres termes, l'approbation automatique est plus facile à justifier lorsque l'accès aux fichiers, la sortie réseau, la porte du dépôt et le nettoyage sont déjà contraints par l'exécution autour de Codex.
• --skip-git-repo-check est utile pour les tâches de bootstrap, mais le modèle plus fort pour le travail d'ingénierie réel est encore de cloner un dépôt spécique dans le bac à sable et d'exécuter Codex à partir de ce checkout contrôlé.
• Écrire ~/.codex/auth.json et ~/.codex/config.toml à l'intérieur du bac à sable rend la personnalisation du fournisseur et du modèle partie de l'environnement isolé, plutôt que quelque chose d'emprunté à un ordinateur portable développeur.
• sandbox.git.clone s'intègre naturellement avec l'isolation du dépôt et le contrôle de branche: extrayez seulement le dépôt dont la tâche a besoin, exécutez l'agent dans ce répertoire étendu, et gardez la machine hôte hors du circuit.
• La reprise de session via --json, thread_id capturé, et codex exec resume <thread_id> est un moyen pratique de gérer un travail de longue durée sans prétendre que la peristence et l'auditabilité sont la même chose. Vous avez toujours besoins de règles explicites de rétention, de capture de journaux et de propriété pour les sessions reprises.

C'est la séparation utile entre la documentation et les conseils du blog. La documentation montre la séquence opérationnelle. La décision de workflow est de traiter ces mécaniques comme des preuves pour un modèle plus sûr: exécutez Codex dans un espace de travail borné, gardez l'approbation automatique limitée aux bacs à sable de confiance, préservez intentionnellement l'état du dépôt, et rendez les sessions reprises visibles aux réviseurs plutôt qu'à une mémoire d'agent opaque.

Utilisez des frontières de produit conservatrices lors de la conception de votre workflow:

• Traitez Novita Agent Sandbox comme l'environnement d'exécution, pas une garantie de sécurité générale.
• Gardez les secrets, les installations de paquets, la sortie et les actions de publication derrière votre propre politique.
• Validez les détails actuels du SDK, CLI, tarifs et limites de compte à partir de la documentation Novita avant de les coder en dur dans l'automatisation de production.
• Évaluez les frontières d'isolation, la compatibilité avec des agents tiers et les exigences de conformité par rapport à votre propre politique avant de vous fier à un bac à sable en production.

Cette séparation maintient les conseils d'implémentation utiles même lorsque la couche d'agent change. Vous pouvez utiliser des agents de style Codex, des agents de codage internes, des agents de navigateur ou des tâches d'évaluation tout en gardant les mêmes questions de contrôle de bac à sable.

Liste de vérification de mise en œuvre du bac à sable d'agent de codage

Utilisez cette liste de vérification avant de passer un bac à sable d'agent de codage au-delà d'un prototyp.

Domaine	Question minimale de production
Espace de travail	Chaque tâche a-t-elle un systèmes de fichier étendu et un comit de base de dépôt connu?
Branche	Les modicications de l'agent sont-elles isolées sur une branche ou un patch que les réviseurs peuvent inspecter?
Terminal	Les commandes sont-elles journálisées avec le répertoire de travail, la sortie, le code de sortie et le délai?
Approbation	Quelles commandes s'exécutent automatiquement, nécessitent une approbation ou sont bloquées?
Paquets	Les installations de dépendances sont-elles reproductibles et journálisées?
Réseau	La sortie est-elle séparée entre les récupérations de paquets, la navigation dans la documenation, les appels API et l'accès aux prévisualisations?
Secrets	Les identifiants sont-ils étendus à la tâche et masqués dans les journaux?
Prévisualisations	Les ports de prévisualisation sont-ils explicites et faciles à arrêter?
Artéfacts	Les fichies générés, captures d'écran, rapports et journaux sont-ils attachés à la révision?
Persistance	La pause/reprise de session est-elle intentionell, avec propriétaire et expiration?
Nettoyage	Les processus, ports, fichies temporaires, secrets et espaces de travail obsolètes sont-ils supprimés?
Révision	Un humain approuve-t-il la fusion, la publication ou le déploiemnt pour les modicications risquées?

Si votre configuration actuelle ne peut pas répondre à plusieurs de ces questions, gardez le workflow dans une voie de prototype. L'agent peut encore être utile, mais il ne devrait pas recevoir un accès large au dépôt, au réseau ou aux identifiants.

FAQ

Puis-je exécuter Codex lui-même à l'intérieur d'un bac à sable cloud?

Oui. Novita documente maintenant un modèle d'agent Codex propriétaire pour Novita Sandbox, avec un flux publié pour exécuter codex exec dans un environnement isolé, cloner des dépôts dans le bac à sable, personnaliser les paramètres du fournisseur Codex à l'intérieur de ~/.codex/, et reprendre des sessions précédentes avec un thread_id capturé. La prudence s'applique toujours au niveau du compte et de la configuration: validez le chemin d'authentification exact, les identifiants du dépôt, les limites d'exécution et les contrôles de politique pour votre propre environnement au lieu de supposer que chaque workflow local Codex se transfère sans changement.

Est-ce que Docker sut pour un bac à sable d'agent de codage?

Docker peut être utile pour le développement local, les tâches CI et les environnements reproductibles, mais “sut” dépend de votre modèle de menaces. Demandez ce qui partage un noyau, quels montages de fichiers existent, comment la sortie réseau est contrôlée, si les secrets sont exposés au conteneur, et comment les évasions ou les compromissions de dépendances seraient gérées. Pour les charges de travail sensibles, les équipes de sécurité évaluent souvent des frontières d'isolation plus fortes et des contrôles de sortie plus stricts.

Un agent de codage devrait-il avoir un accès internet?

Seulement lorsque la tâche en a besoin, et seulement à travers une politique que vous pouvez expliquer. La consultation de documentation, l'accès aux registres de paquets, les appels API de staging et la navigation arbitraire sont des autorisations diférentes. Journalisez ce que l'agent a récupéré, gardez les instalations de paquets reproductibles, et évitez de donner un accès réseau de production à une session de codage généraliste.

Que doit examiner un réviseur avant de fusionner du code généré par agent?

Examiner le diff, les commandes qui ont été exécutées, la sortie des tests/construction, les modifications de dépendances, les artéfacts générés, le comportement de prévisualisation et toute validation sautée. Portez une attention particulière à l'authentification, aux permissions, à la gestion des données, aux appels réseau, aux migrations, aux scripts d'installation et aux secrets.

Comment Novita aide-t-elle avec les bacs à sable d'agent de codage?

Novita Agent Sandbox fournit un environnement d'exécution d'agent isolé pour des charges de travail telles que l'exécution de code, l'automatisation de navigateur, les tâches de type “utilisation d'ordinateur”, l'analyse de données, les évaluations et les workflows de plus longue durée. Avec le modèle Codex propriétaire, cet environnement d'exécution peut également héberger des flux spécifiques à Codex tels que l'exécution non interactive, les checkouts étendus au dépôt, la configuration personnalisée du fournisseur et la reprise de session. Assortissez ces mécaniques à des politiques explicites de dépôt, de commande, de paquet, de réseau, de secrets et de révision afin que le bac à sable reste la frontière d'exécution au lieu de devenir un raccourci non surveillé autour de vos contrôles d'ingénierie normaux.

Articles recommandés

• AI-Generated Code Sandbox Requirements for Production Apps
• Run Claude Code or Managed Agents in an Isolated Sandbox
• MCP Servers in Isolated Sandboxes: Filesystem, Secrets, and Network Tradeoffs