Letterbox

Letterbox

📌 社内の本番環境向けに構築されています。 数か月にわたる日々の AI 開発で、そのアーキテクチャの有効性が実証されています。リファレンス実装としてオープンソース化しました。ほぼ毎日使っています。

ターミナルで AI コーディングアシスタントを使う場合、通常は一度に 1 つだけを使います。2 つを連携させるには、ウィンドウ間で自分でメッセージをコピー＆ペーストしなければなりません。Letterbox を使えば、2 つのアシスタント（たとえば Claude と Gemini、あるいは Gemini と Mistral's Vibe）が 直接 会話し、手を介さずに一緒にタスクに取り組めます。

その結果： 1 つのエージェントが計画を立てている間に、もう 1 つがレビューできます。または 2 つで作業を分担し、あなたが見守るなか、それぞれが自律的に連携できます。すべてのメッセージを手作業で伝える必要はありません。

別々のターミナルで動作する 2 つの AI エージェントがリアルタイムで会話できる、小さなファイルベースの通信プロトコルです。

Letterbox を使うと、Claude Code、Gemini CLI、Antigravity、Mistral's Vibe などのターミナル上のコーディングエージェント 2 つが、共有ディレクトリを介してメッセージファイルをやり取りし、リアルタイムで会話できます。一方のエージェントが発言すると、もう一方のターミナルに 📬 通知が挿入され、エージェントが起動してメッセージを読み、返信します。ネットワークもサーバーも共有メモリも不要です。必要なのは、フォルダー内の JSON ファイルと OS のアトミックリネームだけです。社内の計画ループ向けに構築されたメッセージングレイヤーを切り出し、2026 年に独立したバージョン管理ツールとして公開しました。ウィンドウ間でコピー＆ペーストせずに、2 つの CLI エージェントを連携させたいと思ったことがあるなら、これはあなたのためのツールです。作者の判断で時折アップデートされます（新しいバージョンが公開されると、ランチャーが知らせます）。ただし、これは現在サポート対象外の小規模プロジェクトであり、コミュニティプロジェクトではありません。

このブリッジはハーネスをまたいで使えます。一方が Claude、もう一方が Gemini で同じチャネルを通じて会話する動作は、実際に検証済みです。注意点はセットアップです。Claude は自動で接続を設定しますが、Gemini と Antigravity はそれぞれの設定から letterbox を読み込みます。セットアップセクションでは、その両方について説明しています。

開発の背景

私は毎日、Claude と Gemini という 2 つの AI コラボレーターと作業しています。それぞれ Claude Code、Gemini CLI、Antigravity CLI、そして最近では Mistral's Vibe など、実行環境となるターミナルハーネスで動いています。Letterbox は、私を介さずに彼らを 互いに 会話させるためのツールです。

使い方は 2 通りあります。ブレインストーミング中に、もう一方のモデルを会話に加えたいときは、手動で使います。計画ループのように自動化する場合は、Claude が計画案を作成し、各計画案が組み込みステージとして Gemini のレビューに回されます。Letterbox は、どちらの場合も同じようにメッセージを届けます。

設計上、特定のハーネスに依存しません。Claude Code ↔ Gemini CLI ↔ Antigravity CLI ↔ Vibe の任意の組み合わせで使えます。同じモデル同士の組み合わせも同様に機能します。Claude のタブ 2 つでも、Gemini のタブ 2 つでも、1 つのチャネルを通じて会話できます。

これは何か

letterbox <harness> を起動するたびに、1つのターミナル内で連携する2つのプロセスが実行されます。

  letterbox claude --channel demo --as alice
        │
        ├─ PTY-Parent  (the foreground letterbox process)
        │    • spawns the harness CLI as a PTY child
        │    • watches the channel directory for peer writes
        │    • injects 📬 notifications into the PTY on arrival
        │
        └─ the harness spawns:
             └─ letterbox mcp  (stdio MCP server, agent-spawned)
                  • send_message / check_messages / acknowledge
                  • check_latest_message / channel_info / list_channels

  Both sides coordinate ONLY through the filesystem:

        ~/.letterbox/channels/demo/
          msg-*.json           ← one file per message
          .read/alice.json     ← per-agent read markers
          .read/bob.json

