teleptyは、複数のマシンで動作するターミナルAI CLIセッション（claude、codex、gemini など）にリモートで指示を送り、画面を読み取れるようにする軽量なエージェントセッション・コントロールプレーンです。推論と作業は各エージェントがそのまま担当し（data plane）、teleptyはそれらのセッションをアドレスで呼び出し、配送を保証する層だけを担います（PTYベースのバックグラウンドデーモン + セッションブリッジ）。各セッションには名前ベースのアドレスを付与し、指示が実際に受理されたかどうかまで確認でき、macOS・Linux・Windowsをサポートします。クロスマシン転送は独自実装せず、実績のあるTailscale（WireGuard）の上に構築しました。鍵交換・NATトラバーサル・暗号化を新たに実装して攻撃面を増やす代わりに、長年本番で検証されてきた層へ委ねる方を選んでいます。MITライセンスのオープンソースです。
npm i -g @dmsdc-ai/aigentry-telepty && telepty daemon start
# 既存のCLIをそのまま包んで、名前付きセッションにします（各マシンで1回ずつ）
telepty allow --id orchestrator claude # このマシンのclaudeセッション → "orchestrator"
telepty inject "backend@100.x.y.z" "認証ミドルウェアのリファクタリングを始めて" # リモートセッションに指示
telepty read-screen "backend@100.x.y.z" # 進行状況を確認
telepty broadcast "作業を締めて状態を報告して" # 全セッションに通知
背景
複数のAI CLIセッションを、複数のマシンにまたがって運用する開発は一般的になってきました。実行はセッション数に応じて並列にスケールしますが、セッション間の配送――指示の伝達、進捗確認、結果回収――は依然として人が端末を行き来して行っています。このツールの出発点もそのボトルネックでした。3台のマシンで3つのAI CLIセッションを同時に回してみると、実行そのものより先に、指示と結果を運ぶ「配送」の段階で人が詰まったのです。
- 従来: 3つのターミナルを行き来しながらフォーカスを切り替え → 指示をコピペ → 進捗確認を各セッションごとに繰り返す
- telepty: 1つのターミナルから
名前@ホストアドレスに指示を注入し、画面を回収する
既存ツールではこの層を埋められません。tmux/SSHはセッションに「接続する」ためのツールなので、送信と確認の作業は依然として手動ですし、エージェントフレームワークは既存のセッションやワークフローを自分たちの流儀に合わせて書き換えることを求めます。teleptyはその中間、つまり、すでに動いているセッションはそのままにして、配送だけをインフラへ下ろす薄い層を目指しています。
設計
- 名前でセッションを指定 — すべてのセッションを
<セッション名>@<ホスト>で呼びます。対象がどのマシンの、どのOS上にあるかを意識する必要はありません。 - 「送信」と「受信」を分離 — 受信側セッションが作業中ならメッセージをキュー（mailbox）に保管し、実際に受理されたタイミングをターミナルのレンダリング状態で判定して確定します。送ったあとに人が再確認する必要はありません。
- デーモンを再起動してもセッションは維持 — セッションを保持するプロセス（bridge）とルーティングデーモン（daemon）が分離されているため、デーモンのアップグレードでも進行中の作業は中断されません。
- 転送は実績ある層に委任 — 独自のP2Pプロトコルは作っていません。Tailscaleがあればデーモンがtailnet IPを自動検出してその上で直接接続します。ポート開放 0、証明書管理 0、ファイアウォールルール 0。tailnetがない環境ではSSHトンネル（
telepty connect user@host）で接続します。どちらの場合でも暗号化と身元確認はすでに検証済みのツールが担い、teleptyはその上でセッションのアドレス指定と配送だけを担当します。
コマンドは inject / read-screen / attach / send-key / broadcast / list の6つで、CLIそのものがAPIなのでシェルスクリプトからそのまま組み合わせられます。そして人だけのために作られたものではありません。Claude Code・Codex・Gemini CLI向けのスキル9種がパッケージに同梱されており（内蔵インストーラで導入可能）、エージェント自身がteleptyをツールとして使えます。セッションを照会し、別マシンのエージェントに指示を送り、画面を読み取れます。下のデモのリレーはまさにその場面で、人ではなく各LLMが直接 telepty inject を実行します。
初期の参考指標（0.6.11ビルドで測定 — 現行リリースは0.7.1、ネットワーク往復・PTY初期化オーバーヘッドを含む）
- busyセッション向け gated inject のキュー投入→受理確定: Linux 約487ms・Windows 約1.2s。さらに測定を積み増し中ですが、重要なのは数値そのものよりも、HTTP受理ではなく受信側ACKの到着を受理基準にしている点です。
- macOS・Linux・Windows の3OS間クロスマシン配送を同じ基準で確認しました。
セキュリティ
デーモンは localhost（127.0.0.1）とtailnet専用IPにのみバインド されます。0.0.0.0 への露出がないため、tailnet外からはポートスキャンでも到達できません。信頼するのはtailnetピアのみで、PTYへの書き込み権限もそのセッションを所有するユーザーの範囲を超えません。0.7.1からはブラウザから来たリクエストを明示的に拒否します。ユーザーが訪れたWebページからlocalhost上の制御APIやWebSocket経由でセッションへアクセスする経路を遮断しました（許可オリジンのデフォルト値なし）。
制限事項
ベータ版です。CLIごとのレンダリングのエッジケースが残っており、Windowsにはbetaの注記が付いています。ターミナルエミュレーションを行わないため、read-screen はセルグリッドではなく出力ストリームの末尾部分を返します。再描画の多いTUIでは同じフレームが繰り返し表示されることがあります。既知の項目はREADMEのLimitationsセクションに整理されています。
リンク
- GitHub: https://github.com/dmsdc-ai/aigentry-telepty
- READMEデモ: 3台のマシン（macOS・Linux・Windows）上の3つのLLM（Grok・Codex・Claude）が telepty inject を直接実行し、互いにリレーする場面。各画面は元のCLI TUIを
attachでライブキャプチャしたものです。同じコマンドは1台のマシン内のセッション間でもそのまま動作します（同一マシン内リレーデモを含む）。 - npm:
@dmsdc-ai/aigentry-telepty（MIT, 0.7.1）
複数のAI CLIセッションを運用している方々が、配送層をどう解決しているのか気になります。フィードバックをいただければ反映します。
1件のコメント
開発の動機を補足すると、Cluade、Codex Gemini、Grok の4つのセッションを3台のクロスプラットフォーム環境のマシンで回していたときに、「実行はスケールアウトできるのに、受け渡しは1人の人間に縛られる」というボトルネックを経験したのが始まりでした。tmux/SSH の代替ではなく、並行利用するためのツールです — 目的は「ターミナル接続」ではなく「セッションのアドレス指定 + 受け渡し確認」です。気になる点があれば気軽に聞いてください。