Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@claude-tools-gateway Start a read-only session to view ~/project/config.json"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
In one sentence: Make web ChatGPT the sole brain, driving real local Claude Code native Sessions to perform controlled reads, modifications, verification, and recovery.
The public repository contains only source code and tests; it does not include local keys, Tunnel configuration, or state/ session state.
The Gateway now has only one execution engine: Native V2.
当前 ChatGPT Chat（唯一主脑）
↔ Claude Tools Native MCP（六个 Session 控制工具）
↔ 本地模型回合桥（127.0.0.1）
↔ 隔离的 Claude Code 原生 Session
→ 原生 Agent loop
→ 网关自有的受控工具 ExecutorThe Gateway itself handles MCP initialization, tool inventory, and call dispatch; it no longer starts or proxies V1's claude mcp serve tool server. A Claude Code process dedicated to a Session is started only after the Native Session is created.
The original V1 Agent Session, top-level Read/Edit/Write/Bash, local task tools, legacy DeepSeek delegation, and ChatGPT Bridge have been removed from the runtime entry points and the code tree. What remains are the shared low-level facilities V2 still needs: atomic state writes, credential path protection, process identity verification, and macOS sandbox rules. Old V1 state files are not automatically deleted, but the Native Gateway will not read or execute them.
Related MCP server: Session Buddy
The web version sees only six tools:
native_session_start
native_session_continue
native_session_recover
native_session_reply_and_wait
native_session_status
native_session_stop
Any V1 tool name, top-level file tool, Bash, legacy DeepSeek tool, or other MCP method is rejected server-side, rather than merely hidden from the tool list.
Sessions have three distinct tiers; after creation, they cannot be upgraded, downgraded, or have their root directory changed:
read_only: Read, FindFiles, SearchText, and read-only RunCommand; the read scope is the entire computer, except for protected state/credential paths and macOS permissions.
direct_write: adds Edit, Write, and NotebookEdit on top of full-computer read capability, modifying only the real directory the user explicitly selected. This tier should only be chosen when the user explicitly asks to modify real files.
worktree_write: the tool set is the same as direct_write, but modifications go to a separate Git worktree created and retained by the Gateway; the source checkout remains unchanged.
These are logical tools the model can call in Claude Code's native Agent loop, but the executors belong to the Gateway. Unregulated Claude Code built-in file tools and Bash remain disabled, to avoid bypassing action authorization, hashing, recovery, and the audit ledger.
Read can read any unprotected plain UTF-8 file on the computer, no longer restricted to the write directory.
FindFiles performs bounded file enumeration from any absolute directory.
SearchText does UTF-8 literal matching only; it does not accept regex or glob.
Searches do not follow symbolic links and skip .git, protected paths, and external hard links.
Both a single search result and a full action receipt are limited to 64 KiB.
All tiers can inspect different disks and directories; working_directory is only the default search location, the command CWD, and the write boundary for write tiers. macOS TCC/file permissions may still deny Desktop, Documents, or other system-protected locations.
Under direct_write, Edit, Write, and NotebookEdit modify the real directory bound to the Session; under worktree_write, they modify only the managed worktree.
Write can create missing parent directories on demand within the authorized root, then atomically create the target file; it cannot use this to escape the root, symbolic links, .git, or protected paths.
NotebookEdit supports replacing, inserting, and deleting cells by cell ID, but does not execute the Notebook.
Every write action saves pre-write and post-write SHA-256 and uses prepare, CAS, atomic persistence, and a durable receipt.
After a process crash, the real file state is verified; if it cannot be determined, recovery stops rather than blindly repeating the write.
direct_write has no file deletion tool and does not write files because of read-only check commands; it may still overwrite or modify target files per explicit user instructions.
In worktree_write, the source checkout's files, HEAD, tree, index, and working tree state remain unchanged; the Git common dir registers a retained worktree.
RunCommand accepts installed system commands and executables inside the Session directory; it no longer maintains a static command whitelist that could easily break normal development tools. Arguments are still passed as exact argv, never assembled into a shell string by the Gateway:
The Session root filesystem is read-only from the command's perspective;
Network, process signals, Keychain/XPC, and model CLIs are blocked by the macOS Seatbelt;
Entry points such as sudo, direct delete/move, system control, find -delete/-exec, rg --pre, and model CLIs remain explicitly rejected;
Symbolic links, hard links, or file counts in ordinary projects no longer cause the command to be rejected for the entire repository before startup; actual access is constrained by Seatbelt, protected paths, and macOS permissions;
Output, runtime, and subprocess group reclamation all have bounds;
Results first enter the same action ledger, then are handed to the next GPT turn.
It is intended for trusted repository verification, not as a container against malicious processes running under the same macOS account. Do not concurrently modify the managed worktree with other editors or processes while the Session is running.
The main route is fixed to chatgpt-main and does not accept model, provider, endpoint, API key, or fallback parameters. When the current ChatGPT turn stops, Claude Code pauses at waiting_for_gpt; it will not switch to Claude, DeepSeek, or Codex on its own to continue thinking.
Web search continues to be handled by web ChatGPT. Claude Code's WebSearch/WebFetch are not enabled, so there is no risk of GPT search conflicting with Claude's own search or of sources getting out of control.
By default, subagent_policy: "none" means no DeepSeek is created. Only after worktree_write explicitly selects deepseek_explicit can GPT use it in the main loop:
deepseek_subagent_start
deepseek_subagent_get
deepseek_subagent_stop
Delegation must first enter the main Session's persistent action ledger before the isolated sub-Session is allowed through. While a subtask is running, the main Session cannot concurrently Edit, Write, NotebookEdit, RunCommand, or start a second subtask. The route is fixed as Sonnet/Opus → Flash, Fable → Pro; failures do not fall back to Claude, Codex, OpenAI, or another DeepSeek tier.
native_session_start can accept up to eight skill_contexts explicitly selected by ChatGPT. They are not Claude Code's native Skill runtime:
Only the validated instruction body is extracted and frozen;
Scripts, resources, plugins, Hooks, Slash Commands, and extra tools are not loaded;
Each allowed item pins both the skill ID and the SHA-256 of the normalized full SKILL.md;
The first start and subsequent resume use the same persistent snapshot;
The full body appears only in 0600 private state and in the model context the current GPT turn requires.
Example allowlist:
CLAUDE_TOOLS_NATIVE_SKILL_ALLOWLIST_JSON='[{"skill_id":"personal:review","content_sha256":"<64位小写SHA-256>"}]' \
npm startThe hash is computed over the full text after removing the UTF-8 BOM and normalizing CRLF/CR to LF.
Each Session uses an independent HOME, Claude config directory, runtime directory, and process group.
Claude Code runs with --bare, empty setting sources, strict MCP configuration, and a precise tool set.
The main Claude process can only reach the exact local Broker/Executor loopback port.
Credential directories, Gateway state, .git, symbolic links, and external hard links all fail closed; access to ordinary system/user paths is determined jointly by the Session root, macOS TCC, and file permissions.
ChatGPT replies and each approved action are atomically persisted before being released to the running process.
Lease expiry stops the Runner and leaves an inspectable state.
A Gateway restart does not kill a Runner that still belongs to a Session; native_session_recover verifies ownership, rotates the lease, and continues the same Claude Code Session.
When the Runner no longer exists, recovery is not faked, and completed actions are not repeated.
Claude Code 2.1.247 has no verified standalone switch to "enable only Hooks while continuing to disable keychain, plugins, and automatic memory," so native Hooks, native Skill/Slash, Agent, Workflow, Web, and third-party MCP not governed by the action ledger remain disabled.
npm startThe Native Gateway no longer needs the CLAUDE_TOOLS_NATIVE_V2 or CLAUDE_TOOLS_NATIVE_V2_ONLY switches; Native-only is the only runtime mode.
State is saved in state/ by default and can be changed via the absolute-path environment variable CLAUDE_TOOLS_STATE_DIR. The default Claude Code path is $HOME/.npm-global/bin/claude and can be overridden with CLAUDE_BIN.
Long-running Tunnel/Connector instances need to be restarted after source updates. ChatGPT may cache the connected tool schema; if a new session does not see the six native_session_* tools, refresh or reconnect the 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:skillsAutomated tests cover:
Native-only MCP direct initialization, the exact six tools, and rejection of V1 tools and unknown methods;
Turn and action ledger, reply idempotency, leases, process ownership, stop and recovery;
Read/FindFiles/SearchText full-computer reads, protected paths, size, ordering, literal matching, and race boundaries;
Edit/Write/NotebookEdit direct real-directory writes, worktree isolation, CAS, hashing, and crash recovery;
RunCommand permissive development command entry points, Session-local executables, read-only filesystem, zero network, sensitive service blocking, and timeout reclamation;
Skill ID/body hash pinning, start/resume consistency, and private state boundaries;
DeepSeek explicit delegation startup barrier, single-task write lock, route verification, Gateway restart recovery, and stop;
Public MCP/Session/history does not leak authorization IDs, Runner tokens, PIDs, internal paths, or model credentials.
Installed tests use the local Claude Code 2.1.247 and a localhost scripted GPT, without connecting to real models:
test:native:installed: executes FindFiles → literal SearchText → Read → final with / as the read-only root, and recovers the same Runner/Claude Session after the Gateway disconnects.
test:native:installed:write: Read → Edit → Write → NotebookEdit → RunCommand → resume → Read.
test:native:installed:direct-write: the same set of real Claude Code turns directly modifies a real directory in the test fixture, then resumes and verifies the persisted results.
test:native:installed:deepseek: uses a local fake DeepSeek CLI to verify explicit delegation, result verification, active write lock, restart recovery, and stop.
test:native:installed:skills: verifies that two hash-pinned, instruction-only Skills use the same snapshot across start/resume.
These local scripted tests do not consume real ChatGPT, Claude, or DeepSeek model quota. A real DeepSeek minimal smoke test still requires separate user authorization.
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.
Let ChatGPT, Claude & Cursor use your Mac: email, calendar, iMessage, Teams, files. Local, free.
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
