npm install ne fonctionne pas dans Codex CLI : le sandbox

Mon premier problème après l’installation n’a pas été une demande d’approbation. C’est npm install qui ne fonctionnait pas dans Codex CLI.

Les fichiers étaient modifiés normalement, mais l’installation des dépendances restait bloquée. Pendant un bon moment, j’ai cru à un problème de npm lui-même.

Je commence par la conclusion. Forcer avec sudo n’est pas la solution.

Ensuite, l’approbation et le sandbox sont deux axes complètement différents. Sans les distinguer, la même confusion revient sans cesse : « Je l’ai pourtant autorisé, pourquoi ça ne passe pas ? »

Pourquoi npm install ne fonctionne pas dans Codex CLI avec workspace-write ?

Le mode workspace-write autorise l’écriture de fichiers, mais l’accès réseau dépend d’un réglage séparé. Une commande qui a besoin du réseau, comme npm install, peut donc être bloquée alors que les modifications passent.

Au début, j’ai simplement pensé que npm faisait des siennes. Les fichiers de code, eux, continuaient d’être modifiés sans problème.

Une fois Codex CLI installé, je l’ai lancé sur un vrai travail. Les modifications de code passaient bien.

Seule l’étape d’installation des dépendances bloquait, à plusieurs reprises.

Pendant un temps, j’ai soupçonné la configuration de npm. La vraie cause était la condition d’accès réseau du sandbox.

Depuis, je traite « puis-je écrire des fichiers ? » et « puis-je utiliser le réseau ? » comme deux permissions totalement distinctes.

Selon la documentation officielle, workspace-write traite l’écriture sur le système de fichiers et l’accès réseau comme deux limites différentes (Documentation OpenAI : Sandbox).

Je n’ai toutefois pas pu confirmer dans la documentation le nom exact de la clé de configuration. Ici, je dis donc seulement que l’accès réseau dépend d’un réglage séparé.

Faut-il utiliser sudo quand npm install -g renvoie EACCES ?

Dans mon cas, non : avec sudo, le paquet s’installe sur le moment, mais les permissions s’emmêlent davantage ensuite. Ce qui a marché, c’est de remettre de l’ordre dans le chemin de Node, puis de réinstaller dans un environnement Node côté utilisateur.

Ce problème EACCES était distinct, survenu au tout début de l’installation.

Sur la même machine cohabitaient le Node du système et un gestionnaire de versions de Node installé à part. En installant un paquet npm global, je suis tombé sur un problème de permissions.

Mon premier réflexe a été sudo npm install -g .... Je me suis arrêté là, parce que j’avais déjà vu ce qui se passe quand on force avec sudo.

Une fois le chemin de Node remis en ordre et l’installation refaite, le problème a disparu.

Ce que j’ai retenu de ces tâtonnements : un EACCES ne doit pas mener automatiquement à sudo.

Approbation et sandbox dans Codex CLI : quelle différence ?

L’option approval_policy décide quand demander à une personne, et sandbox_mode décide jusqu’où l’agent peut exécuter sans demander. Ce sont deux axes indépendants : une approbation permissive ne lève donc pas les limites du sandbox.

Au début, cette distinction n’était pas claire pour moi.

Pourquoi j’ai pris never pour « tout autoriser »

Quand j’ai vu approval_policy = "never", ma première pensée a été simple : « Désormais, tout sera autorisé automatiquement. »

Ce n’était pas le cas. Même avec never, les actions hors du sandbox restaient limitées.

Selon la documentation officielle, --ask-for-approval never est conçu pour fonctionner avec tous les modes --sandbox.

La documentation précise aussi que les limites du sandbox restent en place, quel que soit le réglage d’approbation (Documentation OpenAI : Agent approvals & security).

Points d’attention en septembre 2026

Ce que je raconte ici a été vérifié en septembre 2026. Les noms d’options et les valeurs de configuration de Codex CLI ont changé d’une version à l’autre.

Des options copiées d’un ancien tutoriel peuvent donc ne plus correspondre à la dernière version.

