Codex sur GitHub et dans l'IDE

Vous pouvez confier une issue GitHub à Codex, partir faire autre chose et revenir devant une pull request relue et testée qui attend votre validation. C'est le workflow que nous construisons dans cette leçon : Codex comme coéquipier de code qui vit dans votre dépôt et votre éditeur, pas comme une fenêtre de chat dans laquelle vous faites du copier-coller.

Codex est l'agent de génie logiciel d'OpenAI. Il tourne dans trois endroits qui comptent ici : le cloud (un environnement sandboxé connecté à vos dépôts GitHub), votre IDE (via l'extension officielle) et la CLI / le terminal. Ils partagent le même agent sous-jacent mais diffèrent par le degré d'autonomie que vous accordez. Commencez par la présentation officielle sur la documentation Codex.

Les deux surfaces : cloud et local

Il y a une distinction à fixer dans votre tête avant tout le reste.

Codex cloud exécute chaque tâche dans un conteneur isolé. Il clone votre dépôt, dispose de son propre système de fichiers et, par défaut, n'a pas d'accès réseau pendant la tâche. C'est là que vit le flux « j'assigne une issue, je récupère une PR ».

Codex local (l'extension IDE et la CLI) tourne sur votre machine, sur votre arbre de travail réel. Il voit vos modifications non commitées et votre outillage local. C'est là que vous travaillez à deux sur quelque chose en direct, en regardant chaque diff.

Même agent, rayon d'impact différent. Le cloud sert à déléguer un travail autonome. Le local sert à collaborer sur l'instant.

Connecter codex à GitHub

Dans ChatGPT, ouvrez Codex et connectez votre compte GitHub, puis accordez l'accès à des dépôts spécifiques (pas à toute votre organisation). Codex installe une GitHub App avec des permissions restreintes. Une fois la connexion faite, vous pouvez pointer une tâche sur n'importe quelle branche et Codex peut ouvrir des pull requests vers ce dépôt.

Dans votre éditeur, installez l'extension Codex pour VS Code (et ses forks comme Cursor) ou le plugin JetBrains. Connectez-vous avec votre compte ChatGPT. L'extension partage votre environnement Codex : une tâche lancée dans l'IDE peut donc être inspectée plus tard dans le dashboard cloud.

Pas à pas : prendre une issue, ouvrir une PR

Voici le flux concret. Supposons que votre dépôt contienne cette issue :

#214 : le formulaire de login accepte des mots de passe composés uniquement d'espaces Les utilisateurs peuvent soumettre un mot de passe fait uniquement d'espaces. Ajouter une validation et un test.

1. Assigner la tâche

Dans la vue Codex cloud, sélectionnez le dépôt et la branche, puis décrivez la tâche. La chose la plus efficace que vous puissiez faire est de coller l'issue et de référencer de vrais fichiers :

Corrige l'issue #214. Dans src/auth/validators.py, rejette les mots de passe vides ou composés uniquement d'espaces. Reprends le pattern ValidationError existant utilisé par validate_email. Ajoute un test unitaire dans tests/test_validators.py.

Codex démarre un conteneur, lit les fichiers pertinents et planifie. Comme l'environnement est sandboxé, il peut exécuter votre suite de tests pendant qu'il travaille.

2. Laissez-le travailler, puis lisez le diff

Codex modifie les fichiers, lance les tests et itère si quelque chose échoue. Quand il a terminé, vous obtenez un résumé : ce qu'il a changé, les commandes qu'il a exécutées et la sortie des tests. Lisez le diff. Traitez-le exactement comme la PR d'un développeur junior : l'agent est rapide et infatigable, pas infaillible.

3. Ouvrir la pull request

Si le diff vous semble juste, cliquez pour ouvrir une PR directement depuis Codex. Il rédige un titre et une description, lie l'issue #214 et pousse une branche. Vos protections de branche habituelles, les relecteurs obligatoires et la CI s'appliquent toujours. Rien ne se merge sans que vos règles existantes soient satisfaites.

C'est la boucle : une issue en entrée, une PR relue en sortie, avec vous comme point de contrôle.

Configurer l'environnement avec AGENTS.md

Codex ne connaît pas par magie les conventions de votre projet. Vous lui apprenez une fois, dans un fichier qu'il lit automatiquement : `AGENTS.md` à la racine du dépôt. Voyez-le comme un README écrit pour l'agent plutôt que pour des humains.

Un bon AGENTS.md indique à Codex comment installer les dépendances, comment lancer les tests et quelles conventions respecter. Restez court et factuel.

# AGENTS.md (front-matter style config Codex reads)
setup:
  - pip install -e ".[dev]"

checks:
  test: pytest -q
  lint: ruff check .
  typecheck: mypy src/

conventions:
  - Follow PEP 8; format with ruff before committing.
  - All new functions need type hints and a docstring.
  - Tests go in tests/ and mirror the src/ path.
  - Never edit files under migrations/ by hand.

before_pr:
  - Run test, lint, and typecheck. All must pass.

Avec ça en place, Codex installe correctement, exécute vos vrais checks et refuse de toucher aux répertoires que vous avez marqués comme interdits. Si pytest échoue, il voit l'échec et réessaie avant de vous remettre la PR. Résultat : moins de PR qui cassent la CI dès qu'elles arrivent.

Vous pouvez aussi placer des fichiers AGENTS.md imbriqués dans des sous-répertoires pour les monorepos : pour les fichiers d'un chemin donné, le plus proche l'emporte.

Codex dans l'IDE : travailler en binôme en direct

Le flux cloud, c'est de la délégation. Le flux IDE, c'est de la collaboration, et vous y allez quand vous voulez voir le travail se faire.

Dans VS Code avec l'extension Codex, ouvrez la sidebar Codex et décrivez une modification sur votre projet ouvert. Une tâche locale typique :

Refactore OrderService.process pour extraire la logique de remise dans une classe DiscountCalculator. Garde un comportement identique et mets à jour les tests existants.

La différence avec le cloud, ce sont les approbations. Codex local fonctionne selon des modes qui contrôlent ce qu'il peut faire sans demander :

• Lecture seule / suggestion : il propose des diffs, vous les appliquez.
• Auto / agent : il modifie les fichiers et exécute des commandes, en s'arrarrL'Annual Recurring Revenue (ARR) est le revenu normalisé et prévisible qu'une entreprise par abonnement attend de ses contrats actifs sur une année.Voir la définition complète →êtant pour demander avant toute action risquée.
• Accès complet : il modifie et exécute librement dans le workspace.

Pour le quotidien, le mode intermédiaire est le bon compromis. Codex fait les modifications et lance vos tests, mais s'arrête pour demander avant, par exemple, de supprimer des fichiers ou d'exécuter une commande qui n'a pas été pré-approuvée. Vous restez dans la boucle sans surveiller chaque frappe.

Le flux IDE brille aussi pour comprendre du code. Sélectionnez une fonction tordue, demandez à Codex de l'expliquer ou d'écrire des tests, et il travaille sur le fichier en direct avec tout le contexte du projet.

Les garde-fousgarde-fousRègles et contrôles qui maintiennent un système d'IA dans des limites sûres, légales et conformes à la marque, en bloquant les sorties et actions hors cadre.Voir la définition complète → de sécurité à vraiment utiliser

Codex est conçu pour être sûr par défaut, mais les réglages par défaut sont conservateurs précisément pour que vous puissiez les desserrer en conscience. Connaissez les vrais leviers.

Sandboxing et réseau

Les tâches Codex cloud tournent sans accès réseau pendant l'exécution, sauf si vous l'activez explicitement. C'est un garde-fou volontaire : une tâche ne peut pas exfiltrer discrètement du code ni tirer des paquets non fiables. Si votre build a réellement besoin de récupérer des dépendances, activez l'accès réseau pour cet environnement et privilégiez le pinning de ce qu'il peut atteindre. Traitez un accès réseau large comme une décision, pas comme un défaut.

Les approbations sont votre coupe-circuit

En modes locaux, la demande d'approbation est la fonctionnalité de sécurité la plus importante, pas une gêne. Les commandes qui modifient votre système ou sortent du workspace remontent pour confirmation. Résistez à l'envie de tout passer en accès complet sur un dépôt qui compte. Réservez l'autonomie totale aux branches jetables et aux expérimentations.

La protection de branche fait le gros du travail

Codex respecte votre configuration GitHub existante. Comme chaque changement arrive sous forme de PR sur une branche, vos relectures obligatoires, status checks et règles CODEOWNERS continuent de conditionner le merge. L'agent peut ouvrir une PR ; il ne peut pas contourner une branche main protégée. C'est pour cela que le pattern « ouvrir une PR » est plus sûr que de laisser un outil pousser directement : votre processus de revue humaine reste inchangé.

Les secrets restent hors du prompt

Ne collez pas de clés d'APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → ni d'identifiants dans les descriptions de tâches. Pour les environnements cloud qui ont besoin de secrets pour lancer les tests, utilisez la configuration de secrets de l'environnement plutôt que de les mettre en clair. Tout ce qui est dans le prompt fait partie du contexte de la tâche ; gardez les identifiants dans le secret store, à leur place.

Restreignez le périmètre de la GitHub App

Quand vous avez connecté GitHub plus haut, vous avez accordé l'accès à des dépôts spécifiques. Gardez-le ainsi. Il n'y a aucune raison de donner à la GitHub App Codex l'accès à des dépôts qu'elle ne touchera jamais. Revoyez périodiquement les dépôts autorisés dans vos paramètres GitHub.

Un modèle mental simple : cloud + sandbox + revue de PR pour le travail délégué que vous ne surveillerez pas, et local + approbations pour celui que vous surveillerez. Dans les deux cas, le point de contrôle du merge, ce sont vos règles GitHub existantes, et vous ne devriez jamais les affaiblir juste pour accélérer l'agent.

Quelle surface choisir, et quand

Un guide de décision rapide :

• Issue bien définie et autonome ? Codex cloud. Assignez-la, faites autre chose, relisez la PR.
• Refactor exploratoire où vous voulez tenir la barre ? L'extension IDE en mode auto.
• Tâche scriptable et répétable en CI ou dans un workflow terminal ? La CLI Codex.
• Tout un lot de petites corvées (bump de versions, corrections de lint sur plusieurs fichiers) ? Le cloud, une tâche par item, relecture de la pile de PR.

Le savoir-faire consiste à faire correspondre la surface au degré de confiance que vous accordez à la tâche pour tourner sans surveillance. Pour les détails pratiques de configuration et les limites, gardez sous la main les articles Codex du centre d'aide, car les options d'environnement exactes évoluent.

Points clés

• Pilotez la boucle, pas le clavier. Assignez une issue GitHub avec des références de fichiers précises, laissez Codex cloud produire une PR, et relisez-la comme le travail d'un coéquipier. Le point de contrôle du merge reste le vôtre.
• Écrivez un `AGENTS.md`. Un petit fichier qui dit à Codex comment installer, tester, linter et quels répertoires sont interdits améliore nettement la qualité des PR et garde la CI au vert.
• Choisissez la surface selon l'autonomie. Le cloud pour les tâches déléguées et autonomes ; l'extension IDE pour le travail en binôme en direct, quand vous voulez regarder et approuver.
• Traitez les approbations et le sandboxing comme des fonctionnalités. Gardez les tâches cloud isolées du réseau sauf besoin réel, réservez les modes accès complet aux branches jetables, et ne collez jamais de secrets dans les prompts.
• Laissez la protection de branche faire le filtrage. Comme Codex vous remet des PR, vos relectures obligatoires, status checks et règles CODEOWNERS protègent déjà main. Ne les affaiblissez pas pour aller plus vite.