🛰️ T3 Codeで手元のコーディングエージェントを複数端末から操る仕組み

T3 Code は、自分のマシンで動く Claude Code や Codex などのコーディングエージェントを、Web・デスクトップ・スマートフォンから 1 つの画面で操作するオープンソースのアプリです。この記事では、t3.codes と GitHub の pingdotgg/t3code（2026-10-03 時点の main）をもとに、T3 Code の構造、データモデル、導入、利用、運用を順に説明します。

読み終えると、次のことがわかります。

• 「作業領域を持つサーバ」と「指示だけを出すクライアント」がどう分かれているか
• 会話・実行・プロバイダのセッションを、どんなデータで管理しているか
• インストール、プロバイダの認証、遠隔接続、常駐化、更新の手順

この記事の全体像。以下、順に解説します。

T3 Codeとは

T3 Code は、コーディングエージェントのための制御画面です。README は自身を "agent harness control surface" と呼んでいます。開発者向けの AGENTS.md は、Claude Desktop、Codex App、Cursor Glass、Conductor の代わりになる "bring-your-own-subscription"、つまり利用者が自分の契約を持ち込む製品と位置づけています。

T3 Code の基本方針は、作業領域をサーバ側に置くことです。

• プロバイダのプロセス、ターミナル、Git、プロジェクトのファイルは、作業領域を持つサーバのマシンに残ります。
• リモートのクライアントは指示と表示だけを担います。
• クライアントは自分のファイルシステムや認証情報をサーバの代わりに使いません。

リポジトリは TypeScript のモノレポ @t3tools/monorepo で、ライセンスは MIT です。

T3 Code を理解するには、次の用語を押さえておくと便利です。

公式サイトは、スレッドごとにブランチを切り、差分を確認してから commit、push、プルリクエスト作成までを 1 画面で行える、と案内しています。独立したドキュメントサイトは無く、利用者向けの資料はリポジトリの docs/user/ にあります。

特徴

• 複数プロバイダ: Claude Code、Codex、Cursor、Grok Build、OpenCode、Antigravity を、既存の契約と認証のまま 1 つの画面から操作できます。インストール文書は Pi にも対応しています。
• トークンの再販なし: 認証とバイナリは、環境のマシンに置きます。
• 3 種類のクライアント: Web（app.t3.codes とローカル配信）、Electron デスクトップ、モバイルがあります。
• 遠隔接続の手段: LAN のペアリング、Tailscale HTTPS、SSH、T3 Connect（リレー）を使い分けます。
• イベントログが正本: オーケストレーションの状態はイベントログで決まります。コマンドの受領は「意図が確定した」という意味で、プロバイダの作業完了とは別です。
• ブランチを汚さないチェックポイント: 利用者のブランチにコミットを足さず、隠し Git ref に作業領域を記録します。
• 権限モード: スレッドごとに Supervised、Auto-accept edits、Auto、Full access を選べます。新規スレッドの初期既定は Full access です。
• ソース管理連携: GitHub、GitLab、Forgejo、Gitea、Bitbucket、Azure DevOps に対応し、クローン、公開、プルリクエスト、レビューを扱います。
• テレメトリ: 製品の利用イベントを PostHog へ送ります。プロンプト本文や会話 ID は含みません。T3CODE_TELEMETRY_ENABLED=false で停止できます。
• フォーク可能: MIT ライセンスなので、フォークして UI やプロバイダを変えられます。README は、まだ初期段階のため大きな機能の貢献は原則として受け付けていない、と書いています。

類似製品との位置づけ

README と AGENTS.md が名指しする類似製品との関係です。一次資料に性能の実測値は無いため、ここでは位置づけだけを比べます。

Orca との違い

既存の CLI 契約を持ち込んで 1 つの画面にまとめる MIT ライセンスの製品には、Orca もあります。Orca の構造は「複数のCLIエージェントをworktreeで並列に走らせるADE Orcaの構造と使い方」で解説しています。両者は目的が近い一方、中心に置くものが違います。