デーモンも IPC もバックグラウンドサービスもありません。ファイルシステムそのものが連携手段です。PTY-Parent のウォッチャーが新しい msg-*.json の出現を検知して通知を表示します。チャネルディレクトリは永続的で、内容を確認でき、cat で読み取れます。メモリ上に重要なデータを保持しないため、クラッシュからの復旧は簡単です。

エージェントが letterbox のツールを利用する方法はハーネスごとに異なり、一度だけ設定が必要なのはこの点です。

• Claude Code は起動フラグを受け取るため、letterbox が自動的に設定します。一時的な MCP 設定を生成し、--mcp-config を claude に渡します。ユーザー側で設定する必要はありません。
• Gemini CLI と Antigravity はこのフラグを受け取らず、それぞれの設定ファイルから MCP サーバーを読み込みます。チャネルに依存しない letterbox エントリを1行追加するのは最初の一度だけです。起動時にランチャーが環境変数を通じて各セッションにチャネルと ID を渡すため、チャネルごとに設定を編集する必要はありません。
• Vibe は ~/.vibe/config.toml から MCP サーバーを読み込みます。MCP サブプロセスが引き継ぐ環境変数は必要なものだけに絞られているため、Vibe 自身のプロセス環境から LETTERBOX_CHANNEL / LETTERBOX_SENDER を中継するブリッジスクリプトを一度設定する必要があります。設定後は、どのチャネルでも Gemini と同じように動作します。Vibe の設定セクションを参照してください。

対象ユーザー

• ターミナルでコーディングエージェントを実行していて、ウィンドウ間でコピー＆ペーストを見守ることなく、1台のマシン上で自律的な AI↔AI の対話を実現したい人。
• ファイルを信頼できる情報源とすることを重視する人。監査可能で、grep で検索でき、不透明なプロトコルや仕組みの分からない機能がありません。

対象外のユーザー

• ホスト型またはネットワーク接続型のチャットサービスを求める人。メッセージプロトコルはローカルファイルシステム内で完結し、ネットワークには一切アクセスしません。（ランチャーは起動時に、任意でベストエフォートのバージョン確認を1回行います。無効にするには LETTERBOX_NO_UPDATE_CHECK=1 を設定します。）
• マルチユーザープラットフォームを求める人。これは1台のマシン上のエージェント間をつなぐ一対一のブリッジであり、多数のユーザーを収容するハブではありません（2人のための設計を参照）。
• Windows ネイティブ環境のユーザー。v1 は POSIX 専用です（サポート対象外を参照）。
• サポート付きの製品を求める人。letterbox にはバージョンが付けられ、作者の都合で時折更新されます（新しいバージョンが出るとランチャーが知らせます）が、ロードマップも SLA もなく、機能要望への対応や保守継続の約束もありません。そのまま利用し、役立つ場合は新しいバージョンを取得してください。

2人のための設計

Letterbox の本質は2者間のブリッジです。1人の相手とやり取りする用途を想定して設計・調整されています。3つ以上のエージェントでチャネルを共有することもできます。宛先指定（send_message(to="<label>")）と participants リストがあるため実用可能で、同じチャネルへのブロードキャストは全員に届きます。ただし、共有チャネルはブロードキャストバスです。すべてのメッセージによって、すべての参加者が起動します。ターン交代、指定されたコーディネーター、発言タイミングのルールなどのオーケストレーションがなければ、N者間のルームは通知の嵐となり、モデルのメッセージ数や使用量の上限を驚くほど速く消費する可能性があります。3人以上で使う場合は、独自の指揮役を用意してください。この基盤はルームの参加者を正確に示しますが、エチケットは利用者次第です。

インストール

PyPI および MCP Registry から入手できます。

pip install letterbox

またはソースからインストールします。

pip install -e .          # or: pip install -e ".[dev]" for the test extras

これにより、letterbox コマンドが PATH に追加されます。コマンドは名前で解決できる必要があります。各エージェントが独自に letterbox mcp を起動するため、これは必須です。次のコマンドで確認してください。

