Claude Code ou Codex en équipe : comparer les garde-fous avant de choisir

Pour choisir entre Claude Code et Codex dans une équipe de développement, ne comparez pas seulement la qualité du code produit : comparez ce qui empêche l'assistant d'agir hors de son périmètre, sur chaque poste, et ce que l'administrateur peut imposer. Les deux outils n'abordent pas la question de la même façon. Dans sa documentation, Codex CLI part d'un bac à sable appliqué par le système d'exploitation, actif par défaut. Claude Code part de règles de permission appliquées par l'outil, et son bac à sable pour les commandes shell est désactivé tant que vous ne l'activez pas.

Ce guide s'adresse au responsable technique ou au dirigeant qui prépare un pilote et doit retenir un outil, ou fixer les mêmes exigences pour les deux. Il s'appuie sur la documentation publique d'OpenAI et d'Anthropic consultée le 23 octobre 2026, citée en fin d'article. Il ne classe pas les outils et ne rapporte aucun test client : il propose une grille de lecture et quatre essais à mener vous-même. Kairia travaille avec les deux.

1. Deux points de départ différents

La confusion la plus fréquente consiste à mettre sur le même plan un mode « automatique » et une isolation. Ce sont deux couches distinctes, et les deux éditeurs les séparent.

Chez OpenAI, la documentation décrit deux couches qui fonctionnent ensemble : le mode de bac à sable, qui fixe ce que Codex peut faire techniquement (où écrire, accès au réseau ou non), et la politique d'approbation, qui fixe quand Codex doit vous demander avant d'agir. Pour la CLI et l'extension d'éditeur, le bac à sable est appliqué par des mécanismes du système d'exploitation ; par défaut, il n'y a pas d'accès réseau et l'écriture est limitée à l'espace de travail actif.

Chez Anthropic, la documentation précise que les règles de permission sont appliquées par Claude Code, pas par le modèle. Un mode de permission fixe ce qui s'exécute sans vous demander. Le bac à sable, lui, est une frontière appliquée par le système d'exploitation autour des commandes shell ; il est désactivé par défaut et s'active avec la commande /sandbox ou le réglage sandbox.enabled.

Ce tableau ne dit pas qu'un outil est plus sûr que l'autre. Il dit qu'avec Claude Code, la frontière système est une décision de configuration à prendre explicitement, alors qu'avec Codex, la décision porte surtout sur ce que vous autorisez à en sortir.

2. Ce que le bac à sable ne couvre pas

Les deux documentations sont précises sur les limites, et ce sont elles qui comptent pour un pilote.

Chez Claude Code, le bac à sable couvre les commandes shell et les processus qu'elles lancent. Les outils de fichiers et de web de Claude (lecture, écriture, recherche) suivent les règles de permission, et les hooks, les serveurs MCP locaux et d'autres processus démarrés par Claude Code tournent avec vos droits complets. Autre point : si le bac à sable ne peut pas démarrer, parce qu'une dépendance manque ou que la plateforme n'est pas prise en charge, Claude Code exécute par défaut les commandes sans bac à sable. Le réglage sandbox.failIfUnavailable le fait au contraire quitter au démarrage.

Chez Codex, le filtre réseau ne s'applique qu'aux commandes du bac à sable local. Il ne filtre ni la recherche web, ni les appels d'applications et de connecteurs, ni les connexions aux serveurs MCP, ni les tâches cloud. La documentation recommande, pour les utilisateurs gérés, de combiner la politique réseau avec des contrôles dédiés, dont la liste des serveurs MCP approuvés.

Chez les deux, une lecture n'est pas une fuite empêchée. Le bac à sable de Claude Code laisse lire par défaut la plus grande partie de la machine, y compris des fichiers d'identifiants comme ~/.ssh et ~/.aws/credentials, sauf interdiction explicite. Côté Codex, la documentation d'administration rappelle qu'un mode lecture seule ne masque pas, à lui seul, les fichiers : il faut des interdictions de lecture explicites. Dans les deux cas, la règle prudente reste de ne pas laisser de secrets réels dans le dépôt ni sur le poste du pilote, comme le détaille notre article sur les permissions Claude Code en équipe.

3. Ce que l'administrateur peut imposer

Pour une équipe, la vraie question n'est pas le réglage d'un poste, mais ce qu'un développeur ne peut pas desserrer seul.

Point commun utile : dans les deux outils, l'interdiction l'emporte. Chez Claude Code, une règle refusée à un niveau ne peut être autorisée à aucun autre. Chez Codex, une valeur locale en conflit avec une exigence est remplacée par une valeur compatible, et l'utilisateur en est averti.

4. Les deux « modes automatiques » ne se ressemblent pas

Les deux éditeurs proposent de réduire les demandes d'accord en confiant une partie de la décision à un second modèle. Le périmètre n'est pas le même.