• T3 Code は、エージェントとの**会話（スレッド）**を中心に置く制御画面です。
• Orca は、タスクごとの worktree と端末を中心に置く ADE（Agent Development Environment）です。

どちらも、初期設定ではエージェントに承認なしで操作させます。チームで使うときは、どちらの製品でも権限の既定を見直します。

使い分けの目安は次のとおりです。

ユースケース

構造

作業領域を所有するのは環境サーバです。クライアントは認証済みの RPC でサーバに指示します。Desktop のレンダラも同じ境界に従います。

システムコンテキスト図

コンテナ図

SSH と Tailscale は、環境サーバに到達するための手段です。ACP や Codex の app server を包む Effect ラッパは、プロバイダプロトコルとの境界に置かれます。

コンポーネント図

環境サーバの内部では、オーケストレーション v2 の部品が次のようにつながります。

この構造には、時間の扱いに関する重要な性質があります。

• コマンドの受領は、プロバイダの作業、チェックポイント作成、差分計算の完了を含みません。
• プロバイダのターン終了と、その後の確定は別のマイルストーンです。
• 差分の計算が遅れても、記録済みのプロバイダ所要時間は延びません。

データ

オーケストレーション v2 は、利用者に見える会話と、プロバイダ固有の会話ハンドルを分けて管理します。

• 同一性を決めるのはアプリ側の ID です。プロバイダ側の ID は、対応づけのための証拠として扱います。
• 確定したイベントには、ストアが単調増加の sequence を振ります。
• クライアントはスナップショットの snapshotSequence をカーソルにし、それより大きい sequence のイベントだけを適用します。
• プロバイダから届く生のフレームは、アプリ状態の正本ではありません。

概念モデル

AppThread と ProviderThread を分けているため、同じ会話の途中でプロバイダを切り替えたり、別プロバイダへフォークしたりできます。

情報モデル

次の図は、設計文書の型スケッチを packages/contracts/src/orchestrationV2.ts の現行フィールド名に寄せた抜粋です。図の読み方の補足は次のとおりです。

• IdentityBinding は entity-ids-and-correlation.md に書かれた対応づけの概念で、現行の OrchestrationV2 の構造体にはありません。
• Checkpoint.kind は、現行の型では CheckpointScope.kind です。
• ContextHandoff の対応フィールドは strategy です。

会話と実行の側（Project から RuntimeRequest まで）です。

プロバイダとの対応づけ、コンテキスト転送の側です。

永続ファイルの配置

永続ファイルの場所は apps/server/src/config.ts の deriveServerPaths が決めます。既定のベースディレクトリはホームの .t3 です（os-jank.ts）。

待受ポートはモードで変わります。デスクトップモードはポート未指定なら DEFAULT_PORT の 3773 をそのまま使います。web モードは 3773 から空いているポートを探します。設定用の環境変数は次のとおりです。

• ポート: T3CODE_PORT
• ホスト: T3CODE_HOST
• データディレクトリ: T3CODE_HOME または --base-dir

構築方法

前提

• スレッドを始める前に、プロバイダを 1 つ以上インストールして認証します。アプリを先に起動して、あとから Settings で足すこともできます。
• CLI の t3 は ~/.local/bin に入ります。シェルの PATH にこのディレクトリが含まれている必要があります。
• Intel Mac 向けの t3 実行ファイルはありません。デスクトップアプリを使うか、Node.js 24 と vp でソースからサーバをビルドします。
• ソースからビルドする場合の Node は ^24.13.1 です。Bun は任意です。

CLI をインストールする

安定版は次のコマンドで入れます。

curl -fsSL https://t3.codes/install.sh | sh

Windows の PowerShell では次のコマンドです。

irm https://t3.codes/install.ps1 | iex

ナイトリー版や版の固定は、インストーラを実行するシェルの環境変数で指定します。パイプの右側の sh が読めるように、先に export します。

export T3CODE_CHANNEL=nightly
curl -fsSL https://t3.codes/install.sh | sh

export T3CODE_VERSION=0.0.42
curl -fsSL https://t3.codes/install.sh | sh

インストールせずに 1 回だけ試すときは、Node.js 上で npx t3@latest を使います。

