D3 · Extending and Configuring Codex

Ce domaine vaut 20 % de l’examen blanc — soit environ 10 items sur 50. Il évalue votre capacité à configurer Codex en sécurité et à l’étendre délibérément : le config.toml partagé et AGENTS.md, les points d’extension (skills, plugins, MCP, hooks), et surtout la surface de sécurité — modes et profils de permission, sandboxing, auto-review et contrôles d’accès internet. De nombreux items récompensent la configuration sûre, pas la plus permissive.

Ce que vous devez savoir

Un seul config.toml partagé configure l’application desktop, le CLI et l’extension IDE ; AGENTS.md porte les directives d’agent propres au dépôt, et les règles et subagents façonnent le comportement. Codex s’étend via des skills, des plugins, des serveurs MCP, des hooks, le record & replay et des outils de site (WebMCP). Sa surface de sécurité est là où l’examen se concentre : modes et profils de permission, sandboxing (dont le Windows sandbox et WSL), auto-review des diffs et contrôles d’accès internet cloud. Il existe aussi une fonctionnalité de gestion de contexte expérimentale opt-in, avec des limites de connexion spécifiques.

Objectifs d’apprentissage

À l’issue de cette page, vous devriez être capable de :

1. Configurer Codex via le config.toml partagé et l’AGENTS.md, les règles et les subagents propres au dépôt.
2. Étendre Codex avec des skills, des plugins, des serveurs MCP et des hooks, et savoir ce que chacun apporte.
3. Choisir des modes et profils de permission adaptés au risque d’une tâche.
4. Appliquer le sandboxing — dont le Windows sandbox et WSL — pour contenir ce que Codex peut faire.
5. Utiliser l’auto-review et les contrôles d’accès internet cloud dans le cadre d’un workflow sûr.
6. Expliquer la gestion de contexte expérimentale et ses limites de connexion.

3.1 Le config.toml partagé

Un seul fichier de configuration sert l’application desktop, le CLI et l’extension IDE. Fixez le modèle, et référez-vous à la documentation config basics/advanced/reference, aux variables d’environnement et à l’exemple de config pour la surface complète.

# config.toml — partagé par l'application desktop, le CLI et l'extension IDE
model = "gpt-5.6"

[features]
# les fonctionnalités opt-in vivent ici (voir 3.7)

3.2 AGENTS.md, règles et subagents

La configuration d’agent façonne comment Codex travaille dans un dépôt donné.

• AGENTS.md — la directive durable et enregistrée : commandes de build/test, conventions, zones interdites (couvertes en D2).
• Règles — contraintes comportementales qui orientent ou interdisent des actions.
• Subagents — délégation de parties d’une tâche à des agents parallèles (le mécanisme derrière le niveau de raisonnement Ultra).
• Vitesse — configuration qui arbitre la latence contre l’exhaustivité.

config.toml         AGENTS.md            rules            subagents
(machine/           (per-repo            (behavioural     (parallel
 workspace          build, conventions,   constraints)     delegation)
 defaults)          no-go areas)
     └───────── how Codex is set up ──────────┘   └── how work is split ──┘

3.3 Étendre Codex : skills, plugins, MCP, hooks, record & replay

Codex a plusieurs points d’extension distincts ; l’examen attend que vous les distinguiez.

3.4 Modes et profils de permission

Les modes de permission régissent ce que Codex peut faire sans demander. Les profils regroupent des réglages pour un contexte (personnel, équipe, CI). C’est le levier de sécurité à plus forte valeur du domaine.

LESS PERMISSIVE ───────────────────────────────► MORE PERMISSIVE
ask before every         auto-approve reads,        broad auto-approve
sensitive action         prompt on writes /         (only in a trusted,
(read-only leaning)      network / escalation       sandboxed context)

Match the mode to the RISK of the task, not to convenience.

• Utilisez un mode restrictif pour les exécutions sans surveillance (codex exec en CI) pour qu’un agent ne puisse pas escalader silencieusement.
• Utilisez des profils pour garder une valeur par défaut sûre sur les machines partagées et une plus lâche uniquement dans un sandbox.
• Les approbations sont le point de décision humain pour les escalades — traitez-les comme une porte de revue, pas comme une gêne.

3.5 Sandboxing, dont le Windows sandbox et WSL

Le sandboxing contient ce que Codex peut toucher — le système de fichiers, le réseau, le shell. Les environnements incluent local, cloud et git worktrees ; sous Windows, le Windows sandbox et WSL sont pris en charge.

3.6 Auto-review et accès internet cloud

Deux fonctionnalités complètent le tableau d’un workflow sûr.

• Auto-review — Codex passe en revue le diff qu’il a produit et fait remonter un résumé que vous pouvez joindre comme preuve pour le relecteur (voir D2 §2.6). C’est une aide à la revue, pas un remplacement d’un relecteur humain.
• Contrôles d’accès internet cloud — régissent si une exécution cloud peut atteindre le réseau. Par défaut, pas d’accès ou accès restreint ; ouvrez-le délibérément quand une tâche en a réellement besoin (p. ex. récupérer une dépendance), et souvenez-vous des implications de traitement des données.

