Al terminar, Codex CLI podrá hacer dos trabajos en un repositorio de GitNest en osFoundry. Escribe en una rama archivos que salen de tu sesión de terminal, y saca un change set terminado como pull request, ya sea dentro de GitNest o como borrador en GitHub o GitLab. Codex no hace commit ni push de nada por su cuenta. Cada trabajo llega como una tarjeta en "Needs your approval" de la conexión Codex CLI, con los archivos, la rama o el commit exacto impresos en ella. No pasa nada hasta que el propietario del repositorio hace clic.
Quién hace qué
| Codex CLI | osFoundry | |
|---|---|---|
| Inicio de sesión | Tu sesión de Codex. Codex guarda un token OAuth de osFoundry con osfoundry:read y osfoundry:write
|
El propietario aprobó la conexión una sola vez, en la pestaña Connected |
| Qué puede enviar | Hasta 20 archivos UTF-8, 200 KB en total, para una rama. O un ID de change set fijado a una versión y a un commit compuesto | Guarda cada petición como una propuesta con caducidad |
| Quién aprueba | Codex te pregunta antes de cada llamada de escritura (default_tools_approval_mode = "writes") |
El propietario de la conexión hace clic en Approve and create, o en Approve and publish, mientras siga teniendo el rol en el repositorio |
| Quién escribe | Nadie del lado de Codex | osFoundry hace el commit, o abre el pull request, después de la aprobación |
| Tokens del proveedor | Nunca se envían | Al aprobar se usa la cuenta de GitHub o GitLab vinculada del propietario, solo para la rama propia del change set |
| Merge | Fuera de su alcance | Queda en manos de personas, en GitNest o en el proveedor |
Configuración
1. Limita Codex a las herramientas de GitNest
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 aparece en cada tarjeta y en cada notificación, así que elige uno que el propietario reconozca.
Del lado de Codex:
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"]
default_tools_approval_mode = "writes"
enabled_tools = [
"list_granted_resources",
"read_gitnest_repository",
"list_gitnest_work",
"list_gitnest_checks",
"propose_gitnest_file_import",
"propose_gitnest_native_publication",
"propose_gitnest_provider_publication",
]
codex mcp login osfoundry
El servidor expone 59 herramientas. Estas siete son las que necesita esta guía. Las tres herramientas propose_ son las únicas que no están marcadas como de solo lectura, así que con "writes" Codex ejecuta las cuatro de lectura por su cuenta y se detiene a preguntarte antes de cada propuesta. Son dos aprobaciones seguidas: la tuya en la terminal y luego la del propietario en osFoundry. Si el propietario eres tú, la primera es solo una comprobación de que Codex va a pedir lo que querías.
2. Pon el repositorio en un proyecto donde esté la conexión
Una conexión solo ve un repositorio de GitNest a través de un proyecto. En GitNest, abre el repositorio y busca la sección Project. Solo el propietario del repositorio tiene el selector. Elige el proyecto y aparecerá el aviso "Repository project updated". Después, en la pestaña Connected, selecciona Codex CLI y, en Projects, haz clic en Add to project para ese mismo proyecto.
La importación de archivos además necesita un repositorio nativo de GitNest, es decir, uno cuyo Git vive en osFoundry. La descripción de la herramienta lo dice sin rodeos: "Repository GitNest must be enabled." Un repositorio que solo refleja GitHub va por la otra vía, la del change set y la publicación en el proveedor.
3. Para GitHub o GitLab, vincula la cuenta del proveedor
propose_gitnest_provider_publication hace push con la cuenta de proveedor Git vinculada del propietario, en el momento en que el propietario aprueba. Si no hay ninguna cuenta vinculada, esa aprobación no tiene con qué hacer push. Codex nunca necesita un token de GitHub para nada de esto.
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 salen del tools/list del servidor real, con el prefijo mcp__osfoundry__ que añade Codex. El repositorio, los archivos, los IDs y las respuestas son contenido de demostración.
Example (simulated)
> shop-api has no CI. In osFoundry, put a GitHub Actions workflow that runs
`make test` on pull requests, plus the Makefile target, on a branch
codex/ci-workflow.
• mcp__osfoundry__list_granted_resources {}
← project "Checkout" · GitNest repository "shop-api"
• mcp__osfoundry__read_gitnest_repository {"repository_id": "…"}
← native, GitNest enabled, default branch main
• mcp__osfoundry__propose_gitnest_file_import {
"repository_id": "…", "branch": "codex/ci-workflow",
"message": "Add CI workflow and make test target",
"files": [
{"path": ".github/workflows/ci.yml", "content": "name: ci\non: [pull_request]\n…"},
{"path": "Makefile", "content": "test:\n\tpython -m pytest -q\n"}],
"idempotency_key": "codex-shop-api-ci-0001"}
[Codex asks: allow this tool call? → yes]
← proposal waiting for the owner
I prepared one commit for shop-api on codex/ci-workflow with two files.
Nothing is committed yet. The owner approves it in osFoundry.
En osFoundry, la campana muestra "Codex CLI proposes GitNest file changes". En el panel de la conexión, la tarjeta dice "Commit GitNest files in shop-api", después "Commit to branch: codex/ci-workflow" y el mensaje del commit. "Review all proposed files (2)" se despliega con el texto completo de cada archivo, no con un resumen del diff. Approve and create hace el commit. Decline lo descarta.
Ejemplo: la tarjeta Commit GitNest files de shop-api con los dos archivos propuestos desplegados
Más tarde, ese mismo día, con un change set ya compuesto en GitNest:
Example (simulated)
> Is the "Add CI workflow" change set green? If so, open it on GitHub as a draft PR.
• mcp__osfoundry__list_gitnest_work {"repository_id": "…", "kind": "changes"}
← "Add CI workflow" · version 3
• mcp__osfoundry__list_gitnest_checks {"repository_id": "…", "change_set_id": "…"}
← composed commit 73e59f27bc4f…: unit passed · lint passed
• mcp__osfoundry__propose_gitnest_provider_publication {
"repository_id": "…", "change_set_id": "…",
"expected_change_set_version": 3,
"expected_composition_oid": "73e59f27bc4f…",
"idempotency_key": "codex-shop-api-ci-pr-0001"}
[Codex asks: allow this tool call? → yes]
← proposal waiting for the owner
Both checks passed on the composed commit. I asked for a draft GitHub PR of
version 3; it opens when the owner approves it in osFoundry.
Codex no elige rama, título ni destino para el pull request. El esquema solo admite el change set, la versión que leyó y el commit compuesto que leyó. Si pide draft: false o un target_branch distinto, la petición se rechaza antes de llegar a nadie.
La tarjeta se titula "Open a draft GitHub or GitLab pull request in shop-api". Muestra "Change set: … · expected version 3", "Reviewed commit: 73e59f27bc4f…", un enlace "Review change set before approving" y una línea sobre lo que hace la aprobación: "uses your linked Git provider account to push this change-set branch and open a draft pull request". El botón es Approve and publish. Para un repositorio que vive en GitNest, propose_gitnest_native_publication genera la tarjeta hermana, "Publish GitNest pull request", que "creates a publication branch and opens a pull request in this native repository".
Ejemplo: una tarjeta de pull request en el proveedor y una tarjeta de publicación nativa en Needs your approval
El enlace de la tarjeta abre el change set en GitNest. Los checks de su commit compuesto están arriba, encima de las pestañas de revisión, así que el propietario ve lo mismo que vio Codex antes de decidir.
Dónde está el límite
Una importación de archivos solo lleva texto. Cada entrada es una ruta y su contenido completo, nada más. No hay modo de archivo, ni borrado, ni binarios, y el commit entero se queda dentro de 20 archivos y 200 KB. Así cada byte se puede leer en la tarjeta. La subida que hace el propio propietario desde el navegador en GitNest llega mucho más lejos (2,000 archivos, 8 MB cada uno, 32 MB en total), porque ahí es una persona haciendo commit de sus propios archivos.
La publicación parte de un change set compuesto, no de una rama que nombre Codex. La tarjeta fija la versión y el commit que Codex miró. Si el change set se vuelve a componer antes del clic, la nueva comprobación de osFoundry rechaza la propuesta en lugar de publicar algo que nadie revisó. Al aprobar, también comprueba los permisos actuales, los niveles de riesgo y los checks obligatorios del repositorio, y el destino. Esas reglas las definen personas en GitNest, en Risk tiers y Required checks, y Codex no puede tocarlas.
En GitHub o GitLab solo se mueve la rama propia del change set. El pull request se abre como borrador, y el push usa la cuenta vinculada del propietario en el momento de aprobar. Codex nunca ve ese token, y tus otras ramas no forman parte del push.
El merge no está en la lista. Lo más lejos que llega cualquiera de estas propuestas es a un pull request abierto. Quién lo fusiona, y lo que ese merge desencadene, queda en manos de las personas del repositorio.
Las dos herramientas de publicación llevan openWorldHint: true en tools/list, y la importación de archivos no. Un pull request lo ve gente que está fuera de la conversación. Un cliente bien hecho lo toma como motivo para preguntar antes, como hace Codex aquí.
Como siguiente paso, prueba la importación en una rama que nadie use todavía. Pide a Codex que proponga un único archivo nuevo, un CONTRIBUTING.md o un workflow de CI, abre "Review all proposed files" en la tarjeta y apruébalo. La página de GitNest explica cómo encajan los change sets, los checks y la publicación del lado del repositorio.
Top comments (0)