デスクトップとモバイルを入れる

• .deb 版の更新はパスワードプロンプトを使います。プロンプトが出ないデスクトップ環境では、新しい .deb を同じ手順で入れ直します。
• WSL をエージェントの実行先にするときは、Settings の Connections でディストロを選びます。プロバイダの CLI は、そのディストロの中に入れます。

Intel Mac でサーバをビルドする

Intel Mac 向けの t3 実行ファイルはありませんが、デスクトップアプリはあります。サーバをソースから動かす公式手順は次のとおりです。

git clone https://github.com/pingdotgg/t3code
cd t3code && vp i && vp run build:desktop
node apps/server/dist/bin.mjs

この方法では t3 update とバックグラウンドサービスを使えません。更新は git pull と再ビルドで行います。

ソースから開発起動する

まず vp を入れます。

curl -fsSL https://vite.plus | bash

Windows では irm https://vite.plus/ps1 | iex です。チェックアウト後に次を実行します。

vp i
vp run dev

• 開発ランナーが表示するペアリング URL を開きます。オリジンの URL だけでは、新しいブラウザは認証されません。
• デスクトップアプリの開発起動は vp run dev:desktop です。
• ポートは [dev-runner] の出力で確認します。

開発時の状態の置き場所は、起動方法で変わります。

本番データの ~/.t3/userdata を、開発サーバの対象にしないようにします。

利用方法

起動、認証、権限、遠隔接続、ソース管理は、どれもエージェントが動く環境のマシンを基準にします。クライアントは指示と表示を担い、資格情報の保存先にはなりません。

起動コマンド

• t3 app は、同じマシンでデスクトップアプリが動いている必要があります。スタンドアロンのサーバや SSH セッションだけでは動きません。パスを渡す例は t3 app ../my-project です。
• デスクトップモードの待受ホストの既定は 127.0.0.1 です。web モードはホスト未指定です。
• Tailscale Serve の HTTPS ポートの既定は 443 で、--tailscale-serve-port で変えられます。

プロバイダを認証する

Settings → Providers → 対象の環境、の順に開いて、プロバイダを有効にします。スマートフォンから接続していても、インストールとログインは環境のマシンで行います。

• CLI はサーバの PATH 上に必要です。見つからないときは Binary path を指定します。
• Cursor の実行ファイル名は cursor-agent で、ログインコマンドは agent login です。
• ChatGPT 接続の Codex と Antigravity は、PATH を必要としないマネージドランタイムを使えます。

別のアカウントは、別のプロバイダインスタンスとして登録します。インスタンスごとに環境変数を持てます。秘密値を sensitive にすると、保存後は元の値を表示しません。

スレッドと権限モード

コンポーザでモードを選ぶと、そのスレッドに適用されます。

• 新規スレッドの既定は Settings → General → New threads → Permissions で決めます。
• プロジェクトは環境の既定を上書きできます。
• 新規スレッドは、直前に見ていたスレッドのモードを引き継ぎません。
• 初期の既定は Full access です。

モードの効き方はプロバイダで異なります。

権限モードは、エージェントが課題について質問することは止めません。

プロバイダごとの接続の違いは次のとおりです。

• OpenCode は 1.14.19 以降が必要です。Server URL が空なら T3 Code がローカルサーバを起動します。既存のサーバを使うときは Server URL とパスワードを設定します。
• Pi は利用者の pi を使います。同じインスタンス内の再開、ロールバック、フォークは Pi のネイティブセッションファイルで行います。
• ACP Registry のエージェントは自分のツールを持ちます。チェックポイントのロールバックでファイルは戻りますが、会話は巻き戻せず、次のターンは新しいセッションになります。
• Codex は作業中に質問できます。回答はスレッドの質問パネルから行います。

リモートで接続する

T3 Connect

デスクトップでは Settings → Connections でサインインし、その環境で有効にします。CLI のホストでは次を実行します。

t3 connect

