aiterm-mcp 0.29.6 → 0.29.8

package/README.ja.md

@@ -20,7 +20,7 @@
 >
 > **これは何か:** AI が握る 1 本の永続 MCP 端末——その中に他のコーディングエージェントも起動できる。`ssh`・`docker exec`・REPL・別エージェントの TUI は、すべてその 1 本の端末の中へ「送るだけのテキスト」として入れ子になる。仕組みはあえて素朴——MCP クライアントが相手エージェントの端末を 1 ターンずつ操作するだけ。隠れたプロトコルも・aiterm独自の共有メモリ層も・自律的な交渉も無い。起動したagentは、直接CLIと同じproject／harnessの通常memory・設定を読む。
 >
-> **人が tmux に張り付く必要はない。** aiterm は MCP 越しにプログラムから駆動されるので、「AI が別のエージェントを起動して操作する」のに端末の前に誰も座らなくていい——オーケストレーションのループ・CI ステップ・cron から動かせる。
+> **人が端末に張り付く必要はない。** aiterm は MCP 越しにプログラムから駆動されるので、「AI が別のエージェントを起動して操作する」のに端末の前に誰も座らなくていい——オーケストレーションのループ・CI ステップ・cron から動かせる。
 >
 > *MCP = Model Context Protocol — Claude Code のようなツールが AI に機能を差し込むためのオープン標準。*
 
@@ -35,7 +35,7 @@ cloneもビルドも不要。どのクライアントでも公開パッケージ
 npx -y aiterm-mcp
 ```
 
-**Node.js ≥ 18** と **tmux** が必要。Codexを操作する場合は、Codex CLIの導入と認証も必要。
+**Node.js ≥ 18** と対応multiplexer backend（POSIXは**tmux**、Windows nativeは**psmux 3.3.8以上**）が必要。Codexを操作する場合は、Codex CLIの導入と認証も必要。
 
 ### Claude Code
 
@@ -94,7 +94,7 @@ host統合は、kitepon.devの製品開発を支える内部基盤
 
 **言葉でなく実測で:** 記録済み203テストのベンチマークでは、`pty_read` はコンテキストに載るトークンを生ログの **約 7.1 分の 1** に減らす。しかも pass/fail の判定は畳んでも残る。→ [組み込みシェルツールとの使い分け](#組み込みシェルツールとの使い分け)
 
-15ツール: 6つのPTYツール、正規のagent起動入口`agent_launch`、移行用の旧4alias、`agent_configure`、`claude_turn`、`claude_approval`、`diagnostics`。バックエンドはtmuxなので、MCPサーバやAIクライアントが再起動してもsessionは生き残る。
+15ツール: 6つのPTYツール、正規のagent起動入口`agent_launch`、移行用の旧4alias、`agent_configure`、`claude_turn`、`claude_approval`、`diagnostics`。backendはPOSIXのtmux／Windows nativeのpsmuxなので、MCPサーバやAIクライアントが再起動してもsessionは生き残る。
 
 **v0.28.0では実行基盤harnessとmodelを分離した。** harnessはagent loop・認証・hook・session・transcriptを所有し、modelはその上で選ぶ。Cursor Agent CLIでGPT／Claude／Grokを選んでも完了契約はCursor方式のまま。Composerは別harnessではなく、`harness:"grok-cli", model:"grok-composer-2.5-fast"`で表す。旧4起動ツールは同じ実装へ流れる互換alias。
 
@@ -109,7 +109,7 @@ model／effort変更に対応した。明示したGrok／Composer modelとCompos
 現在の`grok models` catalogへ照合し、不在時は別modelへ黙ってfallbackせず明示失敗する。
 
 **v0.24.3ではlauncherへ渡す環境変数を現在のMCP processから明示選択できる。** `env_vars`へ
-変数名だけを指定すると、aitermは起動時の現在値を読み、存在する値だけをそのagentへ渡す。永続tmux
+変数名だけを指定すると、aitermは起動時の現在値を読み、存在する値だけをそのagentへ渡す。永続multiplexer
 serverがMCP processより先に起動していても、古いserver環境に席identityやworkflow変数を消されない。
 あわせてCodex v0.147が長寿命footerへ加える任意`fast`を認識し、idleな`medium fast ·` sessionでも
 再描画・再試行・再起動なしに`agent_configure`できる。
@@ -163,7 +163,7 @@ Publishing）で公開し、GitHub Release が Official MCP Registry を再登
 
 ### 1. SSH・コンテナ・REPL を 1 本の永続端末で操作する — 土台
 
-これが土台で、tmux だけで動く——他の CLI は要らない。`pty_open` がローカル端末を 1 個握り、`ssh host`・`docker exec -it x bash`・REPL は、その中へ `pty_send` で打ち込む「ただのテキスト」——**一度だけ**。以降のコマンドは同じ認証済みセッションを通る。セッション種別をツールで区別しない。
+これが土台で、platform backend（POSIXのtmux／Windows nativeのpsmux）だけで動く——他の CLI は要らない。`pty_open` がローカル端末を 1 個握り、`ssh host`・`docker exec -it x bash`・REPL は、その中へ `pty_send` で打ち込む「ただのテキスト」——**一度だけ**。以降のコマンドは同じ認証済みセッションを通る。セッション種別をツールで区別しない。
 
 ```
 pty_open()                         → ローカル端末を 1 個握る
