Skip to content
Apothem
Adaptateurs d'environnement

Codex

Adaptateur d'environnement Apothem pour Codex (bêta).

Éditeur : OpenAI Nom d'installation : codex Statut : Bêta Configuration native : ~/.codex/AGENTS.md, ~/.codex/hooks.json, ~/.codex/hooks/, ~/.codex/agents/*.toml et ~/.agents/skills/

Installation

apothem install --harness codex

L'adaptateur installe les instructions et les hooks natifs de Codex, convertit les agents Apothem en agents TOML de Codex et encapsule les prompts de commande réutilisables sous forme de skills Codex.

Fichiers écrits : ~/.codex/AGENTS.md, ~/.codex/hooks.json, ~/.codex/hooks/, ~/.codex/agents/*.toml, ~/.agents/skills/*/SKILL.md, ~/.agents/skills/*/agents/openai.yaml pour les skills invoqués par l'utilisateur, et les fichiers de support sous ~/.config/apothem/{rules,templates}/.

Interpréteur des hooks. Avant d'écrire quoi que ce soit, l'installation résout un interpréteur CPython 3.10+. Sous Windows, l'entrée commandWindows de chaque hook dans hooks.json exécute le chemin absolu de cet interpréteur au lieu du lanceur py -3 ; les entrées command POSIX conservent python3. Relancez apothem update --harness codex après le déplacement ou la suppression de l'interpréteur. Si aucun CPython 3.10+ n'est trouvé, l'installation s'arrête avant d'écrire le moindre fichier.

Le bloc Apothem de AGENTS.md se termine par une section consacrée aux fichiers de support Apothem, qui nomme le répertoire absolu par rapport auquel se résout chaque citation de style dépôt dans les skills et règles installés : rules/<name>.md et templates/... sous ~/.config/apothem/, et hooks/... sous ~/.codex/hooks/. L'installation Codex ne livre aucune arborescence schemas/ ni conformity/ ; la section ne mentionne donc ni l'une ni l'autre.

Skills invoqués par l'utilisateur. Codex ignore la clé disable-model-invocation. Pour chaque skill ou commande dont la source définit disable-model-invocation: true, l'adaptateur écrit agents/openai.yaml à côté de son SKILL.md avec policy.allow_implicit_invocation: false, de sorte que Codex ne choisit pas ce skill de lui-même ; vous pouvez toujours l'exécuter explicitement avec $skill-name. Voir la documentation des skills de Codex.

Correspondance entre le profil et la configuration native

L'adaptateur lit les cohortes partagées d'Apothem et installe chacune dans la bonne surface de Codex : les instructions dans AGENTS.md, les hooks dans hooks.json et hooks/, les agents en TOML, les skills dans ~/.agents/skills/, et les règles et templates Markdown non natifs dans ~/.config/apothem/ comme matériel de support.

Chaque auxiliaire converti définit name, description et developer_instructions, qui porte le corps de l'auxiliaire. Aucun modèle ni effort de raisonnement n'est défini ; chaque auxiliaire hérite donc des choix de la session. Codex n'a ni liste d'outils ni limite de tours par auxiliaire ; les tools et maxTurns d'un auxiliaire ne sont donc pas repris.

Les auxiliaires en lecture seule (voir la référence des auxiliaires) indiquent dans leurs instructions qu'ils ne modifient rien. La lecture seule est imposée par le bac à sable de la session parente, et non par le fichier TOML de l'auxiliaire : chaque auxiliaire s'exécute sous les paramètres de bac à sable et d'approbation de la session qui l'a lancé. Un fichier d'auxiliaire ne peut pas remplacer le mode de bac à sable, la politique d'approbation, le fournisseur de modèle ni les serveurs MCP de la session ; l'adaptateur n'en écrit donc aucun, et les instructions d'un auxiliaire peuvent lui demander d'éviter les modifications sans créer de bac à sable distinct en lecture seule. Pour rendre une limite de lecture seule contraignante, définissez les contrôles de bac à sable et d'approbation sur la session Codex elle-même. Une version de Codex antérieure à celle qui a ajouté cette restriction peut encore respecter sandbox_mode dans un fichier d'auxiliaire ; Apothem n'a pas établi de quelle version il s'agit, et n'écrit aucun sandbox_mode dans un cas comme dans l'autre.

Notes de compatibilité

~/.agents/skills/ est une racine partagée dont Codex est propriétaire : neuf autres outils pris en charge la chargent aussi (le registre des environnements les liste) ; les skills Apothem qu'une installation Codex y écrit apparaissent donc également dans ces outils. Quatre de ces outils écrivent aussi eux-mêmes ce dossier lorsque vous les installez (le registre les liste comme co-installateurs), avec les mêmes fichiers qu'une installation Codex ; les skills sont donc présents sur une machine dépourvue d'installation Codex. Il en va de même pour les règles et templates de ~/.config/apothem/, que sept adaptateurs de portée projet écrivent aussi. Le dossier se trouve toujours dans votre répertoire personnel, quelle que soit la valeur de CODEX_HOME : Codex lit $HOME/.agents/skills ; un CODEX_HOME autre que ~/.codex déplace donc les fichiers Codex mais pas les skills. Chaque installation Apothem qui utilise le dossier y écrit les mêmes fichiers, et l'installation enregistre quelles installations l'utilisent ; l'ordre dans lequel vous installez n'a donc pas d'importance. Une désinstallation de Codex ne retire les skills que si aucune autre installation Apothem ne les utilise encore ; sinon, elle les conserve et indique quelles installations les utilisent (voir Désinstallation). Le propriétaire enregistré est l'outil pour lequel l'éditeur documente le chemin. L'installation qui a placé les fichiers est celle qui les utilise encore, et la note d'installation la nomme. Un dossier de skill qu'Apothem n'a pas écrit et qui porte le même nom qu'un skill Apothem est laissé tel quel, avec un avertissement qui le nomme. L'installation affiche une note qui nomme ces outils. ~/.codex/agents/ est une seconde racine partagée : un autre outil pris en charge liste ce dossier comme emplacement de compatibilité (le registre le nomme), et sa documentation ne dit pas s'il lit les fichiers TOML qu'une installation Codex y écrit.

Codex réserve ~/.codex/rules/ aux politiques d'exécution .rules. Apothem n'y place pas de règles comportementales Markdown ; il les conserve dans ~/.config/apothem/ et les référence depuis AGENTS.md et les skills installés.

Plugin Codex

Apothem livre aussi un plugin Codex, ajouté depuis la marketplace de plugins du dépôt (le guide d'installation liste les commandes sous le canal 7). Le plugin est une amorce : il embarque un skill d'entrée qui exécute le moteur, et apothem install --harness codex écrit tout ce qui est listé ci-dessus.

Le plugin se trouve dans plugins/apothem/. Son manifeste est un plugin.json à la racine, l'emplacement que Codex documente pour un nouveau paquet. Le manifeste ne nomme aucun chemin de skills, car Codex découvre le répertoire skills/ d'un plugin depuis la racine du plugin. Un fichier .codex-plugin/plugin.json reste à côté comme solution de repli de compatibilité pour les versions de Codex qui ne lisent que cet ancien emplacement ; Codex le prend toujours en charge et traite le manifeste racine comme canonique pour l'identité du plugin. Les deux fichiers portent la version de la release, et un test les aligne sur la version du moteur.

Le plugin n'embarque ni agents, ni hooks, ni serveurs MCP. Codex ne documente aucun composant d'agents personnalisés pour les plugins ; le moteur continue donc d'écrire les agents dans ~/.codex/agents/*.toml. Les hooks embarqués dans un plugin sont limités aux plugins installés manuellement dans Codex desktop et ne sont pas approuvés automatiquement ; le moteur continue donc de les écrire dans ~/.codex/hooks.json.

L'entrée de marketplace définit le bloc policy que Codex demande aux auteurs de toujours inclure : policy.installation vaut AVAILABLE et policy.authentication vaut ON_INSTALL, les valeurs par défaut que Codex documente pour une nouvelle entrée.

Vérification

apothem verify --harness codex

La commande verify confirme que :

  1. La configuration native existe au chemin attendu.
  2. Chaque cible gérée existe ; les fichiers gérés ne sont pas vides, et les configurations JSON ou YAML s'analysent correctement. Ajoutez --profile PATH pour vérifier en plus que les fichiers installés correspondent à ce profil.
  3. La routine de vérification propre à l'adaptateur signale un succès.

Mise à jour

apothem update --harness codex

Actualise l'amorce Codex, les agents convertis, les skills et les cohortes de support.

Les dossiers de skills de ~/.agents/skills/ sont écrits sous une forme unique, partagée par chaque installation Apothem de ce dossier : les clés d'en-tête version, updated, archetype et portability de SKILL.md se trouvent sous une table metadata, et userInvocable s'écrit user-invocable. La première mise à jour après la montée de version réécrit sous cette forme les dossiers qu'une installation Codex a écrits auparavant, et sauvegarde chaque dossier qu'elle modifie. apothem rollback --harness codex les restaure.

Désinstallation

apothem uninstall --harness codex

Supprime le bloc Apothem de ~/.codex/AGENTS.md et conserve tout texte situé en dehors de ce bloc, et supprime les entrées d'Apothem de ~/.codex/hooks.json en conservant les vôtres. Supprime aussi les fichiers Apothem de ~/.codex/hooks/, ~/.codex/agents/, ~/.agents/skills/ et ~/.config/apothem/{rules,templates}/, sauf si une autre installation Apothem les utilise encore (la désinstallation conserve ceux-là et les liste) ; les autres fichiers de ces dossiers restent en place. Les skills retirés de ~/.agents/skills/ disparaissent aussi des autres outils qui chargent ce dossier (voir Notes de compatibilité). Si vous avez défini CODEX_HOME sur un dossier autre que ~/.codex et installé avec une version antérieure, les copies que cette version a écrites à côté de ce dossier (<CODEX_HOME>/../.agents/skills/ et <CODEX_HOME>/../.config/apothem/) ne sont pas supprimées ; supprimez-les à la main. Chaque fichier est sauvegardé sous ~/.apothem/backups/ avant d'être modifié ou supprimé. Le YAML du profil partagé et le moteur Apothem ne sont pas affectés.

Portail de conformité

python -m apothem.conformity.gate --all .

Dépannage

SymptômeCorrectif
Fichier de configuration introuvableRelancez apothem install --harness codex
Échec de la vérificationExécutez apothem update --harness codex, puis vérifiez à nouveau
Contenu de configuration inattenduVérifiez ~/.config/apothem/profile.yaml ou --profile PATH, puis relancez apothem update --harness codex

Paramètres de configuration

OptionPar défautDescription
--dry-runfalsePrévisualise l'installation sans écrire de fichiers.

Voir aussi

On this page