aiterm-mcp 0.29.7 → 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
 
@@ -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/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

@@ -94,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: {

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.7",
+  "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": [