From any MCP client, launch Claude Code, Codex CLI, Grok CLI, or Cursor Agent CLI through one harness API inside a persistent interactive TUI.

<p align="center"> <img src="https://raw.githubusercontent.com/kitepon/aiterm-mcp/main/.github/og.png" alt="Aiterm — a shared forest observatory where different intelligences work in one persistent execution space" width="100%"> <br> _{<em>This image represents different intelligences sharing one persistent workspace and advancing the same work from their own perspectives.</em>} </p>

Aiterm

(日本語: [README.ja.md](README.ja.md))

Let your AI orchestrate other AIs. One agent_launch call selects the execution harness separately from its model and hands you a persistent session to drive. Cursor can run GPT, Claude, or Grok while Cursor still owns the session, hooks, and transcript.

>

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 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.

Built and maintained by Quo at kitepon.dev.

Install in your MCP client

検出したClaude Code・Codex・Grok・Cursorのユーザー設定へ登録する標準入口:

npm install -g aiterm-mcp@latest
aiterm-setup --json

aiterm-setupは端末の依存準備、MCP経由の端末実行、登録と読戻しまでを一回で行う。 WindowsはwingetでPowerShell 7・Git for Windows・psmux、macOSはHomebrewでtmux、 Ubuntu／Debianはsudoとaptでtmuxを準備する。必要な公式package managerと実行権限は事前に必要。 他のLinuxでも既存tmuxを利用できるが、自動導入はunsupportedで停止する。 既存設定の他サーバーを保持し、JSON設定は変更前の.aiterm-backupを残す。 結果のstatusはready／unsupported／failed／restart_required。未検出のAIはnot_detectedとし、全AI未検出は成功にしない。 登録先はglobal packageのNodeとMCP入口の絶対パスで、npm一時cacheやsource checkoutは登録しない。 global packageは、npmの現在のglobal rootか、実行中のNodeの既定のglobal rootにあるものを指す。npmのprefixを利用者ごとの場所へ向けた環境でも、共通の場所へ導入したAitermを登録できる。 CodexとGrokは、登録が同じなら公式CLIで作り直さず、利用者が足した項目（待ち時間など）を保つ。 HomebrewのNodeは更新後も有効なoptのパスをMCP登録とCodexのhookに使う。旧版の登録でNode更新後に起動できなくなった場合も、更新後のaiterm-setup --jsonで修復できる。 更新後も同じ入口を実行し、MCP clientを再起動する。npm install自体はユーザー設定を変更しない。 公開JSONはschema: "aiterm.setup-result.v1"、全体のstatus、端末のbackend、 AI別のintegrationsと選択機能のcodex_steerを持つ。失敗時はreason_codeを付け、終了コードはreadyなら0、再起動待ちは3、それ以外は2となる。

MCP登録を利用者や他の製品が管理する環境では、aiterm-setup --hooks-onlyでClaude Code・Cursorの親配送hookだけを登録できる。 依存準備、端末の実動作確認、MCP登録、Codex Steerには触れない。登録済みなら設定を書き換えない。 結果はschema: "aiterm.parent-hooks-result.v1"、全体のstatus（ready／unsupported／failed）、AI別のhooks（configured／unchanged／not_detected／failed）を持つ。終了コードはreadyなら0、それ以外は2となる。

CodexへSteerを有効にする（macOS・Windows・Linux）

対話実行のaiterm-setupで「Aiterm単品」と「Steer付き」を選べます。無人導入では明示します。

aiterm-setup --json --codex-steer enable

公式キューと公式hookを使い、実行中の親には同じターンの次の推論へ回答を渡し、終了後は同じ会話を自動再開します。 Codexの起動プログラムと通常のstdio通信は変更しません。hookの実行ファイルが失われてもCodexの起動・応答は継続します。 終了後の再開は公式キューの監視周期に従い、約10秒かかる場合があります。 Codexのアプリは、見ていない会話を60秒で寝かせます。寝ている会話のキューは、その会話が開かれるまで動きません。 Aitermは、入れた約15秒後にまだ文が残っていて、番が普通に終わって寝ている会話なら、アプリにその会話を開かせて起こします（codex://threads/<会話>）。 その時、アプリの画面はその会話へ切り替わります。番の途中の会話、途中で止められた会話、CLIの席は起こしません。止める時は環境変数AITERM_STEER_CODEX_WAKE=0を立てます。 起こすのはmacOSとWindowsのアプリです。Linuxのアプリが寝かせた会話は、まだ起こしません（実物で確かめられていません。会話が開かれた時に届きます）。

aiterm-setupはCODEX_HOME/hooks.jsonへ専用のPostToolUseとStopを追加し、公式APIでその2件だけを承認・読戻しします。 他のhookや承認は保持します。選択と配送の所有記録は~/.config/aiterm-mcp/codex-parent-hooks/へ保存します。 同じ設定で再実行しても既存hookの順序を変えず、新たな再起動要求を発生させません。 WindowsのhookはPowerShell 7で実行します。更新後のsetupで、既存のAiterm hookコマンドも更新します。 既存の中継は新しいhookの確認後に解除し、保存していたCODEX_CLI_PATHを復元します。macOSの専用LaunchAgentも解除します。 移行前から動いているCodexがあればrestart_required（終了コード3）を返します。完全終了・再起動後に aiterm-setup --codex-steer statusでreadyを確認してください。旧設定は移行を実行するまで維持します。