• サインインを保存しただけでは、外から到達できるようにはなりません。セットアップが勧めるバックグラウンドサービスを断ったときは、t3 serve でサーバを起動します。
• 別のデバイスからは、同じ T3 Connect アカウントで環境を選びます。
• SSH 越しでは、CLI がブラウザ用のリンクと短いコードを出します。コードが一致することを確認してから承認します。

T3 Connect の管理コマンドは次のとおりです。

t3 connect status
t3 connect login
t3 connect unlink
t3 connect logout

LAN、SSH、Tailscale

• LAN: デスクトップで Network access を有効にし、ペアリングリンクを作ります。変更するとデスクトップアプリが再起動します。ループバックの 127.0.0.1 は、リンクを開いたデバイス自身にしか届きません。
• app.t3.codes から接続する場合: 接続先に HTTPS の終点が必要です。ホスト型のペアリングリンクは、届かないバックエンドを到達可能にはしません。
• SSH: デスクトップの Settings → Connections → Add environment → SSH で追加します。リモートは Linux か Apple Silicon の Mac で、curl または wget、tar、sha256sum または shasum が必要です。初回はサーバ本体を ~/.t3/runtime へダウンロードします。
• Tailscale: t3 pair --tailscale の設定は再起動後も残ります。既定ポートの公開を外すコマンドは tailscale serve --https=443 off です。

操作専用のデスクトップにする

デスクトップを操作専用にするときは、Settings → Connections の Local environment をオフにします。

• ローカルサーバ、ローカルエージェント、WSL バックエンドが止まります。
• 他のデバイスからこのコンピュータへは接続できなくなります。
• プロジェクトと履歴は残ります。
• 同じ場所でオンに戻すと、以前のローカル設定で再起動します。

モバイルからの環境の更新は、Settings → Environments で環境を選び、Check for updates を押します。

T3 Connect のエラーと回復

Connect が恒久的な拒否を返した場合は、原因を直したあとホストのサーバを再起動します。

ソース管理を使う

Git の認証はサーバのマシンで行います。サインインしたら Settings → Source Control → Rescan を実行します。

gh auth login
glab auth login
az extension add --name azure-devops
az login

• 新規プロジェクトは ~/.t3/projects に Git リポジトリを作ります。
• コマンドパレットは Cmd/Ctrl+K で開きます。
• スレッドの Git 操作から、commit、push、プルリクエスト作成を行います。
• GitHub sharing は既定でオフです。Read PRs または Read and act は、信頼する環境ごとに Connections で有効にします。

Web、デスクトップ、モバイル、環境サーバは、それぞれ別々に更新されます。そのため、プルリクエストの紐づけ方はクライアントの版ではなく、環境ディスクリプタで決まります。

運用

常駐、更新、ログ、テレメトリ、待受ポートは、いずれもホスト側で行う操作です。サービスを再起動すると、実行中のターンとリモートクライアントは中断されます。

バックグラウンドサービス

Linux と macOS では、利用者単位のサービスとして常駐させられます。Windows にバックグラウンドサービスはありません。

• サービスを外しても、プロジェクト、スレッド、設定は残ります。
• t3 uninstall は、確認のあとランチャとダウンロード済みのバージョンを削除し、~/.t3/userdata は残します。スクリプトからは --yes を渡せます。
• Linux は systemd のユーザサービスです。ログアウト後も動かすには lingering を有効にします。
• macOS ではログイン中だけ動き、ログアウトすると止まります。画面に誰もログインしていない状態で SSH から導入すると、最後の起動で失敗することがあります。その場合もサービス登録は残り、次のログインで起動します。
• T3 Connect からサインアウトしても、サービスは止まりません。

チャネルと更新

t3 update は、現在のチャネルの最新版へ切り替え、サービスを再起動する前に確認を求めます。

• 確認を断ると、t3 service restart するまで旧版のまま動きます。
• 手動で起動したサーバは動き続けます。止めてから、同じオプションで起動し直します。

t3 update
t3 update 0.0.42
t3 update --channel nightly
t3 update --allow-downgrade

preview はメンテナ向けの試験チャネルです。更新候補には表示されず、入れるときに確認が求められます。

クライアントとサーバでオーケストレーションプロトコルの版が違うと、片方だけ上げた状態では接続できません。