which letterbox           # note this absolute path; Gemini/Antigravity setup needs it

また、起動するハーネス（claude、gemini、antigravity、または vibe）がインストールされ、PATH 上にあり、ログイン済みである必要があります。letterbox がハーネスを起動します。

更新

Letterbox にはバージョンが付与され（唯一の信頼できる情報源は letterbox.__version__）、PyPI に公開されています。ユーザーが起動する際、CLI は最善努力で 1 回だけ（1 日に最大 1 回、~/.cache/letterbox/ にキャッシュ）更新を確認し、新しいバージョンがあれば 1 行の通知を表示します。更新するには、次のようにします。

pip install --upgrade letterbox

これが Letterbox が行う唯一のネットワーク呼び出しです。メッセージングプロトコルは完全にローカルで動作します。タイムアウトは短く設定され、失敗しても何も通知しません。GitHub に接続できない場合は何も表示せず、起動を遅らせることもありません。letterbox mcp（エージェントの stdio サーバー）では実行されません。LETTERBOX_NO_UPDATE_CHECK=1 を設定すると、完全に無効にできます。

ハーネスごとのセットアップ

ハーネスごとにセットアップするのは 1 回だけです。使用しないハーネスはスキップしてください。

Claude Code — 設定不要

Letterbox は Claude を自動的に設定します。起動時に一時的な MCP 設定（モード 0600）を書き込み、--mcp-config <path> を指定して claude を実行します。Letterbox のツールはそのセッションでのみ表示されます。編集する設定ファイルはありません。

Gemini CLI — 2 つの初回設定手順

1. MCP サーバーを登録するには、~/.gemini/settings.json に設定します（ファイルが存在しない場合は作成してください）。インストール済みの letterbox の絶対パス（上記の which letterbox で確認できます）を使用し、["mcp"] だけを渡してください。チャンネルや ID は不要です。

{
  "mcpServers": {
    "letterbox": {
      "command": "/absolute/path/to/letterbox",
      "args": ["mcp"]
    }
  }
}

このエントリは、意図的にチャンネルに依存しない設定です。起動時にランチャーが LETTERBOX_CHANNEL、LETTERBOX_SENDER、LETTERBOX_INSTANCE_ID を Gemini の環境にエクスポートし、MCP サーバーがそれらを読み取ります。そのため、同じエントリをすべてのチャンネルで使え、以後編集する必要はありません（これは Forge オーケストレーターが環境変数でチャンネルを渡す方法と同じです）。

2. 起動元のフォルダーを信頼するように設定します。Gemini は、信頼されていないディレクトリでは、対話形式の 「このフォルダーを信頼しますか？」 というプロンプトなしでの実行を拒否します。このプロンプトで TUI がブロックされると、自動化が停止してしまいます。~/.gemini/trustedFolders.json で、起動ディレクトリ（またはその親ディレクトリ）をあらかじめ信頼するように設定してください。

{
  "/home/you/projects": "TRUST_PARENT"
}

TRUST_FOLDER はそのディレクトリだけを信頼します。TRUST_PARENT はそのディレクトリと配下すべてを信頼するため、1 つのエントリですべてのプロジェクトフォルダーをカバーできます。（ヒント：これを回避するために Gemini の --skip-trust フラグを使うのは避けてください。このフラグはワークスペースのシステムプロンプトの検索を強制するため、すでに信頼されているディレクトリでもクラッシュします。フォルダーを信頼するように設定してください。）

Antigravity（agy）

letterbox agy … として起動してください（長い形式の letterbox antigravity … も使えます。agy はバイナリ名に合わせたエイリアスです）。Antigravity は Gemini と同じ環境変数を通じて、起動ごとのチャンネルと ID を受け取ります。異なるのは MCP サーバーの登録方法です。agy はプラグインから MCP サーバーを読み込むため、Letterbox を小さなローカルプラグイン（2 つの JSON ファイルを含むディレクトリ）としてインストールします。

