Usare Codex CLI come worker di osFoundry

Alla fine, un agente nell'app desktop di osFoundry ha cli:codex:agent come modello. Quando gli arriva del lavoro, l'app avvia codex exec sul tuo Mac con il tuo login ChatGPT. L'esecuzione avviene in una cartella che hai autorizzato. Quello che Codex restituisce, il suo ragionamento, i comandi che ha eseguito e il messaggio finale, compare come righe nell'esecuzione di osFoundry. Non entra mai in gioco una chiave API di OpenAI. Chi fa cosa Codex CLI osFoundry Login Il proprio login ChatGPT (codex login), salvato da Codex Non lo vede mai. Rimuove CODEX_API_KEY, OPENAI_API_KEY e OPENAI_BASE_URL dall'ambiente del processo figlio, così l'esecuzione resta sull'abbonamento Chiamate al modello Vanno direttamente a OpenAI dal processo codex Registra il costo come 0.0 (abbonamento, non a consumo) Strumenti La propria shell e le proprie modifiche ai file, dentro la cartella di lavoro I propri strumenti (per esempio memory_search), serviti da un bridge MCP in loopback su 127.0.0.1, solo quando un git worktree isola l'esecuzione Approvazioni Nessuna durante l'esecuzione: exec non è interattivo, approval_policy="never" Ogni chiamata a uno strumento tramite il bridge passa per orchestrator::execute_tool e i suoi controlli di policy Output Un evento JSON per ogni elemento completato su stdout (--json) Trasforma ogni evento in una riga di avanzamento o in testo di risposta; conserva la coda di stderr per gli errori I tuoi file Letti e scritti nella cartella o nel worktree Sceglie la cartella: il repository della superficie Code, altrimenti la tua prima cartella locale autorizzata Configurazione Installa Codex CLI ed effettua il login una volta. osFoundry cerca il binario nel PATH, in ~/.codex/bin e dentro /Applications/Codex.app (l'installazione con cask lo mette in Contents/Resources/codex, dove which codex non trova nulla). codex login Apri l'icona della chiave nell'intestazione (il tooltip dice API Keys (BYOK)) e passa alla scheda External AI (IA esterna). La riga di Codex mostra Installed, un badge No live stream e l'id del modello autonomo. Codex non ha un id di chat, quindi compare un solo id: 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. Esempio: Claude Code e Codex nella scheda External AI Se non hai ancora fatto il login, il pulsante Sign in apre un terminale che esegue codex login. Clicca Verify sign-in (verifica login). Esegue una completion minuscola con lo stesso builder usato dalle esecuzioni reali: 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 viene aggiunto solo quando codex exec --help lo elenca. osFoundry lo chiede al binario perché le build più vecchie rifiutano il flag e fanno fallire l'intera esecuzione. Dai una cartella all'agente. Aggiungine una in Settings → Local Folders. Se vuoi che Codex raggiunga anche gli strumenti di osFoundry, trasforma quella cartella in un repository git e, sulla superficie Code, clicca Enable for this workspace. Da lì ogni esecuzione ha il proprio branch e la propria copia di lavoro. Apri l'agente in Studio e imposta Model Preference. Il selettore elenca Codex nella sezione CLI agents come cli:codex:agent (provider "External AI (subscription)"). Imposta Runtime Role su worker se l'agente deve occuparsi di step da worker. Quando il lavoro viene passato, il comando ha questo aspetto. Senza worktree si mantiene la sandbox di Codex: codex exec " User: " \ --json --skip-git-repo-check --ignore-user-config --ignore-rules \ -C /path/to/folder -s workspace-write -c 'approval_policy="never"' Con un worktree, il flag della sandbox viene sostituito e il bridge viene collegato: 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 non ha un flag per aggiungere un system prompt, quindi osFoundry mette il system prompt dell'agente davanti alla conversazione, separato da una riga vuota. I turni precedenti seguono come trascrizione User: / Assistant:. Un'esecuzione Esempio. Queste sono le righe di evento che Codex scrive e le righe che osFoundry ne ricava. Il testo è illustrativo, ma i tipi di evento e i formati delle righe sono quelli che il codice mappa. $ 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 indica uno strumento del bridge con due campi, server e tool, quindi la riga mostra memory_search senza il prefisso mcp__osfoundry__. La risposta arriva come elementi agent_message interi, non come token. Le righe di avanzamento compaiono una alla volta mentre Codex sta ancora lavorando. Il testo di ogni messaggio compare solo quando Codex ha finito quel messaggio. I conteggi dei token vengono da turn.completed, dove input_tokens esclude la parte in cache, quindi osFoundry riaggiunge cached_input_tokens per ottenere la dimensione del contesto. Dove sta il confine Non esiste una modalità chat cli:codex. La configurazione di Codex non ha un interruttore che spenga il suo strumento shell, quindi una "completion senza strumenti" fatta con Codex sarebbe comunque un agente con una shell. osFoundry rifiuta l'id di chat invece di eseguirla in silenzio: "codex has no tool-less chat mode — use 'cli:codex:agent' for an autonomous run instead." -s è una sandbox per filesystem e comandi. workspace-write limita dove Codex può scrivere e cosa possono fare i suoi comandi. Non limita quali strumenti il modello può chiamare, e Codex non ha niente di simile a --disallowedTools. Per questo, quando aggiungi Codex a un canale, il pannello Add agent avvisa che su questo harness non si può imporre un ambito di strumenti. Gli strumenti di osFoundry hanno bisogno del worktree. Nell'exec non interattivo, Codex annulla ogni chiamata a strumenti MCP a meno che approvazioni e sandbox non vengano entrambe aggirate. Le modalità di approvazione per strumento, i progetti fidati e approval_policy="never" annullano comunque. Così l'app fa un solo scambio: rinuncia alla sandbox di sistema di Codex solo quando l'isolamento git ne prende il posto. Senza worktree, l'esecuzione mantiene -s workspace-write, il bridge non viene collegato e una riga nell'esecuzione lo segnala. La tua configurazione personale di Codex resta fuori. --ignore-user-config salta ~/.codex/config.toml, quindi i server MCP che hai configurato per te non entrano in un'esecuzione di osFoundry. L'autenticazione viene comunque caricata da CODEX_HOME. --ignore-rules tiene fuori anche i file di execpolicy .rules. Ogni esecuzione ha un tetto di tempo reale: 1.800 secondi per un'esecuzione autonoma, 300 secondi per la verifica del login. Quando il tempo scade, il processo figlio viene rilasciato e terminato. Prossimo passo Punta l'agente su un piccolo repository git, abilita gli agenti di codice per il workspace e dagli un compito che richieda sia un comando shell sia qualcosa dalla memoria di osFoundry. Così vedrai comparire Using shell e Using memory_search… nella stessa esecuzione. La pagina degli agenti di Studio mostra dove si trova Model Preference, e la build desktop è nella pagina di download.