Codex
Profils
- (aucun profil) — analyse en lecture seule (pas de compilation, pas de tests)
--profile edit— modifications locales, construction ou test (workspace-write, entièrement automatique)--profile full— accès réseau ou large au système de fichiers (danger-full-access, entièrement automatique)
Utilisez --profile edit lorsque la tâche implique go test, go build ou toute commande qui écrit des artefacts de construction. Le bac à sable par défaut en lecture seule bloque toutes les écritures, y compris les répertoires temporaires du compilateur.
Pour les tâches complexes, ajoutez --config model_reasoning_effort="xhigh".
Sélection du modèle
Par défaut, utilisez le modèle du projet dans .codex/config.toml (gpt-5.4).
Utilisez --model gpt-5.3-codex-spark pour un travail interactif priorisant la rapidité :
- itérations aller-retour rapides
- corrections rapides de bugs et modifications ciblées
- refactorisations de petite à moyenne envergure ou ajustements d'interface
- prototypage rapide où des réorientations/interruptions fréquentes sont attendues
Restez sur le modèle par défaut gpt-5.4 pour un travail en profondeur :
- longs runs autonomes
- modifications multi-fichiers larges avec raisonnement poussé
- tâches lourdes en tests ou en vérifications
- surfaces à risque élevé de correction où un raisonnement plus profond justifie la latence supplémentaire
Si l'utilisateur demande explicitement un modèle, suivez sa demande.
Commandes
Valeurs par défaut du projet dans .codex/config.toml. Incluez toujours --skip-git-repo-check et 2>/dev/null. Ne surchargez le modèle que lorsque l'utilisateur le demande explicitement, ou lorsque la tâche correspond clairement aux critères Spark de rapidité ci-dessus.
| Cas d'usage | Commande |
|---|---|
| Analyse en lecture seule | codex exec --skip-git-repo-check -o "$CODEX_OUT" "invite" 2>/dev/null |
| Boucle interactive priorisant la rapidité (Spark) | ajouter --model gpt-5.3-codex-spark |
| Appliquer des modifications locales | ajouter --profile edit |
| Accès réseau / large | ajouter --profile full |
| Reprendre une session | echo "invite" | codex exec --skip-git-repo-check -o "$CODEX_OUT" resume --last 2>/dev/null |
Créez un fichier temporaire pour la sortie avant d'exécuter : CODEX_OUT=$(mktemp /tmp/codex-out.XXXXXX). Lisez le résultat depuis $CODEX_OUT après la fin.
Exécutez avec Bash run_in_background: true. Surveillez via TaskOutput avec block: true, timeout: 600000 — n'utilisez PAS de commandes sleep pour interroger. Lisez le fichier -o pour la réponse finale.
Reprise
Ne passez pas les indicateurs de modèle/effort/bac à sable lors de la reprise — les paramètres de la session d'origine sont conservés. -o peut être inclus sans danger.
Conventions
Il s'agit d'un projet Go. Utilisez go test, go build, go vet dans les invites. Les workers Codex ne reçoivent pas CLAUDE.md ni hooks, donc les conventions du projet doivent être explicites.
Vérification post-exécution
Vérifiez toujours la sortie de Codex via git diff --stat — ne faites jamais confiance à la liste de fichiers auto-déclarée par le worker. Les workers Codex peuvent effectuer des modifications hors du périmètre (supprimer des fichiers, annuler du code non lié, supprimer des fonctions de test). La promesse d'achèvement peut lister uniquement les fichiers prévus tout en omettant les effets secondaires destructeurs.
Lorsque d'autres travaux existent dans la même base de code, incluez des listes de fichiers explicites "NE PAS modifier ni supprimer" dans l'invite. L'instruction positive ("ne toucher que ces fichiers") est insuffisante — Codex interprète "nettoyer" de manière large.
Selon [[principles/prove-it-works]] : faites confiance aux artefacts, pas aux auto-déclarations.
Utilisation du répertoire de travail
Avec -C <worktree-dir>, le répertoire de travail possède son propre index git. .claude/ peut être un lien symbolique vers .agents/ — utilisez les chemins .agents/ pour les opérations git.