Diff produced ─► AUTO-REVIEW summary ─► attach as evidence ─► HUMAN review ─► merge
                 (agent's own read;        (D2 §2.6)          (still required)
                  not a substitute)

3.7 Gestion de contexte expérimentale

Astra peut conserver des notes entre les fenêtres de contexte et rechercher dans les messages et résultats d’outils antérieurs au sein de la même tâche. C’est expérimental et opt-in.

[features.context_management]
experimental_mode = true

Les limites de connexion comptent : au lancement, c’est disponible sur connexion ChatGPT Plus/Pro uniquement — pas Business, Enterprise ni connexion par clé API. Ainsi, une équipe d’entreprise sur un espace de travail Business/Enterprise ne peut pas encore s’y fier, et un item qui l’offre comme correctif pour une équipe d’entreprise a tort ne serait-ce que sur la disponibilité.

Cadre de décision

Utilisez CONFIGURE → CONTAIN → EXTEND → REVIEW (CCER) lorsque vous mettez Codex en place pour une tâche ou une équipe.

Erreurs courantes

Défi de mise en situation

Scénario. Une équipe fintech veut que Codex exécute un job nocturne qui met à niveau les dépendances et ouvre une PR. Elle veut aussi que l’agent « conserve des notes tout au long de la longue tâche pour ne pas perdre le contexte », et elle tourne sur un espace de travail ChatGPT Enterprise. Un ingénieur propose : un large auto-approve pour que le job ne s’arrête jamais, un accès internet cloud complet, la gestion de contexte expérimentale activée, et l’auto-review comme seule revue avant que la PR ne soit mergée automatiquement.

Trace de raisonnement d’expert.

1. Le mode de permission est faux. Un large auto-approve sur un job nocturne sans surveillance signifie que l’agent peut escalader silencieusement — exactement le risque à éviter. La configuration sûre est un mode de permission restrictif plus un sandbox, avec toute escalade remontée plutôt qu’auto-approuvée.
2. L’accès internet est trop ouvert. Une mise à niveau de dépendances peut avoir besoin d’un accès réseau pour récupérer des paquets, mais un accès internet complet dépasse ce que la tâche exige et comporte un risque de traitement des données dans un contexte fintech. Accordez le minimum dont la tâche a besoin, délibérément.
3. La gestion de contexte expérimentale est indisponible ici. Au lancement, elle est sur connexion Plus/Pro uniquement ; un espace de travail ChatGPT Enterprise ne peut pas l’utiliser. La proposition échoue sur la disponibilité, donc « conserver des notes tout au long de la longue tâche » doit être résolu autrement (cadrage, subagents, ou acceptation de la limite) — pas par cette fonctionnalité.
4. L’auto-review ne remplace pas la revue humaine. Il produit un résumé utile à joindre comme preuve, mais auto-merger sur l’auto-review supprime la porte humaine. Pour un changement de dépendances fintech, une revue humaine avant merge est exactement le contrôle que vous conservez.
5. Réassembler la conception sûre. Mode de permission restrictif + sandbox, accès internet minimal et délibéré, abandon de la fonctionnalité expérimentale sur cet espace de travail, et exigence d’une revue humaine du résumé d’auto-review et du diff avant merge.

Décision conforme à l’examen : mode de permission restrictif avec un sandbox, accès internet cloud au moindre privilège accordé uniquement pour la récupération, aucune dépendance à la gestion de contexte expérimentale sur un espace de travail Enterprise, et auto-review utilisé comme preuve alimentant une porte de revue humaine requise — pas d’auto-merge. Pas de large auto-approve, pas d’accès internet complet, pas de gestion de contexte expérimentale sur Enterprise, pas d’auto-merge sur l’auto-review.

Pièges d’évaluation

Questions d’entraînement

Chaque item indique combien de réponses sélectionner. Essayez avant de révéler.

Points clés à retenir

• Un seul config.toml partagé fixe les valeurs par défaut (modèle, fonctionnalités, permissions) pour l’application desktop, le CLI et l’extension IDE ; AGENTS.md porte la directive par dépôt.
• Étendez délibérément : les skills pour les aptitudes réutilisables, les plugins pour le comportement groupé, MCP pour les systèmes/données externes, les hooks pour la logique de cycle de vie, record & replay pour la reproductibilité.
• Faites correspondre les modes et profils de permission au risque ; les exécutions sans surveillance nécessitent un mode restrictif plus un sandbox.
• Le sandboxing contient le rayon d’impact ; sous Windows, utilisez le Windows sandbox ou WSL.
• L’auto-review produit une preuve pour le relecteur mais ne remplace pas une porte de revue humaine.
• Par défaut, mettez l’accès internet cloud sur restreint ; ouvrez-le délibérément pour le besoin spécifique.
• La gestion de contexte expérimentale est opt-in via features.context_management.experimental_mode et, au lancement, sur connexion Plus/Pro uniquement — pas Business/Enterprise/clé API.