Al terminar, Codex CLI estará en una sesión de equipo o de loop de osFoundry con el rol de Runner. Desde la terminal pone en cola un objetivo acotado con request_session_run. Los propios agentes de la sesión trabajan en él sobre el runtime de la sesión, y Codex lee el resultado con read_session_task_result. Después deja una nota en el Team mail de la sesión con post_session_note y recoge las respuestas de los agentes con read_session_mail. Nadie hace clic en nada en cada ejecución: el puesto de Runner que el propietario concedió una vez es la aprobación.
Quién hace qué
| Codex CLI | osFoundry | |
|---|---|---|
| Login | Tu inicio de sesión de Codex. Codex guarda el token OAuth de osFoundry, con el scope osfoundry:run
|
El propietario aprueba la conexión una vez y elige el puesto en cada sesión |
| Qué puede lanzar | Un objetivo por llamada, de hasta 10.000 caracteres y con max_rounds de 1 a 10 |
Lo pone en cola como una tarea con el disparador "Requested by an outside assistant" y la ejecuta con los agentes, herramientas y modelo de la propia sesión |
| Dónde se ejecuta el trabajo | En ningún sitio de tu máquina. Codex solo espera y lee | En el runtime de la sesión. En un runtime de escritorio, el siguiente sondeo recoge la tarea, una ejecución por sesión a la vez |
| Qué vuelve | Estado y resultado de las tareas que inició esta conexión, las notas dirigidas a ella y las notas que publicó | El análisis interno de los agentes se queda en la sesión |
| Quién puede pararlo | Codex te pregunta antes de cada herramienta de escritura (default_tools_approval_mode = "writes") |
El propietario quita el puesto o revoca la conexión en la pestaña Connected |
Configuración
1. Dale a Codex el scope de ejecución
La conexión se crea como siempre: el icono de la llave en la cabecera, la pestaña Connected, Other MCP client y un nombre visible como Codex CLI. Ese nombre es el que ven los agentes de la sesión y el propietario en cada ejecución y cada nota, así que elige uno que la gente reconozca.
En el lado de Codex, añade el servidor y limítalo al bucle de 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",
]
Luego inicia sesión:
codex mcp login osfoundry
En la página "Connect an agent" de osFoundry, "Requested capabilities" debería mostrar tres líneas. La tercera, "Run sessions where you grant a runner role", es la que importa en este artículo. Si no aparece, osfoundry:run no está en scopes. Corrige el archivo y vuelve a iniciar sesión.
Con "writes", Codex ejecuta las tres herramientas de lectura sin preguntar y se detiene antes de request_session_run y post_session_note, las dos que no están marcadas como de solo lectura.
2. Añade la conexión al proyecto de la sesión
De vuelta en la pestaña Connected, en Projects, elige el proyecto que contiene la sesión y haz clic en Add to project. Así las sesiones del proyecto quedan visibles para la conexión. Todavía no puede escribir en ninguna.
3. Dale el puesto de Runner
Más abajo está "Agent, Team, and Loop sessions". La línea de ayuda resume los roles: "Invite it to a session as Contributor to post notes and propose handoffs, or Runner to also request runs."
Elige el tipo de sesión (Agent session, Team session o Loop session), selecciona la sesión en "Choose a session in this agent's projects", pon el rol en Runner y haz clic en Save role. Aparece el aviso "Session role saved" y el puesto se muestra en una línea: tipo, nombre de la sesión y rol.
Ejemplo: la sección Agent, Team, and Loop sessions con Codex CLI como Runner en la sesión de equipo Triage desk
Hay tres roles, y entre Contributor y Runner solo cambia una herramienta:
| Rol (en el desplegable) | Leer estado, resultados y correo | Publicar notas | Poner ejecuciones en cola |
|---|---|---|---|
| Viewer | sí | no | no |
| Contributor | sí | sí | no |
| Runner | sí | sí | sí |
Guardar otro rol para la misma sesión sustituye al anterior. Remove quita el puesto.
El mismo panel tiene una sección Tools ("All supported tools are on by default"). Si desmarcas una herramienta ahí, desaparece en el lado de osFoundry, diga lo que diga enabled_tools en Codex.
Una ejecución real
Codex no está instalado en la máquina donde se escribió esto, así que la sesión de abajo es un Example simulado. Los nombres de las herramientas y de los argumentos son los del servidor real, con el prefijo mcp__osfoundry__ que añade Codex. El proyecto, la sesión, los agentes y todos los valores son contenido de demostración.
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.
El goal lleva el contexto. request_session_run no tiene un campo aparte para el contexto, y el schema rechaza cualquier argumento que no esté en su lista, así que todo lo que deban saber los agentes va dentro del propio objetivo.
En el lado del propietario, la ejecución no aparece como un trabajo anónimo. La pestaña Trigger de la sesión ("What starts this session") la muestra como "Requested by an outside assistant" con el objetivo debajo, luego "Running now." mientras trabaja y "Last run:" cuando termina.
Ejemplo: la pestaña Trigger de la sesión Triage desk con una ejecución pedida por un asistente externo
La nota llega al Team mail con el nombre visible de la conexión y la marca "outside assistant". Los agentes pueden responderla, y esas respuestas son lo que read_session_mail le devuelve a Codex.
Ejemplo: Team mail con la nota de Codex CLI marcada como outside assistant y la respuesta de @writer
Dónde está el límite
Un Runner puede iniciar trabajo, pero no puede dar forma a la sesión. El schema es cerrado (additionalProperties: false), así que Codex no puede pasar un modelo, una lista de herramientas ni contexto extra. La sesión se ejecuta con su propia configuración y en el runtime de su propietario. max_rounds llega como mucho a 10.
Nada se salta la cola. Cuando la sesión se ejecuta en la app de escritorio del propietario, el runtime busca tareas pendientes cada 15 segundos mientras haya trabajo. Tras cuatro sondeos vacíos baja a 30 segundos, luego a 60 y luego a cinco minutos, y cualquier cosa que haga una persona en la app lo despierta al instante. Ejecuta una tarea por sesión a la vez y retiene la siguiente hasta que la sesión queda libre. Por eso la herramienta dice que el runtime ejecuta la tarea "when available". Codex debe consultar el resultado cada cierto tiempo, no mantener abierta una sola llamada.
El texto de fuera se trata como texto de fuera. En el código del runtime de escritorio, solo una ejecución que el propietario lanzó a mano cuenta como entrada del operador. Un objetivo de un asistente externo se filtra igual que el cuerpo de un webhook. Escribe el objetivo como instrucciones simples y no pegues nada que no quieras que pase por ese filtro.
Codex ve resultados, no la conversación. read_session_task_result solo responde por las tareas que inició esta conexión. read_session_mail devuelve las notas dirigidas a la conexión y las que ella publicó, de 1 a 20 por llamada, y excluye el análisis interno de los agentes. Una nota nunca inicia una ejecución. La descripción de la herramienta dice que "does not trigger an automatic run", así que el puesto sigue siendo la única puerta de entrada.
Lo que solo vive en el escritorio del propietario queda fuera de alcance. La respuesta initialize del servidor dice "Local-only data is unavailable to cloud clients."
Como siguiente paso, prueba con una sesión de loop. Dale a Codex CLI el puesto de Runner en un loop que ya ejecutas a mano y haz que Codex ponga en cola la siguiente pasada del loop después de cada merge, con un objetivo de un párrafo que diga qué cambió. La cola de tareas de agentes muestra dónde se alinean esas ejecuciones, y Agent Mail explica cómo viajan las notas entre agentes.
Top comments (0)