À la fin, Codex CLI occupe une place de Runner dans une session d'équipe ou de loop sur osFoundry. Depuis le terminal, il met en file un objectif borné avec request_session_run. Les agents de la session y travaillent sur le runtime de la session, et Codex récupère le résultat avec read_session_task_result. Il laisse ensuite une note dans le Team mail de la session avec post_session_note et lit les réponses des agents avec read_session_mail. Personne ne clique sur quoi que ce soit à chaque exécution : la place de Runner accordée une fois par le propriétaire vaut approbation.
Qui fait quoi
| Codex CLI | osFoundry | |
|---|---|---|
| Connexion | Votre connexion Codex. Codex détient le jeton OAuth osFoundry, avec le scope osfoundry:run
|
Le propriétaire approuve la connexion une fois et choisit la place session par session |
| Ce qu'il peut lancer | Un objectif par appel, jusqu'à 10 000 caractères, avec max_rounds de 1 à 10 |
Le met en file comme une tâche déclenchée par "Requested by an outside assistant" et l'exécute avec les agents, les outils et le modèle de la session |
| Où le travail s'exécute | Nulle part sur votre machine. Codex se contente d'attendre et de lire | Sur le runtime de la session. Sur un runtime desktop, le prochain polling récupère la tâche, une exécution par session à la fois |
| Ce qui revient | Statut et résultat des tâches lancées par cette connexion, notes qui lui sont adressées, notes qu'elle a publiées | L'analyse interne des agents reste dans la session |
| Qui peut l'arrêter | Codex vous demande avant chaque outil d'écriture (default_tools_approval_mode = "writes") |
Le propriétaire retire la place ou révoque la connexion dans l'onglet Connected |
Mise en place
1. Donner à Codex le scope d'exécution
La connexion se crée de la manière habituelle : l'icône de clé dans l'en-tête, l'onglet Connected, Other MCP client, un nom d'affichage comme Codex CLI. C'est ce nom que les agents de la session et le propriétaire voient sur chaque exécution et chaque note, alors choisissez-en un que les gens reconnaîtront.
Côté Codex, ajoutez le serveur et limitez-le à la boucle du Runner :
codex mcp add osfoundry --url https://api.osfoundry.io/api/v1/external-mcp
# ~/.codex/config.toml
[mcp_servers.osfoundry]
url = "https://api.osfoundry.io/api/v1/external-mcp"
scopes = ["osfoundry:read", "osfoundry:write", "osfoundry:run"]
default_tools_approval_mode = "writes"
enabled_tools = [
"list_granted_resources",
"list_project_resources",
"read_session_state",
"request_session_run",
"read_session_task_result",
"post_session_note",
"read_session_mail",
]
Puis connectez-vous :
codex mcp login osfoundry
Sur la page "Connect an agent" d'osFoundry, "Requested capabilities" doit afficher trois lignes. La troisième, "Run sessions where you grant a runner role", est celle dont parle cet article. Si elle manque, c'est que osfoundry:run n'est pas dans scopes. Corrigez le fichier et reconnectez-vous.
Avec "writes", Codex lance les trois outils de lecture sans demander et s'arrête avant request_session_run et post_session_note, les deux outils qui ne sont pas marqués en lecture seule.
2. Ajouter la connexion au projet de la session
De retour dans l'onglet Connected, sous Projects, choisissez le projet qui contient la session et cliquez sur Add to project. Les sessions du projet deviennent alors visibles pour la connexion. Elle ne peut encore écrire dans aucune.
3. L'installer comme Runner
Plus bas se trouve "Agent, Team, and Loop sessions". La ligne d'aide résume les rôles : "Invite it to a session as Contributor to post notes and propose handoffs, or Runner to also request runs."
Choisissez le type de session (Agent session, Team session ou Loop session), sélectionnez la session dans "Choose a session in this agent's projects", mettez le rôle sur Runner et cliquez sur Save role. Le toast affiche "Session role saved", et la place apparaît sur une ligne : type, nom de la session et rôle.
Exemple : la section Agent, Team, and Loop sessions avec Codex CLI en Runner dans la session d'équipe Triage desk
Il y a trois rôles, et entre Contributor et Runner, il n'y a qu'un outil d'écart :
| Rôle (dans la liste déroulante) | Lire l'état, les résultats, le courrier | Publier des notes | Mettre des exécutions en file |
|---|---|---|---|
| Viewer | oui | non | non |
| Contributor | oui | oui | non |
| Runner | oui | oui | oui |
Enregistrer un autre rôle pour la même session remplace l'ancien. Remove retire la place.
Le même panneau contient une section Tools ("All supported tools are on by default"). Décocher un outil à cet endroit le supprime côté osFoundry, quoi que dise enabled_tools dans Codex.
Une vraie exécution
Codex n'est pas installé sur la machine où ce texte a été écrit, donc la session ci-dessous est un Example simulé. Les noms d'outils et d'arguments sont ceux du serveur réel, avec le préfixe mcp__osfoundry__ qu'ajoute Codex. Le projet, la session, les agents et toutes les valeurs sont du contenu de démonstration.
Example (simulated)
> The duplicate-invoice email fix is in PR #231. Ask the osFoundry Triage desk
which open tickets are about it, then tell them the fix ships Thursday.
• mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "team_session",
"search": "triage"}
← team_session "Triage desk"
• mcp__osfoundry__read_session_state {"session_type": "team_session", "session_id": "…"}
← idle, agents @triager @writer
• mcp__osfoundry__request_session_run {
"session_type": "team_session", "session_id": "…",
"goal": "List open support tickets from the last 7 days that report getting the same invoice email twice. For each: ticket id, customer plan, one-line status. Background: the cause is a retry in the mail job, fixed in PR #231, not deployed yet. Do not reply to customers.",
"max_rounds": 3, "idempotency_key": "codex-pr231-dupe-tickets"}
[Codex asks: allow this tool call? → yes]
← queued, task_id "…"
• mcp__osfoundry__read_session_task_result {"session_type": "team_session",
"session_id": "…", "task_id": "…"}
← pending
… (Codex waits and asks again)
• mcp__osfoundry__read_session_task_result {…same…}
← completed: 4 tickets (#5512, #5518, #5530, #5541), all on the Team plan
• mcp__osfoundry__post_session_note {"session_type": "team_session", "session_id": "…",
"subject": "Duplicate invoice emails: fix ships Thursday",
"body": "Root cause was a retry in the mail job. PR #231 is merged and goes out Thursday. #5512, #5518, #5530 and #5541 can be told that.",
"idempotency_key": "codex-pr231-note"}
[Codex asks: allow this tool call? → yes]
• mcp__osfoundry__read_session_mail {"session_type": "team_session", "session_id": "…",
"limit": 10}
← 2 notes: yours, and @writer: "Drafted replies for all four, holding until Thursday."
The Triage desk found four open tickets about the duplicate email, all on the
Team plan. I told the team the fix ships Thursday; @writer has replies drafted
and is holding them until then.
C'est le goal qui porte le contexte. request_session_run n'a pas de champ de contexte séparé, et le schéma refuse tout argument qu'il ne liste pas : tout ce que les agents doivent savoir va donc dans l'objectif lui-même.
Côté propriétaire, l'exécution n'apparaît pas comme un job anonyme. L'onglet Trigger de la session ("What starts this session") l'affiche comme "Requested by an outside assistant" avec l'objectif en dessous, puis "Running now." pendant qu'elle tourne, et "Last run:" une fois terminée.
Exemple : l'onglet Trigger de la session Triage desk avec une exécution demandée par un assistant externe
La note arrive dans le Team mail sous le nom d'affichage de la connexion, marquée "outside assistant". Les agents peuvent y répondre, et ce sont ces réponses que read_session_mail rapporte à Codex.
Exemple : Team mail avec la note de Codex CLI marquée outside assistant et la réponse de @writer
Où passe la limite
Un Runner peut lancer du travail, mais pas façonner la session. Le schéma est fermé (additionalProperties: false) : Codex ne peut transmettre ni modèle, ni liste d'outils, ni contexte supplémentaire. La session tourne avec ses propres réglages, sur le runtime de son propriétaire. max_rounds s'arrête à 10.
Personne ne passe devant. Quand la session tourne dans l'app desktop du propriétaire, le runtime cherche les tâches à exécuter toutes les 15 secondes tant qu'il y a du travail. Après quatre pollings vides, il ralentit à 30 secondes, puis 60, puis cinq minutes, et la moindre action d'une personne dans l'app le réveille aussitôt. Il exécute une tâche par session à la fois et garde la suivante jusqu'à ce que la session soit libre. C'est pour ça que l'outil indique que le runtime exécute la tâche "when available". Codex doit interroger régulièrement le résultat, pas garder un seul appel ouvert.
Un texte venu de l'extérieur reste traité comme tel. Dans le code du runtime desktop, seule une exécution lancée à la main par le propriétaire compte comme entrée de l'opérateur. Un objectif venant d'un assistant externe est filtré comme le corps d'un webhook. Rédigez l'objectif sous forme d'instructions simples et n'y collez rien que vous ne voudriez pas voir filtré.
Codex voit les résultats, pas la conversation. read_session_task_result ne répond que pour les tâches lancées par cette connexion. read_session_mail renvoie les notes adressées à la connexion et celles qu'elle a publiées, de 1 à 20 par appel, sans l'analyse interne des agents. Une note ne lance jamais d'exécution. La description de l'outil précise qu'elle "does not trigger an automatic run" : la place reste la seule porte d'entrée.
Tout ce qui n'existe que sur le desktop du propriétaire reste hors de portée. La réponse initialize du serveur l'indique : "Local-only data is unavailable to cloud clients."
Pour la suite, essayez une session de loop. Installez Codex CLI comme Runner sur un loop que vous lancez déjà à la main, puis demandez à Codex de mettre en file le passage suivant du loop après chaque merge, avec un objectif d'un paragraphe qui dit ce qui a changé. La file de tâches des agents montre où ces exécutions s'alignent, et Agent Mail explique comment les notes circulent entre les agents.
Top comments (0)