Si el código fuente de un proyecto comercial no puede enviarse a un modelo en la nube, ¿qué puedo hacer todavía con ChatGPT en la web? ¿Puede consultar el estado del proyecto local o solicitar una comprobación SSH controlada? Y si el código sí puede alojarse en la nube, ¿por qué usar un MCP local?

La elección no depende de una herramienta concreta, sino de qué puede ver, dónde se ejecuta el trabajo y adónde vuelve el resultado.

En resumen: la aplicación web no lee automáticamente tu Mac. Si no entregas el código al modelo, puede aconsejarte a partir de resúmenes o estados que compartas explícitamente, pero no puede revisar ni depurar por sí sola un código que no ha visto.

Ejecutar Codex localmente no significa que la inferencia también sea local. Codex Cloud no es una conexión a tu Mac. Un túnel MCP reenvía solicitudes, pero no limita por sí mismo los permisos de las herramientas. GitHub Private controla el acceso al repositorio, no convierte un repositorio alojado en uno local. Si entregas código a un modelo en la nube, ese contexto entra en su perímetro de procesamiento. A continuación comparo las opciones y dos ejemplos públicos: VXI Local-First MCP y VXI SSH Ops Bridge. El primero comparte únicamente el estado del proyecto local; el segundo permite una sola operación SSH de solo lectura, definida de antemano.

Comparar las vías: ¿dónde está el espacio de trabajo y qué ve el modelo?

Vía	Espacio de trabajo y ubicación de ejecución	Qué puede ver el modelo en la nube	Uso adecuado
Codex Local environment de escritorio + MCP local	Proyecto/worktree, terminal y proceso MCP en el Mac	Depende del contexto que realmente se envíe al modelo; ejecución local no significa inferencia local	Leer/escribir archivos, ejecutar comandos y revisar diff dentro de los permisos concedidos, tras verificar el límite de datos del modelo
Codex Cloud / tarea web en la nube	Repositorio de GitHub seleccionado dentro de un espacio de trabajo aislado en la nube	Código fuente y archivos accesibles para la tarea	Modificar código, ejecutar comprobaciones y entregar una rama o resultado cuando el uso de GitHub y la nube esté autorizado
Agente de codificación en la nube de GitHub	Repositorio y entorno temporal del agente en la nube	Archivos del repositorio, contexto de la tarea y contenido accesible durante la ejecución	Colaboración mediante ramas, PR y comprobaciones
ChatGPT Web + Secure MCP Tunnel + Local-First MCP	El MCP se ejecuta localmente; el equipo inicia un túnel saliente	Solo los recuentos y estados que el MCP devuelve explícitamente	Compartir metadatos limitados sin conceder lectura del código ni acceso Shell
ChatGPT Web + Secure MCP Tunnel + SSH Ops Bridge	El puente MCP local y el cliente SSH conectan con un host configurado	Alias del destino y resultado filtrado de una comprobación fija	Solicitar una comprobación de solo lectura permitida en un destino que no sea de producción
Modelo web + relay local de coding-agent (por construir)	Un adaptador local delega en Codex u otro agente de codificación local	Depende de dónde se ejecute la inferencia y de lo que devuelva el adaptador	Diseño futuro posible, pero requiere controles propios de herramientas, salida, escritura, tiempos de espera y aprobación humana

Una limitación importante antes de continuar: la configuración del túnel descrita aquí se basa en la documentación oficial de OpenAI, pero el autor todavía no ha probado de extremo a extremo en su Mac real la conexión entre ChatGPT Web y el MCP local. Es una guía de configuración, no un tutorial de un clic verificado.

Elegir la vía antes de configurarla