hookはAiterm自身の配送記録と本文が一致する回答だけを取り出し、利用者がキューに入れた入力は保持します。 取り出し中断や出力失敗はparent_deliveriesにunknownとCODEX_HOOK_DELIVERY_UNCONFIRMEDで現れ、本文を保存します。 自動再送はしません。長い回答はCodexの公式hook処理で抜粋と全文ファイルへの参照になる場合があります。

解除・hook未対応の旧版への巻き戻し前はaiterm-setup --codex-steer disableを実行してCodexを再起動してください。 公式Codex Desktop（macOS・Windows・Linux）の同梱CLIを先に使い、Desktopが無い端末では通常のCodex CLI（公式キュー・hookに対応する0.154以上）を使います。 When a Desktop update moves the bundled Codex CLI, Aiterm finds it again at use time and updates its configuration. If it cannot, it returns CODEX_DESKTOP_BINARY_MOVED; start Desktop and rerun setup. Aiterm単品の公式キュー配送は従来どおり利用できます。

No clone or build is required. Each client launches the published package with:

npx -y aiterm-mcp

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

Add it for your user account:

claude mcp add --scope user --transport stdio aiterm -- npx -y aiterm-mcp

Or commit this as a project-scoped .mcp.json:

{
  "mcpServers": {
    "aiterm": {
      "command": "npx",
      "args": ["-y", "aiterm-mcp"]
    }
  }
}

Claude Desktop

Add this server to claude_desktop_config.json:

{
  "mcpServers": {
    "aiterm": {
      "command": "npx",
      "args": ["-y", "aiterm-mcp"]
    }
  }
}

Cursor

Save this as .cursor/mcp.json for the project, or ~/.cursor/mcp.json globally:

{
  "mcpServers": {
    "aiterm": {
      "command": "npx",
      "args": ["-y", "aiterm-mcp"]
    }
  }
}

Ownership boundary: this repository owns installation, configuration, persistent PTYs, agent sessions, state/schema/migrations, diagnostics, recovery, updates, and releases. It can be cloned and operated on its own using this README and the product docs. dotagents optionally integrates Aiterm into the wider factory—host wiring, cross-product compatibility, and aggregate acceptance—but does not control Aiterm and is not a runtime dependency.

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

19 tools: seven PTY tools — pty_open / pty_send / pty_read / pty_key / pty_close / pty_list / pty_observe — to open, drive, read, and observe one persistent terminal; one canonical agent launcher, agent_launch, which selects claude-code, codex-cli, grok-cli, or cursor-cli as the execution harness; three deprecated launcher aliases kept for migration; agent_models; agent_configure; agent_goal; agent_auth; agent_approval; 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. Composer is one of Cursor's models, not a harness and not a Grok model: use harness: "cursor-cli", model: "composer-2.5-fast" (or composer-2.5). The old launcher tools are thin compatibility aliases over the same implementation.

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 harness CLI fall back to another model. Composer has since left the Grok CLI and is now one of Cursor's models.

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 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.

v0.24.2 keeps in-place configuration working in long-lived Codex sessions. Once the startup header has scrolled out of the captured pane, aiterm recognizes Codex by its persistent model/effort footer together with the input prompt. An idle session is therefore configured directly; callers do not need to redraw the TUI, retry, or restart the agent.

v0.24.0 adds in-place agent configuration. agent_configure uses each harness's native controls to change the model and/or reasoning effort of a running Codex or Claude session while preserving its PTY, harness session, and conversation context.

v0.23.0 adds a local, cross-harness portable fork. Pass throughline_source_session with a mission in prompt to any launcher, and aiterm asks the locally installed Throughline for that session's read-only handoff context before creating the PTY. The exact returned memory is prepended to the mission without moving or copying the source session's database ownership. If Throughline is missing or returns an invalid/empty result, launch fails visibly with no clean fallback. Omitting the field preserves the ordinary clean launch.

v0.22.0 makes launched agents full project collaborators. All four launchers now use the same normal HOME, working tree, harness home, project/user/local configuration, MCP servers, plugins, skills, permissions, trust, memory, and session history as a direct CLI launch. Aiterm isolates only its own per-launch completion correlation state. Every child is told that it is a sub-agent and receives its parent session, delegation depth, lineage, and delegation_allowed=true; a child may delegate further, while the lineage makes reflexive self-copy loops visible and avoidable. The historical managed_completion receipt field remains for API compatibility and means “completion correlation enabled,” not environment isolation.

v0.21.3 removes Codex Stop hooks from the completion path. Codex completion and final-message attribution now come from the root rollout transcript's durable task_complete.turn_id, observed after the dispatch byte boundary. A broken or stale hook executable can no longer strand aiterm-wait. v0.21.0 added explicit write_scope declarations for external-agent launchers; v0.21.3 also fixes their structured launch receipts so a supplied scope and its enforcement status are retained. v0.20.3 prevents concurrent correlated Claude/Fable sessions from turning one broken login into many competing login flows. Every new Claude launch verifies the harness-owned shared credential store before creating a PTY, while healthy credentials remain reusable across concurrent and repeated sessions. The v0.20 line also distinguishes a non-blocking aiterm-wait --timeout 0 observation (running, exit 5) from a real timed-out wait. The v0.19 line added the correlated Claude approval relay, preserved multiline shell delivery, and extended factory diagnostics on native Windows. As of v0.16/0.17 a parent agent never blocks on aiterm: agent sessionへの送信は非ブロックdispatchであり、Codex／Claude Code親には回答本文を自動配送する。 それ以外の親はreceiptのprocess起動情報でaiterm-waitを実行する。 終了コードは0=done、3=timeout、4=closed、待機しない照会の5=runningを表す。 Factory diagnostics and the local runtime-error store collect only when canonical dotagents config explicitly sets collection.enabled: true; collection is off by default and performs no network I/O. It ships via tag-triggered CI with npm provenance (OIDC Trusted Publishing); the GitHub Release re-registers the Official MCP Registry entry.