• 新しいアプリは、古いサーバへ接続する前に止まります。
• 新しいサーバは、古いアプリからの接続を拒否します。
• 通知が名指しした側を更新します。

サーバをクライアントの版に合わせるには、ホスト上で次を実行します。

t3 update <client-version>

npx で動かしているサーバには、更新対象のバイナリがありません。サーバを止めて、npx t3@<client-version> に同じサブコマンドとオプションを付けて起動し直します。サービスの更新に失敗すると、前の版に戻ることがあります。

Settings → General → Continue threads after restarts は既定でオフです。有効にすると、更新、クラッシュ、マシン再起動のあと、再開情報を持つスレッドを続けられます。自動起動そのものは有効になりません。旧オーケストレーションから更新した場合、会話の記録は残りますが、実行時の履歴がすべて引き継がれるわけではありません。

ログと状態を確認する

• t3 service status がログのパスを表示します。
• Linux では、導入済みのサービスが running、enabled、ログアウト後も許可されているかを確認します。壊れていると表示されたら、もう一度 t3 service install を実行すると修復されます。
• プロバイダの診断ログは、ライフサイクル、応答、失敗を残します。トークン差分と重複フレームは落とし、機密値はマスクします。
• 診断ログのエンコード上限は 64 KiB です。これを超えるペイロードは、経路識別子、メソッド、ステータス、エラーフィールドを残した構造要約になります。

フォークして開発している場合は、変更したファイルに対して次を実行します。

vp test run <files>
vp lint <files>
vp run --filter <package> typecheck

ネイティブのモバイル変更には vp run lint:mobile、リポジトリ全体の未使用コード検査には vp run knip:check を使います。

テレメトリを止める

サーバは、ハッシュ化したアカウントまたはインストールの識別子に紐づけて、利用イベントを PostHog へ送ります。

止めるには、起動前のサーバ環境に次の変数を置きます。

T3CODE_TELEMETRY_ENABLED=false t3 serve

ポート、データ、観測の設定値

OpenTelemetry へのエクスポートは、トレース、メトリクス、ログで同じサービス識別子を使います。

• 終点 URL はシグナルごとに分かれます: T3CODE_OTLP_TRACES_URL、T3CODE_OTLP_METRICS_URL、T3CODE_OTLP_LOGS_URL
• プロトコル、ヘッダ、export interval は 3 シグナルで共通です。

ベストプラクティス

認証はホストのマシンで済ませる

リモートのスマートフォンやブラウザは、指示を出すだけの端末です。プロバイダの CLI、Git、GitHub CLI は、エージェントが動く環境の PATH に置き、非対話のログインシェルからも見えるようにします。SSH 環境では、次のように確認できます。

ssh user@example.com 'sh -lc "command -v claude codex"'

新規スレッドの権限を明示する

新規スレッドの初期既定は Full access です。承認を前提に運用するチームは、Settings の New threads で Supervised か Auto に変更します。

• Grok で Auto-accept edits を選んでも、Supervised として動きます。
• OpenCode の Auto には AI レビューが無く、Supervised と同じ規則で動きます。
• 承認の範囲にも注意します。共有の外部サーバで他のセッションにも許可が広がるのは Allow for workspace です。単一の要求だけを許すのは Allow once です。

開発データと本番の userdata を分ける

• vp run dev は、メインチェックアウトでベースを明示しないとき ~/.t3/dev/statev2.sqlite を使います。
• --home-dir を指定するとそのディレクトリがベースになり、状態は配下の userdata に入ります。
• worktree は、自分の .t3/userdata を既定にします。
• 本番の ~/.t3/userdata を開発サーバに向けないようにします。
• 暗黙の開発トレースは ~/.t3/dev/logs/server.trace.ndjson に出ます。
• 使い回す開発用の認証トークンは、そのホスト名の全ポートへクッキーが送られる前提で扱い、コミットや公開ログに出さないようにします。

更新は通知が指したマシンで行う