• El código nunca debe enviarse a un modelo en la nube: mantén el trabajo a nivel de código en inferencia local u otro flujo local de confianza. Un MCP de solo metadatos puede compartir estados aprobados, pero un modelo en la nube que no ve el código no puede revisarlo de forma independiente.
• Solo necesitas que ChatGPT Web vea el estado local: usa una proyección de campos fijos como Local-First MCP; no necesita acceso de lectura al código ni Shell.
• Quieres solicitar desde la web una comprobación SSH fija: usa una operación con nombre, como SSH Ops Bridge, y conserva localmente la identidad del host, las claves privadas y la lista de destinos permitidos.
• El código puede alojarse y quieres que la IA lo lea y modifique: usa GitHub-first, Codex Cloud u otro agente en la nube autorizado, y deja ramas, PR, commits y CI como evidencia revisable.
• Quieres que la IA web delegue tareas de código al Codex local: debes construir y revisar un relay de agente local independiente. Ni el MCP de metadatos ni el puente SSH ofrecen esa capacidad.
• Los proyectos tienen clasificaciones de datos diferentes: elige la vía por proyecto. Poder alojar un repositorio del blog no significa que el código comercial pueda seguir el mismo camino.

Las herramientas web de otros proveedores deben verificarse individualmente: comprueba la vía de MCP remoto o agente local admitida, la autenticación, las capacidades del agente local y las entradas y resultados de herramientas que realmente llegan al modelo. Que una herramienta admita MCP no implica que pueda reutilizar Secure MCP Tunnel de OpenAI sin cambios.

Referencias oficiales: Codex Local environments, Codex Cloud environments, Codex MCP, OpenAI Secure MCP Tunnel y GitHub Copilot cloud agent.

Tres flujos de datos

A. La IA web consulta el estado del proyecto local

ChatGPT Web
    |
OpenAI Secure MCP Tunnel endpoint
    ^ tunnel-client local inicia HTTPS saliente
    |
vxi-local-first-mcp local (stdio MCP)
    |
directorio local: cuenta entradas; no lee el contenido del código

Devuelve: recuentos + PASS / FAIL / UNKNOWN
No devuelve: código, rutas, diff, registros ni comandos

B. La IA web solicita una comprobación SSH fija

ChatGPT Web
    |
OpenAI Secure MCP Tunnel endpoint
    ^ tunnel-client local inicia HTTPS saliente
    |
vxi-ssh-ops-bridge local (stdio MCP)
    |
cliente SSH local + clave privada + pinned known_hosts
    |
destino SSH no productivo: script fijo de solo lectura
    |
estados filtrados health / service / storage
    |
respuesta a la aplicación web

C. Desarrollo cloud GitHub-first

Repositorio GitHub autorizado para alojar código
    |
Codex Cloud / agente cloud de GitHub
    |
el espacio de trabajo cloud lee código, modifica archivos y ejecuta comprobaciones
    |
branch + PR + commit + CI
    |
revisión y aprobación humana

Son modelos operativos diferentes. Los dos primeros limitan lo que una herramienta web puede ver o solicitar. El tercero permite que la IA desarrolle a nivel de código dentro de un espacio de trabajo en la nube autorizado.

No confundas Codex Local, Codex Cloud y MCP

Codex Local environment en la aplicación de escritorio configura pasos de preparación y acciones habituales para un proyecto o worktree local. El terminal integrado ejecuta comandos localmente, y las herramientas Git permiten revisar diff, preparar archivos, hacer commit, push y crear PR. Un cliente Codex local también puede iniciar un servidor MCP local por stdio; en ese caso, un host MCP local inicia un servidor local y no hace falta un túnel web.

Pero «ejecución local» solo indica dónde se ejecutan los archivos y comandos. Si el modelo está alojado, el contexto del código usado para analizar puede enviarse a la nube. Para impedir estrictamente la salida del código se necesita inferencia local o un flujo local de confianza verificado, además de auditar por separado otros procesos y rutas de red del equipo.