• Codex, revue automatique des approbations (approvals_reviewer = "auto_review") : un agent de revue n'examine que les actions qui demandent déjà une approbation, comme une sortie du bac à sable, une requête réseau bloquée ou un appel d'outil avec effet de bord. Les actions qui restent dans le bac à sable continuent sans revue. En cas d'échec de la revue, l'action n'est pas exécutée. Ces revues consomment des appels de modèle supplémentaires.
• Claude Code, mode auto : il supprime les demandes de routine, et un modèle classifieur examine les actions avant leur exécution, en bloquant ce qui dépasse votre demande, vise une infrastructure non reconnue ou semble dicté par un contenu hostile lu par Claude. Les règles ask explicites continuent de déclencher une demande.

Les deux ont un mode sans aucune protection, à réserver à un environnement isolé : --dangerously-bypass-approvals-and-sandbox (alias --yolo) chez Codex, sans bac à sable ni approbation ; bypassPermissions chez Claude Code, que la documentation réserve à des conteneurs ou des machines virtuelles.

5. Journaliser ce que l'assistant a fait

Pour un pilote, vous voudrez savoir quelles actions ont été approuvées ou refusées. Les deux outils exportent des événements au format OpenTelemetry, désactivés par défaut :

• Codex s'active par un bloc [otel] dans la configuration ; ses événements incluent les décisions sur les outils (approuvé ou refusé, et par qui : la configuration ou l'utilisateur). Le texte des prompts est masqué par défaut.
• Claude Code s'active avec CLAUDE_CODE_ENABLE_TELEMETRY=1 ; l'enregistrement du contenu des prompts est désactivé par défaut et s'active à part.

Dans les deux cas, envoyez ces journaux vers un collecteur que vous contrôlez, et décidez avant le pilote si le contenu des prompts, qui peut contenir du code, doit y figurer.

6. Quatre essais identiques avant de choisir

Une grille sur le papier ne suffit pas : les réglages réels d'un poste dépendent de la version, du système et des réglages gérés reçus. Nous proposons de passer les mêmes quatre essais sur les deux outils, dans un dépôt de test sans secret réel, avec la configuration que vous comptez déployer.

Les deux documentations fournissent de quoi vérifier. Chez Claude Code, la page du bac à sable propose précisément l'essai touch ~/sandbox-probe, qui doit échouer quand le bac à sable est actif ; si Claude propose ensuite de relancer la commande hors du bac à sable, refusez. Chez Codex, la commande codex sandbox macos (ou linux, windows) exécute une commande sous le bac à sable de Codex pour voir ce qui se passe.

Consignez pour chaque essai la version de l'outil, le système, le mode actif et le résultat. C'est cette fiche, pas la réputation de l'outil, qui justifie le choix devant votre direction.

7. Décider

• Votre équipe veut une frontière système sans configuration préalable : Codex part de là. Vérifiez ensuite ce qui sort du bac à sable (recherche web, MCP, connecteurs) et verrouillez les modes autorisés.
• Votre équipe veut des règles fines par commande et par fichier, partagées dans le dépôt : Claude Code est construit autour de ces règles. Activez le bac à sable dès le pilote, avec failIfUnavailable, plutôt que de compter sur les seules règles Bash.
• Vous déployez les deux : appliquez les quatre mêmes essais et les mêmes exigences (pas de mode sans protection, interdictions de lecture des identifiants, journaux exportés), puis comparez le coût par tâche acceptée avec la méthode de notre article sur le budget d'un pilote Claude Code, transposable à Codex.

Le coût suit une logique différente selon l'éditeur. Chez OpenAI, la CLI et l'extension d'éditeur de Codex sont incluses dans les offres ChatGPT à partir de Plus, avec un usage partagé entre Codex et ChatGPT Work ; avec une clé API, l'usage est facturé au tarif de l'API, sans les fonctions cloud. Vérifiez les offres et les limites le jour de votre décision : elles changent souvent.

La bonne question n'est pas « quel assistant est le plus sûr ? », mais « quelle frontière est active sur chaque poste, que peut-on en faire sortir, et qui peut la desserrer ? ».

Pour cadrer ce choix avec vos équipes et le traduire en configuration réelle, consultez notre offre d'intégration de l'IA en entreprise. Si votre choix se porte sur Claude Code, notre formation Claude Code part de vos dépôts et de vos conventions.

Sources et limites

• OpenAI, documentation Codex, consultée le 23 octobre 2026 : Agent approvals and security (bac à sable, approbations, réseau, revue automatique, OpenTelemetry), Managed configuration (exigences d'administrateur, interdictions de lecture) et Pricing.
• Anthropic, documentation Claude Code, consultée le 23 octobre 2026 : Configure permissions, Permission modes, Configure the sandboxed Bash tool, Server-managed settings et Monitoring usage.
• Les deux documentations évoluent rapidement ; revérifiez les réglages cités avant de les déployer.
• La grille, les quatre essais et les recommandations de décision sont une méthode proposée par Kairia. Nous ne rapportons ici ni essai client ni mesure comparative de sécurité. Gemini et Mistral proposent aussi des assistants de code ; nous n'avons pas relu leur documentation pour cet article.