# 1. Build the plugin (one directory, two files). Use the absolute
#    `letterbox` path from `which letterbox`.
mkdir -p ~/.letterbox/agy-plugin/letterbox
cat > ~/.letterbox/agy-plugin/letterbox/plugin.json <<'JSON'
{ "name": "letterbox", "version": "1.0.0",
  "description": "Letterbox file-based AI-to-AI comms bridge." }
JSON
cat > ~/.letterbox/agy-plugin/letterbox/mcp_config.json <<'JSON'
{ "mcpServers": { "letterbox": {
    "command": "/absolute/path/to/letterbox", "args": ["mcp"] } } }
JSON

# 2. Install it (and confirm).
agy plugin install ~/.letterbox/agy-plugin/letterbox
agy plugin list

mcp_config.json がチャンネルに依存しないのは、Gemini の設定エントリと同じ理由です。起動時にランチャーがチャンネルと ID を環境経由で渡します。Gemini と同様に、agy もフォルダーが信頼されているかを確認します。~/.gemini/antigravity-cli/settings.json の trustedWorkspaces リストに従うため、起動ディレクトリがまだ登録されていなければ追加してください。

ステータス： PTY レイヤー（通知とメッセージ配信の双方向）は実環境で検証済みで、上記のプラグインインストールによりツールも問題なく設定されます。agy でのツールの往復動作は最近正常に動作し、軽くテストされています。Antigravity は3 つの中で最も新しいものとして扱い、気になる点があれば報告してください。

Vibe（Mistral）

letterbox vibe … として起動します。Vibe は ~/.vibe/config.toml から MCP サーバーを読み込みますが、MCP サブプロセスが継承する環境変数は絞り込まれており（HOME、PATH、SHELL、TERM、USER、LOGNAME のみ）、通常の継承では LETTERBOX_CHANNEL などが渡りません。起動時に /proc 経由で Vibe のプロセスからこれらを読み取る、小さなブリッジスクリプトを一度だけ用意すれば解決します。その後は、チャンネルごとに設定を編集することなく、Gemini と同じようにどのチャンネルでも使えます。

1. ブリッジスクリプトをインストールします（letterbox に付属しています）。

cp "$(python3 -c 'import letterbox.data, pathlib; print(pathlib.Path(letterbox.data.__file__).parent / "vibe-mcp-bridge.sh")')" \
   ~/.letterbox/vibe-mcp-bridge.sh
chmod +x ~/.letterbox/vibe-mcp-bridge.sh

2. ~/.vibe/config.toml に登録します。 既存の letterbox エントリーがあれば、次の内容に置き換えてください。

[[mcp_servers]]
name = "letterbox"
transport = "stdio"
command = "/home/YOU/.letterbox/vibe-mcp-bridge.sh"
args = []

実際のホームディレクトリのパスを使用してください（~ ではありません。Vibe が展開しない場合があります）。このエントリーは、意図的にチャンネルに依存しない設定になっています。ブリッジスクリプトは、Gemini が環境変数から読み取るのと同じように、実行時に Vibe のプロセス環境変数からチャンネルと ID を読み取ります。

3. 完了です。 どのチャンネルでも使えます。

letterbox vibe --channel blueberry-fields --as mistral

Vibe は --yolo（自動承認）を付けて起動するため、ツールごとの確認プロンプトで止まることなく、注入された通知でエージェントを起動できます。

注記： ブリッジスクリプトは Vibe の環境変数を読み取るために /proc/$PPID/environ を使用します。これは Linux 専用であり、letterbox の POSIX 専用という方針にも合致しています。macOS をサポートするには別の方法（ps -p $PPID -Ewww）が必要ですが、現時点では提供されていません。

ステータス： 📬 起動通知の注入が動作することを確認済みです（STEP 0 で、Vibe の ChatTextArea が Enter キーの動作をオーバーライドして送信することを確認したため、標準の PTY 注入経路を使用できます）。Vibe は4 つの中で最も新しいものとして扱い、気になる動作があれば報告してください。

クイックスタート

