Si vous avez déjà exploré les bases de Codex CLI, il est temps de passer aux fonctionnalités avancées. Le mode full-auto transforme Codex en véritable agent autonome capable de modifier votre code, d'exécuter des tests et de résoudre des problèmes complexes sans intervention humaine. Cet article explore en profondeur l'architecture sandbox, les policies d'approbation, l'intégration CI/CD et les stratégies de sélection de modèles.

Le mode full-auto : agents autonomes

Codex CLI propose trois niveaux d'autonomie, chacun avec des policies d'approbation différentes :

# Mode suggest : propose sans modifier (par défaut)
codex --approval-mode suggest "Optimise cette requête SQL"

# Mode auto-edit : modifie les fichiers, demande confirmation pour les commandes
codex --approval-mode auto-edit "Refactore ce module en TypeScript"

# Mode full-auto : exécute tout dans le sandbox sans demander
codex --approval-mode full-auto "Corrige tous les tests qui échouent"

Le mode full-auto est le plus puissant : Codex CLI crée des fichiers, les modifie, installe des dépendances et exécute des commandes de manière autonome. Mais cette puissance s'accompagne d'une architecture de sécurité robuste.

Comparaison des modes

Mode	Édition fichiers	Commandes shell	Cas d'usage
suggest	Demande	Demande	Exploration, apprentissage
auto-edit	Auto	Demande	Refactoring supervisé
full-auto	Auto	Auto (sandbox)	CI/CD, tâches répétitives

Architecture sandbox : seatbelt et Docker

La sécurité du mode full-auto repose sur un sandbox qui isole l'exécution des commandes. L'implémentation varie selon la plateforme :

macOS : seatbelt

Sur macOS, Codex CLI utilise le framework seatbelt (sandbox-exec) d'Apple pour restreindre les commandes exécutées :

# Le sandbox restreint automatiquement :
# - L'accès réseau est bloqué (pas de requêtes HTTP sortantes)
# - L'écriture est limitée au répertoire de travail
# - Les processus système sont protégés
# - Les fichiers sensibles (~/.ssh, ~/.aws) sont inaccessibles

Linux : Docker

Sur Linux, le sandbox s'appuie sur Docker pour fournir une isolation complète :

# Codex CLI crée un conteneur éphémère avec :
# - Un volume monté en lecture/écriture pour le répertoire de travail
# - Aucun accès réseau (--network=none)
# - Ressources CPU/RAM limitées
# - Utilisateur non-root

Restrictions réseau

Dans les deux cas, l'accès réseau est désactivé par défaut en mode full-auto. Cela signifie que Codex ne peut pas :

Télécharger des packages depuis npm/pip pendant l'exécution sandbox
Appeler des APIs externes
Exfiltrer des données de votre projet

Pour les tâches nécessitant le réseau, utilisez le mode auto-edit qui demande confirmation pour chaque commande.

Le fichier codex.md : instructions de projet

Le fichier codex.md à la racine de votre projet est lu automatiquement par Codex CLI au démarrage de chaque session. Il définit le contexte et les conventions :

# Mon Projet - Instructions Codex

## Stack
- TypeScript 5.5 strict mode
- React 19 avec Server Components
- Prisma ORM avec PostgreSQL

## Conventions
- Tests avec Vitest, couverture minimale 80%
- Composants fonctionnels uniquement
- ESLint + Prettier obligatoires

## Commandes
- `npm run dev` — Serveur de développement
- `npm run test` — Lancer les tests
- `npm run lint` — Vérification du style

## Règles
- Ne jamais modifier les fichiers de migration Prisma manuellement
- Chaque endpoint API doit avoir une validation Zod
- Les variables d'environnement doivent être typées dans env.ts

Opérations multi-fichiers

Le mode full-auto excelle dans les opérations de refactoring touchant plusieurs fichiers simultanément :

# Renommer un composant dans tout le projet
codex --approval-mode full-auto "Renomme le composant UserCard
  en ProfileCard dans tous les fichiers du projet. Mets à jour
  les imports, les tests, les stories Storybook et le barrel export."

# Migration de syntaxe
codex --approval-mode full-auto "Migre tous les composants React
  de class components vers des functional components avec hooks.
  Préserve la logique et ajoute les types TypeScript manquants."

