termada

Termada

実環境で動作する AI エージェントのための、永続的でポリシー制御されたミッション。

Termada は、AI エージェントとターミナルの間に位置する、単一バイナリのローカルファーストなランタイムです。ローカルでも SSH 経由でも動作します。エージェントは Model Context Protocol 経由で Termada と通信し、生のシェルではなく、堅牢なツールセットを利用できます。これには、待機時間に上限を設けた exec_run、cwd／環境変数を維持する永続セッション、出力をストリーミングする非同期ジョブ、対話型プロンプトに入力する PTY、構造化された結果が含まれます。また、ライブダッシュボードからアクティブなジョブを監視・制御でき、ジョブ停止スイッチと承認キューも利用できます。Mission Control は、実行に永続的な目標、GPT／Codex が作成した計画、ランタイムで検証されるステップ、中断からの復旧、エクスポート可能なエビデンスレポートを追加します。

_{ライブダッシュボード：すべてのセッションは、監視や操作の引き継ぎができる実際のターミナルです。エージェントをブロックまたは一時停止したり、自分で入力したりできます。エージェントパネル、ポリシー管理、改ざんの痕跡を検出できる履歴、アクティブなジョブをすべて停止するスイッチも並んでいます。}

Why

AI エージェントに生のシェルを渡すのは、脆弱で不透明です。コマンドがプロンプトで停止するとエージェントがハングし、呼び出しをまたぐと cd やエクスポートした環境変数が失われ、長時間のビルドはコンテキストウィンドウをあふれさせます。さらに、何が実行中なのかを確認することも、まして停止することもできません。Termada は生のシェルをランタイムに置き換えることで、エージェントにとって信頼性が高く、利用者にとって透明性の高い環境を実現します。

• エージェントにとっての信頼性 — ブロッキングする exec_run 呼び出しは待機時間に上限を設け、構造化された出力を返します。セッションは cwd／環境変数を保持し、長時間のジョブは非同期で実行され、出力は一括でなく逐次ストリーミングされます。対話型プロンプトにも応答できます。
• 利用者にとっての透明性 — 1 つのダッシュボードで、すべてのエージェントとセッションを実際のターミナルとして表示します。confirm に一致する制御対象の操作は、利用者の承認を待ちます。ボタン 1 つで短時間の操作受付バリアを設置し、アクティブなゲートウェイ実行のキャンセルを要求し、アクティブなエンジンジョブにシグナルを送り、フォワードを閉じます。リモート／プロバイダーへの影響については、引き続きターミナルでの検証または照合が必要です。
• ミッションとしての説明責任 — エージェントの計画、実際のコマンド、承認の判断、検証ジョブ、結果、監査アンカーを一緒に保管します。Termada が実際のミッションジョブの終了コード 0 を確認しない限り、計画のステップは完了できません。

ミッションコントロール

具体的な運用上の成果を目指す場合、Codex または別の MCP エージェントは mission_create(goal, plan) から開始します。Termada は専用の永続セッションを割り当てます。 通常の exec_* 呼び出しでは、引き続き同じポリシー、承認、PTY/SSH、監査の 各経路が使われます。エージェントは、成功した各 job_id を mission_update で 紐付け、その後 mission_report をエクスポートします。

レポートでは、実行時に観測された証拠とエージェントのメモを分けて記載し、正確な 監査シーケンス／ハッシュのアンカーを含め、監査ログに記録された SHA-256 を返します。 デーモンが再起動すると、終了状態でないミッションは interrupted になります。 mission_resume は、新しいセッション試行を作成し、PTY の状態が維持されたかのように 扱うことはありません。

分離された実実行デモを実行します。

./demo/mission-control/run.sh

このコマンドは、ループバック上の壊れた HTTP サービスと、別のデモ用デーモンを起動します。 保護された修復処理では、実際にサービスの状態を変更し、人間による承認を待ちます。 最後のプローブでは HTTP 200 が観測される必要があります。 demo/mission-control と 2:40 demo script を参照してください。

機能

実行エンジン

• コマンド間で cwd、env、venv を保持する、PTY 上の永続シェルセッション。
• 非同期ジョブ：exec_start → job_id。安定したカーソルを使って差分をポーリングし、順次取得できる上限付きページ、完全な状態マシン、構造化エラーを提供します。
• 対話型プロンプトに応答します（exec_write、シークレットをマスキング）。ローカル PTY ジョブではプロセスグループへのシグナル送信／強制終了が可能です。リモート SSH の割り込み／強制終了要求はベストエフォートの Ctrl-C であり、強制終了が保証されるものではありません。
• 出力をクリーンアップします。状態を保持する ANSI/VT の除去、CR の折りたたみ、保持量の上限設定、ベストエフォートのシークレットマスキングに対応します。