Codex Cloud coloca el repositorio de GitHub seleccionado en un espacio de trabajo aislado en la nube, prepara dependencias y ejecuta tareas allí. Los agentes cloud de GitHub también pueden leer código, modificar ramas, ejecutar comprobaciones y crear PR en entornos cloud. Esta opción sirve para proyectos que pueden cruzar ese límite; no sustituye a mantener el código en el Mac.

Diferencia entre MCP host y MCP server

• ChatGPT de escritorio, Codex CLI y extensiones IDE como hosts MCP: pueden iniciar servidores locales por stdio mediante la configuración que admita cada cliente. El formato oficial del CLI es:

codex mcp add vxi-local-status \
  --env "VXI_WORKSPACE=/absolute/path/to/project" \
  -- /absolute/path/to/node /absolute/path/to/vxi-local-first-mcp/bin/vxi-local.mjs mcp

codex mcp list

Para SSH Ops Bridge, usa el mismo patrón, configura VXI_OPS_CONFIG con la ruta local de ops.config.json y apunta el comando al servidor vxi-ssh-ops-bridge/bin/vxi-ops.mjs. Los nombres de host, cuentas, rutas de claves privadas y ops.config.json deben permanecer locales. No pegues secretos de ejecución en el chat ni los subas a Git. La aplicación de escritorio, Codex CLI y las extensiones IDE compatibles pueden usar la configuración MCP del host Codex, según los permisos del espacio de trabajo.

• ChatGPT Web como cliente: la aplicación web no lee ~/.codex/config.toml local ni hereda automáticamente el menú de comandos de Codex local. Necesita una vía MCP remota compatible. Secure MCP Tunnel permite que un cliente local se conecte hacia fuera a un endpoint alojado por OpenAI y reenvíe solicitudes a un servidor MCP local por stdio o HTTP.

Conectar la web con un MCP local y solicitar SSH

La documentación de Secure MCP Tunnel de OpenAI describe un tunnel-client que se ejecuta en una red con acceso al servicio MCP privado. El cliente inicia HTTPS saliente, recibe solicitudes del endpoint alojado, las reenvía al servidor MCP local por stdio o HTTP y devuelve la respuesta por el mismo túnel. No hace falta abrir un puerto entrante público en el Mac.

Las rutas y los identificadores de túnel siguientes son marcadores de posición. Guarda las credenciales de ejecución únicamente en variables de entorno locales.

1. Crea o selecciona un túnel en OpenAI Platform. Comprueba la asociación entre el workspace de ChatGPT y la organización de Platform, además del permiso Tunnel necesario.
2. Descarga el tunnel-client actual desde la configuración del túnel de Platform. Consulta su ayuda/quickstart vigente y configura un perfil independiente para cada servidor MCP.
3. Antes de configurar el túnel, prueba cada servidor MCP sin conexión. Para Local-First MCP:

cd /path/to/vxi-local-first-mcp
node --version  # >= 22
npm test
npm run demo

Cuando las pruebas pasen, configura el perfil Local-First:

export CONTROL_PLANE_API_KEY="<runtime-key kept in the local terminal>"

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile vxi-local-status \
  --tunnel-id "<your-tunnel-id>" \
  --mcp-command "/usr/bin/env VXI_WORKSPACE=/absolute/path/to/project /absolute/path/to/node /absolute/path/to/vxi-local-first-mcp/bin/vxi-local.mjs mcp"

tunnel-client doctor --profile vxi-local-status --explain
tunnel-client run --profile vxi-local-status

Las rutas absolutas evitan depender de que un proceso en segundo plano tenga el mismo directorio de trabajo o PATH que una terminal interactiva.

Para SSH Ops Bridge, ejecuta primero npm test y npm run demo. Crea un ops.config.json local a partir de ops.config.example.json y cambia mode de disabled a read_only. Configura solo un destino no productivo verificado de forma independiente, una cuenta de pocos privilegios, la ruta local de la clave privada y un archivo known_hosts fijado. Instala el script de solo lectura en el host de prueba en /usr/local/bin/vxi-health-check según el README. Después configura otro perfil:

