aiterm-mcp 0.24.3 → 0.25.2

package/README.ja.md

@@ -1,4 +1,4 @@
-> **Claude Code から Codex CLI の対話 TUI を操作する——スラッシュコマンドや [`$imagegen`](https://learn.chatgpt.com/docs/image-generation#generate-or-edit-an-image) のようなスキルまで、MCP越しに使える。**
+> **任意のMCPクライアントから、Claude・Codex・Grok・Composerをクロスベンダーでも同一ベンダーでも永続対話TUIへ起動する。Codexのスラッシュコマンドや[`$imagegen`](https://learn.chatgpt.com/docs/image-generation#generate-or-edit-an-image)のような固有機能もそのまま使える。**
 
 <p align="center">
   <img src=".github/og.png" alt="Aiterm — 異なる知性が一つの持続する実行現場を共有する森の観測拠点" width="100%">
@@ -8,7 +8,7 @@
 
 # Aiterm
 
-[![CI](https://github.com/kitepon-rgb/aiterm-mcp/actions/workflows/ci.yml/badge.svg)](https://github.com/kitepon-rgb/aiterm-mcp/actions/workflows/ci.yml)
+[![CI](https://github.com/kitepon/aiterm-mcp/actions/workflows/ci.yml/badge.svg)](https://github.com/kitepon/aiterm-mcp/actions/workflows/ci.yml)
 [![npm](https://img.shields.io/npm/v/aiterm-mcp.svg)](https://www.npmjs.com/package/aiterm-mcp)
 [![週間ダウンロード](https://img.shields.io/npm/dw/aiterm-mcp.svg)](https://www.npmjs.com/package/aiterm-mcp)
 [![node](https://img.shields.io/node/v/aiterm-mcp)](https://nodejs.org)
@@ -16,7 +16,7 @@
 
 > *(English: [README.md](README.md))*
 
-> **あなたの AI に、ほかの AI を操らせる。** 任意の MCP クライアントから 1 回の呼び出しで、コーディングエージェント（Claude・Codex・Grok・Composer）を永続端末の中に起動し、操作用のセッションを手渡す。何をしているかをトークン削減して読み、次の指示を送る。
+> **あなたの AI に、ほかの AI を操らせる。** 任意の MCP クライアントから 1 回の呼び出しで、コーディングエージェント（Claude・Codex・Grok・Composer）を永続端末の中に起動し、操作用のセッションを手渡す。何をしているかをトークン削減して読み、次の指示を送る。呼び出し元と起動先のベンダーは独立しており、ClaudeからClaude／Codexを、CodexからClaude／Codexを起動できる。
 >
 > **これは何か:** AI が握る 1 本の永続 MCP 端末——その中に他のコーディングエージェントも起動できる。`ssh`・`docker exec`・REPL・別エージェントの TUI は、すべてその 1 本の端末の中へ「送るだけのテキスト」として入れ子になる。仕組みはあえて素朴——MCP クライアントが相手エージェントの端末を 1 ターンずつ操作するだけ。隠れたプロトコルも・aiterm独自の共有メモリ層も・自律的な交渉も無い。起動したagentは、直接CLIと同じproject／vendorの通常memory・設定を読む。
 >
@@ -90,11 +90,21 @@ claude mcp add --scope user --transport stdio aiterm -- npx -y aiterm-mcp
 
 **所有境界:** 本repositoryは永続PTYと外部agent実行レーンを所有します。製品横断の導入と
 host統合は、kitepon.devの製品開発を支える内部基盤
-[dotagents](https://github.com/kitepon-rgb/dotagents)が担当します。
+[dotagents](https://github.com/kitepon/dotagents)が担当します。
 
 **言葉でなく実測で:** 記録済み203テストのベンチマークでは、`pty_read` はコンテキストに載るトークンを生ログの **約 7.1 分の 1** に減らす。しかも pass/fail の判定は畳んでも残る。→ [組み込みシェルツールとの使い分け](#組み込みシェルツールとの使い分け)
 
-14 ツール: 6 つの **PTY ツール**（`pty_open` / `pty_send` / `pty_read` / `pty_key` / `pty_close` / `pty_list`）で 1 本の永続端末を開き・操作し・読む。加えて 4 つの **エージェント起動ツール**（`claude_agent` / `codex_agent` / `grok_agent` / `composer_agent`）が別のコーディングエージェントの TUI を新しい端末の中に起動し、`agent_configure`が起動中のCodex／Claudeのmodel・effortを再起動なしで変更し、`claude_turn`がdurable caller向けの構造化issue／recoveryを、`claude_approval`が相関済みClaude承認UI中継を、`diagnostics`が安全なfactory readinessを返す。バックエンドは **tmux** なので、MCP サーバや AI クライアントが再起動してもセッションは生き残る。
+14 ツール: 6 つの **PTY ツール**（`pty_open` / `pty_send` / `pty_read` / `pty_key` / `pty_close` / `pty_list`）で 1 本の永続端末を開き・操作し・読む。加えて 4 つの **エージェント起動ツール**（`claude_agent` / `codex_agent` / `grok_agent` / `composer_agent`）が別のコーディングエージェントの TUI を新しい端末の中に起動し、`agent_configure`が起動中のClaude／Codex／Grok／Composerのmodel・effortを再起動なしで変更し、`claude_turn`がdurable caller向けの構造化issue／recoveryを、`claude_approval`が相関済みClaude承認UI中継を、`diagnostics`が安全なfactory readinessを返す。バックエンドは **tmux** なので、MCP サーバや AI クライアントが再起動してもセッションは生き残る。
+
+**v0.25.2ではGrok 4.6を含む同一sessionの連続設定変更を安定化。** Grok Build 1.0.3で
+`/model`の成功通知が再描画により消えても、変更前には無かった要求model／effortが常駐footerへ現れた
+最終状態を確認する。caller側のretry、再起動、失敗の成功丸めは不要で、`grok-4.6`は従来どおり
+明示`model`としてlive catalog照合後に起動・変更できる。
+
+**v0.25.0ではGrok／Composerへ共通launcher制御を同等実装。** 起動時`reasoning_effort`、
+`write_scope:"read-only"`の`--sandbox read-only`強制、`agent_configure`による同一session内の
+model／effort変更に対応した。明示したGrok／Composer modelとComposer既定modelはPTY作成前に
+現在の`grok models` catalogへ照合し、不在時は別modelへ黙ってfallbackせず明示失敗する。
 
 **v0.24.3ではlauncherへ渡す環境変数を現在のMCP processから明示選択できる。** `env_vars`へ
 変数名だけを指定すると、aitermは起動時の現在値を読み、存在する値だけをそのagentへ渡す。永続tmux
@@ -168,7 +178,7 @@ pty_read(id, { wait: true })       → 削減済みの出力を読む（完了
 
 既存の人間向けtextに加えて`aiterm.agent-launch-result.v1` structured receiptも返すため、durable callerは表示文字列を解析せずsession handleを取得できる。Codexは通常rollout transcriptの`task_complete`、Grok/Composerは通常session event、Claudeは通常settingsへ加算したlaunch固有Stop hookを完了正本に使う。agent sessionへの`pty_send`は非ブロックの **dispatch** になり`event_cursor`入りreceiptを即返す。完了通知は`aiterm-wait --session <id> --cursor <event_cursor>`を親のターンを塞がない別processで受ける。durable machine callerは`claude_turn`を使い、recoveryは再送せず、検証済み完了だけがexact `raw_output`を持つ。
 
-`codex_agent`・`grok_agent`・`composer_agent`は任意の`write_scope`（`"read-only"`または書込み許可パスの説明）も受ける。指定値はlaunch receipt・session metadata・`pty_list`へ保存する。Codexの`write_scope:"read-only"`だけは実効能力壁であり、aitermがCLIの`--sandbox read-only`を付ける。Grok/Composerには対応する対話起動sandboxがなく、Codexにもパス説明をallowlistへ変換するフラグがないため、それらは強制済みと偽らず`write_scope_enforcement:"declaration_only_unsupported"`を返す。`write_scope`を省略した起動は従来どおりである。
+`codex_agent`・`grok_agent`・`composer_agent`は任意の`write_scope`（`"read-only"`または書込み許可パスの説明）も受ける。指定値はlaunch receipt・session metadata・`pty_list`へ保存する。3 launcherすべてで`write_scope:"read-only"`は実効能力壁となり、aitermがCLIの`--sandbox read-only`を付ける。パス説明をallowlistへ変換する同等CLI引数はないため、そちらだけは`write_scope_enforcement:"declaration_only_unsupported"`を返す。`write_scope`を省略した起動は従来どおりである。
 
 ```text
 codex_agent({ session_name: "codex1", cwd: "/repo",
@@ -188,8 +198,8 @@ $ aiterm-wait --session codex1 --cursor <event_cursor>   # exit 0=done / 3=timeo
 | --- | --- | --- |
 | `claude_agent` | Claude Code CLI（Anthropic） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（`low`/`medium`/`high`/`xhigh`/`max`）, `env_vars?`, `cwd?`, `session_name?` |
 | `codex_agent` | Codex CLI（OpenAI・端末設定／CLI既定、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（`low`/`medium`/`high`/`xhigh`/`max`/`ultra`）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `grok_agent` | Grok Build（xAI、既定`grok-4.5`、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`は非対応（指定時は明示エラー）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `composer_agent` | Grok Build（xAI、既定`grok-composer-2.5-fast`、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`は非対応（指定時は明示エラー）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `grok_agent` | Grok Build（xAI、既定`grok-4.5`、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（vendor対応値）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `composer_agent` | Grok Build（xAI、既定`grok-composer-2.5-fast`、`model?`で上書き。全modelをlive catalog照合） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（vendor対応値）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
 
 `env_vars`は環境変数の**名前**だけを並べるallowlistであり、name/value mapではない。aitermは
 launcher起動時に現在のMCP processから各名前を読み、存在する値をshell quoteして、その1回のvendor
@@ -290,9 +300,9 @@ claude mcp add --scope user --transport stdio aiterm -- aiterm-mcp
 
 ## ヘッドレス: 端末に人が居ない
 
-MCP クライアントが aiterm を stdio 越しにプログラムから駆動するので、上のすべては **tmux に誰も座らないまま**動く。あなたの Claude Code セッションは、`codex_agent()` でタスクを起こし、`pty_read` で結果を読み、それを使って動ける——無人で。これは、人が操作する端末が向かない場所にこそ aiterm が合うということ:
+MCP クライアントが aiterm を stdio 越しにプログラムから駆動するので、上のすべては **tmux に誰も座らないまま**動く。Claude／Codexのどちらからでも、自分自身を含む任意のlauncherを呼び、`pty_read`で結果を読んで次へ進める——無人で。これは、人が操作する端末が向かない場所にこそ aiterm が合うということ:
 
-- **複数エージェントのオーケストレーション** — 統括役がサブタスクを Codex / Grok / Composer に渡し、各々を専用の永続セッションに置き、全部を読み戻す。
+- **複数エージェントのオーケストレーション** — 統括役がサブタスクを Claude / Codex / Grok / Composer に渡し、各々を専用の永続セッションに置き、全部を読み戻す。
 - **CI** — ジョブのステップがエージェントを起こし、操作し、片付けられる。
 - **cron** — スケジュール実行がエージェントを起動して出力を回収できる。
 
@@ -383,7 +393,7 @@ aiterm は同じ核心の洞察——端末を出会いの場にする——を
 | `pty_key` | 制御キーを送る | `session_id`, `key`（`C-c`/`Enter`/`Up`…） |
 | `pty_close` | 冪等に閉じ、`closed` / `already_closed`を返す | `session_id` |
 | `pty_list` | セッション一覧 | （なし） |
-| `agent_configure` | 起動中のCodex／Claudeを再起動せずmodel／effort変更 | `session_id`, `model?`, `reasoning_effort?` |
+| `agent_configure` | 起動中のClaude／Codex／Grok／Composerを再起動せずmodel／effort変更 | `session_id`, `model?`, `reasoning_effort?` |
 | `claude_turn` | 相関済みClaude operationをdispatch（issue）または回収（recover） | `action`, `session_id`, `operation_id`, `text?` |
 | `claude_approval` | 現在表示中の相関済みClaude承認UIを検査または応答 | `action`, `session_id`, `operation_id?`, `approval_choice?`, `observed_prompt_digest?` |
 | `diagnostics` | 機械可読 JSON による read-only factory readiness | （なし） |
@@ -400,14 +410,14 @@ consumer は `aiterm-runtime-errors snapshot` を読み、durable ingestion 後
 
 各ツールは特定ベンダーの対話型コーディングエージェント TUI を新しい永続 PTY の中に起動し、`session_id` を返す。以後は他のセッションと同様に `pty_read` / `pty_send` で操作する。モデルごとに 1 ツール＝ツール名を見ればどのモデルか分かる。TUI は全画面アプリなので、`pty_read({ screen: true })` で描画済みの画面を読む。
 
-`agent_configure({ session_id, model?, reasoning_effort? })`はvendor標準操作で起動中のCodex／Claudeを変更し、PTYと会話contextを維持する。Claude Code標準の`/model`・`/effort`は、新しいClaude sessionの既定値も同時に保存する。
+`agent_configure({ session_id, model?, reasoning_effort? })`はvendor標準操作で起動中のClaude／Codex／Grok／Composerを変更し、PTYと会話contextを維持する。Grok／Composerは同じlive model catalog照合後に`/model <model> [effort]`または`/effort <effort>`を使う。Claude Code標準の`/model`・`/effort`は、新しいClaude sessionの既定値も同時に保存する。
 
 | ツール | 起動するもの | 主な引数 |
 | --- | --- | --- |
 | `claude_agent` | Claude Code CLI（Anthropic） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（`low`/`medium`/`high`/`xhigh`/`max`）, `env_vars?`, `cwd?`, `session_name?` |
 | `codex_agent` | Codex CLI（OpenAI・端末設定／CLI既定、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（`low`/`medium`/`high`/`xhigh`/`max`/`ultra`）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `grok_agent` | Grok Build（xAI、既定`grok-4.5`、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`は非対応（指定時は明示エラー）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `composer_agent` | Grok Build（xAI、既定`grok-composer-2.5-fast`、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`は非対応（指定時は明示エラー）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `grok_agent` | Grok Build（xAI、既定`grok-4.5`、`model?`で上書き） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（vendor対応値）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `composer_agent` | Grok Build（xAI、既定`grok-composer-2.5-fast`、`model?`で上書き。全modelをlive catalog照合） | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?`（vendor対応値）, `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
 
 対応するCLI（`claude` / `codex` / `grok`）の導入・認証が必要。前提違反はsession作成前に明示失敗する。4 launcherすべてが通常project/user環境と同じ非ブロックdispatch契約を使う。Claude／Codex／Grok／Composerのdepth 1 live smokeと、Claude親→Claude孫のdepth 2 nested delegation smokeはgreenであり、fixtureによる検証とは区別して記録する。
 
@@ -467,6 +477,11 @@ npm test           # build してから node:test 回帰スイート（tmux 必
 npm link           # ローカルで `aiterm-mcp` を PATH に
 ```
 
+開発中は変更に直結するfocused testを先にローカルで実行します。GitHub Actionsの最終gateは
+self-hostedのmacOS native・Linux native・Windows native・WSL2で同じ`npm test`を同時実行し、
+OS別の縮小suiteで代用しません。tag起点のnpm公開は4環境greenとtagged commitの`origin/main`
+祖先確認を通過した後だけ実行します。
+
 ロジックは `src/core.ts`（tmux 制御・削減・完了検出・安全・エージェント起動）と `src/rtk.ts`（コマンド別 reducer）、公開は `src/index.ts`。設計の出発点と reducer の移植元（pytest reducer は本家 rtk 0.42.0 と一致するよう移植・ただし上記の `FAILED` 行の差異は意図的・回帰テストで固定）は `prototype/python/` を参照。
 
 ## 試す
@@ -477,10 +492,10 @@ npm link           # ローカルで `aiterm-mcp` を PATH に
 claude mcp add --scope user --transport stdio aiterm -- npx -y aiterm-mcp
 ```
 
-aiterm が、あなたの AI に別のエージェントへ仕事を渡させたなら——あるいはトークンの往復を 1 回でも省けたなら——**[リポジトリに star](https://github.com/kitepon-rgb/aiterm-mcp)** を。他の人に見つけてもらう一番安い方法です。
+aiterm が、あなたの AI に別のエージェントへ仕事を渡させたなら——あるいはトークンの往復を 1 回でも省けたなら——**[リポジトリに star](https://github.com/kitepon/aiterm-mcp)** を。他の人に見つけてもらう一番安い方法です。
 
 - **npm:** https://www.npmjs.com/package/aiterm-mcp
-- **Issue / バグ報告:** https://github.com/kitepon-rgb/aiterm-mcp/issues
+- **Issue / バグ報告:** https://github.com/kitepon/aiterm-mcp/issues
 
 ## ライセンス
 

package/README.md

@@ -1,4 +1,4 @@
-> **Drive Codex CLI's interactive TUI from Claude Code — including slash commands and skills such as [`$imagegen`](https://learn.chatgpt.com/docs/image-generation#generate-or-edit-an-image) — through MCP.**
+> **From any MCP client, launch Claude, Codex, Grok, or Composer — cross-vendor or same-vendor — inside a persistent interactive TUI, with native features such as Codex slash commands and [`$imagegen`](https://learn.chatgpt.com/docs/image-generation#generate-or-edit-an-image) available.**
 
 <p align="center">
   <img src=".github/og.png" alt="Aiterm — a shared forest observatory where different intelligences work in one persistent execution space" width="100%">
@@ -8,7 +8,7 @@
 
 # Aiterm
 
-[![CI](https://github.com/kitepon-rgb/aiterm-mcp/actions/workflows/ci.yml/badge.svg)](https://github.com/kitepon-rgb/aiterm-mcp/actions/workflows/ci.yml)
+[![CI](https://github.com/kitepon/aiterm-mcp/actions/workflows/ci.yml/badge.svg)](https://github.com/kitepon/aiterm-mcp/actions/workflows/ci.yml)
 [![npm](https://img.shields.io/npm/v/aiterm-mcp.svg)](https://www.npmjs.com/package/aiterm-mcp)
 [![weekly downloads](https://img.shields.io/npm/dw/aiterm-mcp.svg)](https://www.npmjs.com/package/aiterm-mcp)
 [![node](https://img.shields.io/node/v/aiterm-mcp)](https://nodejs.org)
@@ -16,7 +16,7 @@
 
 > *(日本語: [README.ja.md](README.ja.md))*
 
-> **Let your AI orchestrate other AIs.** From any MCP client, one call spawns a coding agent (Claude, Codex, Grok, or Composer) inside a persistent terminal and hands you a session to drive: read what it's doing token-reduced, send it the next instruction.
+> **Let your AI orchestrate other AIs.** From any MCP client, one call spawns a coding agent (Claude, Codex, Grok, or Composer) inside a persistent terminal and hands you a session to drive: read what it's doing token-reduced, send it the next instruction. The caller and launched vendor are independent: Claude can launch Claude or Codex, and Codex can launch Claude or Codex.
 >
 > **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 vendor memory/configuration that a direct CLI launch would use.
 >
@@ -89,12 +89,23 @@ Save this as `.cursor/mcp.json` for the project, or `~/.cursor/mcp.json` globall
 
 **Ownership boundary:** this repository owns the persistent PTY and external-agent
 execution lane. Cross-product installation and host integration are handled by
-[dotagents](https://github.com/kitepon-rgb/dotagents), the internal development
+[dotagents](https://github.com/kitepon/dotagents), the internal development
 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)
 
-Fourteen tools: six **PTY tools** — `pty_open` / `pty_send` / `pty_read` / `pty_key` / `pty_close` / `pty_list` — to open, drive, and read one persistent terminal, four **agent launchers** — `claude_agent` / `codex_agent` / `grok_agent` / `composer_agent` — that each start another coding agent's TUI inside a fresh one, `agent_configure` to change a running Codex/Claude session's model and effort without restarting it, `claude_turn` for durable structured issue/recovery, `claude_approval` for correlated Claude approval prompts, and `diagnostics` for safe factory readiness. The backend is **tmux**, so sessions survive even if the MCP server or the AI client restarts.
+Fourteen tools: six **PTY tools** — `pty_open` / `pty_send` / `pty_read` / `pty_key` / `pty_close` / `pty_list` — to open, drive, and read one persistent terminal, four **agent launchers** — `claude_agent` / `codex_agent` / `grok_agent` / `composer_agent` — that each start another coding agent's TUI inside a fresh one, `agent_configure` to change a running Claude/Codex/Grok/Composer session's model and effort without restarting it, `claude_turn` for durable structured issue/recovery, `claude_approval` for correlated Claude approval prompts, and `diagnostics` for safe factory readiness. The backend is **tmux**, so sessions survive even if the MCP server or the AI client restarts.
+
+**v0.25.2 stabilizes repeated in-place configuration changes, including Grok 4.6.** If Grok Build
+1.0.3 redraws before its `/model` success notice can be observed, aiterm confirms the requested model/effort
+from the persistent footer when that state was absent before the command. Callers do not retry, restart, or
+round a failure into success; explicit `grok-4.6` launch and configuration still pass the live catalog check.
+
+**v0.25.0 gives Grok and Composer the same shared launcher controls.** Their launchers now pass
+`reasoning_effort`, enforce `write_scope: "read-only"` with `--sandbox read-only`, and support
+in-place model/effort changes through `agent_configure`. Before creating a PTY, aiterm checks an
+explicit Grok/Composer model—and Composer's default model—against the live `grok models` catalog.
+An unavailable model fails visibly instead of letting the vendor CLI fall back to another model.
 
 **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
@@ -162,7 +173,7 @@ A lot of 2026's agent tooling is converging on orchestration: a lead model deleg
 
 ## Built with Codex and GPT-5.6 for OpenAI Build Week 2026
 
-aiterm predates Build Week, so the event work is kept visible in dated commits. During the submission window (July 14–16, 2026), I extended it with safe serialized delivery for long PTY input, correlated operation IDs and bounded result recovery, machine-readable launch and idempotent close receipts, and a hardened readiness gate that prevents prompts from disappearing during TUI startup redraws. The public comparison from the pre-event release is [`v0.12.2...main`](https://github.com/kitepon-rgb/aiterm-mcp/compare/v0.12.2...main).
+aiterm predates Build Week, so the event work is kept visible in dated commits. During the submission window (July 14–16, 2026), I extended it with safe serialized delivery for long PTY input, correlated operation IDs and bounded result recovery, machine-readable launch and idempotent close receipts, and a hardened readiness gate that prevents prompts from disappearing during TUI startup redraws. The public comparison from the pre-event release is [`v0.12.2...main`](https://github.com/kitepon/aiterm-mcp/compare/v0.12.2...main).
 
 I used **Codex with GPT-5.6** as an engineering collaborator: it inspected the implementation, challenged the API and recovery contracts, generated focused regression cases, and helped verify race, security, timeout, and malformed-event paths. I reviewed the diffs and test evidence and retained the final product and architecture decisions. At that Build Week checkpoint, the regression suite contained 262 tests covering normal operation as well as failure and recovery behavior; current release receipts live in the [CHANGELOG](CHANGELOG.md) and release ADRs.
 
@@ -187,7 +198,7 @@ The same primitive hosts another agent's TUI. Four launchers each start one vend
 
 The human-readable launch text is accompanied by an `aiterm.agent-launch-result.v1` structured receipt, so durable callers never parse display text for the session handle; when the launch carries an initial `prompt`, the receipt also includes the `event_cursor`, a ready-made `wait_command` for the completion waiter, and a `submit_residue` observation (`true` = the prompt is likely still sitting unsubmitted in the composer — the hint explains recovery; `false` = no residue observed, not a proof of submission; `null` = not applicable). From there you drive it with the same `pty_read` / `pty_send` you'd use on any shell. Codex completion comes from its normal durable rollout transcript's `task_complete`; Grok/Composer use their normal session events; Claude receives a launch-specific Stop hook settings addition while still loading normal user/project/local settings. Sending to an agent session is a non-blocking **dispatch** — the call returns immediately with an `event_cursor`, and completion arrives via [`aiterm-wait`](#completion-push-for-parent-agents-aiterm-wait). Durable machine callers use `claude_turn({ action: "issue" | "recover", session_id, operation_id, ... })`: it returns fixed `accepted` / `pending` / `completed` / `unknown` states without parsing human-facing errors, never resends during recovery, and includes exact `raw_output` only for a verified completion. An initial `prompt` on `claude_agent`/`codex_agent` is submitted through the same ready gate and the launcher returns without waiting; on Grok/Composer it is passed on the CLI's argv. This needs the vendor's own CLI installed and authenticated — see [Requirements](#requirements).
 
-`codex_agent`, `grok_agent`, and `composer_agent` also accept an optional `write_scope`: either `"read-only"` or a human-readable description of writable paths. A supplied value is retained in the launch receipt, session metadata, and `pty_list`. For Codex, `write_scope: "read-only"` is an effective boundary: aiterm adds the CLI's `--sandbox read-only` flag. Grok/Composer have no corresponding interactive-launch sandbox, and Codex has no path-description allowlist flag; those cases return `write_scope_enforcement: "declaration_only_unsupported"` rather than claiming enforcement. Omitting `write_scope` preserves prior behavior.
+`codex_agent`, `grok_agent`, and `composer_agent` also accept an optional `write_scope`: either `"read-only"` or a human-readable description of writable paths. A supplied value is retained in the launch receipt, session metadata, and `pty_list`. For all three launchers, `write_scope: "read-only"` is an effective boundary: aiterm adds the CLI's `--sandbox read-only` flag. A path description remains declaration-only because none of these CLI launch surfaces provides an equivalent path allowlist flag; that case returns `write_scope_enforcement: "declaration_only_unsupported"`. Omitting `write_scope` preserves prior behavior.
 
 For a correlated Claude turn stopped at `Do you want to proceed?`, use `claude_approval(action: "inspect", ...)` to capture the active operation and SHA-256 screen digest, review the displayed command, then call `respond` with that exact digest and either `approve_once` or `deny`. The relay rechecks the operation and screen under the send lock, never exposes arbitrary input or permanent approval, keeps the active marker intact, and records a prompt-free owner-only receipt. `pty_send(force: true)` does not bypass this boundary.
 
@@ -210,8 +221,8 @@ One call per model, so the tool name itself tells you which model you get:
 | --- | --- | --- |
 | `claude_agent` | Claude Code CLI (Anthropic) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (`low`/`medium`/`high`/`xhigh`/`max`), `env_vars?`, `cwd?`, `session_name?`, `launch_operation_id?` |
 | `codex_agent` | Codex CLI (OpenAI; terminal config/CLI default unless overridden) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (`low`/`medium`/`high`/`xhigh`/`max`/`ultra`; ultra enables proactive automatic delegation), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `grok_agent` | Grok Build, model `grok-4.5` by default (`model?` overrides) (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` unsupported (an explicit value is an error; Grok CLI `--effort` is headless-only), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `composer_agent` | Grok Build, model `grok-composer-2.5-fast` by default (`model?` overrides) (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` unsupported (an explicit value is an error), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `grok_agent` | Grok Build, model `grok-4.5` by default (`model?` overrides) (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (vendor-supported value), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `composer_agent` | Grok Build, model `grok-composer-2.5-fast` by default (`model?` overrides); every model is live-catalog checked (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (vendor-supported value), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
 
 `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
@@ -231,7 +242,7 @@ places its returned context before a fixed separator and the mission. This route
 `throughline >= 0.9.0`; it reads the source memory without changing that database's session
 ownership. No Throughline dependency is needed when the field is omitted.
 
-Claude and Codex launchers forward `model` and `reasoning_effort` through public CLI flags; Grok/Composer reject `reasoning_effort` because it is headless-only. Pass an absolute path for `cwd` — `~` is not expanded. Durable callers can make a promptless Claude launch exactly replayable by passing an explicit `session_name` and `launch_operation_id`. Claude adds a launch-local settings file only for the correlated Stop hook and loads it together with normal `user,project,local` setting sources; it does not replace normal hooks, MCPs, plugins, permissions, or trust state. The hook event contains no answer body, and the bounded owner-only result is returned by `pty_read({ agent_transcript:true })` without reading Claude's private transcript. While a correlated Claude turn is active, raw sends and non-interrupt keys are rejected. Exact `/login` and `/logout` dispatches are rejected so shared authentication is repaired once in a normal terminal. Codex reads its normal rollout store; Grok/Composer read their normal session event/history files. Before dispatch, Codex waits for an idle TUI, while Grok/Composer additionally require the vendor's structured `mcp_init_completed` event so a visible input box cannot accept a prompt too early. Correlated completion requires POSIX filesystem semantics (Linux, WSL2, macOS).
+All four launchers forward `model` and `reasoning_effort` through public CLI flags. Explicit Grok/Composer models and Composer's default model are checked against the current `grok models` catalog before a PTY exists; missing models are errors, with no cache, retry, or fallback to another model. Pass an absolute path for `cwd` — `~` is not expanded. Durable callers can make a promptless Claude launch exactly replayable by passing an explicit `session_name` and `launch_operation_id`. Claude adds a launch-local settings file only for the correlated Stop hook and loads it together with normal `user,project,local` setting sources; it does not replace normal hooks, MCPs, plugins, permissions, or trust state. The hook event contains no answer body, and the bounded owner-only result is returned by `pty_read({ agent_transcript:true })` without reading Claude's private transcript. While a correlated Claude turn is active, raw sends and non-interrupt keys are rejected. Exact `/login` and `/logout` dispatches are rejected so shared authentication is repaired once in a normal terminal. Codex reads its normal rollout store; Grok/Composer read their normal session event/history files. Before dispatch, Codex waits for an idle TUI, while Grok/Composer additionally require the vendor's structured `mcp_init_completed` event so a visible input box cannot accept a prompt too early. Correlated completion requires POSIX filesystem semantics (Linux, WSL2, macOS).
 
 There is no hidden protocol between agents: a launched Claude, Codex, Grok, or Composer is another user-visible persistent terminal session. The MCP client drives that TUI with ordinary PTY operations, and a human can attach to watch or take over.
 
@@ -317,9 +328,9 @@ This registers it in `~/.claude.json`; you'll get an approval prompt the first t
 
 ## Headless: no human at the terminal
 
-Because an MCP client drives aiterm programmatically over stdio, everything above can run with **nobody sitting at a tmux**. Your Claude Code session can `codex_agent()` a task, `pty_read` the result, and act on it — unattended. That makes aiterm a fit for exactly the places a human-driven terminal isn't:
+Because an MCP client drives aiterm programmatically over stdio, everything above can run with **nobody sitting at a tmux**. A Claude or Codex session can call any launcher — including another instance of itself — then `pty_read` the result and act on it unattended. That makes aiterm a fit for exactly the places a human-driven terminal isn't:
 
-- **Multi-agent orchestration** — an orchestrator hands sub-tasks to Codex / Grok / Composer, each in its own persistent session, and reads them all back.
+- **Multi-agent orchestration** — an orchestrator hands sub-tasks to Claude / Codex / Grok / Composer, each in its own persistent session, and reads them all back.
 - **CI** — a job step can spin up an agent, drive it, and tear it down.
 - **cron** — a scheduled run can launch an agent and collect its output.
 
@@ -412,7 +423,7 @@ On top of that sits a productized layer a raw tmux bridge doesn't have: **token-
 | `pty_key` | Send a control key | `session_id`, `key` (`C-c`/`Enter`/`Up`…) |
 | `pty_close` | Close idempotently; return `closed` / `already_closed` | `session_id` |
 | `pty_list` | List sessions (agent rows carry `agent=<kind>` metadata) | (none) |
-| `agent_configure` | Change model/effort in a running Codex or Claude session without restarting it | `session_id`, `model?`, `reasoning_effort?` |
+| `agent_configure` | Change model/effort in a running Claude, Codex, Grok, or Composer session without restarting it | `session_id`, `model?`, `reasoning_effort?` |
 | `claude_turn` | Issue (dispatch-only) or recover one correlated Claude operation | `action`, `session_id`, `operation_id`, `text?` |
 | `claude_approval` | Inspect or answer the current correlated Claude approval prompt | `action`, `session_id`, `operation_id?`, `approval_choice?`, `observed_prompt_digest?` |
 | `diagnostics` | Read-only factory readiness as machine-readable JSON | (none) |
@@ -429,16 +440,16 @@ Consumer flow is `aiterm-runtime-errors snapshot`, then `aiterm-runtime-errors a
 
 Each launcher starts a specific vendor's interactive coding-agent TUI inside a fresh persistent PTY and returns its `session_id` — from there you drive it with plain `pty_read` / `pty_send`, exactly like any other session. One tool per model, so the tool name itself tells you which model you get. The TUI is a full-screen app, so read it with `pty_read({ screen: true })` for the rendered view.
 
-`agent_configure({ session_id, model?, reasoning_effort? })` changes a running Codex or Claude TUI through the vendor's standard controls, preserving the PTY and conversation context. Claude Code's native `/model` and `/effort` commands also save those choices as defaults for new Claude sessions.
+`agent_configure({ session_id, model?, reasoning_effort? })` changes a running Claude, Codex, Grok, or Composer TUI through the vendor's standard controls, preserving the PTY and conversation context. Grok/Composer use `/model <model> [effort]` or `/effort <effort>` after the same live model-catalog check. Claude Code's native `/model` and `/effort` commands also save those choices as defaults for new Claude sessions.
 
 | Tool | Launches | Key args |
 | --- | --- | --- |
 | `claude_agent` | Claude Code CLI (Anthropic) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (`low`/`medium`/`high`/`xhigh`/`max`), `env_vars?`, `cwd?`, `session_name?`, `launch_operation_id?` |
 | `codex_agent` | Codex CLI (OpenAI; terminal config/CLI default unless overridden) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (`low`/`medium`/`high`/`xhigh`/`max`/`ultra`; ultra enables proactive automatic delegation), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `grok_agent` | Grok Build, model `grok-4.5` by default (`model?` overrides) (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` unsupported (an explicit value is an error; Grok CLI `--effort` is headless-only), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
-| `composer_agent` | Grok Build, model `grok-composer-2.5-fast` by default (`model?` overrides) (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` unsupported (an explicit value is an error), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `grok_agent` | Grok Build, model `grok-4.5` by default (`model?` overrides) (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (vendor-supported value), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
+| `composer_agent` | Grok Build, model `grok-composer-2.5-fast` by default (`model?` overrides); every model is live-catalog checked (xAI) | `prompt?`, `throughline_source_session?`, `model?`, `reasoning_effort?` (vendor-supported value), `env_vars?`, `cwd?`, `session_name?`, `write_scope?` |
 
-The vendor CLI must be installed and authenticated (`claude` for `claude_agent`; `codex` for `codex_agent`; `grok` for both Grok tools). Binary resolution uses `CLAUDE_BIN` / `CODEX_BIN` / `GROK_BIN`, then each documented default location, then `PATH`. Missing binaries, invalid model/effort values, and nonexistent `cwd` fail before a session is created. Claude additionally requires a structured healthy authentication status before any PTY exists, and correlated Claude sessions reject `/login` and `/logout`; repair authentication once in a normal terminal. All four launchers share the normal project/user environment and the same non-blocking dispatch contract. Claude, Codex, Grok, and Composer depth-1 live smokes and a Claude depth-2 nested-delegation smoke are green; fixture coverage remains a separate claim. Native Windows can launch agents but correlated completion is not supported yet.
+The vendor CLI must be installed and authenticated (`claude` for `claude_agent`; `codex` for `codex_agent`; `grok` for both Grok tools). Binary resolution uses `CLAUDE_BIN` / `CODEX_BIN` / `GROK_BIN`, then each documented default location, then `PATH`. Missing binaries, invalid model/effort values, unavailable Grok/Composer catalog models, and nonexistent `cwd` fail before a session is created. Claude additionally requires a structured healthy authentication status before any PTY exists, and correlated Claude sessions reject `/login` and `/logout`; repair authentication once in a normal terminal. All four launchers share the normal project/user environment and the same non-blocking dispatch contract. Claude, Codex, Grok, and Composer depth-1 live smokes and a Claude depth-2 nested-delegation smoke are green; fixture coverage remains a separate claim. Native Windows can launch agents but correlated completion is not supported yet.
 
 Set `throughline_source_session` together with a non-empty mission in `prompt` to prepend
 Throughline's read-only handoff context. This optional route requires `throughline >= 0.9.0`,
@@ -450,7 +461,7 @@ When an agent's answer is longer than the on-screen tail (pane height ≈ 24 lin
 
 ### Completion detection (5 layers)
 
-`pty_read({ wait: true })` decides "is the command done?" via five layers: process exit / a `mark:true` sentinel / an `until` match / output quiescence with shell return / timeout. Agent sessions add a sixth exact layer: Codex observes normal rollout `task_complete`; Grok/Composer observe normal session `turn_ended`; Claude observes its additive launch-correlated Stop event. `aiterm-wait --cursor` performs that vendor-specific observation without the parent blocking or polling. Pre-send readiness failures are MCP errors, and late completion remains recoverable without resending.
+`pty_read({ wait: true })` decides "is the command done?" via five layers: process exit / a `mark:true` sentinel / an `until` match / output quiescence with shell return / timeout. When `mark` or `until` is active, that requested evidence takes precedence and a momentarily quiet shell cannot complete the read as quiescent. Agent sessions add a sixth exact layer: Codex observes normal rollout `task_complete`; Grok/Composer observe normal session `turn_ended`; Claude observes its additive launch-correlated Stop event. `aiterm-wait --cursor` performs that vendor-specific observation without the parent blocking or polling. Pre-send readiness failures are MCP errors, and late completion remains recoverable without resending.
 
 ### Completion push for parent agents (`aiterm-wait`)
 
@@ -475,7 +486,7 @@ As of v0.16 a parent agent **never blocks** on aiterm — there is no wait param
 
 Before sending, `pty_send` blocks destructive commands (`rm -rf /`, `mkfs`, `dd of=/dev/…`, `DROP TABLE`, …) — pass `force: true` to override — and sanitizes ESC / bracketed-paste terminators. `pty_read` neutralizes control characters in what it returns by default (`raw: true` returns the bytes verbatim). This is a **tripwire, not a sandbox** (see [Known constraints](#known-constraints-by-design-not-bugs)).
 
-Each `pty_send` accepts at most 64 KiB of UTF-8 text. Sends to the same session are serialized across aiterm processes so chunks cannot interleave. On macOS, text is pasted through tmux in UTF-8-safe 256-byte chunks to avoid the platform PTY truncation observed with long input; Linux and WSL use one bounded paste. Sanitized multiline text sent while a POSIX shell is in the foreground is encoded as one newline-free `eval` input: the shell receives the complete script before it runs the first line, so a pager or REPL started mid-script cannot consume later lines as interactive keystrokes. Single-line input, `raw:true`, and non-shell frontends remain direct PTY pastes. Agent dispatches additionally paste with tmux bracketed paste (`paste-buffer -p`): panes that requested bracketed-paste mode (the vendor TUIs) receive each chunk wrapped in `ESC[200~/201~`, hardening prompt injection against mid-word key-interpretation corruption and dropped submits. If a later chunk fails, aiterm reports the partial-send state and does not press Enter automatically. A lock left by a terminated sender fails closed before sending; close and recreate that session (or use `pty_kill_all` when every session is disposable) to clean it up safely.
+Each `pty_send` accepts at most 64 KiB of UTF-8 text. Sends to the same session are serialized across aiterm processes so chunks cannot interleave. Every OS pastes through tmux in UTF-8-safe 256-byte chunks with a 10 ms drain interval; macOS, Linux, and WSL2 have all demonstrated silent middle/trailing loss when a long input is pushed without that boundary. Sanitized multiline text sent while a POSIX shell is in the foreground is encoded as one newline-free `eval` input: the shell receives the complete script before it runs the first line, so a pager or REPL started mid-script cannot consume later lines as interactive keystrokes. Single-line input, `raw:true`, and non-shell frontends remain direct PTY pastes. Agent dispatches additionally paste with tmux bracketed paste (`paste-buffer -p`): panes that requested bracketed-paste mode (the vendor TUIs) receive each chunk wrapped in `ESC[200~/201~`, hardening prompt injection against mid-word key-interpretation corruption and dropped submits. If a later chunk fails, aiterm reports the partial-send state and does not press Enter automatically. A lock left by a terminated sender fails closed before sending; close and recreate that session (or use `pty_kill_all` when every session is disposable) to clean it up safely.
 
 ## A human can watch
 
@@ -510,6 +521,13 @@ npm test           # build, then the node:test regression suite (requires tmux)
 npm link           # put `aiterm-mcp` on PATH locally
 ```
 
+Development uses focused local tests first. The final GitHub Actions gate starts the same full
+`npm test` concurrently on self-hosted macOS native, Linux native, Windows native, and WSL2
+runners; it does not replace any OS with a reduced suite. Tag-triggered npm publishing runs only
+after all four environments pass and the tagged commit is confirmed on `origin/main`. The native
+Windows runner must run as the interactive Windows user that owns the initialized WSL distro;
+`NETWORK SERVICE` cannot see that user's WSL/tmux environment and is not a valid runner identity.
+
 Logic lives in `src/core.ts` (tmux control, reduction, completion detection, safety, agent launch) and `src/rtk.ts` (per-command reducers); `src/index.ts` is the MCP surface. The design origin and the reducer's porting source (the pytest reducer is ported to match upstream rtk 0.42.0, except the deliberate `FAILED`-line difference noted above, and is locked by regression tests) are in `prototype/python/`.
 
 ## Try it
@@ -520,10 +538,10 @@ One command, no clone, no build:
 claude mcp add --scope user --transport stdio aiterm -- npx -y aiterm-mcp
 ```
 
-If aiterm let your AI hand a task to another agent — or saved you a round-trip of tokens — **[star the repo](https://github.com/kitepon-rgb/aiterm-mcp)**. It's the cheapest way to help others find it.
+If aiterm let your AI hand a task to another agent — or saved you a round-trip of tokens — **[star the repo](https://github.com/kitepon/aiterm-mcp)**. It's the cheapest way to help others find it.
 
 - **npm:** https://www.npmjs.com/package/aiterm-mcp
-- **Issues / bug reports:** https://github.com/kitepon-rgb/aiterm-mcp/issues
+- **Issues / bug reports:** https://github.com/kitepon/aiterm-mcp/issues
 
 ## Shared agent environment
 

package/dist/core.js

@@ -73,6 +73,8 @@ const AGENT_SUBMIT_RESIDUE_MAX_SAMPLES = 5;
 const AGENT_SUBMIT_RESIDUE_TAIL_CHARS = 32;
 const AGENT_SUBMIT_RESIDUE_MIN_TAIL_CHARS = 8;
 const GROK_AUTH_MAX_BYTES = 64 * 1024;
+const GROK_MODELS_MAX_BYTES = 1024 * 1024;
+const GROK_MODELS_TIMEOUT_MS = 15_000;
 const CLAUDE_RESULT_MAX_BYTES = 4 * 1024 * 1024;
 // 出力削減（RTK の CAP 思想を移植）
 const MAX_LINES_BEFORE_ELIDE = 60;
@@ -84,9 +86,11 @@ const LINE_TAIL_CHARS = 600;
 const DEDUP_MIN_RUN = 3; // 同一行がこれ以上連続したら 1 行＋件数に畳む
 const MAX_FULL_BYTES = 8 * 1024 * 1024; // full/range 読取で一度にメモリへ載せる上限（B7）
 const MAX_SEND_BYTES = 64 * 1024;
-// macOSのPTY入力queueは、tmuxが長文を1回で流すと後半を落とすことがある。
+// PTY入力queueはOSを問わず、tmuxが長文を1回で流すと後半を落とすことがある。
 // UTF-8境界を守って小さいtmux client roundtripに分け、各回にserver event loopがPTYへdrainできる境界を作る。
-const PTY_PASTE_CHUNK_BYTES = process.platform === "darwin" ? 256 : MAX_SEND_BYTES;
+const PTY_PASTE_CHUNK_BYTES = 256;
+const PTY_PASTE_CHUNK_PAUSE_MS = 10;
+const PTY_PASTE_PAUSE_BUFFER = new Int32Array(new SharedArrayBuffer(4));
 const SESSION_SEND_LOCK_WAIT_MS = 10_000;
 const SESSION_SEND_LOCK_POLL_MS = 25;
 // 安全: send 前に弾く破壊的コマンド（外部システム境界の防御）
@@ -785,7 +789,7 @@ async function waitCompletion(name, untilStr, untilRegex, timeout) {
                 if (safeStatSize(logpath(name)) !== size) {
                     stable = 0;
                 }
-                else if (SHELLS.has(fg)) {
+                else if (!until && !markActive && SHELLS.has(fg)) {
                     if (isWin)
                         await settleWinLog(name);
                     return [true, "quiescent"]; // 出力静止 ∧ シェル復帰 ＝ 確証つき完了
@@ -794,7 +798,8 @@ async function waitCompletion(name, untilStr, untilRegex, timeout) {
                     // ネスト中（前面が ssh/docker/REPL 等でシェル集合外）は quiescence の「シェル復帰」条件を
                     // 原理的に満たせない。until も mark も無ければこれ以上待っても確証は増えない（until/dead/
                     // quiescent/mark のいずれも発火し得ない）ので、出力静止時点で「未確定」のまま早期返却する。
-                    // markActive のときは sentinel を待つべく早期返却せず、非シェル前面（sleep 等）でも待ち続ける。
+                    // until/markActive のときは指定した証拠を待つべく早期返却せず、shell builtinや
+                    // 非シェル前面（sleep 等）でも待ち続ける。
                     // fg==="" は前面コマンド取得失敗＝ネスト断定不可なので早期返却せず従来どおり timeout まで待つ。
                     if (isWin)
                         await settleWinLog(name);
@@ -1002,9 +1007,9 @@ export function send(name, text, o = {}) {
                 /* noop */
             }
         }
-        // `send-keys -l`と単発`paste-buffer`は、長文をPTY入力queueへ一度に流し、macOS CIで
-        // 途中以降が欠落しても tmux 自体は code=0 を返した。macOSだけUTF-8を壊さない256byte以下に分け、
-        // Linux/WSLは一括のままとする。全chunk＋Enterはsession単位のcross-process lock内で直列化する。
+        // `send-keys -l`と単発`paste-buffer`は、長文をPTY入力queueへ一度に流すと、OSを問わず
+        // 途中以降が欠落しても tmux 自体は code=0 を返す。UTF-8を壊さない256byte以下に分け、
+        // 全chunk＋Enterをsession単位のcross-process lock内で直列化する。
         const pasteSupportsNoSanitize = pasteBufferSupportsNoSanitizeFlag();
         const chunks = splitPtyText(text);
         const bufferBase = `aiterm-${process.pid}-${randomBytes(8).toString("hex")}`;
@@ -1034,6 +1039,11 @@ export function send(name, text, o = {}) {
                 throw new AitermError(`tmux bufferのPTY送信に失敗しました` +
                     `（chunk ${i + 1}/${chunks.length}）: ${pasted.stderr.trim() || `code=${pasted.code}`}.${partial}`, 2);
             }
+            if (i + 1 < chunks.length) {
+                // tmux clientの終了だけでは、serverが前chunkをPTYへdrainしたことを保証しない。
+                // 次chunkまで短く間を空け、外部PTY入力queueの飽和による黙った末尾欠落を防ぐ。
+                Atomics.wait(PTY_PASTE_PAUSE_BUFFER, 0, 0, PTY_PASTE_CHUNK_PAUSE_MS);
+            }
         }
         if (enter) {
             const entered = tmux("send-keys", "-t", name, "Enter");
@@ -1659,6 +1669,41 @@ function resolveAndValidateGrokAuth(srcHome) {
             fs.closeSync(fd);
     }
 }
+function grokModelCatalog(bin, cwd) {
+    const result = spawnAgentControlCommand(bin, ["models"], cwd, {
+        cwd,
+        encoding: "utf8",
+        env: process.env,
+        timeout: GROK_MODELS_TIMEOUT_MS,
+        maxBuffer: GROK_MODELS_MAX_BYTES,
+        windowsHide: true,
+    });
+    if (result.error || result.status !== 0) {
+        const detail = result.error?.message || result.stderr?.trim() || `exit=${result.status ?? "unknown"}`;
+        throw new AitermError(`Grok model catalog を取得できません: ${detail}`, 2);
+    }
+    const text = result.stdout.replace(/\x1b\[[0-?]*[ -/]*[@-~]/g, "");
+    const marker = "Available models:";
+    const start = text.indexOf(marker);
+    if (start < 0)
+        throw new AitermError("Grok model catalog の出力形式が不正です（Available models がありません）", 2);
+    const models = [];
+    for (const line of text.slice(start + marker.length).split(/\r?\n/)) {
+        const match = line.match(/^\s{2}[-*]\s+(.+?)(?:\s+\(default\))?\s*$/);
+        if (match?.[1])
+            models.push(match[1]);
+    }
+    if (models.length === 0)
+        throw new AitermError("Grok model catalog に利用可能なmodelがありません", 2);
+    return models;
+}
+function assertGrokModelAvailable(bin, cwd, model) {
+    const models = grokModelCatalog(bin, cwd);
+    if (!models.includes(model)) {
+        throw new AitermError(`Grok model catalog に ${JSON.stringify(model)} がありません。利用可能: ${models.join(", ")}。` +
+            "別modelへfallbackせず起動を中止しました", 2);
+    }
+}
 function writeAgentMetadata(meta) {
     writeJson0600(agentMetadataPath(meta.aiterm_session, meta.launch_id), meta);
 }
@@ -3577,6 +3622,55 @@ async function waitForScreenText(name, text, timeoutMs = 3_000) {
     } while (performance.now() < deadline);
     throw new AitermError(`${agentLabel(loadAgentMetadata(name).kind)} の ${text} 画面を確認できません`, 2);
 }
+function lineCounts(screen) {
+    const counts = new Map();
+    for (const line of screen.split("\n").map((value) => value.trim()).filter(Boolean)) {
+        counts.set(line, (counts.get(line) ?? 0) + 1);
+    }
+    return counts;
+}
+function grokFooterHasConfiguration(screen, model, effort) {
+    const modelMatch = model?.match(/^grok-(\d+(?:\.\d+)*)$/) ?? null;
+    if (model && !modelMatch)
+        return false;
+    const modelLabel = modelMatch ? `Grok ${modelMatch[1]}` : null;
+    return screen.split("\n").some((line) => {
+        if (!line.includes("·"))
+            return false;
+        if (modelLabel && !line.includes(`${modelLabel} (`))
+            return false;
+        if (effort && !line.includes(`(${effort})`))
+            return false;
+        return modelLabel !== null || effort !== null;
+    });
+}
+async function waitForGrokConfigurationResult(name, before, model, effort, timeoutMs = 3_000) {
+    const beforeCounts = lineCounts(before);
+    const footerAlreadyMatched = grokFooterHasConfiguration(before, model, effort);
+    const deadline = performance.now() + timeoutMs;
+    do {
+        const screen = captureScreen(name, AGENT_TUI_READY_LINES);
+        const seen = new Map();
+        const added = screen.split("\n").map((value) => value.trim()).filter((line) => {
+            if (!line)
+                return false;
+            const count = (seen.get(line) ?? 0) + 1;
+            seen.set(line, count);
+            return count > (beforeCounts.get(line) ?? 0);
+        });
+        const error = added.find((line) => /^(?:Unknown model:|unknown effort level|Usage: \/(?:model|effort)\b|Invalid (?:model|reasoning effort)|.*does not support reasoning effort)/i.test(line));
+        if (error)
+            throw new AitermError(`Grokの設定変更に失敗しました: ${error}`, 2);
+        if (added.some((line) => /^(?:Switched to |✓?\s*Default model:)/.test(line)))
+            return;
+        // Grok Build 1.0.3では成功通知が次の再描画で消えることがある。変更前には無かった
+        // target model／effortが常駐footerへ現れた場合も、vendor自身の最終状態として受理する。
+        if (!footerAlreadyMatched && grokFooterHasConfiguration(screen, model, effort))
+            return;
+        await sleep(100);
+    } while (performance.now() < deadline);
+    throw new AitermError(`${agentLabel(loadAgentMetadata(name).kind)} の設定変更完了を確認できません`, 2);
+}
 function sendMenuChoice(name, choice) {
     const sent = tmux("send-keys", "-t", name, choice);
     if (sent.code !== 0) {
@@ -3625,10 +3719,10 @@ export async function configureAgent(name, opts) {
     const effort = opts.reasoning_effort?.trim() || null;
     if (!model && !effort)
         throw new AitermError("model または reasoning_effort を指定してください", 2);
-    const meta = loadAgentMetadata(name);
-    if (meta.kind !== "claude" && meta.kind !== "codex") {
-        throw new AitermError("agent_configure はClaudeとCodexのsessionだけに対応します", 2);
+    if ((model && /[\r\n]/.test(model)) || (effort && /[\r\n]/.test(effort))) {
+        throw new AitermError("model／reasoning_effort に改行を含められません", 2);
     }
+    const meta = loadAgentMetadata(name);
     bindCompletedInitialPrompt(meta);
     const ready = await waitAgentTuiReady(name, meta, AGENT_TUI_READY_TIMEOUT_MS);
     if (!ready.ready)
@@ -3654,6 +3748,27 @@ export async function configureAgent(name, opts) {
             reasoning_effort: effort,
         };
     }
+    if (meta.kind === "grok" || meta.kind === "composer") {
+        if (model) {
+            const bin = resolveAgentBin(meta.kind);
+            if (!bin)
+                throw new AitermError(`${agentLabel(meta.kind)} の CLI が見つかりません`, 2);
+            assertGrokModelAvailable(bin, meta.cwd ?? process.cwd(), model);
+        }
+        const command = model
+            ? `/model ${model}${effort ? ` ${effort}` : ""}`
+            : `/effort ${effort}`;
+        const before = captureScreen(name, AGENT_TUI_READY_LINES);
+        await sendAgentPromptText(name, command);
+        await waitForGrokConfigurationResult(name, before, model, effort);
+        return {
+            schema: "aiterm.agent-configure-result.v1",
+            session_id: name,
+            provider: meta.kind,
+            model,
+            reasoning_effort: effort,
+        };
+    }
     await sendAgentPromptText(name, "/model");
     const modelScreen = await waitForScreenText(name, "Select Model and Effort");
     if (model) {
@@ -3828,27 +3943,32 @@ function resolveAgentBin(kind) {
         // 明示指定 env は実在を検証する。存在しないパスを黙って返すと、session を作って
         // `'/typo' ...` を送信し bash が command not found を出すだけで openAgent は「起動した」と
         // 偽成功を返す（既定パス/PATH 経路は検証するのに env だけ無検証だった非対称の解消・A3）。
-        if (isUsableExecutableFile(fromEnv))
-            return fromEnv;
+        if (isUsableAgentExecutableFile(fromEnv))
+            return resolveWindowsCodexShim(kind, fromEnv);
         throw new AitermError(`${envVar} に指定された ${name} が存在しません: ${fromEnv}`, 2);
     }
     const cand = path.join(home, ...rel);
-    if (isUsableExecutableFile(cand))
-        return cand;
+    if (isUsableAgentExecutableFile(cand))
+        return resolveWindowsCodexShim(kind, cand);
     const w = spawnSync(isWin ? "where" : "which", [name], {
         encoding: "utf8",
         timeout: 5000,
     });
     if (w.status === 0 && (w.stdout ?? "").trim()) {
-        const resolved = w.stdout.trim().split(/\r?\n/)[0];
-        if (isUsableExecutableFile(resolved))
-            return resolved;
+        const found = w.stdout.trim().split(/\r?\n/).filter(Boolean);
+        const ordered = isWin
+            ? [...found.filter((p) => /\.(?:exe|com|cmd|bat)$/i.test(p)), ...found.filter((p) => !/\.(?:exe|com|cmd|bat)$/i.test(p))]
+            : found;
+        for (const resolved of ordered) {
+            if (isUsableAgentExecutableFile(resolved))
+                return resolveWindowsCodexShim(kind, resolved);
+        }
     }
     return null;
 }
 const CLAUDE_AUTH_STATUS_TIMEOUT_MS = 5_000;
 function assertClaudeAuthenticationReady(bin) {
-    const result = spawnSync(bin, ["auth", "status", "--json"], {
+    const result = spawnAgentControlCommand(bin, ["auth", "status", "--json"], process.cwd(), {
         encoding: "utf8",
         timeout: CLAUDE_AUTH_STATUS_TIMEOUT_MS,
         maxBuffer: 64 * 1024,
@@ -3893,6 +4013,71 @@ function isUsableExecutableFile(candidate) {
         return false;
     }
 }
+function isWindowsDrivePath(candidate) {
+    return /^[A-Za-z]:[\\/]/.test(candidate);
+}
+function isWindowsNativeExecutable(candidate) {
+    return isWindowsDrivePath(candidate) && /\.(?:exe|com|cmd|bat)$/i.test(candidate);
+}
+function isUsableWslExecutable(candidate) {
+    if (!isWin)
+        return false;
+    let wslPath = candidate;
+    if (isWindowsDrivePath(candidate)) {
+        try {
+            if (!fs.statSync(candidate).isFile())
+                return false;
+            wslPath = toWslPath(candidate);
+        }
+        catch {
+            return false;
+        }
+    }
+    else if (!candidate.startsWith("/")) {
+        return false;
+    }
+    const checked = spawnSync("wsl.exe", ["-e", "test", "-f", wslPath, "-a", "-x", wslPath], {
+        encoding: "utf8",
+        timeout: 5000,
+    });
+    return checked.status === 0;
+}
+function isUsableAgentExecutableFile(candidate) {
+    if (!isWin)
+        return isUsableExecutableFile(candidate);
+    if (isWindowsNativeExecutable(candidate))
+        return isUsableExecutableFile(candidate);
+    return isUsableWslExecutable(candidate);
+}
+function resolveWindowsCodexShim(kind, candidate) {
+    if (!isWin || kind !== "codex" || !/\.(?:cmd|bat)$/i.test(candidate))
+        return candidate;
+    const packageRoot = path.join(path.dirname(candidate), "node_modules", "@openai", "codex", "node_modules", "@openai");
+    try {
+        for (const platformPackage of fs.readdirSync(packageRoot).filter((name) => name.startsWith("codex-win32-"))) {
+            const vendorRoot = path.join(packageRoot, platformPackage, "vendor");
+            for (const target of fs.readdirSync(vendorRoot)) {
+                const executable = path.join(vendorRoot, target, "bin", "codex.exe");
+                if (isUsableExecutableFile(executable))
+                    return executable;
+            }
+        }
+    }
+    catch {
+        /* 下の明示エラーへ */
+    }
+    throw new AitermError(`CODEX_BIN のnpm shimからWindows native codex.exeを解決できません: ${candidate}。` +
+        "@openai/codexを再インストールするか、CODEX_BINへcodex.exeを指定してください", 2);
+}
+function agentBinForWslShell(bin) {
+    return isWin && isWindowsDrivePath(bin) ? toWslPath(bin) : bin;
+}
+function spawnAgentControlCommand(bin, args, cwd, options) {
+    if (!isWin || isWindowsNativeExecutable(bin))
+        return spawnSync(bin, args, options);
+    const wslCwd = isWindowsDrivePath(cwd) ? toWslPath(cwd) : cwd;
+    return spawnSync("wsl.exe", ["--cd", wslCwd, "-e", agentBinForWslShell(bin), ...args], options);
+}
 const THROUGHLINE_HANDOFF_CONTEXT_SCHEMA = "throughline.handoff_context.v1";
 const PORTABLE_FORK_MISSION_SEPARATOR = "\n\n---\n\n## Portable fork mission\n\n";
 function resolveThroughlineBin() {
@@ -4004,12 +4189,16 @@ function buildAgentCmd(kind, bin, model, effort, prompt, meta = null) {
         }
     }
     else {
-        // grok / composer は同じ grok CLI をモデル違いで起動。--effort は headless（grok -p）専用で
-        // 対話 TUI では警告の上無視されるため渡さない（openAgent が指定を事前拒否する）。
+        // grok / composer は同じ grok CLI をモデル違いで起動する。
         parts.push("--no-auto-update");
         if (meta?.kind === "grok" || meta?.kind === "composer")
             parts.push("--no-alt-screen");
         parts.push("--model", shq(model ?? GROK_MODEL_DEFAULTS[kind]));
+        if (effort)
+            parts.push("--reasoning-effort", shq(effort));
+        if ((meta?.kind === "grok" || meta?.kind === "composer") && meta.write_scope === "read-only") {
+            parts.push("--sandbox", "read-only");
+        }
         if ((meta?.kind === "grok" || meta?.kind === "composer") && meta.hook_route === "shared_grok_home") {
             parts.push("--session-id", shq(meta.vendor_session_id ?? ""), "--rules", shq(subagentInstruction(meta)));
         }
@@ -4066,15 +4255,15 @@ function agentLabel(kind) {
 function buildAgentLaunchNote(kind, model, effort, meta) {
     const writeScopeNote = meta?.write_scope === undefined
         ? ""
-        : kind === "codex" && meta.write_scope === "read-only"
-            ? `\n能力宣言: write_scope=${JSON.stringify(meta.write_scope)}。Codex CLIへ --sandbox read-only を付与し、書込みを実効禁止。`
-            : `\n能力宣言: write_scope=${JSON.stringify(meta.write_scope)}。${kind === "grok" || kind === "composer" ? "このCLIには起動sandbox機構がないため" : "パス単位のsandbox allowlistに対応するCLI引数がないため"}宣言の記録のみ（構造的unsupported）。`;
+        : (kind === "codex" || kind === "grok" || kind === "composer") && meta.write_scope === "read-only"
+            ? `\n能力宣言: write_scope=${JSON.stringify(meta.write_scope)}。${agentLabel(kind)} CLIへ --sandbox read-only を付与し、書込みを実効禁止。`
+            : `\n能力宣言: write_scope=${JSON.stringify(meta.write_scope)}。パス単位のsandbox allowlistに対応するCLI引数がないため宣言の記録のみ（構造的unsupported）。`;
     if (kind === "claude") {
         return `起動設定: model=${model ?? "CLI既定"} effort=${effort ?? "CLI既定"}。${writeScopeNote}`;
     }
     if (kind !== "codex") {
         return (`起動設定: model=${model ?? GROK_MODEL_DEFAULTS[kind]}（${model ? "引数" : "ツール既定"}）。` +
-            "reasoning effort は対話 TUI 非対応＝未指定で起動。" + writeScopeNote);
+            `effort=${effort ?? "CLI／model既定"}。` + writeScopeNote);
     }
     const configPath = meta?.kind === "codex" && meta.codex_home
         ? path.join(meta.codex_home, "config.toml")
@@ -4145,18 +4334,6 @@ export function openAgent(kind, opts = {}) {
     if (effort && kind === "claude" && !CLAUDE_EFFORTS.has(effort)) {
         throw new AitermError("Claude Code の reasoning_effort は low/medium/high/xhigh/max のいずれかです", 2);
     }
-    // grok CLI の --effort は headless（grok -p）専用で、対話 TUI では警告の上無視される。
-    // 黙って no-op の引数を受けない＝起動前に明示エラーで拒否する（codex は CLI 側の値集合が
-    // 版で変わるため縛らず送信まで通す）。
-    if (effort && kind === "grok") {
-        throw new AitermError(`${label} は reasoning_effort を指定できません。grok CLI の --effort は headless（grok -p）専用で、` +
-            "対話 TUI では警告の上無視されます（grok-4.5 の TUI 既定 effort は high）。" +
-            "effort 制御が必要なら通常 PTY で `grok -p --effort low|medium|high ...` を使ってください", 2);
-    }
-    if (effort && kind === "composer") {
-        throw new AitermError(`${label} は reasoning_effort を指定できません。grok-composer-2.5-fast は reasoning effort 非対応です` +
-            "（モデルカタログ supports_reasoning_effort=false）", 2);
-    }
     const agentDone = !!opts.agent_done;
     const launchOperationId = opts.launch_operation_id == null
         ? null
@@ -4231,9 +4408,14 @@ export function openAgent(kind, opts = {}) {
     // パスで解決）。toWslPath は session を作る前に呼ぶ＝変換失敗（非ドライブパス）で残骸 session を残さない。
     // 未検証リスク: npm グローバル導入の codex.cmd/.bat シムや WSL interop 上の対話 TUI 描画は実 Windows
     // でしか確認できない（CI 非対象。docs/03_audit-sweep-2026-07.md 参照）。
-    const binForCmd = isWin ? toWslPath(bin) : bin;
+    const binForCmd = agentBinForWslShell(bin);
     const cwdForCmd = cwd && isWin ? toWslPath(cwd) : cwd;
     const grokAuthPath = agentDone && (kind === "grok" || kind === "composer") ? resolveAndValidateGrokAuth(realGrokHome()) : null;
+    if (kind === "grok" || kind === "composer") {
+        const requestedModel = model ?? (kind === "composer" ? GROK_MODEL_DEFAULTS.composer : null);
+        if (requestedModel)
+            assertGrokModelAvailable(bin, cwd ?? process.cwd(), requestedModel);
+    }
     let sid;
     let hint;
     try {

package/dist/index.js

@@ -397,8 +397,8 @@ server.registerTool("claude_approval", {
     }
 });
 server.registerTool("agent_configure", {
-    description: "起動済みのCodex／Claude agent sessionを再起動せず、会話contextを保ったままmodel／reasoning effortを変更する。" +
-        "ClaudeはCLI標準の/model・/effort、CodexはCLI標準の/model選択画面を使う。",
+    description: "起動済みのClaude／Codex／Grok／Composer agent sessionを再起動せず、会話contextを保ったままmodel／reasoning effortを変更する。" +
+        "Claude／Grok／ComposerはCLI標準の/model・/effort、CodexはCLI標準の/model選択画面を使う。",
     inputSchema: {
         session_id: z.string().regex(/^[A-Za-z0-9_-]{1,64}$/),
         model: z.string().min(1).nullish().describe("変更後のmodel。省略時はmodelを変更しない"),
@@ -407,7 +407,7 @@ server.registerTool("agent_configure", {
     outputSchema: {
         schema: z.literal("aiterm.agent-configure-result.v1"),
         session_id: z.string().regex(/^[A-Za-z0-9_-]{1,64}$/),
-        provider: z.enum(["claude", "codex"]),
+        provider: z.enum(["claude", "codex", "grok", "composer"]),
         model: z.string().nullable(),
         reasoning_effort: z.string().nullable(),
     },
@@ -430,14 +430,16 @@ const agentModelDesc = (kind) => kind === "claude"
     : kind === "codex"
         ? "起動モデル（例: gpt-5.6-sol / gpt-5.6-terra / gpt-5.6-luna）。省略時は端末 config／CLI 既定を継承" +
             "（端末側のピンがそのまま効く。実効値は起動応答に明示される）"
-        : `起動モデル。省略時は ${kind === "grok" ? "grok-4.5" : "grok-composer-2.5-fast"}`;
+        : `起動モデル。省略時は ${kind === "grok" ? "grok-4.5" : "grok-composer-2.5-fast"}。` +
+            (kind === "composer"
+                ? "既定／explicit modelを起動前にlive catalogへ照合し、不在ならfallbackせずエラー"
+                : "explicit modelを起動前にlive catalogへ照合し、不在ならfallbackせずエラー");
 const agentEffortDesc = (kind) => kind === "claude"
     ? "Claude Code reasoning effort。low/medium/high/xhigh/max。省略時はCLI既定"
-    : kind === "grok" || kind === "composer"
-        ? "指定不可（grok CLI の --effort は headless 専用で、対話 TUI では警告の上無視される。" +
-            "composer は effort 自体非対応）。指定すると起動前にエラーを返す"
-        : "reasoning effort（思考レベル）。low/medium/high/xhigh/max/ultra（CLI 版依存）。" +
-            "ultra は max 推論＋proactive 自動委譲 ON＝使用量急増注意（明示要求時のみ）。省略時は端末 config／CLI 既定。";
+    : kind === "codex"
+        ? "reasoning effort（思考レベル）。low/medium/high/xhigh/max/ultra（CLI／model 版依存）。" +
+            "ultra は max 推論＋proactive 自動委譲 ON＝使用量急増注意（明示要求時のみ）。省略時は端末 config／CLI 既定。"
+        : "Grok Build reasoning effort。利用可能値はCLI／modelのlive catalogに従う。省略時はCLI／model既定。";
 // 全launcher共通の完了受信ガイド。待ちコマンドは起動応答の wait_command（初回prompt時）または
 // pty_send dispatch の event_cursor から組む。文型は NON_BLOCKING_RULE と同じく「待たない」が先。
 const agentCompletionDesc = `起動して投げたら投げっぱなしでよい＝親はここで待たない。` +
@@ -453,7 +455,7 @@ function registerAgentTool(toolName, kind, desc) {
     const supportsWriteScope = kind === "codex" || kind === "grok" || kind === "composer";
     const writeScopeInputSchema = supportsWriteScope
         ? {
-            write_scope: z.string().min(1).optional().describe("能力宣言。read-only、または書込みを許可するパスの説明文字列。Codexのread-onlyだけはCLI sandboxで実効禁止する"),
+            write_scope: z.string().min(1).optional().describe("能力宣言。read-only、または書込みを許可するパスの説明文字列。Codex／Grok／Composerのread-onlyはCLI sandboxで実効禁止する"),
         }
         : {};
     const writeScopeOutputSchema = supportsWriteScope
@@ -480,8 +482,7 @@ function registerAgentTool(toolName, kind, desc) {
                 .optional()
                 .describe("同一端末のThroughline sessionから所有権を変えずに記憶を読み、promptのmissionより前へ注入する"),
             model: z.string().nullish().describe(agentModelDesc(kind)),
-            // grok/composer の effort は対話 TUI で無効（headless 専用）＝core 側が起動前に明示エラーで拒否。
-            // codex は CLI 側の値集合が版で変わるため縛らない（core 側も同方針）。
+            // CLI／model側の値集合が版で変わるため公開enumでは縛らない（core側も同方針）。
             reasoning_effort: z.string().nullish().describe(agentEffortDesc(kind)),
             env_vars: z.array(z.string()).optional().describe("起動したagentへ現在のMCP processから継承する環境変数名。値はtool引数へ渡さない"),
             cwd: z.string().nullish().describe("作業ディレクトリ（対象リポのルート等・任意）"),
@@ -527,7 +528,7 @@ function registerAgentTool(toolName, kind, desc) {
                 ...(supportsWriteScope && write_scope !== undefined
                     ? {
                         write_scope,
-                        write_scope_enforcement: kind === "codex" && write_scope === "read-only"
+                        write_scope_enforcement: (kind === "codex" || kind === "grok" || kind === "composer") && write_scope === "read-only"
                             ? "enforced_read_only"
                             : "declaration_only_unsupported",
                     }
@@ -563,12 +564,13 @@ registerAgentTool("grok_agent", "grok", "【Grok Build の Grok モデル (既
     agentEnvironmentDesc +
     "turn は pty_send で送る（自動で非ブロック dispatch になる）。" +
     agentCompletionDesc +
-    "model を引数で指定可。reasoning_effort は対話 TUI 非対応（指定はエラー）。");
+    "model／reasoning_effortを引数で指定可。read-only sandboxとagent_configureに対応。");
 registerAgentTool("composer_agent", "composer", "【Grok Build の Composer モデル (既定 grok-composer-2.5-fast)】の対話エージェント TUI を永続端末に起動する。" +
     agentEnvironmentDesc +
     "turn は pty_send で送る（自動で非ブロック dispatch になる）。" +
     agentCompletionDesc +
-    "model を引数で指定可。reasoning_effort は非対応（指定はエラー）。");
+    "model／reasoning_effortを引数で指定可。live catalogにComposer modelがなければGrokへfallbackせず明示エラー。" +
+    "read-only sandboxとagent_configureに対応。");
 async function main() {
     // 親ホストを initialize の clientInfo.name から確定させ、receipt の完了待ちコマンドを
     // そのホストの実際の起動形で名指しする（実測: claude-code は initialize → notifications/initialized

package/package.json

@@ -1,8 +1,8 @@
 {
   "name": "aiterm-mcp",
-  "version": "0.24.3",
-  "mcpName": "io.github.kitepon-rgb/aiterm-mcp",
-  "description": "Persistent tmux terminal MCP that lets Claude Code drive Codex CLI's interactive TUI, including slash commands and $imagegen. Also runs durable PTY sessions for SSH, containers, REPLs, and coding agents.",
+  "version": "0.25.2",
+  "mcpName": "io.github.kitepon/aiterm-mcp",
+  "description": "Persistent tmux terminal MCP for launching and driving Claude, Codex, Grok, or Composer from any MCP client, cross-vendor or same-vendor. Also runs durable PTY sessions for SSH, containers, and REPLs.",
   "keywords": [
     "mcp",
     "mcp-server",
@@ -31,12 +31,12 @@
   },
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/kitepon-rgb/aiterm-mcp.git"
+    "url": "git+https://github.com/kitepon/aiterm-mcp.git"
   },
   "bugs": {
-    "url": "https://github.com/kitepon-rgb/aiterm-mcp/issues"
+    "url": "https://github.com/kitepon/aiterm-mcp/issues"
   },
-  "homepage": "https://github.com/kitepon-rgb/aiterm-mcp#readme",
+  "homepage": "https://github.com/kitepon/aiterm-mcp#readme",
   "type": "module",
   "bin": {
     "aiterm-mcp": "dist/index.js",