ライブ制御と可観測性

• Unix ソケット経由のコントロールプレーンを備えた長時間稼働デーモン。serve --stdio は MCP をデーモンに中継する薄いシムです。つまり、複数のエージェントが 1 つのデーモンと 1 つのダッシュボードを共有します。
• 各セッションが実際のターミナルとして表示される Web ダッシュボード（xterm.js、SSE 経由でストリーミング）。オペレーターが操作を引き継ぐことができ、ジョブの PTY に入力したり、エージェントの入力を保留したり、出力を一時停止したりできます。
• ワークスペースラベル、上限付きの状態ブートストラップ、カーソルで再開可能なライブ更新、 英語のコントロール、デスクトップ／モバイルに対応したナビゲーション。
• 承認キュー、アクティビティフィード、ポリシー／サーバー管理、および許可済みの操作、実行中のエンジンジョブ、フォワードを取り消す Stop-All キャンセルバリア。
• TUI（termada top）と、すべての情報を確認できる CLI。
• 同期的に記録され、ハッシュチェーン化され、ベストエフォートでマスキングされる監査ログ。termada audit verify は、ローテーションされたセグメントをまたぐ連続したチェーンを検証します。

ミッションコントロール

• 目標、最大 24 個の計画ステップ、専用セッション、複数の再開試行、上限付きの証拠タイムライン、最終結果を備えた、永続的でオーナーにスコープされたミッション。
• 完了したステップに対する実行時の検証（ミッションセッションの job_id、status=exited、exit_code=0）と、ジョブが実行中のまま成功することの拒否。
• 承認のピン留め、古い状態／オフライン状態、コンパクトな計画／証拠ビュー、Markdown レポートのダウンロードに対応した、ミッション優先のデスクトップ／モバイルダッシュボード。 セキュリティ
• ポリシーエンジン：すべての argv の単語をシェルクォートします。許可／拒否／確認の照合では、先頭の代入、絶対パス、Darwin の大文字・小文字の違い、既知のラッパー、明示的なシェルペイロードを確認します。拒否／確認ルールがある場合、シェルスクリプト、標準入力、対話型シェル、曖昧な複合コマンドはフェイルクローズします。構造化ポリシーでは、認証済みプリンシパル、テナント、型付きのアクション／リソース／コンテキスト、リスク、可逆性も照合します。confirm に該当する制御対象のアクションはすべて永続的なオペレーターキューに登録され、タイムアウト時には拒否されます。また、呼び出し元が承認済みのアクション ID を指定して再試行した場合にのみ実行できます。
• すべてのパブリックな副作用ルートを、単一の正規ゲートウェイで処理します。ゲートウェイは、現在のポリシーの再確認、1 回限りの承認の消費、アトミックな予算承認、永続的なインテント、プロバイダーの結果、明示的な outcome_unknown 調整状態を扱います。
• ポリシーが管理する予算では、操作、実行時間、金額、ツール／モデルのコスト、本番環境の変更、結果確定後の失敗について、グローバル、テナント、プリンシパル、受信者ごとの各スコープで上限を設定できます。
• age 暗号化された Vault（CGO 不要）。Vault API はエージェントにシークレット値を返しません。値はデーモン側で注入され、ベストエフォートで出力をマスキングするために登録されます。
• ジョブ、セッション、セッション単位のリモートファイル操作、ポートフォワードについて、エージェントごとのクォータとオーナー分離を適用します。セッションと保留中の確認はオーナーごとに 32 件、全体で 128 件まで、アクティブなポートフォワードはオーナーごとに 16 件、全体で 64 件までです。ローカルホストのパスは引き続き、OS／ファイルシステムの共有境界に属します。本番環境では security.identity_mode: strict を設定してください。設定済みの各エージェントには既存のポリシーを割り当て、固有の強力な静的トークン、または明示的に有効化されたオフライン検証済みの短期 agent_identity JWT のいずれかで認証する必要があります。トークンがない呼び出し元、不明な呼び出し元、ポリシーのない呼び出し元はフェイルクローズします。構造化ルールのない strict ポリシーでは、明示的なレガシー allow に一致しないコマンドもすべて拒否します。拒否／確認のゲートが優先されます。development は、信頼されたローカルクライアント向けに自己申告の ID を引き続き利用でき、該当フィールドを省略した古い設定との互換性を保つためのデフォルトです。
• オプションの security.run_as を使うと、ローカルシェルプロセスを専用 uid に降格させ、デーモン特権を使うローカルファイルツールとデーモン環境の継承を無効化できます。ローカルファイルにアクセスするには、降格されたそのセッション内でコマンドを実行してください。リモート SFTP は引き続き利用できます。
• すべての TCP /api/* リクエストと /metrics には、ダッシュボードトークン、または有効化され、ピン留めされた JWKS で検証された人間向け JWT のいずれかが必要です。同様に、オペレーター専用の Unix ソケットルートには、検証済みの人間向け JWT、またはローカル CLI が使用する別個の cli.token のいずれかが必要です。
• オプションの、JWKS をピン留めしたオペレーター ID を使うと、サブジェクト、テナント、ロール、委任、検証済み MFA を承認に紐付けられます。ポリシーでは、ロールの定足数、承認者の重複禁止、申請者の除外を必須にできます。オプションの Ed25519 監査アンカリングでは、署名済みの fsync 済みチェーンヘッドを、永続的な HTTPS アウトボックス経由でエクスポートします。 リモートとフリート
• 再接続に対応した永続的なリモート SSH セッション。接続が切れると、新しいコマンドを実行できるよう、新しいシェルとして再接続します。許可済みの名前、ホスト、ポート、ユーザー、タグ、キー付きのボールト参照の関連付けは固定されるため、インベントリを編集しても、承認済みまたは実行中のセッションの接続先は変更されません。以前の作業ディレクトリや環境変数は失われ、実行中のジョブは orphaned になり、そのリモートプロセスは制御できないまま動作を続ける場合があります。再試行する前に、リモートの状態を確認してください。
• 名前またはタグを指定してサーバー間で実行する fleet_run。サーバーごとの結果を構造化して返し、可能な範囲で機密情報をマスキングします。コマンドは空でない argv 配列で指定する必要があり、フリートの各ターゲットの同時実行数はデーモン全体で 5 件に制限されます。呼び出しごとに、これより少ない数を指定できます。1 回の呼び出しで一致するターゲットは最大 256 件、結果テキストの合計は最大 2 MiB です。SSH は、ボールトの認証情報、ssh-agent、またはディスク上の鍵を使用します。TOFU によるホスト鍵のピン留めはシリアル化され、fsync されます。また、形式が不正な known_hosts ファイルがある場合は、安全側に倒して失敗します。
• 所有者の範囲に限定された、ローカルからリモートへのポート転送。開設にはポリシーによる許可が必要で、開始監査レコードが永続化されない場合はロールバックされます。リスナーはループバック専用で、各転送の同時接続数は最大 64 件です。

運用

• クラッシュ復旧（ジョブは永続化され、実行中のジョブは orphaned として復元されます）、上限付きのローカルファイルシステムのスナップショットと取り消し、デスクトップ通知、送信専用の Telegram 通知。
• 型付きアダプター SDK は、永続化可能な prepare → execute → verify → compensate/reconcile フェーズ、プロバイダーの冪等性キー、シークレットを含まないレシート、再起動後の復旧を提供します。具体的なプロバイダーアダプターが意味上の不変条件を定義して証明しない限り、汎用シェルやプラグインの副作用は不透明なままです。
• エージェントには <plugin>.<tool> として公開される、プロセス外プラグイン。プラグインは信頼された実行可能ファイルであり、セキュリティサンドボックスではありません。呼び出しにはポリシーによる許可が必要で、開始監査レコードが永続化されない限り起動しません。
• termada update — Unix で GitHub リリースから上限付きの自己更新を行います（SHA-256 検証は必須、Ed25519 署名付きチェックサムは任意、アーカイブからの抽出対象を厳密に指定し、アトミックに置き換えます）。実行中の .exe はアトミックに置き換えられないため、Windows では手動インストールの方法を明示します。

未対応: ネイティブ Windows ConPTY ランタイム（現時点でクロスコンパイルはできますが、PTY とシグナルはスタブです）、およびコード署名／公証。

インストール

1 行でインストールでき、Go は不要です — macOS または Linux の amd64／arm64 向けにビルド済みバイナリをダウンロードし（SHA-256 検証済み）、~/.local/bin に配置します。

curl -fsSL https://raw.githubusercontent.com/Islomzoda/termada/main/install.sh | sh

バージョンを固定するには TERMADA_VERSION=vX.Y.Z を、配置場所を変更するには TERMADA_BIN_DIR=~/bin を設定します。~/.local/bin が PATH に含まれていない場合、インストーラーが追加する 1 行を表示します。

# Docker (current published image: linux/amd64). Keep the published port on
# host loopback; the image binds 0.0.0.0 only inside its network namespace:
docker run --rm --platform linux/amd64 -p 127.0.0.1:7717:7717 ghcr.io/islomzoda/termada

# Persistent container state runs as uid/gid 10001. A fresh named volume is
# initialized with the image's ownership:
docker run --rm --platform linux/amd64 -p 127.0.0.1:7717:7717 \
  --mount type=volume,src=termada-data,dst=/home/termada/.config/termada \
  ghcr.io/islomzoda/termada

# Homebrew:
brew install Islomzoda/tap/termada

# From source (needs Go 1.26.5+):
TERMADA_FROM_SOURCE=1 ./install.sh
# or:  go build -o ~/.local/bin/termada ./cmd/termada

termada serve                    # start the daemon; prints a tokenized dashboard URL
termada dashboard --open         # print and open a fresh tokenized URL

ダッシュボードのブートストラップはトークンをブラウザーのセッションストレージに保存し、アドレスバーから削除します。ループバック上の静的アセットは公開されていますが、すべての TCP /api/* リクエストと /metrics にはトークンが必要です。従来の dashboard.local_trust 設定は非推奨であり、API 認証を回避することはできません。

エージェントに接続します。これは一度だけ、ユーザー全体に適用される手順です。ユーザーアカウントごとに一度実行すれば、すべてのプロジェクトで Termada が自動的に使えるようになります。各リポジトリにコピーするものはありません。

Claude Code の場合は、次のコマンドを一度実行するだけです。

claude mcp add --scope user termada -- termada serve --stdio

別のエージェントを使う場合（またはファイルで設定する場合）は、次の内容をグローバル MCP 設定に一度追加します。詳しくは .mcp.json.example を参照してください。

{ "mcpServers": { "termada": { "command": "termada", "args": ["serve", "--stdio"] } } }

以上です。これからは、ターミナル作業をエージェントに頼むだけで、作業は Termada を通じて実行され、リアルタイムで確認・制御できます。共有デーモンがすべてのプロジェクトとエージェントのセッションに対応し、すべて同じダッシュボードで確認できます。

設定は厳密に検証されます。未対応または不明なフィールドがあると、起動に失敗します。${NAME} 形式の値は環境変数から展開され、参照先の環境変数が設定されていない場合は、認証情報が空になるのではなくエラーになります。環境変数を利用できるようになるまでは、任意の認証情報フィールドを省略してください。

Termada 経由でリモートサーバーに接続する

エージェントが raw ssh を実行するのではなく、Termada 経由でリモートマシンを操作できるようにするには（操作の可視化、再接続、ポリシー制御に対応）、サーバーを一度登録します。以降は名前で接続でき、IP アドレスも raw ssh クライアントも必要ありません。

config.yaml に追加し（config.example.yaml を参照）、デーモンを再起動します。

servers:
  - name: prod
    host: prod.example.com        # hostname or IP of your server
    user: deploy
    # auth is OPTIONAL: a vault entry name for a Termada-stored credential.
    # Omit it to try SSH_AUTH_SOCK plus unencrypted ~/.ssh/id_ed25519,
    # id_ecdsa, or id_rsa. Termada does not interpret arbitrary ssh config.
    # auth: prod-ssh-key
    tags: [web]

…または、ダッシュボードからその場で追加します（Servers → Add）。登録されたことを確認します。

termada servers          # lists registered servers by name

これで、エージェントは名前を指定して接続できます。

• リモートシェルセッション — session_create(target="prod") を実行し、そのセッションで exec_run / exec_start を実行します（接続中は状態が保持されます。接続が切れると Termada は新しいシェルに再接続しますが、リモートで孤立したプロセスは実行中のままの場合があります）。
• 複数サーバーでコマンドを一度に実行 — fleet_run(command=[...], servers=["prod"])（またはタグを指定）。
• ループバック TCP トンネル — port_forward(server="prod", remote_host="127.0.0.1", remote_port=5432) を実行し、完了したら返された ID を port_forward_close で閉じます。

エージェントに Termada を実際に使わせる

Claude Code や Cursor などのエージェントにはシェルが組み込まれており、デフォルトではそのシェル（および raw ssh）を使います。Termada を使うよう促すには、次の 2 つの方法があります。

1. 使用方法のスキルをインストールする — 以下のプラグイン、または skills/termada を使います。ツールの使い方（および ssh ではなく、登録済みサーバーを経由してリモート作業を行う方法）をエージェントに教えます。

2. プロジェクトルールを追加して、エージェントが Termada を優先するようにします。CLAUDE.md（Claude Code）、.cursor/rules（Cursor）、またはエージェントのシステムプロンプトに、次の内容を記述します。

   シェルとリモート作業のすべてに Termada MCP ツールを使ってください。コマンドには exec_run / exec_start、リモートサーバーには session_create(target="<server>") と fleet_run を使います。組み込みシェルや raw ssh クライアントは使わないでください。作業を可視化し、再接続とポリシー制御を可能にするため、すべて Termada 経由で実行する必要があります。サーバーが server_list() にない場合は、ssh に切り替えるのではなく、登録を依頼してください。具体的な作業結果が必要な場合は、mission_create から開始し、すべてのコマンドでそのセッションを使い、実際に成功したジョブ ID をプランの各ステップに紐付け、最後に mission_report を実行してください。

/plugin marketplace add Islomzoda/termada
/plugin install termada@termada

コマンドはargv 配列（["echo", "hi"]）として渡され、シェル文字列としては渡されません。 そのため、["bash", "-lc", "..."] のように明示的にシェルを呼び出さない限り、メタ文字はそのまま扱われます。 明示的なシェルのペイロードも引き続きポリシーの対象です。拒否または確認のルールが適用されている場合、曖昧な複合ペイロードは安全側に倒して拒否されます。

CLI

termada serve [--stdio]              daemon, or the MCP shim
termada dashboard [--open]           print / optionally open the dashboard URL
termada top | status                 live TUI / overview
termada jobs [-f] | sessions         list jobs / sessions
termada logs <job> [-f]              stream a job's output
termada kill <job> | stop            kill one job / signal all admitted work
termada pending                      list human-in-the-loop approvals
termada approve|deny [--reason text] [--ticket id] <action_id>
termada audit [verify]               audit feed / verify active + rotated chain
termada servers | unlock             remote inventory / unlock the vault
termada vault init|set|list|rm|reset manage credentials
termada snapshot create|list|restore local-FS safety net (undo)
termada setup                        install user-scoped Claude MCP config
termada doctor                       health check
termada service install|uninstall|status  run the daemon at login
termada update                       Unix self-update; Windows prints manual path

ドキュメント

• docs/SECURITY.md — 脅威モデル：保護対象と対象外。
• docs/ACTION_CONTROL_PLANE.md — 制限されたアクションカタログと本番環境の不変条件。
• docs/PLUGINS.md — プロセス外ツールプラグインの作成方法。
• docs/PUBLISHING.md — リリースと MCP レジストリへの登録手順。
• docs/build-week/SUBMISSION.md — OpenAI Build Week の提出パッケージ。
• docs/build-week/ARCHITECTURE.md — Mission Control のアーキテクチャと信頼境界。

アーキテクチャ

単一のデーモンがランタイム状態を管理します。エージェントは標準入出力のシムを介して接続し、ダッシュボード、TUI、CLI でのランタイムの検査と制御されたアクションには、同じデーモンのコントロールプレーンが使用されます。ボルトファイルの作成・リセット、インストール、サービス登録、セルフアップデート、監査ファイルの検証、設定の編集といったホスト所有者向けの保守コマンドは、この API の外部で実行され、信頼された OS／デプロイメント境界の一部として扱われます。

cmd/termada            CLI: daemon, shim, inspection/control, vault
internal/engine        sessions, jobs, PTY, status machine, signals, files, recipes
internal/action        immutable Principal + Action + Resource + Context contract
internal/control       authorization, approval, budget, intent and outcome gateway
internal/ledger        durable one-use grants, budgets and export outbox
internal/budget        typed policy-owned budget resolution
internal/adapter       typed prepare/execute/verify/compensate/reconcile SDK
internal/identity      pinned-JWKS human and machine JWT verification
internal/anchor        signed external audit receipts and durable delivery
internal/output        cursor buffers, VT cleaner, redaction
internal/policy        argv allow/deny/confirm classification
internal/vault         age-encrypted credential store
internal/audit         hash-chained tamper-evident log
internal/bus           event bus (observability + durable audit)
internal/daemon        long-lived process: listeners, auth, lifecycle
internal/controlplane  HTTP/JSON control-plane server + client
internal/dashboard     embedded web UI
internal/tui           termada top
internal/fleet         server selection + concurrent aggregation
internal/sshx          SSH runner (vault / agent / key auth, TOFU host keys)
internal/mcp           MCP JSON-RPC stdio server + tools
internal/mission       durable missions, evidence validation, recovery, reports

開発

make vet test    # vet + tests
make race        # tests under the race detector
./demo/mission-control/verify_demo.sh  # real MCP + approval + HTTP 503→200 flow

エンジンのテストでは実際の PTY と bash を使用します。フリートのロジックはモックランナーで単体テストし、デーモンスタックと SSH はエンドツーエンドで統合テストします。

ライセンス

Apache-2.0。