Status: actively maintained · current public release v0.61.21 · runs on Linux · WSL2 · macOS · native Windows (tmux on POSIX, the tmux-CLI-compatible psmux on native Windows — no WSL required) · MIT · see the CHANGELOG.

Update and rollback

The npm package is the standalone distribution; dotagents is not involved. For a global install, update with aiterm-update. It reinstalls the requested version into the same npm prefix, then reruns the new version's aiterm-setup --json to re-register and re-verify.

aiterm-update                                   # this machine to latest
aiterm-update --host rabbit --host win-test     # this machine and SSH hosts to the same version
aiterm-update --version 0.39.0 --check          # report current and target versions without changing anything

--host takes an ~/.ssh/config alias or host name; hosts are not stored. The version is resolved once on the calling machine so every host lands on the same version. Hosts older than aiterm-update get it through npm first. When the npm prefix is not writable, the result is permission_required with the command to run as an administrator. aiterm-mcp servers that were already running keep the old code until their MCP client restarts (running_servers); tmux/psmux sessions survive. Versions without aiterm-update use npm install -g aiterm-mcp@latest and aiterm-setup --json. To roll back, install a known-good immutable version, for example npm install -g "aiterm-mcp@<known-good-version>", then restart the MCP client. setupを持つ版では再起動前にaiterm-setup --jsonを再実行する。For an npx configuration, use aiterm-mcp@latest to update or replace it with aiterm-mcp@<version> to pin or roll back. Check the CHANGELOG for state/schema compatibility before downgrading. Maintainer release and artifact rollback are specified in the product-owned release procedure.

Why now

A lot of 2026's agent tooling is converging on orchestration: a lead model delegating a mechanical refactor to Codex, running Composer on a bulk edit while it reviews the diff, fanning one task across several agents to spare its own context window. All of those agents already live in a terminal. aiterm makes that terminal a first-class, MCP-native tool — so the model doing the orchestrating can spawn and steer the others without a human wiring up panes.

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.

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 and release ADRs.

ClaudeがAPIエラーや安全判定の拒否で終了した時は、Stop hookが発火しなくても次のpty_sendを新しいturnとして扱う。現在のturn開始後のエラー記録だけを確認し、過去のエラーで実行中のturnを解除しない。上流の拒否はエラーのまま返す。

Codexがサービスの誤りや通信の失敗でturnを打ち切った時は、完了待ちがdoneではなくerrorを返す（aiterm-waitはexit 7、親への配送はoutcome=error）。errorは応答の本文とURLを落とした1行の文で、Codexが記録した種類（internal_server_error・http_connection_failedなど）はerror_kindに載る。利用上限は今までどおりrate_limited。誤りで終わった後の席は、次のpty_sendを新しいturnとして受ける。 Cursorが誤りでturnを終えた時（記録のturn_endedがstatus: "error"）も同じで、完了待ちはerrorを返し、文の頭の角括弧の名前（unavailableなど）をerror_kindに載せる。利用上限の文はrate_limited、席で止めたturn（User aborted request）は今までどおりdone。

Two ways to use it

1. Drive SSH, containers, and REPLs in one persistent terminal — the primitive

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
pty_send(id, "ssh 192.168.1.2")    → authenticate once, inside that terminal
pty_send(id, "uname -a")           → every later command rides the SAME session
pty_read(id, { wait: true })       → read the token-reduced output, completion detected

_{Origin. I built aiterm for exactly this. Driving my homelab from Claude Code one command at a time meant every SSH command became its own connect → authenticate → disconnect: re-typing the passphrase and one-time code each time, short-lived sessions piling up, and eventually my own defenses (fail2ban, MaxStartups/MaxSessions, account lockout) locking me out — the security meant to stop attackers ended up stopping me. Holding one authenticated session fixes all three at once. That pain is why the persistent terminal exists; launching whole other agents inside it is what it grew into.}

2. Launch other coding agents into that terminal — the orchestration flagship

The same primitive hosts another agent's TUI. agent_launch starts a selected execution harness inside a fresh persistent terminal and returns a session_id. harness names the component that owns the agent loop, authentication, hooks, session, and transcript; model remains an independent choice. The launched process sees the same project and user environment as a direct CLI invocation: normal configuration, MCPs, plugins, skills, permissions, trust decisions, memory, and history are not copied, filtered, or replaced. Aiterm adds only completion correlation and a non-user sub-agent context containing role=subagent, the parent session, delegation depth, lineage, and delegation_allowed=true.

起動結果には正規harnessを含むaiterm.agent-launch-result.v1が付き、旧providerは互換fieldとして残る。同じharnessはagent dispatch、aiterm-wait、agent_configure、pty_listにも載る。Codexは通常rollout、Grokは通常session event、Claudeはlaunch固有Stop hook、Cursorは通常agent transcriptのturn_endedを完了正本に使う。agentへの送信はpty_sendだけで行い、Aitermが送る時点で子の状態を見て振り分ける。Claudeは画面の実行中表示ではなくStopまで残るturnの印で判定する。実行中のturnへは差し込み（mode=agent_steer、新しいevent_cursorと配送は作らない）、それ以外は非ブロックdispatch（mode=agent_dispatch）で、harnessごとの完了境界を表す整数event_cursorを返す。Codex親は選択に応じて公式Steerまたはqueue、Claude Code親は公式非同期hookで本文を自動受信する。他の親はaiterm-waitを使う。CursorのsubmitはadapterがCLIのextended keyboard protocolへ変換し、送信本文がcomposerへ残る場合は明示errorにする。

