Faire tourner Codex CLI comme worker dans osFoundry

À la fin, un agent de l'application de bureau osFoundry a cli:codex:agent pour modèle. Quand du travail lui arrive, l'application lance codex exec sur votre Mac, avec votre propre connexion ChatGPT. Le lancement se déroule dans un dossier que vous avez autorisé. Ce que Codex renvoie, son raisonnement, les commandes qu'il a exécutées et son message final, s'affiche sous forme de lignes dans le lancement osFoundry. Aucune clé d'API OpenAI n'intervient, à aucun moment. Qui fait quoi Codex CLI osFoundry Connexion Sa propre connexion ChatGPT (codex login), stockée par Codex Ne la voit jamais. Retire CODEX_API_KEY, OPENAI_API_KEY et OPENAI_BASE_URL de l'environnement du processus enfant pour que le lancement reste sur l'abonnement Appels au modèle Partent directement du processus codex vers OpenAI Enregistre le coût à 0.0 (abonnement, non facturé à l'usage) Outils Son propre shell et ses propres modifications de fichiers, dans le dossier de travail Ses propres outils (par exemple memory_search), servis par un pont MCP en loopback sur 127.0.0.1, uniquement quand un git worktree isole le lancement Approbations Aucune en cours de route : exec n'est pas interactif, approval_policy="never" Chaque appel d'outil passant par le pont traverse orchestrator::execute_tool et ses contrôles de politique Sortie Un événement JSON par élément terminé sur stdout (--json) Transforme chaque événement en ligne de progression ou en texte de réponse ; garde la fin de stderr pour les erreurs Vos fichiers Lus et écrits dans le dossier ou le worktree Choisit le dossier : le dépôt de la surface Code, sinon votre premier dossier local autorisé Mise en place Installez Codex CLI et connectez-vous une fois. osFoundry cherche le binaire dans le PATH, dans ~/.codex/bin et dans /Applications/Codex.app (l'installation via cask le place dans Contents/Resources/codex, où which codex ne trouve rien). codex login Ouvrez l'icône de clé dans l'en-tête (l'infobulle indique API Keys (BYOK)) et passez à l'onglet External AI (IA externe). La ligne Codex affiche Installed, un badge No live stream et l'identifiant du modèle autonome. Codex n'a pas d'identifiant de chat, un seul identifiant apparaît donc : Codex Installed No live stream Enabled cli:codex:agent (autonomous) osFoundry tools require git-worktree isolation for Codex (it trades its own sandbox for git safety). Point it at a git repo folder. Exemple : Claude Code et Codex dans l'onglet External AI Si vous n'êtes pas encore connecté, le bouton Sign in ouvre un terminal qui lance codex login. Cliquez sur Verify sign-in (vérifier la connexion). Cela fait passer une toute petite complétion par le même constructeur que les vrais lancements : codex exec "Reply with the single word: ok" \ --json --skip-git-repo-check --ignore-user-config --ignore-rules \ -s read-only -c 'approval_policy="never"' --ignore-rules n'est ajouté que si codex exec --help le mentionne. osFoundry interroge le binaire, car les anciennes versions refusent cette option et font échouer tout le lancement. Donnez un dossier à l'agent. Ajoutez-en un dans Settings → Local Folders. Si vous voulez aussi que Codex accède aux outils propres à osFoundry, faites de ce dossier un dépôt git et, sur la surface Code, cliquez sur Enable for this workspace. Chaque lancement obtient alors sa propre branche et sa propre copie de travail. Ouvrez l'agent dans Studio et réglez Model Preference. Le sélecteur liste Codex dans la section CLI agents sous cli:codex:agent (fournisseur "External AI (subscription)"). Mettez Runtime Role sur worker si l'agent doit prendre en charge des étapes de worker. Quand du travail est transmis, la commande ressemble à ceci. Sans worktree, Codex garde son propre sandbox : codex exec " User: " \ --json --skip-git-repo-check --ignore-user-config --ignore-rules \ -C /path/to/folder -s workspace-write -c 'approval_policy="never"' Avec un worktree, l'option de sandbox est remplacée et le pont est branché : codex exec " User: " \ --json --skip-git-repo-check --ignore-user-config --ignore-rules \ -C /path/to/worktree \ --dangerously-bypass-approvals-and-sandbox \ -c 'mcp_servers.osfoundry.url="http://127.0.0.1:/mcp"' \ -c 'mcp_servers.osfoundry.http_headers={Authorization="Bearer "}' Codex n'a pas d'option pour ajouter un prompt système. osFoundry place donc le prompt système de l'agent devant la conversation, séparé par une ligne vide. Les tours précédents suivent sous forme de transcription User: / Assistant:. Un lancement Exemple. Voici les lignes d'événements que Codex écrit et les lignes qu'osFoundry en tire à l'affichage. Le texte est illustratif, mais les types d'événements et les formats de ligne sont ceux que le code associe. $ codex exec … --json {"type":"item.completed","item":{"type":"reasoning","text":"Check what the tests cover first."}} {"type":"item.completed","item":{"type":"mcp_tool_call","server":"osfoundry","tool":"memory_search"}} {"type":"item.completed","item":{"type":"command_execution","command":"npm test"}} {"type":"item.completed","item":{"type":"file_change","path":"src/date.ts","change":"edit"}} {"type":"item.completed","item":{"type":"agent_message","text":"Fixed the off-by-one in parseRange; 42 tests pass."}} {"type":"turn.completed","usage":{"input_tokens":…,"cached_input_tokens":…,"output_tokens":…}} osFoundry run Thinking: Check what the tests cover first. Using memory_search… Using shell — npm test Edited src/date.ts Fixed the off-by-one in parseRange; 42 tests pass. Codex désigne un outil du pont par deux champs, server et tool, si bien que la ligne affiche memory_search sans le préfixe mcp__osfoundry__. La réponse arrive sous forme d'éléments agent_message complets, pas de tokens. Les lignes de progression apparaissent une par une pendant que Codex travaille encore. Le texte de chaque message n'apparaît qu'une fois que Codex a terminé ce message. Les nombres de tokens viennent de turn.completed, où input_tokens exclut la partie en cache ; osFoundry rajoute donc cached_input_tokens pour obtenir la taille du contexte. Où passe la limite Il n'existe pas de mode chat cli:codex. La configuration de Codex n'a aucun interrupteur qui désactive son outil shell, donc une « complétion sans outils » passée par Codex resterait un agent doté d'un shell. Plutôt que de lancer cela en silence, osFoundry refuse l'identifiant de chat : "codex has no tool-less chat mode — use 'cli:codex:agent' for an autonomous run instead." -s est un sandbox pour le système de fichiers et les commandes. workspace-write limite l'endroit où Codex peut écrire et ce que ses commandes peuvent faire. Il ne limite pas les outils que le modèle peut appeler, et Codex n'a rien d'équivalent à --disallowedTools. C'est pourquoi, quand vous ajoutez Codex à un canal, la fenêtre Add agent indique qu'aucune portée d'outils ne peut être imposée sur ce harness. Les outils d'osFoundry ont besoin du worktree. En exec non interactif, Codex annule tout appel d'outil MCP, sauf si les approbations et le sandbox sont tous deux contournés. Les modes d'approbation par outil, les projets de confiance et approval_policy="never" annulent quand même. L'application fait donc un seul compromis : elle renonce au sandbox système de Codex uniquement quand l'isolation git prend le relais. Sans worktree, le lancement garde -s workspace-write, le pont n'est pas branché, et une ligne du lancement le signale. Votre propre configuration Codex reste à l'écart. --ignore-user-config ignore ~/.codex/config.toml, si bien que les serveurs MCP que vous avez configurés pour vous-même ne rejoignent pas un lancement osFoundry. L'authentification se charge toujours depuis CODEX_HOME. --ignore-rules écarte aussi les fichiers d'execpolicy .rules. Chaque lancement a un plafond en temps réel : 1 800 secondes pour un lancement autonome, 300 secondes pour la vérification de connexion. Une fois le temps écoulé, le processus enfant est abandonné et tué. Pour aller plus loin Pointez l'agent vers un petit dépôt git, activez les agents de code pour le workspace et donnez-lui une tâche qui demande à la fois une commande shell et quelque chose tiré de la mémoire d'osFoundry. Vous verrez ainsi Using shell et Using memory_search… apparaître dans le même lancement. La page des agents Studio montre où se trouve Model Preference, et la version de bureau est sur la page de téléchargement.