tunnel-client init \
  --sample sample_mcp_stdio_local \
  --profile vxi-ssh-readonly \
  --tunnel-id "<your-ssh-tunnel-id>" \
  --mcp-command "/usr/bin/env VXI_OPS_CONFIG=/absolute/path/to/ops.config.json /absolute/path/to/node /absolute/path/to/vxi-ssh-ops-bridge/bin/vxi-ops.mjs mcp"

tunnel-client doctor --profile vxi-ssh-readonly --explain
tunnel-client run --profile vxi-ssh-readonly

Las pantallas de Platform y las versiones del cliente pueden cambiar; consulta la ayuda de la versión instalada para conocer las opciones exactas.

4. Mantén activo tunnel-client run. En la entrada MCP personalizada compatible de ChatGPT, elige Add custom MCP server → Tunnel, selecciona el túnel disponible, autentícate y revisa la solicitud de permisos. Si el túnel no aparece, revisa la asociación de workspace/organización y los permisos en lugar de exponer el MCP local a Internet.
5. Llama primero a vxi_project_status o vxi_ops_policy, ambos de solo lectura, para confirmar que la herramienta aparece; solicita vxi_ssh_health solo si hace falta. No pruebes contra un host de producción y verifica la clave SSH por un canal independiente.

Qué hace localmente el puente SSH

El administrador local guarda el host, usuario, puerto, ruta de clave privada y known_hosts verificado de forma independiente en ops.config.json. El MCP acepta solo alias de la lista permitida local, como lab, no cadenas de comandos generadas por el modelo. El puente ignora la configuración SSH personal, desactiva agent forwarding y las solicitudes interactivas de contraseña, ejecuta el script fijo /usr/local/bin/vxi-health-check y reduce la respuesta a tres estados.

La aplicación web no recibe la clave privada ni inicia sesión directamente en el servidor: solicita una operación fija. El túnel transporta la petición, mientras que la lista de herramientas, la validación de entradas, la configuración local, la vinculación de la clave del host y el script remoto definen conjuntamente el límite de permisos.

Si detrás del MCP se coloca un agente local que puede editar código, hay que revisar por separado sus herramientas, entradas, salidas, escrituras de archivos, ejecución de comandos, tiempos de espera y aprobaciones humanas. La evaluación de seguridad de un MCP SSH restringido no se transfiere automáticamente a un relay de coding-agent con escritura.

Qué hace cada uno de los dos repositorios públicos

VXI Local-First MCP: compartir solo metadatos del proyecto local

Abrir el repositorio

El MCP local por stdio expone dos herramientas de solo lectura:

• vxi_project_status: recuentos por categoría de archivo, cantidad de enlaces simbólicos omitidos y estados de lint/test/build registrados manualmente (PASS / FAIL / UNKNOWN; el valor inicial es UNKNOWN). El MCP no ejecuta pruebas. El escaneo acotado omite directorios ocultos y directorios habituales de compilación/caché como .git, node_modules y dist. Procesa como máximo 20.000 entradas de directorio; si se supera el límite, genera un error en lugar de devolver recuentos parciales. No es un inventario completo de todos los archivos posibles del proyecto.
• vxi_security_contract: describe los campos permitidos y prohibidos en la respuesta.

El escáner clasifica entradas del directorio sin leer el contenido del código fuente. La proyección fija no incluye código, rutas, diff, registros, variables de entorno ni interfaz Shell. Permite que el modelo cloud vea un estado limitado; no cifra y sube el código.

record es un comando CLI local, no una herramienta MCP, y no ejecuta pruebas. Ejemplo:

node bin/vxi-local.mjs record --workspace /path/to/project --kind test --status PASS

kind puede ser lint, test o build, y el estado lo introduce el operador. Solo sirve para proporcionar contexto aproximado de las comprobaciones locales sin subir código ni registros sin filtrar. No diagnostica fallos ni constituye una prueba firmada de test vinculada a un commit. Para depurar, revisa los registros completos localmente o comparte un resumen mínimo de error seleccionado y redactado manualmente.

