一言で言えば：Web版ChatGPTを唯一の主脳とし、ローカルの本物のClaude CodeネイティブSessionを駆動して、制御された読み取り・変更・検証・復元を完了する。
公開リポジトリにはソースコードとテストのみが含まれ、ローカルキー、Tunnel設定、state/セッション状態は含まれません。
Gatewayは現在、Native V2の単一の実行エンジンのみを備えています：
当前 ChatGPT Chat（唯一主脑）
↔ Claude Tools Native MCP（六个 Session 控制工具）
↔ 本地模型回合桥（127.0.0.1）
↔ 隔离的 Claude Code 原生 Session
→ 原生 Agent loop
→ 网关自有的受控工具 ExecutorGateway自身がMCP初期化、ツール一覧、呼び出しディスパッチを完了し、V1のclaude mcp serveツールサーバーを起動またはプロキシしません。Native Sessionを作成した後にのみ、そのSession専用のClaude Codeプロセスが起動されます。
旧V1 Agent Session、トップレベルのRead/Edit/Write/Bash、ローカルタスクツール、旧DeepSeek委任、ChatGPT Bridgeは、実行エントリとコードツリーから削除されました。残っているのはV2が引き続き必要とする共通の基盤機能です：原子的状態書き込み、資格情報パスの保護、プロセス身元認証、macOSサンドボックスルール。旧V1状態ファイルは自動削除されませんが、Native Gatewayはそれらを読み取ったり実行したりしません。
Related MCP server: localterminal-lite
Web版には6つのツールのみが表示されます：
native_session_start
native_session_continue
native_session_recover
native_session_reply_and_wait
native_session_status
native_session_stop
V1のツール名、トップレベルファイルツール、Bash、旧DeepSeekツール、その他のMCPメソッドは、ツールリストから隠すだけでなく、サーバー側で拒否されます。
Sessionには明確な3つのグレードがあり、作成後にアップグレード・ダウングレードやルートディレクトリの変更はできません：
read_only：Read、FindFiles、SearchText、読み取り専用RunCommand。読み取り範囲はコンピュータ全体で、保護された状態/資格情報パスとmacOS権限を除きます。
direct_write：コンピュータ全体の読み取り機能にEdit、Write、NotebookEditを追加し、ユーザーが明示的に選択した実際のディレクトリのみを直接変更します。ユーザーが明示的に実ファイルの変更を要求した場合にのみ、このグレードを選択すべきです。
worktree_write：ツールセットはdirect_writeと同じですが、変更対象はGatewayが作成・保持する独立したGit worktreeであり、ソースcheckoutは変更されません。
これらはClaude CodeネイティブAgentループ内でモデルが呼び出せる論理ツールですが、実行器はGatewayが所有します。監督されていないClaude Code組み込みファイルツールとBashは引き続き無効化され、アクション認可、ハッシュ、復元、監査台帳の迂回を防ぎます。
Readは、コンピュータ上の保護されていない任意の通常のUTF-8ファイルを読み取れます。書き込みディレクトリに制限されなくなりました。
FindFilesは、任意の絶対ディレクトリから境界付きファイル列挙ができます。
SearchTextはUTF-8リテラル一致のみで、正規表現やglobは受け付けません。
検索はシンボリックリンクを追跡せず、.git、保護パス、外部ハードリンクをスキップします。
単一の検索結果と完全なアクション受領書は64 KiB以内に制限されます。
すべてのグレードで異なるディスクやディレクトリを検査できます。working_directoryはデフォルトの検索位置、コマンドCWD、書き込みグレードの書き込み境界にすぎません。macOS TCC/ファイル権限により、Desktop、Documents、その他のシステム保護位置が拒否される場合があります。
direct_writeでは、Edit、Write、NotebookEditがSessionにバインドされた実際のディレクトリを変更します。worktree_writeでは管理対象worktreeのみを変更します。
Writeは、認可されたルートディレクトリ内で不足している親ディレクトリを必要に応じて作成し、その後ターゲットファイルを原子的に作成します。これによってルートディレクトリ、シンボリックリンク、.git、保護パスを越えることはできません。
NotebookEditはcell IDによる置換、挿入、削除をサポートしますが、Notebookを実行しません。
各書き込みアクションは書き込み前と書き込み後のSHA-256を保存し、準備、CAS、原子的ディスク書き込み、永続的な受領書を使用します。
プロセスクラッシュ後は実際のファイル状態を照合し、確定できない場合は復元を停止し、盲目的に書き込みを繰り返しません。
direct_writeにはファイル削除ツールがなく、読み取り専用チェックコマンドによってファイルを書き込むこともありません。ユーザーの明示的な指示に従ってターゲットファイルを上書きまたは変更することは可能です。
worktree_writeでは、ソースcheckoutのファイル、HEAD、tree、index、ワークスペース状態は変更されません。Git common dirは保持型worktreeとして登録されます。
RunCommandは、インストール済みのシステムコマンドとSessionディレクトリ内の実行可能ファイルを受け付けます。通常の開発ツールを誤って傷つけやすい静的コマンドホワイトリストは維持されません。引数は正確なargvとして渡され、Gatewayが自動的にシェル文字列に組み立てることはありません：
コマンドから見たSessionルートファイルシステムは読み取り専用。
ネットワーク、プロセスシグナル、Keychain/XPC、モデルCLIはmacOS Seatbeltによってブロック。
sudo、直接削除/移動、システム制御、find -delete/-exec、rg --pre、モデルCLIなどのエントリは明示的に拒否。
通常のプロジェクト内のシンボリックリンク、ハードリンク、ファイル数によって、コマンドが起動前にリポジトリ全体で拒否されることはありません。実際のアクセス時にはSeatbelt、保護パス、macOS権限によって制約されます。
出力、実行時間、子プロセスグループの回収には境界があります。
結果はまず同じアクション台帳に入り、その後次のGPTターンに渡されます。
これは信頼できるリポジトリの検証に使用され、同じmacOSアカウントの悪意あるプロセスに対抗するコンテナではありません。Session実行中は、他のエディタやプロセスで管理対象worktreeを並行して変更しないでください。
メインルートはchatgpt-mainに固定され、model、provider、endpoint、API key、fallbackパラメータは受け付けません。現在のChatGPTターンが停止すると、Claude Codeはwaiting_for_gptで停止します。Claude、DeepSeek、Codexに勝手に切り替えて思考を続けることはありません。
Web検索は引き続きWeb版ChatGPTが実行します。Claude CodeのWebSearch/WebFetchは開放されないため、GPTの検索とClaude自身の検索が衝突したり、ソースが制御不能になったりすることはありません。
デフォルトのsubagent_policy: "none"ではDeepSeekは作成されません。worktree_writeが明示的にdeepseek_explicitを選択した場合のみ、GPTはメインループで使用できます：
deepseek_subagent_start
deepseek_subagent_get
deepseek_subagent_stop
委任はまずメインSessionの永続的なアクション台帳に入り、その後隔離されたサブSessionが許可されます。サブタスク中、メインSessionはEdit、Write、NotebookEdit、RunCommandを並行実行したり、2つ目のサブタスクを開始したりできません。ルートはSonnet/Opus → Flash、Fable → Proに固定され、失敗してもClaude、Codex、OpenAI、別のグレードのDeepSeekにフォールバックしません。
native_session_startは、ChatGPTが明示的に選択した最大8つのskill_contextsを受け取れます。これらはClaude CodeネイティブSkillランタイムではありません：
検証済みの指示本文のみを抽出して凍結。
スクリプト、リソース、プラグイン、Hook、Slash Command、追加ツールは読み込まれません。
各許可項目はskill IDと正規化された完全なSKILL.mdのSHA-256の両方を固定します。
初回起動とその後のresumeは同じ永続スナップショットを使用します。
完全な本文は0600プライベート状態と、現在のGPTに必要なモデルコンテキストにのみ現れます。
許可リストの例：
CLAUDE_TOOLS_NATIVE_SKILL_ALLOWLIST_JSON='[{"skill_id":"personal:review","content_sha256":"<64位小写SHA-256>"}]' \
npm startハッシュはUTF-8 BOMを除去し、CRLF/CRをLFに統一した後の完全なテキストに対して計算されます。
各Sessionは独立したHOME、Claude設定ディレクトリ、実行ディレクトリ、プロセスグループを使用します。
Claude Codeは--bare、空のsetting sources、厳格なMCP設定、正確なツールセットを使用します。
メインのClaudeプロセスは、正確なローカルBroker/Executorループバックポートにのみアクセスできます。
資格情報ディレクトリ、Gateway状態、.git、シンボリックリンク、外部ハードリンクはすべてfail closed。通常のシステム/ユーザーパスへのアクセス可否は、Sessionルート、macOS TCC、ファイル権限によって共同で決定されます。
ChatGPTの返信と各承認済みアクションは、まず原子的にディスクに書き込まれてから、実行中のプロセスに解放されます。
リースの期限切れはRunnerを停止し、検査可能な状態を残します。
Gatewayの再起動は、Sessionに属するRunnerを殺しません。native_session_recoverは所有権を検証し、リースをローテーションし、同じClaude Code Sessionを継続します。
Runnerが存在しない場合、復元を偽装せず、完了済みアクションを繰り返しません。
Claude Code 2.1.247には、「Hooksのみを有効にし、keychain、プラグイン、自動メモリを引き続き無効にする」という検証済みの独立スイッチがないため、ネイティブHooks、ネイティブSkill/Slash、Agent、Workflow、Web、アクション台帳による監督を受けないサードパーティMCPはオフのままです。
npm startNative GatewayはCLAUDE_TOOLS_NATIVE_V2やCLAUDE_TOOLS_NATIVE_V2_ONLYスイッチを必要としなくなりました。Native-onlyが唯一の実行モードです。
状態はデフォルトでstate/に保存され、絶対パス環境変数CLAUDE_TOOLS_STATE_DIRで変更できます。Claude Codeのデフォルトパスは$HOME/.npm-global/bin/claudeで、CLAUDE_BINで上書きできます。
長期実行のTunnel/Connectorは、ソースコード更新後に再起動が必要です。ChatGPTは接続済みツールのschemaをキャッシュする可能性があります。新しいセッションで6つのnative_session_*が見えない場合は、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:skills自動テストの対象：
Native-only MCPの直接初期化、正確な6ツール、V1ツールと未知メソッドの拒否。
ターンとアクション台帳、返信の冪等性、リース、プロセス所有権、停止と復元。
Read/FindFiles/SearchTextのコンピュータ全体読み取り、保護パス、サイズ、ソート、リテラル一致、競合境界。
Edit/Write/NotebookEditのdirect real-directory書き込み、worktree分離、CAS、ハッシュ、クラッシュ復元。
RunCommandの寛容な開発コマンドエントリ、Sessionローカル実行可能ファイル、読み取り専用ファイルシステム、ゼロネットワーク、機密サービスブロック、タイムアウト回収。
SkillのID/本文ハッシュ固定、start/resumeの一貫性、プライベート状態境界。
DeepSeek明示委任の起動バリア、単一タスク書き込みロック、ルート検証、Gateway再起動復元、停止。
公開MCP/Session/historyが認可ID、Runner token、PID、内部パス、モデル資格情報を漏洩しないこと。
InstalledテストはローカルのClaude Code 2.1.247とlocalhostスクリプトGPTを使用し、実際のモデルには接続しません：
test:native:installed：/を読み取り専用ルートとしてFindFiles → リテラルSearchText → Read → finalを実行し、Gateway切断後に同じRunner/Claude Sessionを復元。
test:native:installed:write：Read → Edit → Write → NotebookEdit → RunCommand → resume → Read。
test:native:installed:direct-write：同じ一連の実際のClaude Codeターンでテストフィクスチャ内の実際のディレクトリを直接変更し、resumeして永続結果を検証。
test:native:installed:deepseek：ローカルの偽DeepSeek CLIを使用して、明示的委任、結果検証、アクティブ書き込みロック、再起動復元、停止を検証。
test:native:installed:skills：ハッシュ固定された2つの純粋指示Skillがstart/resumeで同じスナップショットを使用することを検証。
これらのローカルスクリプトテストは、実際のChatGPT、Claude、DeepSeekモデルクォータを消費しません。実際のDeepSeek最小スモークテストは、ユーザーの個別承認が引き続き必要です。
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.