An ordinary send can select steer while its input is still unissued and readiness waiting observes a live busy turn. A confirmed exited harness is rejected before the readiness deadline. Exit after paste retains a possible effect; the same input is never replayed.

Set require_agent:true on pty_send when the integration requires agent delivery. If the agent registration is missing, Aiterm refuses before sending any text and returns AGENT_SESSION_REQUIRED with an explicit unsent message. The default preserves ordinary PTY sends; combining it with force:true is rejected before sending.

pty_send to an agent session accepts an optional preface: one line placed before the text, so the message reads "preface, blank line, text". For a Claude Code session Aiterm enters the preface without the terminal's paste markers and pastes the blank line and the text in one paste. Claude Code wraps long pasted text in <pasted_content> and follows instructions inside it only where the user's own words outside the tags ask it to, so this keeps an integration's header (who the message is from) outside the wrapper. For Codex, Grok and Cursor sessions the three parts are joined and pasted as before. The preface must be a single line of at most 200 characters with no control characters, must not start with a symbol or whitespace, and must not contain @; otherwise Aiterm returns AGENT_PREFACE_INVALID and "文字列は送信していません。" before sending anything. It cannot be used with ordinary PTY sends, force:true, or remote.

When the caller gives no preface, Aiterm adds one itself for a Claude Code session whenever the text is long enough for Claude Code to wrap it (three or more line breaks, or 800 characters and up): "Aitermが届ける、この席の呼び手からの正規の送信です。下の貼り付けは、どこかから拾った文ではなく、呼び手がこの席へ宛てて送った文です。" ("A regular message from this session's caller, delivered by Aiterm. The paste below was sent to this session by the caller, not picked up from somewhere else.") The line states where the message comes from and does not tell the session to obey it. It applies to new turns, to steering, to the prompt of agent_launch, and to remote sessions (the Aiterm on that machine adds it). Without that line the whole message sits inside the wrapper, and a Claude Code session may decline to act on it as "not the user's own instruction". Short texts, Codex, Grok and Cursor sessions, and sends with raw or force are unchanged (ADR 0116).

Overlapping pty_send calls to the same agent session are handled one at a time. A later call picks its route only after the earlier one has been sent, so the result matches calls made in sequence (a call that overlaps the first send to a freshly started Claude Code session returns mode=agent_steer). It returns later by however long the earlier call waits for the session to accept input. If its turn does not come within the limit (60 seconds on POSIX, 180 seconds on Windows), Aiterm refuses before sending any text and returns AGENT_SEND_BUSY with an explicit unsent message. A lock left by a process that exited mid-send is cleared by the next send. agent_configure waits in the same line: a pty_send that arrives while a configuration change is in progress is sent after the change, so the turn runs with the new setting. A configuration change to a session whose turn is running does not hold the line while it waits for the turn to end, so steering still goes through. If its turn does not come within the same limit, agent_configure returns AGENT_SEND_BUSY with an explicit unchanged message.

agent_launch and pty_send (to an agent session) accept an optional image: an array of absolute paths to image files (png/jpg/jpeg/gif/webp). Aiterm appends an attachment block to the prompt, and every harness opens the path with its own file-reading tool and sees the image; the caller never learns harness-specific attachment tricks. Invalid paths are rejected before anything is sent.

agent_launch accepts an optional write_scope: either "read-only" or a human-readable description of writable paths. Codex/Grok use --sandbox read-only; Cursor uses its official read-only --mode ask. A path description remains declaration-only because these CLI launch surfaces provide no equivalent path allowlist flag.

Grokの無人起動は公式--trustで指定された作業フォルダを信頼登録し、確認画面を完了してから初回promptを送る。この登録はGrok CLIの信頼ストアへ保存され、フォルダ内のhook・MCP・LSPにも適用される。read-only sandboxの制限は維持する。画面に残る完了済みhookの結果は実行中と判定しない。

Grokで終了済みターンのweekly-limitパネルが残っている場合、次の通常pty_sendがShift+Xで一度閉じ、入力受付を確認して今回の本文を送る。同じsessionと会話を保ち、receiptのpane_input_recoveryにgrok_rate_limit_dialog_dismissedを記録する。ターン未終了・harness不在はGROK_RATE_LIMIT_RECOVERY_BLOCKED、解除後の入力受付失敗はGROK_RATE_LIMIT_RECOVERY_FAILEDとなり、本文は未送信。上限の継続はrate_limitedとして返し、過去promptは再送しない。Grokの上限観測には現在の画面だけを使う。Claude Codeの上限は現在の画面の入力欄の下に出る知らせで、Codexの上限はturnを終えた記録（task_completeのcodex_error_info: "usage_limit_exceeded"）で見分ける。pane logや道具の出力に残る上限の文字では判定しない。

Grokの待機中にerror eventが先に現れた場合は、見回り一回分後に現在の上限panelを読み直す。上限が無ければ元のerrorを返し、次turnや消失したlaunchへ古いerrorを結び付けない。timeout=0の即時照会は待たず、入力やAPI要求は再送しない。

When a Cursor pre-submit hook (beforeSubmitPrompt, or a Claude Code UserPromptSubmit hook that Cursor loads for compatibility) rejects the prompt, Cursor drops it and no turn or completion follows. Aiterm recognizes the rejection: an initial prompt returns initial_prompt=failed, and pty_send returns an error instead of a success receipt, both with USER_HOOK_BLOCKED and the hook's output. A rejection that comes after the 3-second start check is reported by the completion wait as outcome=error (aiterm-wait exit 7).

