tmux について
コーディングエージェントが単一の tmux サーバーを調査・操作し、セッション、ウィンドウ、ペインと出力を扱える MCP サーバーです。読み取り範囲の制限や待機ツール、選択可能なツールセットにより、作業の監視と操作権限の制御を支援します。
主な機能
- 01セッション、ウィンドウ、ペインの調査
- 02tmux ペインの作成と配置変更
- 03入力の送信とシェルコマンドの実行
- 04ペインの出力やパターンの待機
- 05ツールセットと個別ツールの選択
活用シーン
- 01テストの完了まで出力を確認
- 02別のペインでコマンドを実行
- 03専用 tmux サーバーの調査をエージェントに任せる
MCP 対応
MCP クライアントに tmux の調査、管理、実行、終了操作のツールを提供します。起動時に接続先の tmux サーバーを選び、利用可能なツールセットを制限できます。
設定
ローカルサーバーの設定はどのクライアントでも共通です。コピーしてクライアントの MCP 設定ファイルに貼り付けてください。
このサーバーのパッケージやリモートエンドポイントはまだ取得できていません。プロジェクトの README の手順に従ってください。
ツール
ローカルサーバーのツールはマシン上で起動して初めて取得できます。メンテナーはまだツール一覧を提供していません。
詳細
mcp
[tmux module] と [Go MCP SDK] を基盤に、1 つの tmux サーバーを Model Context Protocol クライアントに提供します。
$ go install github.com/libtmux/libtmux-go/mcp/cmd/libtmux-mcp@latest
リリース番号は 0.1.N で、各リリースで N が増えます。API はまだ確定していません。どのリリースでもエクスポートされた識別子が変更または削除される可能性があり、変更履歴には各破壊的変更が記載されています。これを避けるには、特定のバージョンを固定してください。
目次 — クイックスタート · 別のクライアントを接続する · 操作対象の tmux を選ぶ · エージェントの作業を見る · 作業を実行して完了を待つ · ツール · クライアントが実行できる操作を制限する · 設定 · 実行先のペイン · 既知の制限 · トラブルシューティング · エージェント向けのプログラム · 組み込み · パッケージ · 含まれない機能 · サポートとステータス · 関連項目
クイックスタート
Go 1.26 以降と、PATH 上の tmux 3.3a 以降が必要です。上記のインストールコマンドは、GOBIN が設定されている場合はそこに、設定されていない場合は $(go env GOPATH)/bin に [libtmux-mcp][libtmux-mcp-command] を配置します。
MCP クライアントはサブプロセスとして起動し、標準入力と標準出力を介して通信するため、常駐するものはありません。シェルで libtmux-mcp が見つからない場合は、そのディレクトリを PATH に追加してください。
Python サーバーも同じ名前のコマンドをインストールします。command -v libtmux-mcp を実行してどちらが先に見つかるか確認し、libtmux-mcp -version を実行してこちらのバージョンを確認してください。
claude mcp add：Claude Code に登録する
$ claude mcp add tmux -- libtmux-mcp
Claude Code は、接続を確認するために登録済みの各サーバーを起動します。
$ claude mcp list
[libtmux-mcp -doctor][guide-diagnose-startup]：接続先を確認する
$ libtmux-mcp -doctor
クライアントを介さずに応答し、次のような内容を出力します。
libtmux-mcp doctor
tmux: 3.6 (requires 3.3a or newer)
socket: /tmp/tmux-1000/libtmux-mcp (from default dedicated socket)
holds: nothing — no tmux server is running on that socket
(not a fault; tmux starts one when something asks it to)
caller: not running inside a tmux pane
続いて、クライアントに「demo という名前の tmux セッションを作成して、どのペインがあるか教えて」のように、tmux でしかできないことを頼んでください。
別のクライアントを接続する
どのクライアントでも同じコマンドとフラグを使います。libtmux.org の [MCP クライアントを接続する][guide-connect-client]では、起動と終了について説明しています。
codex mcp add：Codex CLI
$ codex mcp add tmux -- libtmux-mcp
gemini mcp add：Gemini CLI
$ gemini mcp add tmux libtmux-mcp
claude_desktop_config.json：Claude Desktop
Claude Desktop はシェルの PATH を使わずにサーバーを起動するため、command -v libtmux-mcp が出力するパスを指定してください。フラグは args に、環境変数は env に指定します。
{
"mcpServers": {
"tmux": {
"command": "/path/to/libtmux-mcp",
"args": ["-socket-name", "my-application"],
"env": {"LIBTMUX_TOOLSETS": "inspect,manage,execute"}
}
}
}
操作対象の tmux を選ぶ
選択はサーバーの起動時に一度だけ行われます。クライアントはその後変更できません。設定にはその他のフラグが、[契約][contract-which-tmux]には優先順位の規則が記載されています。
[-socket-name][guide-choose-a-server]：名前でソケットを選ぶ
フラグを指定しない場合、サーバーは独自の tmux サーバーを操作します。このサーバーは libtmux-mcp という名前のソケット上で、パッケージに同梱された最小限の設定で起動します。このサーバーを使うエージェントは、すでにあるセッションに触れることはできません。
セッションを作成したら、別のターミナルからその作業を見てみましょう。
$ tmux -L libtmux-mcp attach
普段使っている tmux を操作させるには、そのソケットを指定します。tmux では通常のソケット名は default です。
$ claude mcp add tmux -- libtmux-mcp -socket-name default
[tmux-workspace load -L project][workspace-cli-load] で構築したワークスペースは、project ソケット上にあります。クライアントに読み取りのみを許可するには、次のようにします。
$ claude mcp add tmux \
-e LIBTMUX_TOOLSETS=inspect \
-- libtmux-mcp -socket-name project
[-socket-path and -binary][guide-choose-a-server]：正確なソケットと tmux
-socket-path はソケットを絶対パスで指定し、-binary は tmux の実行ファイルを指定します。-doctor は選択内容を報告します。
$ libtmux-mcp \
-doctor \
-socket-path /tmp/my-application.sock
環境変数でも同じ選択ができ、クライアントの設定から指定できます。
$ LIBTMUX_SOCKET=my-application libtmux-mcp -doctor
エージェントの作業を見る
examples/agent-workflow が、自分のペインの隣で作業を実行するために行う呼び出しと、その応答を示します。カーソルトークンは省略し、各応答には呼び出しへの回答にあたるフィールドのみを示します。
→ split_window {"direction":"right","pane_id":"%0","percent":40}
← {"paneId":"%1"}
→ paste_text {"enter":true,"pane_id":"%1","text":"if sleep 1; then printf 'agent-workflow-%s\\n' ready; else printf 'agent-workflow-%s\\n' failed; fi"}
← {"bytes":97}
→ wait_for_text {"pane_id":"%1","patterns":["agent-workflow-ready"],"stop":["agent-workflow-failed"],"timeout":30}
← {"found":true,"matched":"agent-workflow-ready","outcome":"matched"}
→ run_shell_command {"command":"printf 'bounded work\\n'","pane_id":"%1","timeout":30}
← {"exit_status":0,"output":["bounded work"],"timed_out":false}
この例では、-trace を指定してこれらを出力します。コマンドはページに記載されています。エージェントは tmux を直接操作するため、ターミナルから何かをコピーして貼り付ける必要はなく、サーバーの起動を待つ処理も1回の呼び出しで済みます。
作業を実行して完了を待つ
tmux send-keys を1回実行するだけなら、シェルから呼び出す方が簡潔です。エージェントが待つ、監視する、調べる、またはターミナルをそのまま使える状態にしておく必要がある場合に、サーバーの真価が発揮されます。
開発サーバーがポートを出力する場合、テストの実行が終わる場合、またはデプロイのログが落ち着く場合、シェル呼び出しはポーリングループになります。そのループはシェルが自身のコマンドをエコーした内容を読み取り、何も起きていないうちに成功を報告してしまいます。
[split_window][split_window]：ペインの隣にスペースを作る
[split_window][split_window] はペインを追加し、その ID を返します。新しいペインの起動時間を確保するため、すぐに [run_shell_command][run_shell_command] を続けて実行できます。
このトレースでは、%0 を "percent":40 で右側に分割し、{"paneId":"%1"} を受け取ります。
[wait_for_text][wait_for_text]：ペインの出力を待つ
[wait_for_text][wait_for_text] はペインを監視し、パターンが現れるか、先に stop パターンが現れると応答します。
[capture_since][capture_since] は、前回の確認以降にペインが出力した内容を返します。
このトレースでは、agent-workflow-ready を待ち、停止パターンとして agent-workflow-failed を指定しています。"outcome":"matched" が返されます。
待機時間が上限を超える場合は短縮され、その旨が応答に示されます。上限は [LIBTMUX_MCP_WAIT_MAX_SECONDS][mcp-waitceilingenvironmentvariable] で設定します。
待機中にペインが終了した場合、応答の outcome は paneDied となり、lines には終了前に出力した内容が格納されます。出力ストリームだけが終了し、ペインが稼働している場合は streamLost となります。詳細は仕様をご覧ください。
[run_shell_command][run_shell_command]：コマンドを実行し、終了ステータスを読み取る
[run_shell_command][run_shell_command] はコマンドの終了を待ち、画面を読み取ることなく、終了ステータスと出力を返します。
[send_keys][send_keys] と [paste_text][paste_text] は入力を送り、応答を返します。
このトレースでは、"bounded work" を出力するコマンドを実行し、"exit_status":0 を受け取ります。
[run_shell_command][run_shell_command] は、synchronize-panes によって他のペインとリンクされているペインでは実行できません。終了ステータス1つでは複数のペインを表せないためです。
読み取り量を抑える
エージェントのコンテキストとターンが限られたリソースであるため、この設計には他にも工夫があります。
- 読み取り量には上限があります。 キャプチャでは、指定された最新の行を保持し、省略した内容を通知します。検索には固定の上限があり、仕様に記載されています。
- 1回の呼び出しで複数の読み取りができます。
[
call_read_tools_batch][call_read_tools_batch] は、inspectの呼び出しリストに対し、各項目につき1行の結果を返します。 - 確認とキャプチャは異なります。 一覧表示ツールは、各ペインに何が表示されているかを読み取らずに、存在するものを報告します。[
snapshot_pane][snapshot_pane] は、ペインのメタデータと内容をまとめて返します。
ツール
ツールは[ツールセット][topic-tool-selection]に分かれています。ツールセットはツールをまとめた名前付きグループで、オペレーターが許可または制限する対象です。
inspectは tmux とペインの表示内容を読み取り、変更は行いません。manageは既存のものを並べ替えます。名前の変更、サイズ変更、選択、移動を行います。executeはセッション、ウィンドウ、ペインを作成し、それらに入力を送ります。teardownはセッション、ウィンドウ、ペインを終了し、スクロールバックを消去します。 | ツールセット | ツール | | --- | --- | |inspect|call_read_tools_batch,capture_pane,capture_since,find_pane_by_position,get_pane_info,get_server_info,get_session_info,get_tmux_variables,get_window_info,list_panes,list_sessions,list_windows,search_panes,show_environment,show_hooks,show_option,snapshot_pane,wait_for_text| |manage|move_window,rename_session,rename_window,resize_pane,resize_window,select_layout,select_pane,select_window,set_history_limit,set_mouse_enabled,set_pane_title,signal_channel,swap_pane,wait_for_channel| |execute|create_session,create_window,paste_text,respawn_pane,run_shell_command,send_keys_batch,send_keys,set_synchronize_panes,split_window| |teardown|clear_pane_scrollback,kill_pane,kill_session,kill_window|
TOOLS.mdには、各ツールの引数と返される内容がすべて記載されています。また、ドキュメントサイトでは各ツールに上記のリンク先ページがあります。このリファレンスは検索用のため、ここには記載していません。
executeを許可する前に、次の3つの動作を把握しておくことが重要です。
- 入力は tmux の送信先に送られます。
synchronize-panesが有効な場合、tmux はウィンドウ内のすべてのペインに入力します。[send_keys][send_keys] は、送信前にリンクされたペインを報告します。 - 新しいペインの起動を待ちます。 入力ツールはシェルがプロンプトに到達するまで待機するため、[
split_window][split_window] の後に [run_shell_command][run_shell_command] を実行できます。 - コピーモードはユーザーに任せます。 読み取りによってアタッチ済みのビューを占有することはありません。また、[
get_pane_info][get_pane_info] はペインがモード中かどうかを報告します。
[契約][contract-input]には、それぞれの残りの説明があります。
クライアントが実行できる操作を制限する
[LIBTMUX_TOOLSETS][mcp-toolsetsenvironmentvariable]：ツールセットを選択する
ツールセット名をカンマ区切りで指定し、順序は問いません。指定しない場合、サーバーは inspect、manage、execute を許可します。
teardownがデフォルトに加わるのは、このプロセスがlibtmux-mcpソケットで tmux サーバーを起動した場合のみです。それ以外では、名前を指定して有効にしてください。- 値が設定されていて空の場合、どのツールセットも許可されません。また、
noneキーワードはありません。
クライアントを使わずに効果を確認するには、1 つのツールセットでサーバーが提供する内容を一覧表示します。
$ LIBTMUX_TOOLSETS=inspect libtmux-mcp -tools
クライアントがサーバーを起動する際の環境からも、同じ選択が適用されます。
$ claude mcp add tmux \
-e LIBTMUX_TOOLSETS=inspect \
-- libtmux-mcp -socket-name default
[LIBTMUX_TOOLS][mcp-toolsenvironmentvariable] と [LIBTMUX_EXCLUDE_TOOLS][mcp-excludetoolsenvironmentvariable]：ツールを正確な名前で指定する
[LIBTMUX_TOOLS][mcp-toolsenvironmentvariable] は、ツールセットで許可されるツールに名前でツールを追加し、続いて [LIBTMUX_EXCLUDE_TOOLS][mcp-excludetoolsenvironmentvariable] が名前でツールを削除します。ツールを除外すると、[call_read_tools_batch][call_read_tools_batch] が呼び出せるツールからも削除されます。
[send_keys][send_keys] と [send_keys_batch][send_keys_batch] を除いたデフォルトのツールを一覧表示します。
$ LIBTMUX_EXCLUDE_TOOLS=send_keys,send_keys_batch libtmux-mcp -tools
どのツールにも一致しない名前や、いずれかのリスト内の空項目があると、tmux を開く前にサーバーの起動が停止します。
ツールを選択すると、クライアントに提示される内容が決まります。すべての呼び出しは、ユーザーの権限で実行されます。[契約][contract-exact-tools]には、以前のリリースからの変数について記載されています。
[libtmux-mcp -tools][guide-inspect-the-selection]：クライアントに提示される内容を確認する
$ libtmux-mcp -tools
サーバーが公開するツールを出力します。各ツールのツールセット、アクセス可能なプロセス、および動作の説明が表示されます。表示内容はフラグと環境によって決まるため、クライアントがサーバーに渡すものと同じものを指定してください。
[tmux://capabilities][mcp-capabilitiesresourceuri]：各ツールが自身について説明する内容
各ツールは、アクセス先と変更内容を _meta["com.git-pull.libtmux-mcp/capability"] の下で説明します。サーバーの唯一のリソースである tmux://capabilities は、現在有効な選択内容とともに同じ説明を報告します。[契約][contract-capability-disclosure]に記載されています。
設定
フラグは起動時に tmux サーバーを一度選択します。
| フラグ | 意味 |
|---|---|
-socket-path | 明示的なソケットパスです。設定されている場合、ほかのすべての設定より優先されます |
-socket-name | tmux のソケット名です。設定されている場合、下記の両方のソケット変数より優先されます |
-binary | tmux の実行ファイルです。空の場合は [LIBTMUX_TMUX_BIN][mcp-binaryenvironmentvariable] を使用し、その後 PATH 上の tmux を検索します |
ほかのフラグは質問に答えて終了します。起動しない設定エントリに必要なのはこのためです。
| フラグ | 回答内容 |
|---|---|
-version | どのビルドか |
-tools | クライアントに表示されるツールとツールセット |
-doctor | 接続先のソケット、そこにあるもの、およびその tmux 自身の内部で実行されているかどうか |
残りは環境変数で設定します。
| 変数 | 機能 |
|---|---|
[LIBTMUX_TOOLSETS][mcp-toolsetsenvironmentvariable] | ツールセットの任意のサブセットを選択します。順序は問いません |
[LIBTMUX_TOOLS][mcp-toolsenvironmentvariable] | ツールセットを展開した後、完全一致するツール名を追加します |
[LIBTMUX_EXCLUDE_TOOLS][mcp-excludetoolsenvironmentvariable] | すべての追加処理の後、完全一致する名前を除外します |
[LIBTMUX_SOCKET_PATH][mcp-socketpathenvironmentvariable] | 絶対ソケットパスを選択します。[LIBTMUX_SOCKET][mcp-socketenvironmentvariable] とは相互に排他的です |
[LIBTMUX_SOCKET][mcp-socketenvironmentvariable] | ソケットを選択するフラグがない場合に、tmux のソケット名を指定します |
[LIBTMUX_TMUX_CONFIG][mcp-tmuxconfigenvironmentvariable] | 空ではない絶対 tmux 設定パスを選択します |
[LIBTMUX_TMUX_BIN][mcp-binaryenvironmentvariable] | -binary が空の場合に、tmux の実行ファイルを選択します |
[LIBTMUX_MCP_WAIT_MAX_SECONDS][mcp-waitceilingenvironmentvariable] | 1 回の待機時間の上限です。デフォルトは 300 です |
[LIBTMUX_AUDIT][mcp-auditenvironmentvariable] | すべての呼び出しを記録する stderr またはパスです |
- フラグは対応する環境変数より優先されます。 すべての設定はサーバーの起動時に確定します。名前は Python サーバーのものと一致します。
- tmux の実行ファイルは一度だけ解決されます。 無効なパスは起動時にエラーになります。tmux サーバーが起動していなくても問題ありません。tmux が必要に応じて起動します。
- 長時間の待機は短縮されます。 応答の
effectiveTimeoutSecondsとtimeoutClampedにそのことが示されます。
[コントラクト][contract-settings]に全文があります。
実行中のペイン
isCaller：自分自身のペインを把握する
サーバーが報告する各ペインには isCaller が付与されます。サーバーが実行されているペインでは true、その他のペインでは false、サーバーがどのペイン内でも実行されていない場合は null です。[get_server_info][get_server_info] でも同じことを直接確認できます。
サーバーはまず TMUX_PANE と TMUX を読み取ります。これらから情報を得られない場合は、サーバーの祖先プロセスのいずれかを実行しているペインを探します。
ターミナルに入力する前に確認する
isCaller が true のペインへの書き込みでは、MCP のエリシテーションリクエストを通じて事前に確認を求めます。これは、クライアントがサーバーに代わってあなたに尋ねる質問です。
- 拒否すると呼び出しは失敗し、確認を求められないクライアントからの呼び出しは拒否されます。
- バッチでも同様に確認を求め、拒否するとその時点でバッチを停止します。
synchronize-panesが有効な場合、入力が届くすべてのペインについて確認を求めます。
[コントラクト][contract-caller-pane]に詳細があります。
既知の制限
- 一部のツールには、より新しい tmux が必要です。 起動処理と通常のツールは、
capture_sinceとrun_shell_commandを含め、3.3a をサポートしています。空でないpaste_textは、バッファーをステージングする前に 3.4 が必要です。wait_for_textは 3.7 より前ではcapture-paneをポーリングし、3.7 以降では制御出力を追跡します。制限付きツールは、サポート対象の古いデーモンでは明示的なバージョンエラーを返します。ランタイムは 3.7 より前ではサブプロセスコマンドを使用し、3.7 以降では保持された制御接続を使用します。 - すべてのツールに破壊的操作の注釈が付いています。 [
list_sessions][list_sessions] も例外ではなく、それぞれにdestructiveHint=trueが設定され、readOnlyHintはありません。各ツールの_metaにあるtmuxEffectsで分類してください。 tools/listは大きな応答になります。 その半分以上を_metaの説明が占めています。より小さな応答を望むクライアントは、_metaを無視できます。- 一部のツールでは、結果のフィールド名が異なります。
[
run_shell_command][run_shell_command]、[send_keys][send_keys]、 [paste_text][paste_text]、および [clear_pane_scrollback][clear_pane_scrollback] はexit_statusなどのフィールドを返し、それ以外のツールはpaneIdなどのフィールドを返します。
[契約][contract-known-limits]では、それぞれの理由を説明しています。また、結果のフィールド名についてはPARITY.mdを参照してください。
トラブルシューティング
まずサーバーに問い合わせてください。-doctor を使うと、クライアントを介さずに、以下の問題のほとんどを確認できます。
$ libtmux-mcp -doctor -socket-name default
- クライアントに tmux ツールが表示されません。 サーバーが起動していません。クライアントの設定にあるコマンドを手動で実行してください。
- ツールが不足しています。 [
LIBTMUX_TOOLSETS][mcp-toolsetsenvironmentvariable]、 [LIBTMUX_TOOLS][mcp-toolsenvironmentvariable]、または [LIBTMUX_EXCLUDE_TOOLS][mcp-excludetoolsenvironmentvariable] によって、一覧の内容が決まっています。-toolsを実行すると、クライアントが受け取る内容を確認できます。 - セッションがひとつも見つかりません。
-socket-nameを指定しない場合、独自の tmux サーバーを操作します。ソケット名は-doctorに表示されます。 - 別の tmux に接続しています。 クライアントの環境はシェルの環境とは異なるため、プロファイルで設定した
TMUX_TMPDIRがクライアントでは設定されていない場合があります。 - 確認できるセッションが「何もない」と報告されます。
-doctorが表示する tmux のバージョンをtmux -Vの結果と比較し、-binaryに正しい実行ファイルを指定してください。 - シェルでは動作するコマンドが、ツール経由では動作しません。
[
show_environment][show_environment] を使うと、新しいペインが引き継ぐ環境を確認できます。
[契約][contract-troubleshooting]では、それぞれについて説明しています。
エージェント向けのプログラム
examples/agent-workflow は、一連の処理をひとつのファイルにまとめたものです。自身のペインを見つけて別のペインを分割し、そこで作業を開始して出力を待ち、コマンドを実行して終了ステータスを読み取り、最後に生成された内容を読み戻します。
これはインストールしたモジュールの外側にあるリポジトリ内のファイルなので、クローンから実行してください。
$ git clone https://github.com/libtmux/libtmux-go.git
$ go -C libtmux-go/mcp run ./examples/agent-workflow -socket-name demo
何もないソケットに接続すると、そこでセッションを開始して、次のように出力します。
no tmux server on that socket yet; starting one
not running inside this tmux server; using active pane %0
split into %1
2 panes in this window while the work runs
the work printed agent-workflow-ready
the command exited 0 and printed:
| bounded work
the window now holds 2 panes: %0 %1
クライアントとサーバーはメモリー上で接続されるため、ひとつのプログラムとして動作します。ツール名、スキーマ、結果は、クライアントが標準入力と標準出力を介して見るものと同じです。後片付けには tmux -L demo kill-server を実行してください。
組み込み
[mcp.NewServer][mcp-newserver]：独自のプログラムからひとつの tmux サーバーを提供する
[mcp.Run][mcp-run] は、標準入力と標準出力を介して tmux サーバーを提供します。libtmux-mcp コマンドが行うのはこれだけです。別のトランスポートを使う場合は、[Instance][mcp-instance] を構築して、自分で接続してください。
次のコードブロックは、このパッケージ独自のサンプルテストから引用したものです。SDK のインメモリー・トランスポートペアの一端に接続し、もう一端をクライアントに渡します。
// Given: ctx context.Context; target tmux.Server; serverTransport sdk.Transport
instance, err := tmuxmcp.NewServer(target)
if err != nil {
return nil, nil, err
}
serverSession, err := instance.Connect(
ctx, tmuxmcp.AssumeResponseCommit(serverTransport), nil,
)
このパッケージも SDK も mcp という名前なので、このコードブロックでは、こちらのパッケージを tmuxmcp、SDK を sdk としてインポートしています。[NewServer][mcp-newserver] は対象を確認しますが、何も起動しません。
[mcp.AssumeResponseCommit][mcp-assumeresponsecommit]：トランスポートが各レスポンスを一度に書き込むことを保証する
標準入力と標準出力では、書き込みが戻ると各レスポンスがすぐに配信されることがわかっています。それ以外のトランスポートは、メモリ内トランスポートに対してこのブロックが行うように、[AssumeResponseCommit][mcp-assumeresponsecommit] でラップしてください。
サービスの提供を終えたら、[インスタンスを閉じて][mcp-instance-close]ください。[リファレンス][mcp-reference]には組み込み側に求められるその他の要件が記載されており、[コントラクト][contract-embedding]には全文が記載されています。
パッケージ
mcp：ライブラリとしてのサーバー
[mcp.Run][mcp-run] と [mcp.NewServer][mcp-newserver] は、tmux サーバーをクライアントに提供します。リファレンス：pkg.go.dev および [libtmux.org][mcp-reference]。
libtmux-mcp：クライアントが起動するコマンド
標準入力と標準出力を介して、1 つの tmux サーバーを提供します。リファレンス：[pkg.go.dev][libtmux-mcp-command] およびコマンドの README。
対応していないこと
- 2 つ目の tmux サーバー。 このサーバーはプロセスの存続期間中、1 つの tmux サーバーを提供し、クライアントは呼び出しで別のソケットを指定できません。
- ツール以外の機能。 リソースは 1 つのみで、プロンプト、リソーステンプレート、補完、バックグラウンドジョブのハンドルはありません。
- アクセス制限。 ツールセットによって、クライアントに提示する内容を調整できます。すべての呼び出しはユーザーの権限で実行されるため、[
send_keys][send_keys] を使用できるクライアントは、あなたが実行できることなら何でも実行できます。 - Python サーバーの呼び出しごとのソケット。 ソケットは起動時に一度だけ選択されます。その他の相違点は PARITY.md をご覧ください。
サポートとステータス
- Go 1.26 以降および tmux 3.3a 以降。 MCP トランスポートの開始前に、古い tmux をサーバーが拒否します。CI では tmux 3.3a から 3.8 までを実行します。
- Linux（WSL を含む）および macOS。 CI では Linux 上で、tmux 3.3a から 3.8 までを使ってこのモジュールのテストを実行します。macOS はベストエフォートでサポートされており、CI のカバレッジは非常に限られています。
- 独立したモジュール。 tmux ライブラリに対して
go getを実行しても、MCP SDK は取得されません。 mcp/vNとしてタグ付け。 独自のgo.modでは正確なバージョンを固定してください。以下のコマンドは最新バージョンを取得します。
関連項目
コメント
AI アプリケーションが外部のツールやデータソースに統一的な方法で接続するためのオープンなプロトコルです。クライアントはモデルとの対話を担い、MCP サーバーはツール・リソース・プロンプトテンプレートを提供します。標準メッセージでやり取りするため、1 つのサーバーを複数のクライアントで再利用できます。