Auf einen Satz: Die Webversion von ChatGPT wird zur einzigen Zentrale, die echte native Claude-Code-Sessions auf diesem Rechner steuert – für kontrolliertes Lesen, Ändern, Verifizieren und Wiederherstellen.
Das öffentliche Repository enthält nur Quellcode und Tests, keine lokalen Schlüssel, Tunnel-Konfigurationen oder den state/-Sitzungszustand.
Das Gateway besitzt jetzt nur noch eine einzige Ausführungs-Engine: Native V2.
当前 ChatGPT Chat（唯一主脑）
↔ Claude Tools Native MCP（六个 Session 控制工具）
↔ 本地模型回合桥（127.0.0.1）
↔ 隔离的 Claude Code 原生 Session
→ 原生 Agent loop
→ 网关自有的受控工具 ExecutorDas Gateway übernimmt selbst die MCP-Initialisierung, die Werkzeugliste und die Aufrufverteilung; es startet und proxyt keinen V1-claude mcp serve-Werkzeugserver mehr. Erst nach dem Erstellen einer nativen Session wird der für diese Session exklusive Claude-Code-Prozess gestartet.
Die ursprüngliche V1-Agent-Session, die Top-Level-Werkzeuge Read/Edit/Write/Bash, die lokalen Aufgabenwerkzeuge, die alte DeepSeek-Delegierung und die ChatGPT-Bridge wurden aus den Einstiegspunkten und dem Codebaum entfernt. Erhalten geblieben sind die gemeinsamen Basis-Infrastrukturen, die V2 weiterhin benötigt: atomares Status-Schreiben, Schutz der Anmeldedatenpfade, Prozessidentitätsprüfung und macOS-Sandbox-Regeln. Alte V1-Statusdateien werden nicht automatisch gelöscht, aber das Native Gateway liest und führt sie nicht aus.
Related MCP server: localterminal-lite
Die Webversion sieht nur sechs Werkzeuge:
native_session_start
native_session_continue
native_session_recover
native_session_reply_and_wait
native_session_status
native_session_stop
Jegliche V1-Werkzeugnamen, Top-Level-Dateiwerkzeuge, Bash, alte DeepSeek-Werkzeuge oder andere MCP-Methoden werden serverseitig abgelehnt, nicht nur aus der Werkzeugliste ausgeblendet.
Eine Session hat drei klar definierte Stufen, die nach der Erstellung weder hoch- noch herabgestuft noch auf ein anderes Wurzelverzeichnis umgestellt werden können:
read_only: Read, FindFiles, SearchText und schreibgeschütztes RunCommand; der Lesebereich umfasst den gesamten Computer, mit Ausnahme geschützter Status-/Anmeldedatenpfade und macOS-Berechtigungen.
direct_write: Erweitert die computerweite Lesefähigkeit um Edit, Write, NotebookEdit und ändert nur echte Verzeichnisse, die der Benutzer ausdrücklich ausgewählt hat. Diese Stufe sollte nur gewählt werden, wenn der Benutzer ausdrücklich verlangt, echte Dateien zu ändern.
worktree_write: Werkzeugsatz identisch mit direct_write, aber die Änderungen erfolgen in einem separaten Git-Worktree, den das Gateway erstellt und verwaltet; der Quell-Checkout bleibt unverändert.
Dies sind logische Werkzeuge, die das Modell in der nativen Claude-Code-Agent-Schleife aufrufen kann, aber die Ausführung gehört dem Gateway. Die unbeaufsichtigten eingebauten Claude-Code-Dateiwerkzeuge und Bash bleiben deaktiviert, um eine Umgehung von Aktionsautorisierung, Hashing, Wiederherstellung und Audit-Ledger zu vermeiden.
Read kann jede ungeschützte normale UTF-8-Datei auf dem Computer lesen und ist nicht mehr auf das Schreibverzeichnis beschränkt.
FindFiles kann begrenzte Dateiaufzählungen von beliebigen absoluten Verzeichnissen aus durchführen.
SearchText führt nur UTF-8-Literalabgleiche durch, keine regulären Ausdrücke oder Globs.
Die Suche folgt keinen symbolischen Links und überspringt .git, geschützte Pfade und externe Hardlinks.
Einzelne Suchergebnisse und vollständige Aktionsbelege sind auf 64 KiB begrenzt.
Alle Stufen können verschiedene Laufwerke und Verzeichnisse prüfen; working_directory ist nur der Standardsuchort, das Befehls-CWD und die Schreibgrenze für Schreibstufen. macOS-TCC/Dateiberechtigungen können Desktop, Dokumente oder andere systemgeschützte Orte weiterhin verweigern.
Unter direct_write ändern Edit, Write und NotebookEdit das an die Session gebundene echte Verzeichnis; unter worktree_write nur den verwalteten Worktree.
Write kann fehlende übergeordnete Verzeichnisse im autorisierten Wurzelverzeichnis nach Bedarf erstellen und die Zieldatei dann atomar anlegen; es kann dadurch nicht über das Wurzelverzeichnis, symbolische Links, .git oder geschützte Pfade hinausgehen.
NotebookEdit unterstützt das Ersetzen, Einfügen und Löschen von Zellen nach Cell-ID, führt das Notebook jedoch nicht aus.
Jede Schreibaktion speichert SHA-256 vor und nach dem Schreiben und verwendet Prepare, CAS, atomares Ablegen und dauerhafte Belege.
Nach einem Prozessabsturz wird der reale Dateizustand geprüft; wenn er nicht sicher bestimmt werden kann, wird die Wiederherstellung gestoppt, ohne blind zu wiederholen.
direct_write hat kein Dateilöschwerkzeug und schreibt keine Dateien wegen schreibgeschützter Prüfbefehle; es kann Zieldateien dennoch auf ausdrückliche Benutzeranweisung überschreiben oder ändern.
In worktree_write bleiben Dateien, HEAD, Tree, Index und Arbeitsbereichsstatus des Quell-Checkouts unverändert; das Git-Common-Verzeichnis registriert den erhaltenden Worktree.
RunCommand akzeptiert installierte Systembefehle und ausführbare Dateien im Session-Verzeichnis und pflegt keine statische Befehlsliste mehr, die normale Entwicklungswerkzeuge leicht fälschlich blockiert. Argumente werden weiterhin als exaktes argv übergeben, nicht automatisch vom Gateway zu einer Shell-Zeichenkette zusammengesetzt:
Das Session-Wurzeldateisystem ist aus Sicht des Befehls schreibgeschützt;
Netzwerk, Prozesssignale, Keychain/XPC und Modell-CLIs werden durch macOS Seatbelt blockiert;
Einstiegspunkte wie sudo, direktes Löschen/Verschieben, Systemsteuerung, find -delete/-exec, rg --pre, Modell-CLIs usw. werden weiterhin ausdrücklich abgelehnt;
Symbolische Links, Hardlinks oder Dateianzahlen in normalen Projekten führen nicht mehr dazu, dass der Befehl vor dem Start als ganzes Repository abgelehnt wird; beim tatsächlichen Zugriff greifen Seatbelt, geschützte Pfade und macOS-Berechtigungen;
Ausgabe, Laufzeit und Reklamation der Prozessgruppe sind begrenzt;
Ergebnisse gehen zuerst in dasselbe Aktions-Ledger und werden dann an die nächste GPT-Runde übergeben.
Es dient der Verifikation vertrauenswürdiger Repositories, nicht als Container gegen bösartige Prozesse desselben macOS-Kontos. Während der Session-Laufzeit sollten verwaltete Worktrees nicht gleichzeitig mit anderen Editoren oder Prozessen geändert werden.
Die Hauptroute ist fest auf chatgpt-main eingestellt und akzeptiert keine Parameter für model, provider, endpoint, API-Key oder Fallback. Wenn die aktuelle ChatGPT-Runde stoppt, bleibt Claude Code bei waiting_for_gpt stehen; es wechselt nicht heimlich zu Claude, DeepSeek oder Codex, um weiterzudenken.
Die Websuche übernimmt weiterhin die Webversion von ChatGPT. WebSearch/WebFetch von Claude Code sind nicht geöffnet, sodass es keinen Konflikt zwischen GPT-Suche und Clauses eigener Suche oder einen Kontrollverlust über die Quellen gibt.
Standardmäßig gilt subagent_policy: "none", es wird kein DeepSeek erstellt. Nur wenn worktree_write ausdrücklich deepseek_explicit wählt, kann GPT es in der Hauptschleife verwenden:
deepseek_subagent_start
deepseek_subagent_get
deepseek_subagent_stop
Die Delegierung muss zuerst in das dauerhafte Aktions-Ledger der Hauptsession eingehen, bevor die isolierte Untersession freigegeben wird. Während der Unteraufgabe kann die Hauptsession nicht gleichzeitig Edit, Write, NotebookEdit, RunCommand ausführen oder eine zweite Unteraufgabe starten. Die Route ist fest auf Sonnet/Opus → Flash, Fable → Pro eingestellt; bei Fehlern gibt es kein Fallback auf Claude, Codex, OpenAI oder eine andere DeepSeek-Stufe.
native_session_start kann bis zu acht skill_contexts empfangen, die ChatGPT ausdrücklich auswählt. Es handelt sich nicht um die native Claude-Code-Skill-Laufzeit:
Es werden nur validierte Anweisungstexte extrahiert und eingefroren;
Es werden keine Skripte, Ressourcen, Plugins, Hooks, Slash-Commands oder zusätzlichen Werkzeuge geladen;
Jeder erlaubte Eintrag fixiert gleichzeitig die Skill-ID und den SHA-256 des normalisierten vollständigen SKILL.md;
Erster Start und spätere resume verwenden denselben dauerhaften Snapshot;
Der vollständige Text erscheint nur im privaten 0600-Status und im für die aktuelle GPT-Runde erforderlichen Modellkontext.
Beispiel für die erlaubte Liste:
CLAUDE_TOOLS_NATIVE_SKILL_ALLOWLIST_JSON='[{"skill_id":"personal:review","content_sha256":"<64位小写SHA-256>"}]' \
npm startDer Hash wird über den vollständigen Text nach Entfernen des UTF-8-BOM und Normalisierung von CRLF/CR auf LF berechnet.
Jede Session verwendet ein eigenes HOME, Claude-Konfigurationsverzeichnis, Laufzeitverzeichnis und eine eigene Prozessgruppe.
Claude Code verwendet --bare, leere Setting-Quellen, strikte MCP-Konfiguration und einen präzisen Werkzeugsatz.
Der Haupt-Claude-Prozess kann nur auf den präzisen lokalen Broker/Executor-Loopback-Port zugreifen.
Anmeldedatenverzeichnisse, Gateway-Status, .git, symbolische Links und externe Hardlinks sind fail closed; der Zugriff auf normale System-/Benutzerpfade wird durch Session-Wurzel, macOS-TCC und Dateiberechtigungen gemeinsam bestimmt.
ChatGPT-Antworten und jede genehmigte Aktion werden zuerst atomar abgelegt, bevor sie an den laufenden Prozess freigegeben werden.
Ablauf des Leases stoppt den Runner und hinterlässt einen prüfbaren Zustand.
Ein Gateway-Neustart tötet keine Runner, die noch zu einer Session gehören; native_session_recover verifiziert das Eigentum, rotiert das Lease und setzt dieselbe Claude-Code-Session fort.
Wenn der Runner nicht mehr existiert, wird keine vorgetäuschte Wiederherstellung durchgeführt und keine bereits abgeschlossene Aktion wiederholt.
Claude Code 2.1.247 hat keinen verifizierten unabhängigen Schalter für „nur Hooks aktivieren, während Keychain, Plugins und automatisches Gedächtnis weiterhin deaktiviert bleiben", daher bleiben native Hooks, native Skills/Slash, Agent, Workflow, Web und nicht durch das Aktions-Ledger überwachte Drittanbieter-MCP deaktiviert.
npm startDas Native Gateway benötigt keine Schalter CLAUDE_TOOLS_NATIVE_V2 oder CLAUDE_TOOLS_NATIVE_V2_ONLY mehr; Native-only ist der einzige Betriebsmodus.
Der Status wird standardmäßig in state/ gespeichert und kann über die absolute Pfad-Umgebungsvariable CLAUDE_TOOLS_STATE_DIR geändert werden. Der Standardpfad für Claude Code ist $HOME/.npm-global/bin/claude und kann mit CLAUDE_BIN überschrieben werden.
Langlaufende Tunnel/Connector müssen nach Quellcode-Updates neu gestartet werden. ChatGPT kann das Schema verbundener Werkzeuge zwischenspeichern; wenn eine neue Session die sechs native_session_*-Werkzeuge nicht sieht, aktualisieren Sie die Seite oder verbinden Sie den Claude Tools Connector neu.
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:skillsAutomatisierte Tests decken ab:
Native-only-MCP-Direktinitialisierung, exakt sechs Werkzeuge, Ablehnung von V1-Werkzeugen und unbekannten Methoden;
Runden- und Aktions-Ledger, Antwort-Idempotenz, Leases, Prozesseigentum, Stopp und Wiederherstellung;
Computerweites Lesen von Read/FindFiles/SearchText, geschützte Pfade, Größen, Sortierung, Literalabgleich und Wettlaufgrenzen;
Edit/Write/NotebookEdit mit direktem Real-Verzeichnis-Schreiben, Worktree-Isolation, CAS, Hashing und Absturzwiederherstellung;
RunCommand mit lockerem Entwicklungsbefehlseinstieg, Session-lokalen ausführbaren Dateien, schreibgeschütztem Dateisystem, null Netzwerk, Blockierung sensibler Dienste und Timeout-Reklamation;
Skill-ID-/Text-Hash-Fixierung, start/resume-Konsistenz und private Statusgrenzen;
Explizite DeepSeek-Delegierung mit Startbarriere, Einzelaufgaben-Schreibsperre, Routenverifikation, Gateway-Neustartwiederherstellung und Stopp;
Öffentliche MCP/Session/history geben keine Autorisierungs-IDs, Runner-Tokens, PIDs, internen Pfade oder Modell-Anmeldedaten preis.
Installierte Tests verwenden lokales Claude Code 2.1.247 und ein lokales Skript-GPT, ohne Verbindung zu echten Modellen:
test:native:installed: führt FindFiles → Literal-SearchText → Read → final mit / als schreibgeschütztem Stamm aus, sowie Wiederherstellung desselben Runners/Claude-Session nach Gateway-Trennung.
test:native:installed:write: Read → Edit → Write → NotebookEdit → RunCommand → resume → Read.
test:native:installed:direct-write: dieselbe Reihe echter Claude-Code-Runden ändert direkt echte Verzeichnisse in der Test-Fixture, dann resume und Verifikation dauerhafter Ergebnisse.
test:native:installed:deepseek: verwendet ein lokales Fake-DeepSeek-CLI zur Verifikation von expliziter Delegierung, Ergebnisverifikation, aktiver Schreibsperre, Neustartwiederherstellung und Stopp.
test:native:installed:skills: verifiziert, dass zwei hash-fixierte reine Anweisungs-Skills bei start/resume denselben Snapshot verwenden.
Diese lokalen Skripttests verbrauchen keine echten ChatGPT-, Claude- oder DeepSeek-Modellkontingente. Ein echter DeepSeek-Minimal-Smoke-Test erfordert weiterhin eine separate Benutzerfreigabe.
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.