Codex CLI analyse les dépendances entre fichiers, planifie les modifications dans le bon ordre et s'assure que le projet reste fonctionnel après chaque étape.

Intégration CI/CD avec GitHub Actions

L'un des cas d'usage les plus puissants de Codex CLI est son intégration dans des pipelines CI/CD. Voici un workflow GitHub Actions complet :

name: Codex Auto-Fix
on:
  issues:
    types: [opened, labeled]

jobs:
  auto-fix:
    if: contains(github.event.issue.labels.*.name, 'codex-fix')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - name: Install Codex CLI
        run: npm install -g @openai/codex

      - name: Run Codex Fix
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          codex --approval-mode full-auto             --quiet             -p "Résous l'issue suivante : ${{ github.event.issue.title }}. ${{ github.event.issue.body }}"

      - name: Create Pull Request
        uses: peter-evans/create-pull-request@v6
        with:
          title: "fix: ${{ github.event.issue.title }}"
          body: "Correction automatique par Codex CLI pour #${{ github.event.issue.number }}"
          branch: "codex-fix/${{ github.event.issue.number }}"

Ce workflow surveille les issues avec le label codex-fix, lance Codex CLI en mode full-auto pour résoudre le problème, puis crée automatiquement une pull request avec les corrections.

Piping et chaînage avec les commandes Unix

Codex CLI s'intègre naturellement dans l'écosystème Unix grâce au piping :

# Analyser les logs d'erreur
cat error.log | codex -p "Analyse ces logs et identifie la cause racine"

# Générer de la documentation à partir du code
find src/ -name "*.ts" -exec cat {} + | codex -p "Génère un README avec l'API publique"

# Corriger le linting automatiquement
npm run lint 2>&1 | codex --approval-mode auto-edit -p "Corrige toutes ces erreurs de lint"

# Chaîner avec d'autres outils
codex -p "Liste les dépendances obsolètes" | xargs npm update

Stratégie de sélection des modèles

Codex CLI supporte plusieurs modèles OpenAI, chacun avec ses forces :

Modèle	Force	Vitesse	Coût	Cas d'usage
codex-1	Optimisé code	Rapide	Moyen	Tâches de coding quotidiennes
gpt-4.1	Raisonnement	Moyen	Élevé	Architecture, design complexe
o4-mini	Reasoning compact	Rapide	Bas	Scripts simples, corrections rapides
o3	Reasoning avancé	Lent	Très élevé	Problèmes algorithmiques complexes

# Sélectionner un modèle spécifique
codex --model gpt-4.1 "Conçois l'architecture de ce microservice"

# Utiliser o4-mini pour les tâches simples (économique)
codex --model o4-mini "Ajoute les types TypeScript manquants dans ce fichier"

# Utiliser o3 pour les problèmes complexes
codex --model o3 "Optimise cet algorithme de tri pour des datasets de 10M d'entrées"

La stratégie recommandée est d'utiliser codex-1 par défaut, o4-mini pour les tâches simples et répétitives, et gpt-4.1 ou o3 uniquement pour les problèmes nécessitant un raisonnement approfondi.

Bonnes pratiques

Commencez en mode suggest : familiarisez-vous avec les réponses de Codex avant de passer au mode full-auto.
Maintenez un codex.md détaillé : incluez les conventions, les patterns architecturaux et les contraintes spécifiques à votre projet.
Utilisez full-auto dans un environnement contrôlé : idéalement sur une branche Git dédiée ou dans un pipeline CI/CD.
Combinez les modèles : utilisez les modèles économiques pour les tâches courantes et les modèles puissants pour les défis architecturaux.
Testez après chaque opération full-auto : ajoutez systématiquement npm run test dans vos workflows pour valider les changements.

Codex CLI en mode avancé transforme l'IA d'un simple assistant en un véritable agent de développement autonome. L'architecture sandbox garantit la sécurité, tandis que l'intégration CI/CD et le piping Unix permettent d'automatiser des workflows complexes à l'échelle d'un projet entier.

OpenAI Codex CLI avancé : agents autonomes, sandbox et automatisation de projets