VXI SSH Ops Bridge: solo operaciones SSH fijas de solo lectura

Abrir el repositorio

El puente está desactivado por defecto y solo expone vxi_ops_policy y vxi_ssh_health. Esta última acepta un alias de la lista local permitida, ejecuta un script remoto fijo y filtra la respuesta a los estados health, service y storage. El health: PASS del script de ejemplo solo demuestra que el script fijo se ejecutó; service y storage siguen en UNKNOWN hasta instalar y verificar comprobaciones específicas de la aplicación. No ofrece exec(command) genérico, transferencia de archivos, despliegue, reinicio ni exportación arbitraria de registros.

Los repositorios son independientes. Uno comparte estado del proyecto local y el otro permite una comprobación SSH fija. Ninguno incluye herramientas para editar código ni llama al otro.

¿Qué demuestra realmente una prueba en verde?

Las cifras siguientes corresponden a repositorios y niveles de prueba distintos; no son la misma suite contada varias veces:

• Local-First MCP: main tiene 6 pruebas unitarias (CI de referencia). PR #3 añade una matriz Ubuntu/macOS, no nuevos casos; las mismas seis pruebas pasan 6/6 en ambos sistemas (CI de PR #3).
• SSH Ops Bridge: main tiene 7 pruebas unitarias (CI de referencia). PR #3 conserva esas siete y añade un trabajo de integración OpenSSH localhost separado en un Runner Ubuntu alojado en GitHub de un solo uso. Pasan las pruebas unitarias y las comprobaciones SSH de bucle local (CI de PR #3).
• SSH Ops Bridge PR #4: añade un caso de prueba a los siete existentes para cubrir valores host/user ausentes o de tipo incorrecto, junto con la validación de cadenas correspondiente. En esa rama Draft todavía sin fusionar pasan las 8/8 pruebas unitarias y la demo (CI de PR #4).

El fixture de bucle local reveló problemas reales de diseño de pruebas: al principio, el usuario del Runner y la configuración PAM no coincidían y la autenticación fallaba. Más tarde se descubrió que un ForceCommand del servidor podía sobrescribir la solicitud del cliente y producir un falso positivo aunque el comando previsto no se ejecutara. Tras corregirlo, el fixture no configura ForceCommand: el cliente SSH real ejecuta el script remoto fijo generado. Las pruebas comprueban tanto las llamadas directas como los resultados MCP y rechazan una clave de host fijada incorrecta y solicitudes exec arbitrarias.

Estos resultados solo corresponden a las versiones exactas enlazadas. En el momento de la revisión, los tres PR de código siguen abiertos como Draft y sin fusionar. La matriz multiplataforma y el trabajo de bucle local del PR #3, así como la corrección de validación del PR #4, todavía no forman parte de main.

Conclusión: elige por el límite de datos, no por el nombre de la herramienta

Si el código puede entrar en la nube, GitHub-first permite que la IA lea y modifique código y deja evidencia de ingeniería revisable mediante ramas, PR, commits y CI. Si el código debe permanecer local, Local-First MCP puede compartir el estado con un modelo web y SSH Ops Bridge puede ofrecer una única operación remota de solo lectura. El desarrollo a nivel de código sigue necesitando una persona local, inferencia local u otro flujo local revisado.

El límite que importa no es simplemente «usar una herramienta local» o «conectar MCP». Es qué envía realmente cada vía al modelo, qué operaciones puede solicitar y adónde termina la respuesta.

Ambos repositorios siguen siendo prototipos mínimos. El túnel no se ha verificado en el Mac real del autor; tampoco se ha probado un host SSH externo, auditado todo el dispositivo en busca de salida de código, verificado una inferencia genuinamente local ni comparado calidad, latencia, uso de tokens y coste en la misma tarea.