A current Cursor Error: containing a complete JSON object with error.code equal to prepaid_balance_exhausted ends the wait as outcome=error with that error_kind, even without a new user record. Quoted diagnostic codes, malformed JSON and old errors followed by a composer or busy display do not establish this terminal. Aiterm does not resend or close the session.

Grokがread-only sandboxの適用を拒否した場合、prompt送信時にGROK_SANDBOX_STARTUP_FAILEDとCLIの原因を返す。hookパスのシンボリックリンクなど、CLIが示した原因を設定の管理元で修正し、対象sessionをpty_closeして起動し直す。Aitermはsandboxを解除したりhookをコピーしたりしない。

この判定はGrok専用アダプターが所有する。初回prompt付きのagent_launchと通常のpty_sendで、入力受付待ち中に拒否を検出すると未送信のエラーを返す。promptなし・trust_project指定なしの起動応答は入力受付を保証しない。trust_project:trueでは入力受付まで確認し、startup.statusを返す。Grokのprivacy notice起動設定も同アダプターが所有する。実装の責務分担はDESIGNを参照。

Codex 0.155.1の「Approaching rate limits」model切替dialogは、通常のpty_sendとagent_configureで同じsessionのまま一時的な2. Keep current modelだけを選ぶ。入力受付を再確認してから本文または設定変更を進め、dispatch receiptのpane_input_recoveryにはcodex_rate_limit_model_switch_kept_currentを記録する。model切替と今後の表示抑止は選ばない。入力受付へ戻らなければCODEX_RATE_LIMIT_MODEL_SWITCH_RECOVERY_FAILEDとなり、本文・設定変更は未送信。このdialogはagent_approvalの対象ではなく、inspectはreason="rate_limit_model_switch"だけを返し、prompt digestとchoicesを出さない。

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.

agent_launch({ harness: "codex-cli", session_name: "codex1", cwd: "/repo",
              prompt: "port test/legacy.py to vitest",
              model: "gpt-5.6-sol", reasoning_effort: "high",
              write_scope: "test/ only; no commit" })
                                    → { session_id: "codex1", … }   # Codex now live in a persistent terminal
pty_read("codex1", { screen: true })   → read what it's doing (token-reduced)
pty_send("codex1", "also fix the imports it broke")
                                    → non-blocking dispatch; receipt carries event_cursor
# Codex／Claude Code親には回答が自動で届く。それ以外の親:
$ aiterm-wait --session codex1 --cursor <event_cursor>   # never in the parent's foreground; exit 0=done, 3=timeout (not done), 4=closed, 7=error (turn aborted by an API error)
pty_read("codex1", { agent_transcript: true })           → collect the full answer

The canonical harness choices are:

A new terminal gets the environment of the MCP process that opened it (since 0.50.0, ADR 0081). Values from another caller that happened to start the tmux server first no longer appear in it. AITERM_SESSION_ID and AITERM_AGENT_* are not inherited; aiterm sets them per terminal. If a harness passes only a few variables to its MCP process, the terminal has only those (Codex passes HOME, PATH, SHELL, and TERM by default; forward more with env_vars under [mcp_servers.aiterm]).

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. Only the named values can be read back with env_keys in pty_list. 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 workflow variables, not as a secret transport.

The selected harness CLI must be installed and authenticated. Aiterm resolves CLAUDE_BIN / CODEX_BIN / GROK_BIN / CURSOR_AGENT_BIN, then the documented default binary, then PATH. Cursor resolution deliberately uses cursor-agent, never the ambiguous agent name. Claude and Cursor authentication are checked before a PTY exists, so a failed preflight leaves no session. All harnesses use their normal harness-owned credential and configuration stores in place. For Grok, Aiterm does not lock, inspect, or modify the credential. A non-empty inherited GROK_AUTH_PATH must be absolute and exist; Aiterm passes it unchanged to Grok. Grok owns its contents, permissions, and link handling. Absence of the default auth file is accepted only when XAI_API_KEY is set.

Portable fork is optional. When throughline_source_session is present, prompt is the required new mission and launch_operation_id cannot be combined with it. aiterm resolves Throughline via THROUGHLINE_BIN and then PATH, runs throughline handoff-context --session <id> --json, and places its returned context before a fixed separator and the mission. This route requires throughline >= 0.9.0; throughline_supplement_file requires Throughline 0.10.8 or later. Aiterm appends --supplement-file <path> without reading or interpreting the file. Throughline owns its project binding, validation, and shared context budget. The route reads source memory without changing database session ownership. No Throughline dependency is needed when the field is omitted.

Harness adapters translate model and reasoning_effort into each CLI's public controls. Explicit Grok models are checked against grok models; Cursor combines a base model such as gpt-5.6-luna with a separate effort such as high, checks the resulting current catalog ID, and uses Cursor's standard model picker for in-session changes. Missing models are errors, with no cache, retry, or fallback. Claude adds only launch-local Stop-hook settings, Codex reads its normal rollout store, Grok reads its normal session event/history, and Cursor binds its normal agent transcript with the launch ID. Pass an absolute cwd; ~ is not expanded.

There is no hidden protocol between agents: every launched harness 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.

Demo

<p align="center"> <img src="https://raw.githubusercontent.com/kitepon/aiterm-mcp/main/.github/demo.gif" alt="aiterm-mcp demo: pty_open, a token-reduced grep read, then a nested Python REPL — all in one persistent session" width="100%"> </p>

