claude-tools-gateway

Overview Schema Source Related Servers Discussions Admin

native_session_start

Idempotent

Launch an isolated native Claude Code session using the current ChatGPT conversation as the main model, with configurable read-only or write access to a specified working directory.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description
`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.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`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

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.8.0Aug 28, 2026

TDQS

A4.6/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Deploy Server