2 つのターミナルを開き、それぞれで同じチャンネルを指定し、異なる ID を設定します。設定ファイルがない場合、letterbox の組み込みデフォルトにより、共有のグローバル状態ディレクトリ（~/.letterbox）が使用されます。

異なるハーネス間の実際のブリッジです。Claude から Gemini に話しかけます（先にGemini のセットアップを完了してください）。

# Terminal 1
letterbox claude --channel demo --as claude

# Terminal 2
letterbox gemini --channel demo --as gemini

シンプルにしたい場合は、同じハーネスを 2 つ起動することもできます。

# Terminal 1
letterbox claude --channel demo --as alice

# Terminal 2
letterbox claude --channel demo --as bob

両方のセッションが起動し、静かに待機します。次に、ターミナル 1 のエージェントに「仲間にメッセージを送って」といった指示を出します。あとは、📬 通知のたびにもう一方のエージェントが起動し、メッセージを読んで返信します。この引き継ぎこそが、letterbox の目的です。--as <label> の名前はトランスクリプトを読みやすくするためのものです。内部では、メッセージのフィルタリングにラベルではなく、起動ごとに割り当てられるインスタンス ID を使用します。

補足しておきたい点がいくつかあります。

• letterbox mcp を自分で実行することはありません。 このサブコマンドは stdio MCP サーバーであり、ハーネスによって起動されます。これはあなたではなく、エージェントのためのものです。ターミナルで手動実行すると、その旨を表示して終了します。
• 起動引数は、自律的に動作するよう意図されています。 Claude アダプターは --dangerously-skip-permissions を、Gemini アダプターは --yolo を付けて起動します。アクションごとの承認プロンプトで止まっているエージェントは、注入されたメッセージでは起動できないためです。このトレードオフを受け入れられない場合、letterbox は適していません。letterbox.toml で引数を上書きするか、使用をお控えください。

詳しい説明付きのウォークスルー（ホットドッグはサンドイッチかどうかを議論する 2 つの Claude）については、examples/two-claudes-debating/ のサンプルプロジェクトをご覧ください。

ブリッジの状態を確認する

設定済みのハーネスは毎回のセッションで letterbox を読み込むため、アクティブなブリッジがなくても、エージェントが letterbox のツールを利用できることがあります。たとえば、letterbox 経由で起動していない通常の Gemini セッションなどです。Letterbox はこの状態を落ち着いて扱い、確認手段をエージェントに提供します。

• 通常のセッションは故障ではなく、休止状態です。 チャネルがなくても、MCP サーバーへの接続は維持されます（ハーネスには問題なく「接続済み」と表示されます）が、メッセージングツールは何もせず待機します。実際に呼び出された場合にのみ、明確で対処可能なメッセージを表示して失敗し、勝手に動作することはありません。意図的な通常セッションにメッセージが大量に送られることはなく、ブリッジの設定に本当の問題がある場合は、エージェントがメッセージを送ろうとした時点で明らかになります。
• channel_info は、エージェントがブリッジの状態を確認するための情報源です。 これを呼び出すと、サーバー側で、ブリッジがアクティブかどうか、どのチャネルで誰として参加しているか、相手（最新のメッセージから判定）が誰か、未読数はいくつか、最後に相手が発言したのはいつかが分かります。状況が分からないエージェントは、送信前に確認できます。「相手が最後に発言したのは90秒前」と「一度も発言していない」では、受け取る印象が大きく異なります。

チャネルの監視と一覧表示

任意のターミナルから、会話の生ログを監視したり、存在するチャネルを確認したりできます。

letterbox tail --channel demo --follow   # stream messages as JSON, one per line
letterbox list-channels                  # list channels with last-activity

デフォルト設定に頼らず、初期設定用の letterbox.toml を生成するには、次のようにします。

letterbox init --channel demo            # writes ./letterbox.toml (project-local)
letterbox init --global                  # writes ~/.letterbox/config.toml instead

操作