Real captured output — each block below was just run through aiterm in this repo; the numbers, the elision marker, and every is_complete verdict are the tool's own, not mocked. The bracketed meta line is what pty_read appends; its labels are Japanese in the actual output, translated here for readability (the Japanese README shows them verbatim).

A long output folded head+tail — the middle is elided by the reducer, not by me (166 → 56 tokens):

→ pty_send("demo", "seq 1 150")
→ pty_read("demo", { wait: true })
← 1
  2
  3
  ⋮  (head runs to line 29 — abbreviated in this README)
  … ⟨102 lines elided · full=true, or line_range="A:B"⟩ …    ← the tool's own marker
  ⋮  (tail resumes at line 132 — abbreviated in this README)
  149
  150
  [aiterm demo: 51 lines / ~56 tok (raw 152 lines / ~166 tok); 102 lines hidden] [is_complete=True via quiescent]

A grep comes back exactly as grep printed it while it stays within rtk's caps (200 lines in all, 25 per file). Past a cap, the per-command reducer groups the hits by file and says what it left out:

→ pty_send("demo", "grep -rn session src/")
→ pty_read("demo", { wait: true, rtk: true })
← 550 matches in 23 files:

  src/agent-resolver.ts:211:// …(long lines keep ~80 chars around the pattern)
  …
  src/remote.ts:268:session_id: session, agent_transcript: true, raw: true,
    +4 more in src/remote.ts
  +7 more files
  [aiterm demo: rtk:grep applied / ~4286 tok (raw ~12546 tok)] [is_complete=True via quiescent]

Nesting is just text you send in — here a Python REPL inside the same PTY (an ssh host, a docker exec -it … bash, or a launched coding-agent TUI nests exactly the same way):

→ pty_send("demo", "python3")
→ pty_read("demo", { until: ">>>" })                # nested prompt = "the inner shell is ready"
→ pty_send("demo", "print(sum(range(1_000_000)))")
→ pty_read("demo", { wait: true, until: ">>>" })
← 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 and Known constraints. A human can attach to the same multiplexer backend and watch any of this live (see A human can watch).

First run (≈60 seconds)

aiterm-setup --jsonがreadyになったら、利用するMCP clientを再起動して接続を確認する。Claude Codeの場合:

/mcp        # aiterm should show as connected, exposing 19 tools

Your first session — four calls, one persistent terminal:

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

pty_close is idempotent and returns a structured closed / already_closed receipt, so durable callers can retry the same session_id after losing the MCP response. On Windows, closing a Claude Code session first asks Claude Code to exit on its own (Ctrl-C twice, then a wait of up to 4 seconds) so that its SessionEnd hooks run; psmux stops a session without the hangup signal that tmux sends on POSIX. The session is stopped afterwards either way.

That's it. The terminal in t1 is real and persistent — ssh, docker exec, a REPL, or a launched agent's TUI are just things that live inside it. To launch a worker agent instead, one call does it: agent_launch({ harness: "codex-cli" }) returns a session_id you drive with the same pty_read / pty_send.

Prefer a global install, or a different client?

# install globally, then register the command name
npm i -g aiterm-mcp
claude mcp add --scope user --transport stdio aiterm -- aiterm-mcp

This registers it in ~/.claude.json; you'll get an approval prompt the first time. For client-specific JSON, see Install in your MCP client.

Headless: no human at the terminal

Because an MCP client drives aiterm programmatically over stdio, everything above can run with nobody sitting at the terminal. Any MCP-capable orchestrator can call agent_launch — including a harness matching 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 Claude Code / Codex / Grok / Cursor harnesses, each in its own persistent session, and reads them all back. Composer is one of the models Cursor selects (composer-2.5-fast).
• 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.

The terminal is real and shared, so a human can jump in (A human can watch) — but nothing requires one to.

How it works

flowchart LR
    AI["AI / MCP client<br/>(the orchestrator)"] -->|"pty_send · pty_observe · agent_launch · agent_models · agent_configure · agent_auth · agent_approval · claude_turn · claude_approval<br/>legacy launcher aliases · diagnostics"| S["aiterm-mcp<br/>stdio MCP · 19 tools"]
    S -->|"pty_read<br/>token-reduced"| AI
    S -->|"tmux / psmux<br/>send · capture"| P["persistent PTYs<br/>survive restarts"]
    P -->|"ssh · docker · repl"| R["nested<br/>remote · container · REPL"]
    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 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