Par exemple, la valeur approval_policy = "untrusted" a été retirée par une PR fusionnée en août 2026. Depuis la 0.149.0, un fichier de configuration qui contient encore cette valeur empêche Codex de démarrer, avec une erreur (openai/codex PR #39630).

Aujourd’hui, la documentation officielle indique trois valeurs pour approval_policy : on-request, never et granular (contrôle détaillé). Je n’ai pas pu confirmer la valeur « unless-trusted », souvent citée.

Chaque fois que je retouche config.toml, il me semble donc plus sûr de rouvrir l’aide de la CLI et la référence officielle de configuration.

workspace-write ou danger-full-access : combien de temps font perdre les approbations ?

Sur 5 répétitions de la même refactorisation, workspace-write + on-request a pris 14 à 16 minutes, et danger-full-access en environnement isolé 11 à 13 minutes. C’est une mesure personnelle, pas un chiffre de performance général.

Tout a tourné sur un dépôt personnel/POC, sous macOS avec Apple Silicon. Je n’ai changé que deux conditions.

D’où venaient les 2 à 4 approbations ?

Avec workspace-write + on-request, chaque exécution demandait en général 2 à 4 interventions de permission. Les modifications de fichiers dans le workspace et les tests ordinaires avançaient presque sans pause.

La plupart du temps, les pauses arrivaient à des moments similaires : quand il fallait un accès réseau ou un fichier hors du workspace.

14–16 min contre 11–13 min, et pourquoi je ne généralise pas

Avec danger-full-access dans un environnement isolé, le temps passé à attendre les approbations disparaît presque (voir le tableau).

Je ne vais pas en tirer un chiffre général du type « danger-full-access est 20 % plus rapide ». L’écart réel dépendait beaucoup de la quantité d’accès hors sandbox que la tâche demandait.

Je n’ai pas non plus mesuré avec des horodatages précis. Ce ne sont que cinq répétitions personnelles.

Dans quels environnements réserver danger-full-access ?

Mon critère : seulement dans des environnements entièrement jetables, comme Docker, une VM jetable ou un worktree séparé. Le mode read-only, le plus prudent, bloque l’écriture elle-même ; il reste donc hors de cette comparaison.

Selon la documentation officielle, danger-full-access est un mode qui supprime complètement les limites du système de fichiers et du réseau (Documentation OpenAI : Sandbox).

Dans la documentation, l’option --dangerously-bypass-approvals-and-sandbox (alias --yolo) n’est pas présentée comme « EXTREMELY DANGEROUS ».

Son libellé est [Elevated Risk] No sandbox; no approvals (not recommended), avec un avertissement invitant à l’utiliser avec prudence (Documentation OpenAI : Agent approvals & security).

Les options --sandbox/-s et --profile figurent dans la documentation. Pour --worktree et --approve-for-me, je n’ai pas trouvé d’appui dans ce que j’ai vérifié cette fois ; je n’en parle donc pas ici.

Dépôt personnel, POC en entreprise, expériences d’automatisation

En pratique, je distingue trois environnements. Dans le dépôt personnel, j’utilise workspace-write + on-request sur l’hôte macOS.

Pour la POC en entreprise, je reste surtout en workspace-write, dans un dépôt de développement. L’accès aux identifiants et à la production reste complètement séparé, dans d’autres outils et environnements.

Seules les expériences d’automatisation à faible risque obtiennent des permissions plus larges, dans Docker ou un worktree jetable.

Par défaut, c’est toujours workspace-write.

Le critère n’est pas la vitesse. La question est : « Si cet agent exécute quelque chose de travers, est-ce acceptable que l’effet sorte du workspace ? »

Dans la plupart des cas, la réponse est non. Sur l’hôte, dans mes dépôts de développement habituels, je ne mets pas d’option de bypass par défaut juste parce que c’est pratique.

Peu de profils, volontairement

Je ne crée pas trop de profils. Je garde une configuration par défaut prudente et, à côté, en général un seul profil séparé : celui des environnements isolés.

Codex CLI ou Antigravity CLI : lequel a demandé le moins d’approbations ?

Dans ma comparaison personnelle, Codex en workspace-write + on-request m’a paru demander moins d’interventions qu’Antigravity CLI (cela peut varier selon l’outil et le moment). Sur la même tâche, Antigravity avait pris environ 18 minutes en mode approbation et environ 12 en mode automatique.

Par rapport à mes essais avec Antigravity, j’ai eu relativement moins l’impression de devoir approuver une à une jusqu’aux commandes normales du workspace.

Pour un usage quotidien d’agent de programmation, cette combinaison était plus confortable.

Dans les deux cas, j’ai jugé selon le même critère : le blast radius (jusqu’où les dégâts peuvent aller) et la réversibilité.

Une chose n’a pas changé : sans distinguer sandbox et approbation, la confusion est la même avec n’importe quel outil.

Dans cet article, je n’entre pas dans le détail de la combinaison Codex qui correspond exactement au --dangerously-skip-permissions de Claude Code.

Pour moi, le sandbox n’est pas une question de méfiance envers l’agent

Même si les modèles s’améliorent, il reste des chemins d’échec indépendants de leur raisonnement. Par exemple : une commande shell, un script de paquet, un mauvais chemin ou un nettoyage de test inattendu.

Mon réglage par défaut, c’est de confiner le blast radius d’une erreur dans le workspace, plutôt que d’économiser quelques clics d’approbation.

Références

• Documentation OpenAI : Sandbox : séparation des limites du système de fichiers et du réseau selon le mode du sandbox, et suppression de ces limites par danger-full-access
• Documentation OpenAI : Agent approvals & security : indépendance entre approval_policy et sandbox_mode, libellé d’avertissement de l’option de bypass et options de la CLI
• openai/codex PR #39630 : Retire the untrusted approval policy : retrait de approval_policy = "untrusted" et erreur au démarrage à partir de la 0.149.0

---

Cet article a été localisé à partir de l’original en coréen : https://jjeongil.tistory.com/3566.