Al terminar, Codex CLI irá recorriendo el canal de registros "Bugs" de uno de tus proyectos de osFoundry. Lee el schema del canal, pagina los elementos que siguen marcados como New, abre cada uno y rellena Status, Owner y Severity. Los cambios aparecen en la pestaña Data del canal como las ediciones de cualquier compañero, y cada llamada queda registrada en el Recent activity (actividad reciente) de la conexión. Cuando un valor no encaja en un campo, osFoundry rechaza la edición, y Codex deja ese campo para una persona en lugar de adivinar.
Quién hace qué
| Lado de Codex | Lado de osFoundry | |
|---|---|---|
| Inicio de sesión | Tu inicio de sesión de Codex, sin cambios. Codex guarda el token OAuth de osFoundry | Una conexión aprobada para un workspace |
| Qué canal | Codex lo encuentra con list_project_resources | Solo canales de registros de los proyectos a los que se añadió la conexión |
| Reglas de los campos | Codex las lee del schema que devuelve list_record_items | La pestaña Schema del canal: tipos de campo, Required, opciones de los select |
| Escrituras | edit_record_item, después del aviso de aprobación propio de Codex | Los valores se validan contra los campos. Un tipo incorrecto o una opción desconocida se rechaza |
| Conflictos | Codex vuelve a leer el elemento y decide de nuevo | expected_version tiene que coincidir con la versión actual del elemento |
| Filas y campos | Codex puede cambiar valores en elementos existentes | Añadir o borrar elementos y cambiar el schema se sigue haciendo en la app |
Configuración
Se da por hecho que Codex ya está conectado: la tabla [mcp_servers.osfoundry] está en ~/.codex/config.toml y codex mcp login osfoundry se completó. Los pasos de aquí son lo que añade un canal de registros encima de eso.
1. Pon el canal de registros en el proyecto conectado
Abre Records en la barra lateral y elige el canal. Un tracker nuevo se crea con Create Record Channel, Record Type Custom, que pide un nombre. En el canal, abre la pestaña Settings. El campo Project muestra "Add to project" mientras el canal no esté en ninguno. Elige el proyecto al que pertenece la conexión de Codex.
La conexión llega a un canal de registros a través de su proyecto. Si mueves el canal a otro proyecto, la siguiente llamada de Codex se rechaza.
2. Revisa el schema al que tendrá que ceñirse Codex
La pestaña Schema ("Define the fields for this record channel.") es el contrato. Cada campo tiene un tipo, un indicador Required opcional y, en Select y Multi-Select, una lista de opciones. Cada opción tiene un valor almacenado y una etiqueta. La tabla muestra la etiqueta. Codex tiene que enviar el valor.
Example: the Bugs channel ticket Text Required title Text Required status Select Required new · triaged · in_progress · fixed · wont_fix owner Select aiko · mika · ren severity Select s1 · s2 · s3 · s4 points Number min 0, max 13 area Multi-Select billing · auth · api · ui due Date age_days Formula computed Ejemplo: La pestaña Schema del canal de registros Bugs
Un campo Formula se calcula a partir de su expresión. Nadie lo escribe, tampoco Codex.
3. Añade la conexión al proyecto y revisa sus herramientas
Haz clic en el icono de la llave de la cabecera y abre Connected. Selecciona la conexión de Codex. En Projects, elige el proyecto y haz clic en Add to project (añadir al proyecto). Eso abre a esta conexión el contenido sincronizado del proyecto, canales de registros incluidos.
Más abajo, abre Tools. La checklist muestra los nombres de las herramientas con espacios, así que busca "list record items", "read record item", "edit record item" y "poll resource events". Todas las herramientas compatibles están activadas por defecto. Si de momento Codex solo debe leer, desmarca "edit record item" y haz clic en Save tools (guardar herramientas).
Ejemplo: La conexión Codex CLI con el proyecto "Product" añadido
4. Recorta lo que se le ofrece a Codex
Codex también filtra herramientas por su lado. Para el triaje bastan seis:
[mcp_servers.osfoundry] url = "https://api.osfoundry.io/api/v1/external-mcp" scopes = ["osfoundry:read", "osfoundry:write"] default_tools_approval_mode = "writes" enabled_tools = [ "list_granted_resources", "list_project_resources", "list_record_items", "read_record_item", "edit_record_item", "poll_resource_events", ] list_record_items, read_record_item y poll_resource_events están marcadas como de solo lectura en el servidor, así que con "writes" se ejecutan sin aviso. Codex pregunta antes de cada edit_record_item. En una pasada de 40 elementos son 40 avisos. También son 40 ocasiones de pararlo.
5. Pídelo con las reglas por escrito
In osFoundry, open the "Bugs" record channel in the Product project. Go through every item with status "new", newest first. For each one: read it, then set status to triaged, pick an owner by area (billing → aiko, auth → mika, everything else → ren) and a severity. Use the option values from the schema, not the labels. If osFoundry rejects a value, don't guess. Leave that field and list the item at the end. Una ejecución real
Codex no está instalado en la máquina en la que se escribió esto, así que la sesión de abajo es un ejemplo simulado. Los nombres de las herramientas y los argumentos son los que el servidor real lista en tools/list. Codex muestra las herramientas MCP al modelo como mcp__<server>__<tool>. El canal, los elementos y la respuesta son contenido de demostración.
Example (simulated) • mcp__osfoundry__list_project_resources {"project_id": "…", "resource_type": "record_channel", "search": "Bugs"} ← record channel "Bugs", id 4127 • mcp__osfoundry__list_record_items {"record_channel_id": "4127", "limit": 50} ← schema: 11 fields · 50 item previews · more before item 9811 • mcp__osfoundry__list_record_items {"record_channel_id": "4127", "before_id": "9811", "limit": 50} ← schema · 23 item previews · no more pages (38 of the 73 items have status "new") • mcp__osfoundry__read_record_item {"record_channel_id": "4127", "item_id": "9874"} ← BUG-1873 "Invoice PDF shows last month's total", area ["billing"], version "…14.208311Z" • mcp__osfoundry__edit_record_item {"record_channel_id": "4127", "item_id": "9874", "values": {"status": "triaged", "owner": "aiko", "severity": "s2"}, "expected_version": "…14.208311Z", "idempotency_key": "triage-9874"} [Codex asks: allow this tool call? → yes] ← saved … 36 more items … • mcp__osfoundry__edit_record_item {… "item_id": "9790", "values": {"status": "triaged", "owner": "ren", "severity": "s3", "points": 20}, …} ← rejected: points must be between 0 and 13 • mcp__osfoundry__read_record_item {… "item_id": "9790"} • mcp__osfoundry__edit_record_item {… "values": {"status": "triaged", "owner": "ren", "severity": "s3"}, …} ← saved • mcp__osfoundry__edit_record_item {… "item_id": "9802", …, "expected_version": "…02.551904Z"} ← rejected: the item changed after that version • mcp__osfoundry__read_record_item {… "item_id": "9802"} ← status "in_progress", owner "mika" (set by Mika in osFoundry a minute ago) Triaged 37 of 38 new items. BUG-1791's description says "about 20 points", but Points only goes to 13, so I left it empty. BUG-1805 was already in progress with Mika, so I didn't touch it. Aquí el trabajo lo hicieron dos rechazos. En este ejemplo, el campo Points tiene un máximo de 13, así que la edición que llevaba 20 se rechazó entera. Codex quitó ese campo y guardó el resto. No recortó 20 a 13, porque una estimación recortada parece una real. El segundo rechazo es la comprobación de versión. Mika había cogido el elemento entre la lectura y la escritura de Codex. Codex lo volvió a leer, vio el nuevo estado y el nuevo responsable, y los dejó como estaban en lugar de sobrescribir lo de ella con su plan.
La paginación fue por before_id. Cada página termina con el elemento más antiguo que contiene, y la siguiente pide los elementos anteriores a ese. Los bugs que se reportan mientras Codex lee no empujan elementos antiguos a la página siguiente, así que nada se lee dos veces.
Ejemplo: La pestaña Data después de la pasada, con Status y Owner rellenados
La pestaña Data muestra el resultado como siempre lo hace la tabla. Status aparece con la etiqueta de la opción, "Triaged", en el color de la opción si tiene uno, no como el valor almacenado triaged. Un elemento que cambió otra persona conserva los valores de esa persona.
Dónde está el límite
El schema es el límite para los valores. Codex solo puede meter en un campo lo que el campo acepta, y los campos select aceptan los valores de sus opciones. Las etiquetas "In progress" o "Aiko Tanaka" se rechazan, no se convierten. Convertirlas obligaría a adivinar. "major" podría significar S2, y "Won't fix" y wont_fix solo se parecen a ojos de una persona. Si quieres que Codex deje de preguntar por un campo, cambia el campo en la pestaña Schema. Codex no puede relajarlo desde fuera.
Codex edita valores y nada más. Por MCP no hay ninguna herramienta para añadir un elemento, borrar uno o añadir un campo. Cerrar duplicados y reorganizar el tracker se hace en la app, donde Versions y el historial propio del canal muestran quién lo hizo.
Cada llamada se comprueba al llegar. El estado de la conexión, el proyecto en el que está ahora el canal y tus propios permisos sobre él se evalúan en cada llamada. Un token emitido antes no mantiene el acceso abierto después de quitar el proyecto o de hacer clic en Revoke connection (revocar conexión). Solo se puede llegar a canales sincronizados y alojados. La respuesta initialize del servidor dice "Local-only data is unavailable to cloud clients."
osFoundry ve las llamadas, no la sesión. Recent activity lista el nombre de la herramienta, la decisión de acceso y la hora. El razonamiento de Codex y tu repositorio se quedan en tu máquina.
Siguiente paso
Lanza el mismo prompt a la mañana siguiente, pero empieza con poll_resource_events sobre el canal de registros desde la secuencia que Codex anotó al final de la pasada anterior. Devuelve los eventos del canal posteriores a esa secuencia, así que Codex vuelve a leer solo el puñado de elementos que cambiaron en lugar de todo el tracker. Cómo se ve un elemento en el lado de osFoundry, con su vista de formulario y su historial, está en la página de detalle de registros.