Your MCP client already has a shell tool, and it wins on some jobs. aiterm wins on others. We measured both on the same commands in this repo, counting tokens the same way on each side (characters ÷ 4, aiterm's own estimator), so the comparison is apples-to-apples.

Start with the built-in tool for a light one-shot. git log --oneline -5 is one round-trip; aiterm is two — pty_send then pty_read — and that second round-trip costs more than a light command saves (~7 s vs ~13 s).

The second round-trip pays for itself once the output runs long, or the state has to outlive the call.

In the recorded 203-test benchmark the reduction is real and safe. The built-in tool drops the whole 223-line log — ~4,292 tokens — into context. aiterm folds its own capture of the run down to ~607:

[aiterm demo: 51 行 / ~607 tok (raw 223 行 / ~4292 tok); 172 行 hidden] [is_complete=True via mark]

_{行 = lines; the meta line is quoted verbatim from aiterm's real output.}

That is about 7.1× fewer tokens reaching the model, and the verdict survives the fold: the tail still carries ℹ tests 203 / ℹ pass 203 / ℹ fail 0. The reduction drops the noise and keeps the line you opened the log for. Wall-clock effectively ties, so on a run this long the extra round-trip is a small part of the total.

aiterm also holds state across calls. The built-in tool runs each call in a fresh shell, so cwd resets between calls and the environment doesn't carry. Send cd /tmp && export BENCH_VAR=hello123, then read it back in a second, separate call:

built-in shell  →  var=                   # empty; env dropped, cwd back at project root
aiterm          →  cwd=/tmp var=hello123  # one persistent PTY holds both

cd then set env then build, ssh once then run ten commands on the authenticated session, drive a live REPL or a launched agent's TUI turn by turn — one persistent PTY holds all of it. Reach for aiterm when the terminal has to remember something.

_{¹ Today's harness auto-offloads the ~192 KB dump to a file and previews only a ~2 KB head, so the token counts nearly tie; aiterm reports the accurate line count and lets line_range="A:B" pull any slice later, head or tail. ² The rtk grep reducer returns grep's output unchanged while it fits rtk's caps (200 lines, 25 per file). Past a cap it groups by file, keeps ~80 chars of each long line around the pattern, and folds the rest into +N more in <file> / +N more files; use the built-in tool when you need every full line of a large search.}

vs. the alternatives

aiterm sits at the intersection of two families: terminal-driving MCP servers, and the newer "agents talk to each other through a shared terminal" idea (see Where aiterm fits). Here's how the axes line up — honestly, including where the others are strong.

Where aiterm fits

"AIs talking to each other through a shared terminal" is becoming its own category — and it's a genuinely good idea. The terminal is a universal interface every coding agent already speaks, so no bespoke agent-to-agent protocol is needed; the shell is the shared surface. smux (by @shawn_pana) popularized this framing as a one-command shared tmux environment a human sets up, that agents then join via a tmux-bridge CLI and Agent Skills. It's good at the in-the-loop, shared-pane workflow it's built for, and it has real traction.

aiterm takes the same core insight — the terminal as the meeting point — and makes three deliberate, different choices:

1. Headless by construction. Because aiterm is driven programmatically over MCP, an AI can launch and drive another agent with no human sitting in the tmux — from an orchestration loop, a CI step, or a cron job. The shared-tmux tools lead with a human at the keyboard (their docs center on interactive pane navigation), so unattended operation isn't their native mode; aiterm's is.
2. MCP-native, not a workflow you adopt. aiterm is a stdio MCP server: one claude mcp add line and it works as structured tools in any MCP client that speaks stdio (tested in Claude Code; Cursor, Cline, and Claude Desktop speak the same protocol and should work the same way). It doesn't ask you to adopt a tmux config, learn pane navigation, or install skills into your setup — the client already knows how to call tools.
3. Launching an agent is one tool call — an orchestration primitive. agent_launch({ harness: "codex-cli" }) spawns Codex in a persistent terminal and returns a session you drive immediately. You don't arrange panes or paste between them by hand; the launch, the steering, and the reads are all tool calls the orchestrating model can make on its own.

On top of that sits a productized layer a raw tmux bridge doesn't have: token-reduced reads and 5-layer completion detection. None of this makes the human-in-the-tmux model wrong — it's a different, complementary bet on where the human is standing.

Tools

Session observation and startup

pty_open defaults to bash on POSIX and PowerShell 7 on Windows. Ordinary terminals and agents receive AITERM_SESSION_ID. A terminal inherits the environment of the MCP process that opened it. Pass names in env_vars to register them on the session. pty_list({ env_keys: ["JOB_OWNER"] }) returns only registered non-secret values in environment; unregistered and missing values are null. Its aiterm.pty-list-result.v1 receipt contains observed_at and sessions, whose entries include session_id, current_command, attached, width, height, harness, and environment. Existing text remains available. After the last session closes, session listing may briefly re-observe an exiting server for up to 500 ms. Managed native operations retain unknown unless the listing or exact scoped absence can be confirmed; this never repeats a close or send.

pty_observe({ session_id, cursor? }) returns aiterm.pty-observe-result.v1 with exists, observed_at, state (busy/idle/blocked/dead/missing/unknown), reason, pane_alive, and harness_alive. pane_process and harness_process are separate identities. process_identity selects the harness for agents, or the unique child process-group leader for an ordinary terminal, using the pane when no child leader exists. An identity contains pid, process_group_id, started_identity, and argv_digest; unresolved identities are null. Windows PIDs are native and its process-group field is null. Start identity uses POSIX LC_ALL=C ps lstart or Windows UTC ISO milliseconds; the argv digest is SHA-256 hex.

Pass activity.cursor into the next observation to obtain output_changed and cpu_delta_seconds; first observations and recreated panes return null differences. cpu_seconds is the current subtree's cumulative CPU. If a process disappeared between observations, the delta covers only observed increments and cpu_delta_complete is false. background_cpu_seconds, background_cpu_delta_seconds, and background_cpu_delta_complete apply the same measurement only to descendants created at least 60 seconds after the pane, excluding startup MCP processes. token_hint is the latest displayed token count or null. Callers do not need raw argv or pane-text parsing.

Two fields tell a caller what closing an agent session would lose. activity.post_startup_process_count is the number of processes in the session that did not exist when agent_launch finished startup (before the first prompt), so background work started in the first minute is counted too. Two kinds of process are not counted: Codex's own codex-code-mode-host helper, and the direct children of an mcp-lazy relay (the MCP server it starts on first use and its wake predicate). What runs below them is counted. A startup process that the harness restarted (a process with the same parent and the same arguments as a startup process that has exited, such as a reconnected MCP server) is not counted either, and neither are the processes Aiterm itself starts to read the process table (ps, or PowerShell and its console host on Windows). pending_child_deliveries is the number of sub-agent results this session is still waiting for as a parent, whoever the caller is. Both are null when Aiterm cannot tell (ordinary terminals, agents launched by 0.48.0 or earlier for the process count, or an unresolved harness process), and may be absent when a remote host runs an older Aiterm. Treat null or absent as unknown, not as zero.

Another product that needs to deliver an answer to a Codex parent can ask Aiterm with aiterm-parent-delivery instead of registering its own hooks. Aiterm's registered hooks and the official queue deliver it. codex verify --thread <uuid> checks the parent and reports configuration in steer (enabled: the hooks are registered and trusted and the parent started after they were installed; disabled: official queue only, so the text arrives after the turn ends). codex submit --thread <uuid> --delivery <uuid> --text-file <file|-> hands the text over once and returns the queue's acceptance id. codex state --thread <uuid> --delivery <uuid> reports how it arrived (hook:"emitted" with turn_id: the hook put the text into that turn; queued: whether it is still in the official queue). Each result is one JSON line; failures are {ok:false, code, message, outcome_unknown} with exit 1, and a reused delivery id is refused with PARENT_DELIVERY_DUPLICATE. Only Codex parents are supported. aiterm-setup records the command's location in ~/.config/aiterm-mcp/delivery-provider.json. Node products can call it through aiterm-steer-delivery (0.3.0 or later), for example submitCodexParentAnswerViaAiterm.

When Aiterm is registered behind a relay that starts the MCP server only on first use, a sleeping server cannot take over the deliveries of an owner that has exited. aiterm-delivery-wake --parent <codex|claude|cursor> answers whether one needs to start: exit 0 when an exited owner still holds a delivery for that parent kind, exit 1 otherwise, exit 2 for bad arguments. It prints nothing, starts no child process, and marks the delivery so that only one of the seats running the same check starts its server (the mark is retaken after 30 seconds if nobody took the delivery over). For mcp-lazy, pass it as the wake predicate with the same environment as the server: MCP_LAZY_WAKE_COMMAND='["/absolute/path/to/node","/absolute/path/to/aiterm-mcp/dist/delivery-wake-cli.js","--parent","claude"]'. Owner start times are checked through /proc on Linux; elsewhere an existing PID is treated as a live owner.

aiterm-setup does not rewrite a registration that wraps the same server in the mcp-lazy relay. When the registered command is an executable whose name starts with mcp-lazy and its args are the direct registration's command followed by its args (relay flags before -- are allowed), the Claude Code, Codex, Grok, and Cursor registrations are left as they are. If the wrapped server path differs, setup writes the direct registration.

agent_launch({ harness, cwd, trust_project: true }) completes known workspace, project-hook, and project-MCP startup consent even without a prompt, then verifies input readiness and harness liveness before returning startup.status="ready". Startup checks wait for concurrent metadata writers before continuing. Each terminal recovery or startup-menu key still checks the current generation and stop state; an uncertain native launch remains available for status inspection without automatic replay. For Claude Code's first-run text-style menu, it confirms the item already selected on screen before continuing startup. If the CLI then requests an account login method, the launch reports vendor_onboarding_required; complete that choice in the official interactive Claude Code CLI. The input-readiness wait is 30 seconds. Only when it expires while the agent has not drawn anything yet (a busy host), the launch waits up to 50 seconds from startup. If nothing is drawn by then, it still returns initial_prompt=not_sent and keeps the session. A prompt-free launch without this option retains startup.status="not_checked". initial_prompt.status distinguishes not_requested, not_sent, submitted_unconfirmed, and started. Failure responses retain structured session information. WindowsのCodexもhook確認を認識し、npm shim経由の起動を一つのharnessとして識別する。 submitted_unconfirmed (the prompt left the composer, but the turn start was not observed within the confirmation window) is not a tool error: isError is not set, the text carries an unconfirmed-start note, the session is alive and the parent delivery stays registered. Do not resend an unconfirmed prompt or relaunch the agent; observe with pty_observe or wait using its returned cursor.

For a live Codex approval, inspect with agent_approval({ action: "inspect", session_id }), review prompt and choices, then respond with observed_prompt_digest and approval_choice (approve_once or deny). Unknown or changed dialogs return status="blocked" and isError:true without sending input. Permanent approval is not exposed. Correlated Claude approvals continue to use claude_approval.

diagnostics never starts a PTY or agent. It reports package version, MCP call readiness, a read-only PTY-list summary, bounded runtime-error-store status, and optional vendor-launcher availability. It deliberately excludes paths, environment values, credentials, command text, PTY output, and raw logs; normal unset optional dependencies are not_applicable, while an indeterminate probe is unverified.

The result carries two text items. The first is the factory JSON described above (aiterm-mcp.factory-diagnostics.v1), whose fields are fixed. The second reports the parent-delivery hooks (aiterm-mcp.parent-delivery-diagnostics.v1): a status (ready / setup_required / not_applicable / unverified) and reason_code for Claude Code and Cursor, plus caller_status for the calling client. When caller_status is setup_required, agent dispatch from that client is rejected; run aiterm-setup. Hook status is not folded into overall in the first item.

Local runtime error snapshot

snapshotのproduct_versionは各recordの最終実発生時の版を表す。store v2は旧v1を読み取り、単発記録の版を保持し、複数回の旧集約の版はunknownにする。読取りでは状態JSONを書き戻さず、次のロック内更新でv2を保存する。consumerを先に更新し、旧writerの終了後に新writerを使う。v2保存後の旧版への切替は、製品のバックアップ復元を伴う。

aiterm-runtime-errors snapshot exposes a machine-readable, product-owned local snapshot for the dotagents fact