• メッセージを読むと未読を確認でき、受信箱は自動的に空になります。 check_messages は未読の相手のメッセージを返しながら、そのエージェントの既読位置を進めます。そのため、続けて呼び出すと未読メッセージを順に確認でき、空になった受信箱は空のままです。手動で既読状態を管理する必要はありません。よくある「相手は今、何と言ったのか？」という場合には、既読位置を進めない check_latest_message で確認できます。また、特定のメッセージを明示的に管理する場合は acknowledge を使えます。
• 再起動は履歴の再生ではなく、新たな開始です。 起動時に、エージェントの既読位置はディスク上の最新メッセージに合わせられます。そのため、参加後に届いたメッセージだけを確認でき、前のセッションでのチャネルの全履歴が一度に流れ込むことはありません。履歴は引き続き保存され、必要に応じて取得できます（since_id カーソルを指定して check_messages を呼び出します）。履歴の確認が強制されることはありません。
• 保持期間は手動で管理します。 メッセージは削除するまでチャネルディレクトリに残ります。通信インフラでは予期しない削除は許容できないため、自動削除はありません。エージェントごとの .read/ マーカーは既読状態を追跡します。これらは既読位置を進めるだけで、ファイルには触れず、相手側の表示にも影響しません。
• 実用上の上限は、整理されていないメッセージがチャネルあたり約10,000件です。 それを超えると、check_messages と list-channels の応答に目立った遅延が生じる可能性があります。それを超える前に整理してください。
• 容量の回復には letterbox prune を使うのが安全です。 デフォルトではドライランで、実行した場合の内容を表示するだけで、何も変更しません。--yes-i-am-sure を指定すると、該当ファイルは元に戻せる cold/ サブディレクトリに移動します。二重の確認が必要な --delete --yes-i-am-sure を指定すると、完全に削除されます。letterbox で破壊的な操作を行うコマンドはこれだけです。

letterbox prune --channel demo --keep-last 100                   # preview (dry run)
letterbox prune --channel demo --keep-last 100 --yes-i-am-sure   # move to cold/
letterbox prune --help                                           # all selection rules

チャネルは単なるフォルダーなので、rm -rf ~/.letterbox/channels/demo でも削除できます。letterbox はロックを一切行いません。

セキュリティモデル

完全な脅威モデルは docs/PROTOCOL.md に記載されています。概要は次のとおりです。

• チャネル上の相手側エージェントは信頼できません。 メッセージ本文には、プロンプトインジェクションのペイロード、ANSI エスケープシーケンス、シェルのメタ文字が含まれている可能性があります。Letterbox は双方を信頼できないものとして扱います。
• 通知は信頼できるコンテキストからのみ生成されます。 📬 通知テンプレートが代入する変数（{channel}、{sender}、{message_id}、{timestamp}）は、ウォッチャー自身の設定と観測結果から取得されます。相手側のメッセージペイロードから取得することはありません。悪意のある相手側は自分のファイルに何でも書き込めますが、その内容が注入された通知に到達することはありません。メッセージ本文が表示されるのは、エージェントが明示的に check_messages を呼び出した場合だけです。同じことは channel_info の相手側フィールドにも当てはまります。これらはトラフィックから観測される情報であり、通知に使われることはありません。
• 実行経路はありません。 Letterbox はメッセージ本文やメタデータフィールドに対して exec、eval、シェル実行を行いません。サブプロセスは argv リストで起動し（shell=True は使用しません）、letterbox.toml で設定されたハーネスの起動にのみ使用します。
• パスの安全性。 ファイルシステム操作の前に、チャネル名とメッセージ ID を厳格なパターンで検証します。../etc やスラッシュを含む値は拒否されます。
• ファイルシステムの権限。 ~/.letterbox/ とチャネルディレクトリは 0700（ユーザーのみ）で作成され、生成される MCP 設定は 0600 です。

Letterbox が防御しないもの： 侵害されたローカルユーザーアカウント（ファイルシステムの権限のみが防壁です）、利用するハーネス自体のプロンプトインジェクションの脆弱性、またはマシン間同期（NFS、syncthing）によって生じる信頼境界です。設計上、保存データの暗号化やネットワークの信頼レイヤーは対象外です。

対象範囲と対象外

Letterbox が意図的に行わないことこそが重要であり、欠落ではありません。

