En una frase: convertir ChatGPT web en el único cerebro principal, que impulse una Session nativa real de Claude Code en la máquina local para completar lectura, modificación, verificación y recuperación controladas.
El repositorio público solo contiene código fuente y pruebas, no incluye claves locales, configuración de Tunnel ni el estado de sesión de state/.
Gateway ahora tiene un único motor de ejecución: Native V2.
当前 ChatGPT Chat（唯一主脑）
↔ Claude Tools Native MCP（六个 Session 控制工具）
↔ 本地模型回合桥（127.0.0.1）
↔ 隔离的 Claude Code 原生 Session
→ 原生 Agent loop
→ 网关自有的受控工具 ExecutorGateway realiza por sí mismo la inicialización de MCP, el inventario de herramientas y la distribución de llamadas; ya no inicia ni actúa como proxy del servidor de herramientas claude mcp serve de V1. Solo después de crear una Session nativa se inicia el proceso de Claude Code exclusivo de esa Session.
La antigua Agent Session de V1, las herramientas de nivel superior Read/Edit/Write/Bash, las herramientas de tareas locales, la antigua delegación a DeepSeek y el ChatGPT Bridge se han eliminado del punto de entrada de ejecución y del árbol de código. Lo que se conserva son las infraestructuras comunes de nivel inferior que V2 aún necesita: escritura atómica de estado, protección de rutas de credenciales, verificación de identidad de procesos y reglas de sandbox de macOS. Los antiguos archivos de estado de V1 no se eliminan automáticamente, pero Native Gateway no los lee ni los ejecuta.
Related MCP server: localterminal-lite
La versión web solo ve seis herramientas:
native_session_start
native_session_continue
native_session_recover
native_session_reply_and_wait
native_session_status
native_session_stop
Cualquier nombre de herramienta de V1, herramienta de archivos de nivel superior, Bash, antigua herramienta de DeepSeek u otro método MCP se rechaza en el servidor, no solo se oculta de la lista de herramientas.
La Session tiene tres niveles claramente definidos que, una vez creados, no se pueden subir, bajar de nivel ni cambiar de directorio raíz:
read_only: Read, FindFiles, SearchText y RunCommand de solo lectura; el alcance de lectura es todo el equipo, excepto las rutas de estado/credenciales protegidas y los permisos de macOS.
direct_write: añade Edit, Write y NotebookEdit a la capacidad de lectura de todo el equipo, modificando únicamente los directorios reales que el usuario haya seleccionado explícitamente. Solo se debe elegir este nivel cuando el usuario pida explícitamente modificar archivos reales.
worktree_write: el conjunto de herramientas es el mismo que direct_write, pero las modificaciones se realizan en un Git worktree independiente creado y conservado por Gateway; el checkout de origen no cambia.
Estas son herramientas lógicas que el modelo puede invocar dentro del bucle de agente nativo de Claude Code, pero el ejecutor pertenece a Gateway. Las herramientas de archivos integradas de Claude Code sin supervisión y Bash permanecen desactivadas para evitar eludir la autorización de acciones, los hashes, la recuperación y el libro de auditoría.
Read puede leer cualquier archivo UTF-8 normal no protegido del equipo; ya no está limitado al directorio de escritura.
FindFiles puede hacer enumeración de archivos acotada desde cualquier directorio absoluto.
SearchText solo hace coincidencia literal UTF-8; no acepta expresiones regulares ni globs.
La búsqueda no sigue enlaces simbólicos y omite .git, rutas protegidas y enlaces duros externos.
Los resultados de una sola búsqueda y el recibo completo de acciones están limitados a 64 KiB.
Todos los niveles pueden inspeccionar diferentes discos y directorios; working_directory es solo la ubicación de búsqueda predeterminada, el CWD de comandos y el límite de escritura para los niveles de escritura. Los permisos TCC/archivos de macOS aún pueden denegar el acceso a Escritorio, Documentos u otras ubicaciones protegidas por el sistema.
En direct_write, Edit, Write y NotebookEdit modifican el directorio real vinculado a la Session; en worktree_write solo modifican el worktree gestionado.
Write puede crear directorios padre faltantes bajo demanda dentro del directorio raíz autorizado y luego crear atómicamente el archivo de destino; no puede cruzar el directorio raíz, enlaces simbólicos, .git ni rutas protegidas.
NotebookEdit admite reemplazar, insertar y eliminar celdas por ID de celda, pero no ejecuta el Notebook.
Cada acción de escritura guarda el SHA-256 antes y después de escribir, y utiliza preparación, CAS, escritura atómica en disco y recibo persistente.
Tras un fallo del proceso se verifica el estado real de los archivos; si no se puede determinar, se detiene la recuperación y no se repite la escritura a ciegas.
direct_write no tiene herramienta de eliminación de archivos y no escribe archivos por comandos de verificación de solo lectura; aún puede sobrescribir o modificar archivos de destino según las instrucciones explícitas del usuario.
En worktree_write, los archivos, HEAD, tree, index y el estado del área de trabajo del checkout de origen permanecen sin cambios; el directorio común de Git registra el worktree conservado.
RunCommand acepta comandos del sistema instalados y ejecutables dentro del directorio de la Session; ya no mantiene una lista blanca estática de comandos que dañe fácilmente las herramientas de desarrollo normales. Los argumentos se siguen pasando como argv exacto; Gateway no los ensambla automáticamente en una cadena de shell:
El sistema de archivos raíz de la Session es de solo lectura desde la perspectiva del comando;
La red, las señales de proceso, Keychain/XPC y los CLI de modelos están bloqueados por el Seatbelt de macOS;
sudo, eliminación/movimiento directo, control del sistema, find -delete/-exec, rg --pre, CLI de modelos y otras entradas siguen rechazadas explícitamente;
Los enlaces simbólicos, enlaces duros o la cantidad de archivos en proyectos normales ya no provocan el rechazo de todo el repositorio antes de iniciar el comando; al acceder realmente, lo limitan Seatbelt, las rutas protegidas y los permisos de macOS;
La salida, el tiempo de ejecución y la recuperación del grupo de procesos hijo tienen límites;
El resultado entra primero en el mismo libro de acciones y luego se entrega a la siguiente ronda de GPT.
Se utiliza para la verificación de repositorios de confianza, no es un contenedor contra procesos maliciosos de la misma cuenta de macOS. Durante la ejecución de la Session, no uses otros editores o procesos para modificar concurrentemente el worktree gestionado.
La ruta principal está fijada en chatgpt-main; no acepta parámetros de model, provider, endpoint, API key ni fallback. Cuando la ronda actual de ChatGPT se detiene, Claude Code se queda en waiting_for_gpt; no cambia por su cuenta a Claude, DeepSeek o Codex para seguir pensando.
La búsqueda web la sigue realizando ChatGPT web. WebSearch/WebFetch de Claude Code no están habilitados, por lo que no habrá conflictos entre la búsqueda de GPT y la búsqueda propia de Claude, ni pérdida de control de las fuentes.
El subagent_policy: "none" predeterminado no crea DeepSeek. Solo cuando worktree_write elige explícitamente deepseek_explicit, GPT puede usarlo en el bucle principal:
deepseek_subagent_start
deepseek_subagent_get
deepseek_subagent_stop
La delegación debe entrar primero en el libro de acciones persistente de la Session principal y solo después se permite la sub-Session aislada. Durante la subtarea, la Session principal no puede ejecutar concurrentemente Edit, Write, NotebookEdit, RunCommand ni iniciar una segunda subtarea. La ruta está fijada en Sonnet/Opus → Flash, Fable → Pro; un fallo no retrocede a Claude, Codex, OpenAI ni a otro nivel de DeepSeek.
native_session_start puede recibir hasta ocho skill_contexts seleccionados explícitamente por ChatGPT. No son el runtime de Skills nativo de Claude Code:
Solo se extrae y congela el cuerpo de instrucciones validado;
No se cargan scripts, recursos, plugins, Hooks, Slash Commands ni herramientas adicionales;
Cada elemento permitido fija simultáneamente el ID de skill y el SHA-256 del SKILL.md completo normalizado;
El primer inicio y los resume posteriores usan la misma instantánea persistente;
El cuerpo completo solo aparece en el estado privado 0600 y en el contexto de modelo necesario para el GPT actual.
Ejemplo de lista permitida:
CLAUDE_TOOLS_NATIVE_SKILL_ALLOWLIST_JSON='[{"skill_id":"personal:review","content_sha256":"<64位小写SHA-256>"}]' \
npm startEl hash se calcula sobre el texto completo después de eliminar el BOM UTF-8 y normalizar CRLF/CR a LF.
Cada Session usa un HOME independiente, directorio de configuración de Claude, directorio de ejecución y grupo de procesos.
Claude Code usa --bare, fuentes de configuración vacías, configuración MCP estricta y un conjunto de herramientas preciso.
El proceso principal de Claude solo puede acceder al puerto de bucle local exacto del Broker/Executor.
Los directorios de credenciales, el estado de Gateway, .git, los enlaces simbólicos y los enlaces duros externos fallan en modo cerrado (fail closed); el acceso a rutas normales del sistema/usuario lo determinan conjuntamente la raíz de la Session, TCC de macOS y los permisos de archivos.
Las respuestas de ChatGPT y cada acción autorizada se escriben atómicamente en disco antes de liberarse al proceso en ejecución.
La expiración del arrendamiento detiene el Runner y deja un estado inspeccionable.
El reinicio de Gateway no mata a los Runners que aún pertenecen a una Session; native_session_recover verifica la propiedad, rota el arrendamiento y continúa con la misma Session de Claude Code.
Si el Runner ya no existe, no se finge la recuperación ni se repiten acciones ya completadas.
Claude Code 2.1.247 no tiene un interruptor independiente verificado de "habilitar solo Hooks mientras se sigue desactivando keychain, plugins y memoria automática", por lo que los Hooks nativos, Skills/Slash nativos, Agent, Workflow, Web y MCP de terceros no supervisados por el libro de acciones permanecen desactivados.
npm startNative Gateway ya no necesita los interruptores CLAUDE_TOOLS_NATIVE_V2 ni CLAUDE_TOOLS_NATIVE_V2_ONLY; Native-only es el único modo de ejecución.
El estado se guarda por defecto en state/ y se puede cambiar con la variable de entorno de ruta absoluta CLAUDE_TOOLS_STATE_DIR. La ruta predeterminada de Claude Code es $HOME/.npm-global/bin/claude y se puede sobrescribir con CLAUDE_BIN.
El Tunnel/Connector de larga ejecución necesita reiniciarse tras actualizar el código fuente. ChatGPT puede almacenar en caché el schema de las herramientas conectadas; si una sesión nueva no ve los seis native_session_*, actualiza o reconecta el Claude Tools Connector.
npm test
npm run test:native:installed
npm run test:native:installed:write
npm run test:native:installed:direct-write
npm run test:native:installed:deepseek
npm run test:native:installed:skillsLas pruebas automáticas cubren:
Inicialización MCP directa solo-Native, exactamente seis herramientas, rechazo de herramientas V1 y métodos desconocidos;
Libro de rondas y acciones, idempotencia de respuestas, arrendamiento, propiedad de procesos, detención y recuperación;
Lectura de todo el equipo con Read/FindFiles/SearchText, rutas protegidas, tamaño, orden, coincidencia literal y límites de condiciones de carrera;
Escritura directa en directorio real con Edit/Write/NotebookEdit, aislamiento de worktree, CAS, hashes y recuperación tras fallo;
Entrada flexible de comandos de desarrollo con RunCommand, ejecutables locales de la Session, sistema de archivos de solo lectura, cero red, bloqueo de servicios sensibles y recuperación por tiempo de espera;
Fijación de ID/hash del cuerpo de Skills, consistencia entre start/resume y límites del estado privado;
Barrera de inicio de la delegación explícita a DeepSeek, bloqueo de escritura de tarea única, verificación de ruta, recuperación tras reinicio de Gateway y detención;
El MCP/Session/history público no filtra IDs de autorización, tokens de Runner, PIDs, rutas internas ni credenciales de modelos.
Las pruebas instaladas usan Claude Code 2.1.247 local y un script GPT en localhost, sin conectarse a modelos reales:
test:native:installed: ejecuta FindFiles → SearchText literal → Read → final con / como raíz de solo lectura, y recuperación del mismo Runner/Session de Claude tras desconexión de Gateway.
test:native:installed:write: Read → Edit → Write → NotebookEdit → RunCommand → resume → Read.
test:native:installed:direct-write: el mismo conjunto de rondas reales de Claude Code modifica directamente el directorio real en el fixture de prueba, luego resume y verifica los resultados persistentes.
test:native:installed:deepseek: usa un CLI falso de DeepSeek local para verificar delegación explícita, verificación de resultados, bloqueo de escritura activo, recuperación tras reinicio y detención.
test:native:installed:skills: verifica que dos Skills de solo instrucciones con hash fijo usan la misma instantánea en start/resume.
Estas pruebas de script local no consumen cuota de modelos reales de ChatGPT, Claude ni DeepSeek. La prueba mínima de humo con DeepSeek real aún requiere autorización separada del usuario.
Continue the same durable native Claude Code session without changing its immutable capability profile or filesystem root. ChatGPT remains the sole main model. A direct_write Session continues to address the same real directory; a worktree_write Session continues in its retained managed worktree. A Session created with deepseek_explicit may inspect or stop its explicitly started DeepSeek subagent; the subagent never takes over the main loop.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | New user prompt to continue the same native session. | |
| lease_id | Yes | Current lease id for the native session. | |
| wait_seconds | No | Seconds to wait for the next pending turn, from 0 to 50. Defaults to 30. | |
| idempotency_key | Yes | Stable retry id. Reusing it with different input is rejected. | |
| native_session_id | Yes | Native session id returned by native_session_start. |
| Name | Required | Description |
|---|---|---|
| route | Yes | |
| replay | Yes | |
| status | Yes | |
| fallback | Yes | |
| lease_id | Yes | |
| revision | Yes | |
| terminal | No | |
| workspace | Yes | |
| current_run | Yes | |
| last_result | No | |
| launch_error | No | |
| pending_turn | Yes | |
| stop_request | No | |
| session_label | Yes | |
| deepseek_route | Yes | |
| recovery_token | No | |
| skill_snapshot | Yes | |
| subagent_policy | Yes | |
| lease_expires_at | Yes | |
| network_boundary | Yes | |
| runtime_attached | Yes | |
| source_directory | Yes | |
| claude_session_id | Yes | |
| native_session_id | Yes | |
| recovery_required | Yes | |
| working_directory | Yes | |
| capability_profile | Yes | |
| deepseek_subsessions | Yes | |
| active_deepseek_subsession_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as idempotent and non-destructive, and the description adds meaningful behavioral invariants: the capability profile and filesystem root stay unchanged, ChatGPT remains the sole main model, worktree behavior depends on session type, and a DeepSeek subagent cannot take over the main loop. These details go beyond what annotations or schema convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then adds behavior details about session types and the DeepSeek subagent. Each sentence contributes useful information, though the session-type sentences could be seen as elaborating what the first sentence already implies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 100% schema coverage, the presence of an output schema, and annotations covering idempotency and safety, the description supplies enough behavioral context for an agent to invoke the tool correctly. The only notable gap is the lack of explicit routing guidance against sibling continuation-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description adds high-level session context but does not add parameter-specific semantics beyond what is already present in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: continue the same durable native session while preserving its capability profile, filesystem root, and main model. This distinguishes it from starting a new session, though it does not explicitly differentiate it from siblings like native_session_recover or native_session_reply_and_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for resuming an existing durable session rather than starting a new one, but it never explicitly names alternatives or states when to prefer this over native_session_recover or native_session_reply_and_wait. The guidance is contextual but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reconnect ChatGPT to a durable native Claude Code session and rotate its lease. ChatGPT remains the sole main model. Any DeepSeek access remains limited to the Session's original explicit subagent policy; a write session is accepted only after its original direct directory or retained managed worktree binding is verified.
| Name | Required | Description | Default |
|---|---|---|---|
| recovery_id | Yes | Stable retry id for this recovery and lease rotation. | |
| wait_seconds | No | Seconds to wait for the recovered state or pending turn, from 0 to 50. Defaults to 0. | |
| recovery_token | Yes | Opaque recovery token returned when the native session was created. | |
| native_session_id | Yes | Native session id to recover. |
| Name | Required | Description |
|---|---|---|
| route | Yes | |
| replay | Yes | |
| status | Yes | |
| fallback | Yes | |
| lease_id | Yes | |
| revision | Yes | |
| terminal | No | |
| workspace | Yes | |
| current_run | Yes | |
| last_result | No | |
| launch_error | No | |
| pending_turn | Yes | |
| stop_request | No | |
| session_label | Yes | |
| deepseek_route | Yes | |
| recovery_token | No | |
| skill_snapshot | Yes | |
| subagent_policy | Yes | |
| lease_expires_at | Yes | |
| network_boundary | Yes | |
| runtime_attached | Yes | |
| source_directory | Yes | |
| claude_session_id | Yes | |
| native_session_id | Yes | |
| recovery_required | Yes | |
| working_directory | Yes | |
| capability_profile | Yes | |
| deepseek_subsessions | Yes | |
| active_deepseek_subsession_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey idempotency and non-destructiveness; the description adds meaningful context by stating that ChatGPT remains the sole main model, that DeepSeek access is limited by the original subagent policy, and that a write session requires verification of its directory or worktree binding. This goes beyond the annotations and helps an agent understand important constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the primary action. The second and third sentences add important behavioral constraints, though the third sentence is dense and slightly harder to parse. Overall, no sentence feels purely redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and key constraints, and the output schema likely handles return-value expectations. However, it lacks explicit usage guidance, does not differentiate from sibling tools, and does not state what happens when verification fails or the lease cannot be rotated. These are meaningful gaps for a recovery operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description does not add parameter-level meaning beyond the schema, such as the relationship between wait_seconds and lease rotation or the origin of the recovery token. Per baseline for high schema coverage, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Reconnect ChatGPT to a durable native Claude Code session and rotate its lease.' This clearly conveys the core action. It does not explicitly name or contrast sibling tools, so it stops short of fully distinguishing itself from tools like native_session_continue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus siblings such as native_session_continue, native_session_status, or native_session_reply_and_wait. The word 'Reconnect' loosely implies a recovery scenario, but no conditions, alternatives, or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit ChatGPT's response for one exact pending native turn. ChatGPT is always the sole main model. Every profile permits bounded whole-computer Read, FindFiles, literal SearchText, and a network-blocked, filesystem-read-only RunCommand except on protected credential/state paths. direct_write permits gateway-authorized Edit, Write, and NotebookEdit only inside the selected real write root. worktree_write permits the same mutations only inside its retained managed worktree. A Session created with deepseek_explicit may additionally start, inspect, or stop one explicit DeepSeek subagent; start must be the only call in that response.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | Optional assistant text for this turn. | |
| turn_id | Yes | Pending turn id being answered. | |
| lease_id | Yes | Lease id returned by native_session_start. | |
| reply_id | Yes | Stable idempotency id for this reply. | |
| tool_calls | No | Optional gateway-authorized calls. The Session profile and fixed subagent policy decide which calls are accepted. DeepSeek start must be the sole call. Text plus all calls must stay within a 768 KiB aggregate reply budget. | |
| native_session_id | Yes | Native session id returned by native_session_start. |
| Name | Required | Description |
|---|---|---|
| route | Yes | |
| replay | Yes | |
| status | Yes | |
| fallback | Yes | |
| lease_id | Yes | |
| revision | Yes | |
| terminal | No | |
| workspace | Yes | |
| current_run | Yes | |
| last_result | No | |
| launch_error | No | |
| pending_turn | Yes | |
| stop_request | No | |
| session_label | Yes | |
| deepseek_route | Yes | |
| recovery_token | No | |
| skill_snapshot | Yes | |
| subagent_policy | Yes | |
| lease_expires_at | Yes | |
| network_boundary | Yes | |
| runtime_attached | Yes | |
| source_directory | Yes | |
| claude_session_id | Yes | |
| native_session_id | Yes | |
| recovery_required | Yes | |
| working_directory | Yes | |
| capability_profile | Yes | |
| deepseek_subsessions | Yes | |
| active_deepseek_subsession_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark the call as destructive and idempotent; the description adds substantial behavioral context by enumerating per-profile permissions (network-blocked read-only RunCommand, direct_write vs worktree_write roots) and the deepseek_explicit subagent exception. It does not explicitly describe the waiting/blocking behavior implied by the name, but the policy detail goes well beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is roughly 130 words and opens with the core action in the first sentence. Each following sentence covers a distinct policy area without significant redundancy, making it dense but not bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool this complex, the description covers the essential constraints: exact turn targeting, sole main-model ownership, per-profile permissions, and subagent limitations. The wait behavior is only hinted at by the tool name, and the description does not state what happens after submission, though an output schema exists to fill return-value gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds a useful summary of which tool_calls are permitted and restates the sole-call rule for DeepSeek start, but it does not individually explain native_session_id, lease_id, turn_id, or reply_id beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence states a specific action: 'Submit ChatGPT's response for one exact pending native turn.' It identifies the verb, the resource, and the exactness constraint, which clearly separates it from the session lifecycle siblings. The 'ChatGPT is always the sole main model' line further clarifies its role in the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the required condition—'one exact pending native turn'—and gives operational rules for tool_calls, such as 'DeepSeek start must be the only call.' However, it never explicitly contrasts this tool with siblings like native_session_continue or states when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start an isolated native Claude Code session with the current ChatGPT conversation as the sole main model. subagent_policy defaults to none. All profiles may use Read, FindFiles, literal SearchText, and a network-blocked, filesystem-read-only RunCommand across the computer except protected credential/state paths. working_directory remains the command CWD and, for write profiles, the only write root. read_only never writes. When the user explicitly asks to modify the actual files in working_directory, choose direct_write; it works for Git and non-Git directories. Choose worktree_write only for an isolated copy of a clean Git repository. deepseek_explicit remains available only with worktree_write; DeepSeek never becomes the main model.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Task to start in the native session. | |
| wait_seconds | No | Seconds to wait for the first pending turn, from 0 to 50. Defaults to 30. | |
| session_label | No | Optional short label for the owning ChatGPT conversation. | |
| skill_contexts | No | Optional explicit, allowlisted SKILL.md contexts selected by ChatGPT for this immutable Session. They add instructions only and cannot grant tools or change providers. | |
| idempotency_key | Yes | Stable retry id. Reusing it with different input is rejected. | |
| subagent_policy | No | Optional subagent boundary. Defaults to none. deepseek_explicit requires worktree_write; ChatGPT remains the sole main model. | |
| working_directory | Yes | Absolute command CWD and write root. Read, FindFiles, and SearchText may inspect other absolute paths across the computer except protected state/credential paths. direct_write modifies this directory in place and does not require Git. worktree_write requires the clean top level of a Git repository. | |
| capability_profile | No | Execution boundary. Defaults to read_only. If the user explicitly requested in-place changes to actual files, use direct_write, including for non-Git directories. Use worktree_write only when an isolated retained copy of a clean Git repository is desired. |
| Name | Required | Description |
|---|---|---|
| route | Yes | |
| replay | Yes | |
| status | Yes | |
| fallback | Yes | |
| lease_id | Yes | |
| revision | Yes | |
| terminal | No | |
| workspace | Yes | |
| current_run | Yes | |
| last_result | No | |
| launch_error | No | |
| pending_turn | Yes | |
| stop_request | No | |
| session_label | Yes | |
| deepseek_route | Yes | |
| recovery_token | No | |
| skill_snapshot | Yes | |
| subagent_policy | Yes | |
| lease_expires_at | Yes | |
| network_boundary | Yes | |
| runtime_attached | Yes | |
| source_directory | Yes | |
| claude_session_id | Yes | |
| native_session_id | Yes | |
| recovery_required | Yes | |
| working_directory | Yes | |
| capability_profile | Yes | |
| deepseek_subsessions | Yes | |
| active_deepseek_subsession_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already marking idempotentHint=true and destructiveHint=false, the description adds rich behavioral context: isolated session, subagent_policy default, restricted tool capabilities (network-blocked, filesystem-read-only RunCommand), protected credential/state paths, working_directory as the only write root for write profiles, and read_only never writes. This gives the agent a clear model of side effects and boundaries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence and every subsequent sentence carries meaningful constraint information. It is a dense paragraph rather than structured bullets, and a couple of details (subagent_policy defaults to none) duplicate the schema, but it is appropriately concise for a tool with this many behavior-affecting choices.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich input schema, output schema, and annotations, the description covers all invocation-critical decisions: profile selection, subagent policy, working directory semantics, tool restrictions, and write behavior. Nothing needed to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds useful decision semantics on top: capability_profile selection guidance (read_only never writes, direct_write works for Git/non-Git, worktree_write only for clean Git), the write-root constraint, and the deepseek_explicit-worktree coupling. Some of this duplicates schema text, but 'only write root' and 'read_only never writes' add meaning beyond the param descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states the exact action: start an isolated native Claude Code session with the current ChatGPT conversation as sole main model. This is a specific verb + resource and distinguishes native_session_start from the continue/recover/reply_and_wait/status/stop siblings by the 'start' action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly tells when to choose direct_write (explicit user request to modify actual files, Git or non-Git) and worktree_write (isolated copy of a clean Git repo), and ties deepseek_explicit to worktree_write. It does not explicitly name sibling tools or state when to use start over continue/recover, so it falls short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read native-session state without advancing it or invoking a model. ChatGPT remains the sole main model. Safe summaries of any explicitly enabled DeepSeek subagent and the retained managed-worktree location are returned when present.
| Name | Required | Description | Default |
|---|---|---|---|
| lease_id | Yes | Lease id returned by native_session_start. | |
| wait_seconds | No | Seconds to wait for a state change, from 0 to 50. Defaults to 0. | |
| native_session_id | Yes | Native session id returned by native_session_start. |
| Name | Required | Description |
|---|---|---|
| route | Yes | |
| replay | Yes | |
| status | Yes | |
| fallback | Yes | |
| lease_id | Yes | |
| revision | Yes | |
| terminal | No | |
| workspace | Yes | |
| current_run | Yes | |
| last_result | No | |
| launch_error | No | |
| pending_turn | Yes | |
| stop_request | No | |
| session_label | Yes | |
| deepseek_route | Yes | |
| recovery_token | No | |
| skill_snapshot | Yes | |
| subagent_policy | Yes | |
| lease_expires_at | Yes | |
| network_boundary | Yes | |
| runtime_attached | Yes | |
| source_directory | Yes | |
| claude_session_id | Yes | |
| native_session_id | Yes | |
| recovery_required | Yes | |
| working_directory | Yes | |
| capability_profile | Yes | |
| deepseek_subsessions | Yes | |
| active_deepseek_subsession_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful context beyond those flags: it explicitly states no session advancement and no model invocation, and clarifies that only safe summaries of enabled DeepSeek subagents and the managed-worktree location are returned. This substantially helps an agent predict side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The most decision-relevant facts—reading state, not advancing, not invoking a model—are front-loaded, and the second sentence adds precise return-value context without unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, 100% parameter coverage, and annotations that already define safety characteristics, the description supplies the remaining context an agent needs: the tool is side-effect-free, returns safe summaries when present, and preserves ChatGPT as the sole main model. Nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameter meanings. The description does not add significant parameter-level detail beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') with a clear resource ('native-session state') and adds a key distinguisher: the operation does not advance the session or invoke a model. It also names exactly what information is returned, making the tool's purpose unmistakable relative to its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'without advancing it or invoking a model' clearly establishes this as a non-mutating status-check tool, implying use when state is needed without side effects. It does not explicitly name alternatives like native_session_continue, so there is some room for inference, but the intended context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the isolated native-session process and preserve durable state and any managed worktree for inspection. ChatGPT remains the sole main model. Any active Session-owned DeepSeek subagent must be safely stopped and durably observed before the Session can finalize.
| Name | Required | Description | Default |
|---|---|---|---|
| reason | No | Optional concise reason for stopping the session. | |
| lease_id | Yes | Lease id returned by native_session_start. | |
| request_id | Yes | Stable retry id for this stop request. | |
| native_session_id | Yes | Native session id returned by native_session_start. |
| Name | Required | Description |
|---|---|---|
| route | Yes | |
| replay | Yes | |
| status | Yes | |
| fallback | Yes | |
| lease_id | Yes | |
| revision | Yes | |
| terminal | No | |
| workspace | Yes | |
| current_run | Yes | |
| last_result | No | |
| launch_error | No | |
| pending_turn | Yes | |
| stop_request | No | |
| session_label | Yes | |
| deepseek_route | Yes | |
| recovery_token | No | |
| skill_snapshot | Yes | |
| subagent_policy | Yes | |
| lease_expires_at | Yes | |
| network_boundary | Yes | |
| runtime_attached | Yes | |
| source_directory | Yes | |
| claude_session_id | Yes | |
| native_session_id | Yes | |
| recovery_required | Yes | |
| working_directory | Yes | |
| capability_profile | Yes | |
| deepseek_subsessions | Yes | |
| active_deepseek_subsession_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and idempotentHint, but the description adds valuable context: durable state and worktree are preserved for inspection, the main ChatGPT model is untouched, and Session-owned DeepSeek subagents must be safely stopped. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the primary action. The second sentence about ChatGPT remaining the sole main model is slightly tangential but adds context; overall every sentence is short and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, a prerequisite, and the side-effect guarantee of preservation. With a full output schema and complete parameter schema, nothing critical is missing; retry semantics are already implied by the idempotentHint annotation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline of 3 applies. The description itself does not add meaning beyond the schema, but each parameter is already fully documented in the schema with origin, format, and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: it stops the isolated native-session process and preserves durable state and managed worktree for inspection. It also clarifies the tool's relationship to the main model, making the action unambiguous. This clearly distinguishes it from the sibling start/continue/recover/status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when the tool should be used by stating that active subagents must be safely stopped and durably observed 'before the Session can finalize.' However, it does not explicitly name alternative tools or give explicit when-not-to-use guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.8.0native_session_continuenative_session_recovernative_session_reply_and_waitnative_session_startnative_session_statusnative_session_stopScored across 6 tools
Each tool maps to a distinct lifecycle action such as start, continue, recover, reply, status, or stop. The only mild ambiguity is between continue and recover, since both involve reconnecting to an existing session, though the descriptions differentiate them by lease rotation and capability immutability.
All tool names follow the same native_session_ prefix with an imperative verb or verb phrase. The naming pattern is uniform and predictable, making the tool set easy to navigate.
Six tools is well-scoped for a session gateway: creation, continuation, recovery, interaction, status inspection, and shutdown. Each tool has a clear role without redundancy.
The tool set covers the full lifecycle of a native session: start it, continue or recover it, send replies, check status, and stop it. Stop preserves durable state rather than losing it, so the workflows do not end in a dead end.
Use your Mac, Windows or Linux computer from ChatGPT, Claude or Codex: files, commands, documents.
Work on your own computers from Claude or ChatGPT: run commands, edit and search files.
Safe folder access for ChatGPT and Claude: read, write and search files, risky tools opt-in.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