@@ -208,7 +208,7 @@ Cursorの`model`は`gpt-5.6-luna`のようなbase model、`reasoning_effort`は`
 `env_vars`は環境変数の**名前**だけを並べるallowlistであり、name/value mapではない。aitermは
 launcher起動時に現在のMCP processから各名前を読み、存在する値をshell quoteして、その1回のvendor
 起動コマンドへ入れる。未設定名は省略し、shell変数名として不正な名前はsession作成前に失敗する。
-全環境の暗黙copy、tmux server再起動、retry、fallbackは行わない。値はMCP tool引数には入らないが、
+全環境の暗黙copy、backend server再起動、retry、fallbackは行わない。値はMCP tool引数には入らないが、
 PTYの起動コマンドとして送られ、sessionの`.lastcmd`にも保持されるため、起動先vendorと同じOS userへ
 到達する。秘密転送路ではなく、席identityやworkflow用の非secret変数だけに使う。
 
@@ -268,7 +268,7 @@ Throughline自体が不要である。
 ← 499999500000                                     [is_complete=True via until]
 ```
 
-上の採取で私が触ったのは 2 本の `⋮` 行（長い head/tail を README 用に省略）と長すぎる grep 行 1 本の truncate だけ——`〈…〉` マーカー・トークン数・各 `is_complete` はツールが出した通り。（`until` は末尾スペース無しの `">>>"` を使う——採取されるプロンプトは末尾が削られるので `">>> "` だと外れて `timeout` に落ちる。）ネスト中は `until`（内側プロンプト）か `mark: true` を渡すこと——そこでは quiescence が原理的に効かないため（[完了検出](#完了検出5-層) / [既知の制約](#既知の制約バグではなく仕様)）。同じ tmux ソケットに人が `attach` すれば、これらをライブで覗ける（[人が覗く](#人が覗く)）。
+上の採取で私が触ったのは 2 本の `⋮` 行（長い head/tail を README 用に省略）と長すぎる grep 行 1 本の truncate だけ——`〈…〉` マーカー・トークン数・各 `is_complete` はツールが出した通り。（`until` は末尾スペース無しの `">>>"` を使う——採取されるプロンプトは末尾が削られるので `">>> "` だと外れて `timeout` に落ちる。）ネスト中は `until`（内側プロンプト）か `mark: true` を渡すこと——そこでは quiescence が原理的に効かないため（[完了検出](#完了検出5-層) / [既知の制約](#既知の制約バグではなく仕様)）。同じmultiplexer backendに人が `attach` すれば、これらをライブで覗ける（[人が覗く](#人が覗く)）。
 
 ## 最初の実行（約60秒）
 
@@ -281,7 +281,7 @@ Claude Code を再起動して、接続を確認:
 最初のセッション——4 回の呼び出しで、1 個の永続端末:
 
 ```text
-pty_open()                          → { session_id: "t1", attach: "tmux -S … attach -t t1" }
+pty_open()                          → { session_id: "t1", attach: "<platform attach command>" }
 pty_send("t1", "echo hello")        → PTY にコマンドを送る
 pty_read("t1", { wait: true })      → "hello"   （トークン削減・完了検出つき）
 pty_close("t1")                     → 端末を解放
@@ -323,7 +323,7 @@ flowchart LR
     P -->|"launches a fresh PTY per agent"| A["another coding-agent TUI<br/>Claude · Codex · Grok · Cursor"]
 ```
 
-primitive は「PTY を 1 個握る」ことだけ。それ以外——SSH・コンテナ・REPL・起動したエージェント TUI——は、永続端末の中で動く「対話的な何か」に過ぎず、同じ `pty_send` / `pty_read` で操作する。各起動ツールは自分専用の新しい PTY を開く。PTY は tmux 上にあるので、MCP サーバや AI クライアントが再起動してもセッションは生き残る。
+primitive は「PTY を 1 個握る」ことだけ。それ以外——SSH・コンテナ・REPL・起動したエージェント TUI——は、永続端末の中で動く「対話的な何か」に過ぎず、同じ `pty_send` / `pty_read` で操作する。各起動ツールは自分専用の新しい PTY を開く。PTY はPOSIXのtmux／Windows nativeのpsmux上にあるので、MCP サーバや AI クライアントが再起動してもセッションは生き残る。
 
 ## 組み込みシェルツールとの使い分け
 

package/README.md

@@ -20,7 +20,7 @@
 >
 > **What it is:** one persistent MCP terminal your AI drives — and can launch other coding agents into. `ssh`, `docker exec`, a REPL, or another agent's TUI all nest inside that one terminal as just text you send in. The mechanism is deliberately plain — your MCP client drives the other agent's terminal turn by turn: no hidden protocol, no separate aiterm-owned shared-memory layer, no autonomous negotiation. Launched agents still read the normal project and harness memory/configuration that a direct CLI launch would use.
 >
-> **No human at a tmux required.** aiterm is driven programmatically over MCP, so an AI can launch and drive another agent with no one sitting in the terminal — from an orchestration loop, a CI step, or a cron job.
+> **No human at a terminal required.** aiterm is driven programmatically over MCP, so an AI can launch and drive another agent with no one sitting in the terminal — from an orchestration loop, a CI step, or a cron job.
 >
 > *MCP = Model Context Protocol — the open standard that lets tools like Claude Code plug capabilities into an AI.*
 
@@ -34,7 +34,7 @@ No clone or build is required. Each client launches the published package with:
 npx -y aiterm-mcp
 ```
 
-Requires **Node.js ≥ 18** and **tmux**. Driving Codex also requires the Codex CLI to be installed and authenticated.
+Requires **Node.js ≥ 18** and a supported multiplexer backend: **tmux** on POSIX or **psmux 3.3.8+** on native Windows. Driving Codex also requires the Codex CLI to be installed and authenticated.
 
 ### Claude Code
 
@@ -94,7 +94,7 @@ toolchain behind kitepon.dev's products.
 
 **Measured, not claimed:** in the recorded 203-test benchmark, a `pty_read` puts **~7.1× fewer tokens** in your context than the raw log — and the pass/fail verdict survives the fold. → [When to reach for it vs. the built-in shell](#when-to-reach-for-it-vs-the-built-in-shell)
 
-Fifteen tools: six **PTY tools** — `pty_open` / `pty_send` / `pty_read` / `pty_key` / `pty_close` / `pty_list` — to open, drive, and read one persistent terminal; one canonical **agent launcher**, `agent_launch`, which selects `claude-code`, `codex-cli`, `grok-cli`, or `cursor-cli` as the execution harness; four deprecated launcher aliases kept for migration; `agent_configure`; `claude_turn`; `claude_approval`; and `diagnostics`. The backend is **tmux**, so sessions survive even if the MCP server or the AI client restarts.
+Fifteen tools: six **PTY tools** — `pty_open` / `pty_send` / `pty_read` / `pty_key` / `pty_close` / `pty_list` — to open, drive, and read one persistent terminal; one canonical **agent launcher**, `agent_launch`, which selects `claude-code`, `codex-cli`, `grok-cli`, or `cursor-cli` as the execution harness; four deprecated launcher aliases kept for migration; `agent_configure`; `claude_turn`; `claude_approval`; and `diagnostics`. The backend is **tmux on POSIX and psmux on native Windows**, so sessions survive even if the MCP server or the AI client restarts.
 
 **v0.28.0 separates the execution harness from the model.** The harness owns the agent loop, authentication, hooks, session, and transcript; `model` is what that harness runs. Cursor Agent CLI can therefore select GPT, Claude, or Grok without changing the completion contract from Cursor hooks to another harness's. Grok Composer is a Grok CLI model preset, not another harness: use `harness: "grok-cli", model: "grok-composer-2.5-fast"`. The old four launcher tools are thin compatibility aliases over the same implementation.
 
@@ -111,8 +111,8 @@ An unavailable model fails visibly instead of letting the harness CLI fall back
 
 **v0.24.3 forwards explicitly selected launcher environment variables from the current MCP process.**
 Pass variable names in `env_vars`; aiterm reads their current values at launch and injects only the
-present ones into that agent. This works even when the persistent tmux server predates the MCP
-process, so a stale tmux-server environment cannot erase per-seat identity or workflow variables.
+present ones into that agent. This works even when the persistent multiplexer server predates the MCP
+process, so a stale backend-server environment cannot erase per-seat identity or workflow variables.
 It also recognizes Codex v0.147's optional `fast` token in long-lived model/effort footers, keeping
 `agent_configure` available on an idle `medium fast ·` session without redraw, retry, or restart.
 
@@ -183,7 +183,7 @@ I used **Codex with GPT-5.6** as an engineering collaborator: it inspected the i
 
 ### 1. Drive SSH, containers, and REPLs in one persistent terminal — the primitive
 
-This is the base, and it works with just tmux — no other CLI. `pty_open` grabs one local terminal; `ssh host`, `docker exec -it x bash`, or a REPL are just text you `pty_send` into it — **once**. Every command after that rides the same already-authenticated session. Session kind is never a tool-level distinction.
+This is the base, and it works with just the platform backend — tmux on POSIX or psmux on native Windows. `pty_open` grabs one local terminal; `ssh host`, `docker exec -it x bash`, or a REPL are just text you `pty_send` into it — **once**. Every command after that rides the same already-authenticated session. Session kind is never a tool-level distinction.
 
 ```
 pty_open()                         → grab one local terminal
@@ -229,7 +229,7 @@ The canonical harness choices are:
 `env_vars` is an allowlist of environment-variable **names**, not a name/value map. At launch,
 aiterm reads each valid name from its current MCP process, shell-quotes present values, and places
 them on that one harness launch command. Missing names are omitted; invalid shell variable names
-fail before session creation. There is no implicit whole-environment copy, tmux-server restart,
+fail before session creation. There is no implicit whole-environment copy, backend-server restart,
 retry, or fallback. Values do not enter the MCP tool arguments, but they are delivered through the
 PTY launch command and retained in aiterm's per-session `.lastcmd`; the launched harness and other
 processes with access to the same OS user may read them. Use this for non-secret seat identity and
@@ -294,7 +294,7 @@ Nesting is just text you send in — here a Python REPL *inside* the same PTY (a
 ← 499999500000                                      [is_complete=True via until]
 ```
 
-The only edits to the captures above are the two `⋮` lines (a long head/tail run abbreviated for the README) and one over-long grep line truncated to fit — the `⟨…⟩` marker, the token counts, and every `is_complete` verdict are exactly what the tool printed. (Use `until: ">>>"` without a trailing space — the captured prompt is trimmed, so `">>> "` would miss and fall through to `timeout`.) While nested, pass `until` (the inner prompt) or `mark: true`, because quiescence cannot fire there by design — see [Completion detection](#completion-detection-5-layers) and [Known constraints](#known-constraints-by-design-not-bugs). A human can `attach` to the same tmux socket and watch any of this live (see [A human can watch](#a-human-can-watch)).
+The only edits to the captures above are the two `⋮` lines (a long head/tail run abbreviated for the README) and one over-long grep line truncated to fit — the `⟨…⟩` marker, the token counts, and every `is_complete` verdict are exactly what the tool printed. (Use `until: ">>>"` without a trailing space — the captured prompt is trimmed, so `">>> "` would miss and fall through to `timeout`.) While nested, pass `until` (the inner prompt) or `mark: true`, because quiescence cannot fire there by design — see [Completion detection](#completion-detection-5-layers) and [Known constraints](#known-constraints-by-design-not-bugs). A human can `attach` to the same multiplexer backend and watch any of this live (see [A human can watch](#a-human-can-watch)).
 
 ## First run (≈60 seconds)
 
@@ -307,7 +307,7 @@ Restart Claude Code, then verify the connection:
 Your first session — four calls, one persistent terminal:
 
 ```text
-pty_open()                          → { session_id: "t1", attach: "tmux -S … attach -t t1" }
+pty_open()                          → { session_id: "t1", attach: "<platform attach command>" }
 pty_send("t1", "echo hello")        → command sent into the PTY
 pty_read("t1", { wait: true })      → "hello"   (token-reduced, completion detected)
 pty_close("t1")                     → terminal released
@@ -349,7 +349,7 @@ flowchart LR
     P -->|"launches a fresh PTY per agent"| A["another coding-agent harness<br/>Claude Code · Codex CLI · Grok CLI · Cursor CLI"]
 ```
 
-One PTY is the only primitive. Everything else — SSH, containers, REPLs, and the launched agent TUIs — is just something interactive running inside a persistent terminal, driven with the same `pty_send` / `pty_read`. Each launcher opens its own fresh PTY. Because the PTYs live in tmux, sessions outlive the MCP server and the AI client.
+One PTY is the only primitive. Everything else — SSH, containers, REPLs, and the launched agent TUIs — is just something interactive running inside a persistent terminal, driven with the same `pty_send` / `pty_read`. Each launcher opens its own fresh PTY. Because the PTYs live in tmux on POSIX or psmux on native Windows, sessions outlive the MCP server and the AI client.
 
 ## When to reach for it vs. the built-in shell
 
@@ -472,7 +472,7 @@ When an agent's answer is longer than the on-screen tail (pane height ≈ 24 lin
 As of v0.16 a parent agent **never blocks** on aiterm — there is no wait parameter anywhere (v0.17 makes the waiter's exit codes mirror its outcome). The whole flow is dispatch + one universal waiter:
 
 1. Launch the child with `agent_launch({ harness: ... })`; every launch shares the normal project/user environment and adds only completion correlation plus lineage. Send a turn with plain `pty_send` (or `claude_turn issue` for durable Claude operations). The call returns immediately with an `event_cursor` in its structured receipt.
-2. Run `aiterm-wait --session <id> --cursor <event_cursor> [--operation sha256:<64hex>] [--timeout <sec>]`. It observes the harness-owned completion source, plus Claude's additive launch hook, as a **pure reader** and exits with a one-line `aiterm.agent-wait-result.v1` receipt. **Exit ≠ done**: the receipt's `outcome` is authoritative (`0` = `done`, `3` = `timeout`, `4` = `closed`, `1` = error).
+2. Pass the receipt's `wait_process.executable` and `wait_process.args` unchanged to a true argv process API. PowerShell 7's `Start-Process` is the exception because it joins `-ArgumentList` arrays; pass `windows_start_process_argument_list` as its one ready-made argument string instead. This invokes the bundled waiter through the exact Node runtime that is already running aiterm, including on native Windows where npm's human-facing bin is a PowerShell script shim and install paths may contain spaces. `wait_command` remains a compatibility display string for humans. The waiter observes the harness-owned completion source, plus Claude's additive launch hook, as a **pure reader** and exits with a one-line `aiterm.agent-wait-result.v1` receipt. **Exit ≠ done**: the receipt's `outcome` is authoritative (`0` = `done`, `3` = `timeout`, `4` = `closed`, `1` = error).
 3. **The parent never runs the waiter in its own foreground.** Waiting is correct — but the waiter is a separate process, not the parent's turn. A harness that re-invokes its agent when a background task exits (Claude Code) runs the waiter **in the background** and gets woken with zero polling. So that this is not left to interpretation, aiterm reads `clientInfo.name` from the MCP `initialize` handshake and its receipts name the concrete invocation for the detected host — for Claude Code, literally `Bash(command: "aiterm-wait …", run_in_background: true)`. Unknown or undeclared hosts get the generic "start it as a process that does not block the parent's turn" wording; nothing else about the contract changes. Every receipt leads with the same rule: dispatch and let go, then go do something else or end the turn.
 4. Collect the result exactly as before: `pty_read(agent_transcript: true)`, or `claude_turn recover` for durable Claude operations. The waiter carries the signal, never the payload.
 
@@ -556,8 +556,8 @@ symlink, filter, or replace harness configuration, authentication, MCP, plugin,
 trust, memory, or history stores. Cleanup removes only aiterm-owned launch metadata and completion
 correlation files.
 
-The ordinary environment still comes from the shell/tmux session. When a caller needs a value that
-belongs to the current MCP process rather than the older persistent tmux server, every harness
+The ordinary environment still comes from the persistent shell session. When a caller needs a value that
+belongs to the current MCP process rather than the older persistent multiplexer server, every harness
 accepts `env_vars: ["NAME", ...]`. Only those names are refreshed at launch; this is a narrow
 per-launch overlay, not a replacement environment or configuration snapshot.
 

package/dist/agent-shared.js

@@ -100,7 +100,7 @@ export function stateRoot() {
     return path.join(base, `aiterm-mcp-${uid}`);
 }
 export function ensureStateRoot() {
-    // state root は OS が与える per-user runtime dir（XDG_RUNTIME_DIR / os.tmpdir()）の下に作る。
+    // state root は OS が与えるper-user runtime dir（Windows隔離時TMPDIR／XDG_RUNTIME_DIR／os.tmpdir()）の下に作る。
     // 以前はここで symlink・owner・mode を検査していたが、共有 /tmp に敵対的な同居主体がいる
     // 前提の防御であり、対応 OS の既定配置では成立しない（オーナー裁定 2026-08-19）。
     // 作成時の 0o700 は検査ではなく妥当な既定として残す。経路の異常は以降の

package/dist/claude-stop-hook.js

@@ -22,7 +22,7 @@ function hasAitermEnv() {
         process.env.AITERM_AGENT_LAUNCH_ID);
 }
 function agentsDir() {
-    // state root は OS が与える per-user runtime dir（XDG_RUNTIME_DIR / os.tmpdir()）の下にある。
+    // state root は OS が与えるper-user runtime dir（Windows隔離時TMPDIR／XDG_RUNTIME_DIR／os.tmpdir()）の下にある。
     // 以前はここで symlink・owner・mode を検査していたが、共有 /tmp に敵対的な同居主体がいる
     // 前提の防御であり、対応 OS の既定配置では成立しない（オーナー裁定 2026-08-19）。
     // 経路の異常は open/stat の OS エラーとしてそのまま露出させる。

package/dist/core.js

@@ -11,6 +11,7 @@ import { spawnSync } from "node:child_process";
 import * as fs from "node:fs";
 import * as path from "node:path";
 import { createHash, randomBytes } from "node:crypto";
+import { fileURLToPath } from "node:url";
 import * as rtk from "./rtk.js";
 import { AitermError, telemetryOwnedFailure, ownTelemetryFailure } from "./errors.js";
 import { isWin, SOCKDIR, tmuxCommand, sendPsmuxPayload, loadPtyBufferChunk, pasteBufferBaseArgs, TMUX_EMPTY_CONFIG, attachCommand, normalizePaneCommand, appendMarkSentinel, settlePaneLog, paneCwdArgument, } from "./tmux-runtime.js";
@@ -2144,6 +2145,48 @@ function assertInitialPromptNotPendingForSend(name, force) {
 }
 // aiterm-wait の exit 契約（CLI と各所の案内文で共有する正）。exit≠完了: outcome が done の時だけ完了。
 export const AITERM_WAIT_OUTCOME_NOTE = `exit 0=done / 3=timeout（既定${DEFAULT_AGENT_DONE_TIMEOUT}秒・未完了） / 4=closed。receiptのoutcomeが正で、done以外は未完了`;
+function quoteWindowsProcessArgument(value) {
+    if (value !== "" && !/[\s"]/u.test(value))
+        return value;
+    let quoted = '"';
+    let backslashes = 0;
+    for (const char of value) {
+        if (char === "\\") {
+            backslashes += 1;
+        }
+        else if (char === '"') {
+            quoted += "\\".repeat(backslashes * 2 + 1) + '"';
+            backslashes = 0;
+        }
+        else {
+            quoted += "\\".repeat(backslashes) + char;
+            backslashes = 0;
+        }
+    }
+    return quoted + "\\".repeat(backslashes * 2) + '"';
+}
+export function windowsStartProcessArgumentList(args) {
+    return args.map(quoteWindowsProcessArgument).join(" ");
+}
+// npmのplatform別bin shimをcallerに解釈させず、現在稼働中のNodeと同梱CLIを直接起動する。
+// Windowsでもbackendはpsmux、対話shellはPowerShell 7のまま。これはwaiter processの入口だけを所有する。
+export function agentWaitProcess(session, cursor, runtime = {}) {
+    const executable = runtime.executable ?? process.execPath;
+    const args = [
+        runtime.cliPath ?? fileURLToPath(new URL("./aiterm-wait-cli.js", import.meta.url)),
+        "--session",
+        session,
+        "--cursor",
+        String(cursor),
+    ];
+    return {
+        executable,
+        args,
+        windows_start_process_argument_list: (runtime.platform ?? process.platform) === "win32"
+            ? windowsStartProcessArgumentList(args)
+            : null,
+    };
+}
 // 親ホストの識別（MCP initialize の clientInfo.name）。完了待ちコマンドを「親のターンを塞がない
 // 起動形」で名指しするためだけに使う。分からない時は汎用文へ落ち、機能は一切変えない。
 let parentClientName = null;

package/dist/harnesses/claude.js

@@ -177,7 +177,15 @@ export function claudeLaunchNote(model, effort, meta) {
     return `起動設定: model=${model ?? "CLI既定"} effort=${effort ?? "CLI既定"}。${writeScopeNote}`;
 }
 export function claudeTuiReady(screen) {
-    return screen.includes("Claude Code") && /(^|\n)\s*❯/.test(screen);
+    if (!screen.includes("Claude Code"))
+        return false;
+    const lastMarker = screen.split(/\r?\n/u).filter((line) => /^\s*❯/u.test(line)).at(-1)?.trim();
+    if (!lastMarker)
+        return false;
+    // Claude Code 2.1.251 のworkspace trust UIも選択カーソルに❯を使う。
+    // 最後のmarker行だけを見ることで、古いtrust表示がscrollbackに残っていても
+    // その下に描画された現在のcomposerを優先する。
+    return !/^❯\s*(?:\d+\.\s*)?(?:No,\s*exit|Yes,\s*I trust this folder)(?:\s|$)/iu.test(lastMarker);
 }
 // submit座礁観測のcomposer領域マーカー（ready判定と同じ記号を行頭基準で探す）。
 export const CLAUDE_COMPOSER_MARKER_RE = /^\s*❯/;

package/dist/index.js

@@ -27,9 +27,17 @@ const server = new McpServer({ name: "aiterm", version: pkg.version });
  * ここでは「待つな」を断定形で先に置き、foreground 実行の禁止までを説明の側に含める。
  */
 const NON_BLOCKING_RULE = "dispatch した子は投げっぱなしでよい＝親はここで待たない。" +
-    "完了通知は `aiterm-wait --session <id> --cursor <event_cursor>` を親のターンを塞がない別プロセスとして起動して受け、" +
+    "完了通知はreceiptの `wait_process.executable` と `wait_process.args` をそのまま親のターンを塞がない別プロセスAPIへ渡して受け、" +
+    "PowerShell 7のStart-Processだけは `windows_start_process_argument_list` を単一文字列として渡す。" +
     `exit を完了通知として扱う（${core.AITERM_WAIT_OUTCOME_NOTE}。ポーリング不要）。` +
-    "この待ちコマンドを foreground で実行して親のターンを塞ぐことはしない（receipt が実際の起動形を示す）。";
+    "`wait_command` は人間向け互換表示でありprocess境界へ使わない。foreground実行で親のターンを塞がない。";
+const waitProcessOutputSchema = z
+    .object({
+    executable: z.string(),
+    args: z.array(z.string()),
+    windows_start_process_argument_list: z.string().nullable(),
+})
+    .nullable();
 function ok(s) {
     return { content: [{ type: "text", text: s }] };
 }
@@ -86,7 +94,7 @@ server.registerTool("diagnostics", {
 }, async () => ok(await factoryDiagnostics()));
 const DEFAULT_PTY_SHELL = process.platform === "win32" ? "pwsh" : "bash";
 server.registerTool("pty_open", {
-    description: "ローカル永続端末(tmux セッション)を1個開き、session_id を返す。tmux サーバ常駐ゆえ本サーバや " +
+    description: "ローカル永続端末（POSIXはtmux、Windows nativeはpsmux 3.3.8以上）を1個開き、session_id を返す。backend server常駐ゆえ本サーバや " +
         "クライアントが再起動してもセッションは生存する。リモート操作は専用ツールにせず、開いた端末の中で " +
         'pty_send(session_id, "ssh host") と打って入る。',
     inputSchema: {
@@ -134,6 +142,7 @@ server.registerTool("pty_send", {
         mode: z.enum(["sent", "agent_dispatch"]),
         session_id: z.string(),
         event_cursor: z.number().int().nullable(),
+        wait_process: waitProcessOutputSchema,
         launch_id: z.string().nullable(),
         vendor: z.enum(["claude", "codex", "grok", "composer", "cursor"]).nullable(),
         harness: z.enum(["claude-code", "codex-cli", "grok-cli", "cursor-cli"]).nullable(),
@@ -151,6 +160,7 @@ server.registerTool("pty_send", {
             if (rtk)
                 throw new Error("agent session への dispatch は rtk:true と併用できません");
             const receipt = await core.dispatchAgentTurn(session_id, text, { raw });
+            const waitProcess = core.agentWaitProcess(receipt.session_id, receipt.event_cursor);
             return {
                 content: [
                     {
@@ -165,6 +175,7 @@ server.registerTool("pty_send", {
                     mode: "agent_dispatch",
                     session_id: receipt.session_id,
                     event_cursor: receipt.event_cursor,
+                    wait_process: waitProcess,
                     launch_id: receipt.launch_id,
                     vendor: receipt.vendor,
                     harness: receipt.harness,
@@ -180,6 +191,7 @@ server.registerTool("pty_send", {
                 mode: "sent",
                 session_id,
                 event_cursor: null,
+                wait_process: null,
                 launch_id: null,
                 vendor: null,
                 harness: null,
@@ -457,13 +469,14 @@ const agentEffortDesc = (kind) => kind === "claude"
         : kind === "cursor"
             ? "Cursor catalogのeffort。指定時はmodel必須で、adapterが model-effort の正規IDへ変換してlive catalogに照合する。"
             : "Grok Build reasoning effort。利用可能値はCLI／modelのlive catalogに従う。省略時はCLI／model既定。";
-// 全launcher共通の完了受信ガイド。待ちコマンドは起動応答の wait_command（初回prompt時）または
-// pty_send dispatch の event_cursor から組む。文型は NON_BLOCKING_RULE と同じく「待たない」が先。
+// 全launcher共通の完了受信ガイド。machine callerはreceiptのwait_processをそのまま別process APIへ渡す。
+// wait_commandは人間向け互換表示。文型は NON_BLOCKING_RULE と同じく「待たない」が先。
 const agentCompletionDesc = `起動して投げたら投げっぱなしでよい＝親はここで待たない。` +
-    `完了通知は起動応答の wait_command（初回prompt時）または pty_send dispatch 後の ` +
-    `aiterm-wait --session <id> --cursor <event_cursor> を親のターンを塞がない別プロセスとして起動して受ける` +
+    `完了通知は起動応答またはpty_send dispatch receiptの wait_processを、親のターンを塞がない` +
+    `別プロセスAPIへexecutable／argsの境界を保ったまま渡して受ける` +
+    `（PowerShell 7のStart-Processはwindows_start_process_argument_listを使う）` +
     `（${core.AITERM_WAIT_OUTCOME_NOTE}。ポーリング不要・foreground実行はしない）。` +
-    `結果回収は pty_read(agent_transcript:true)。`;
+    `wait_commandは人間向け互換表示。結果回収は pty_read(agent_transcript:true)。`;
 const agentEnvironmentDesc = `通常CLIと同じHOME・cwd・project/user/local設定・MCP・plugin・skill・permission/trustを共有する。` +
     `aitermは完了相関stateだけをlaunch単位で所有する。起動されたagentにはsub-agent自己認識、親session、` +
     `delegation depth/lineage、delegation_allowed=trueを注入し、必要な追加委譲は許可する。`;
@@ -492,6 +505,7 @@ async function launchAgent(kind, args) {
             session_id: sid,
             managed_completion: true,
             event_cursor: eventCursor,
+            wait_process: eventCursor === null ? null : core.agentWaitProcess(sid, eventCursor),
             wait_command: eventCursor === null ? null : `aiterm-wait --session ${sid} --cursor ${eventCursor}`,
             submit_residue: submitResidue,
             ...(supportsWriteScope && write_scope !== undefined
@@ -558,9 +572,10 @@ function registerAgentTool(toolName, kind, desc) {
             harness: z.literal(core.agentHarness(kind)),
             session_id: z.string().regex(/^[A-Za-z0-9_-]{1,64}$/),
             managed_completion: z.boolean().describe("後方互換field。trueはaiterm完了相関が有効という意味で、project/user環境の隔離を意味しない"),
-            // 起動時 prompt でturnが走っている時だけ非null（additive拡張）。wait_command はそのままホストの
-            // バックグラウンドタスクとして実行できる完了待ちコマンド。
+            // 起動時promptでturnが走っている時だけ非null。wait_processがmachine向けprocess境界、
+            // wait_commandは人間向け互換表示。
             event_cursor: z.number().int().nullable(),
+            wait_process: waitProcessOutputSchema,
             wait_command: z.string().nullable(),
             // 初回prompt dispatch後のsubmit座礁観測（additive）。true=composerに残存を確認（submit未成立の疑い）/
             // false=残存を観測せず（submit成立の保証ではない）/ null=promptなし・判定不能。
@@ -593,6 +608,7 @@ server.registerTool("agent_launch", {
         session_id: z.string().regex(/^[A-Za-z0-9_-]{1,64}$/),
         managed_completion: z.boolean(),
         event_cursor: z.number().int().nullable(),
+        wait_process: waitProcessOutputSchema,
         wait_command: z.string().nullable(),
         submit_residue: z.boolean().nullable(),
         write_scope: z.string().optional(),

package/dist/state-root.js

@@ -16,6 +16,13 @@ export function currentUid() {
     return process.getuid();
 }
 export function runtimeStateBase() {
+    // Windows Node の os.tmpdir() は TMPDIR を参照せず TEMP を返す。一方、psmux namespace は
+    // tmux-runtime.ts で TMPDIR を最優先する。test／隔離processがTMPDIRだけを変えた時に
+    // PTYは隔離されてもmanaged metadataが本番TEMPへ残ると、隔離側killAllが本番相関だけを
+    // 消してしまう。Windowsだけ同じTMPDIR境界へ揃える。通常serverはTMPDIR未設定なので
+    // 従来どおりos.tmpdir()（%TEMP%）を使う。
+    if (process.platform === "win32" && process.env.TMPDIR)
+        return process.env.TMPDIR;
     const xdg = process.env.XDG_RUNTIME_DIR;
     if (xdg) {
         try {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aiterm-mcp",
-  "version": "0.29.6",
+  "version": "0.29.8",
   "mcpName": "io.github.kitepon/aiterm-mcp",
   "description": "Persistent terminal MCP with one harness-based launcher for Claude Code, Codex CLI, Grok CLI, and Cursor Agent CLI, plus durable PTYs for SSH, containers, and REPLs.",
   "keywords": [