• LLM 呼び出しはありません。 Letterbox は言語モデルを呼び出さず、トークンを消費せず、API キーも保持しません。通知テンプレートはレンダリングされたテキストであり、プロンプトではありません。
• テレメトリ、メトリクス、分析はありません。 何も収集せず、ダッシュボードも使用状況の追跡もありません。
• 外部への定期通信、自動更新、バージョン確認はありません。 Letterbox がサーバーに接続することはありません。初回実行もサイレントです。
• ネットワークは使用しません。 ファイルシステム内で完結します。マシン間での利用はファイルシステム同期の役割であり、Letterbox の役割ではありません。

この対象外の方針により、Letterbox は小さく、受動的で、監査しやすく、長く使えるものになっています。

アクセシビリティ

• デフォルトはプレーンテキスト（--format=plain）です。パイプやスクリーンリーダーで扱いやすく、tail はメッセージ JSON を stdout に出力するため、jq で処理できます。構造化された色付き出力はオプトインです（--format=rich）。
• 色だけで状態を示すことはありません。 --color=auto|always|never で色を個別に制御でき、状態は色だけで伝えられることはありません。
• stdout はデータ、stderr はログです。コマンドを問題なくパイプでつなげられます。
• 全体を UTF-8 で扱います。 ツール自体の文字列は英語で、メッセージ本文は入力した言語のままです。
• 落ち着いた操作画面です。 スピナー、テレメトリのバナー、アップグレードの催促はありません。成功時は静かに、エラーは明確に表示します。エラーにはパス、行、または有効なオプションが示されます。

サポート対象外

Letterbox v1 は POSIX のみ（Linux と macOS）に対応しています。 PTY の起動・注入レイヤーは POSIX プリミティブを基盤としており、標準ライブラリの pty モジュールを使った Windows 対応は不完全なため、提供していません。Windows をお使いの場合、v1 では Letterbox は動作しません。クラッシュに遭遇するより、今知っておくほうがよいでしょう。

関連項目

• examples/two-claudes-debating/ — 実践形式のチュートリアルです。2つの Claude Code セッションがリアルタイムで議論します。
• skills/letterbox/SKILL.md — エージェント向けの使用方法ガイドです。LLM が稼働中のブリッジを使う方法（ブロードキャスト、宛先指定メッセージ、参加者）を説明します。
• skills/letterbox-setup/SKILL.md — エージェント向けのセットアップガイドです。ハーネスごとに一度だけ行う MCP の接続設定、チャンネルごとに1つのラベルを使うルール、アップグレード後の再起動手順を説明します。
• docs/AGENT_POINTER.md — プロジェクトの CLAUDE.md / GEMINI.md / AGENTS.md に貼り付けられる短いブロックです。エージェントにブリッジ上にいることを知らせます。
• ファイル形式とプロトコルの完全なリファレンスは docs/PROTOCOL.md にあります。
• DECISIONS.md — 基盤となるあらゆる選択の背景にあるアーキテクチャ決定記録（ADR）です。ハーネスごとの MCP 接続設定（ADR-054/055）、休止モードと channel_info オラクル（ADR-056）、送信タイミングの修正（ADR-057）、自動維持される既読マーカー（ADR-058）、チャンネルごとの重複インスタンス防止機能（ADR-061）、N者間の宛先指定と参加者（ADR-062）、Vibe アダプターと Textual の送信契約（ADR-067）などが記録されています。
• LICENSE — MIT ライセンスです。

ステータス

Letterbox はバージョン管理された、サポート対象外の成果物です。MIT ライセンスで、github.com/dovahkiin-v/letterbox で公開されています。完成した状態で提供され、ドキュメントに記載されたとおりに動作します。コントリビューションは募集していません。開発が停止したわけではありません。私はほぼ毎日使っています。ただし、次のバージョンをいつリリースするかは未定で、予定もありません。ランチャーは1日1回アップデートを確認し、新しいバージョンが公開されると通知します（通知を止めるには LETTERBOX_NO_UPDATE_CHECK=1 を設定します）。実際にどういうことかは CONTRIBUTING.md をご覧ください。