• クライアントだけを新しくしても、古いサーバには接続できません。
• リモートの更新が進行中のときは、完了を待ってから t3 update します。
• サービスの再起動は、実行中のターン、ターミナル、リモートクライアントを中断します。続けたいスレッドがあるなら、更新前に Continue threads after restarts を有効にします（対応している環境のみ）。

リレーと直結を使い分ける

ソース管理の資格情報は環境に置く

• GitHub sharing の Read and act は、元の環境の資格情報より広い GitHub 権限を使うことがあります。自分が管理する環境だけで有効にします。
• Bitbucket のトークンは保存後に再表示されません。置き換えるときは新しい値を入力します。

注意点

公開資料どうしや、資料と実装の間には、次のような食い違いがあります。設定や手順を探すときの参考にしてください。

トラブルシューティング

起動できない

• PATH とインストール先を分けて確認します。CLI は ~/.local/bin/t3、データは ~/.t3/userdata、SSH の初回で入るサーバ本体は ~/.t3/runtime です。
• Intel Mac で CLI が無いことと、デスクトップアプリの有無は別の問題です。
• npx t3@latest には Node.js が必要です。インストールした t3 とは更新の手順が違います。

接続できない

• ペアリングリンクのアドレスが、それを開くデバイスから到達できるかを最初に確認します。
• プロトコル不一致の通知が出たら、見ている端末ではなく、通知が名指ししたホストを更新します。
• Connect の資格情報の更新に失敗しても、正常な会話そのものは切断されません。失敗はそのリクエストにだけ残ります。
• セッションのアクセス資格が期限切れになっても、開いている接続は一覧に残ります。

プロバイダと権限

• 互換性の警告が出たら、Settings → Providers の推奨バージョンを確認します。Update now は、インストーラの所有が確認できたときだけ表示されます。確認できない経路で入れた場合は手動で更新します。
• Homebrew で提供される版は、npm の最新より数時間遅れることがあります。比較するときは Homebrew が示す版を基準にします。
• 承認しても進まないときは、プロバイダの違いを確認します。Antigravity は Full access でもネイティブの承認要求を出すことがあります。Codex の非同期の質問には、保留中の RPC 応答ではなく、新しいユーザメッセージとして答えます。

ソース管理

• Bitbucket は、Settings に保存した資格情報か、起動中のサーバが見ている T3CODE_BITBUCKET_* を確認します。環境変数を変えたあとはサーバを再起動します。
• レビューが読み込めない間は、ホスティングサービスのサイトで権限と到達性を確認します。
• GitHub の viewed 状態は github.com と双方向に同期します。Forgejo、GitLab、Bitbucket、Azure DevOps の viewed は接続中のサーバにだけ残り、ホスティングサイトには反映されません。
• Code タブは Web と Desktop にあります。モバイルは状態を表示しますが、差分は表示しません。

まとめ

• T3 Code は、自分のマシンで動く複数のコーディングエージェントを、Web・デスクトップ・モバイルから 1 画面で操作する MIT ライセンスの制御画面です。
• 作業領域、資格情報、プロバイダのプロセスは環境サーバに置き、クライアントは指示と表示だけを担います。
• オーケストレーション v2 は、イベントログを正本とし、利用者に見える会話（AppThread / Run）とプロバイダ固有のハンドル（ProviderThread / ProviderTurn）を分けて管理します。
• 遠隔接続は LAN、Tailscale、SSH、T3 Connect から選べます。app.t3.codes から接続するときは HTTPS の終点が必要です。
• 運用では、新規スレッドの既定が Full access であること、開発データと本番の userdata を分けること、クライアントとサーバのプロトコル版を揃えることが要点です。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

公式サイトと配布

• T3 Code
• app.t3.codes
• GitHub pingdotgg/t3code
• Releases
• iOS
• Android
• Discord
• Orca: What is Orca?
• Orca: Supported agents
• stablyai/orca

利用者向け文書

• Install
• Remote access
• Background service
• Updating
• Permission modes
• Source control
• Telemetry

内部構造とデータ

• Architecture overview
• Glossary
• Providers
• Core graph and data model
• Entity IDs
• Provider capability system
• Development
• AGENTS.md
• Server config deriveServerPaths
• Default home directory