讓 T3 Code 住進 Dev Container

tags: T3 Code, Dev Container, WSL2, AI

category: AI

description: 讓 T3 Code 住進 Dev Container

created_at: 2026/10/05 16:00:00

前言

現在開發幾乎都是讓 AI Agent 去實作，一個專案丟出去之後就是等，等的時候當然不會乖乖看著它跑，會一邊做著其他事情，可能是再開第二個專案、第三個專案...，然後就變成同時開著 5 個甚至更多的 VS Code 視窗，一個螢幕只有一個是放大視窗，其他都堆疊上來，看到所有專案的狀態，然後切來切去，切到最後根本忘記哪個視窗在等我回覆，搞得很累。然後電腦的 RAM 也很快就被吃光了...。

於是就開始找有沒有工具可以把多個專案的 Agent 集中在同一個畫面管理。

另外還有一個次要的需求：我想試試看用手機遠端操作 Agent 繼續開發。先前出門在外想讓 Agent 繼續做事，都要很克難地用遠端桌面連回電腦，在手機的小螢幕上操作整個桌面，非常不方便。

不過我有一個前提：只要是認真要開發的專案，我的 Agent 都是跑在 Dev Container 裡面的(隨手試東西的那種就不一定)，畢竟我是個很不喜歡汙染宿主環境的人(上一篇也提過)，也不太放心讓 Agent 直接在宿主環境到處跑。

而我最後選的 T3 Code 並沒有直接支援 Dev Container，所以就有了這篇文章，以及這次實驗的三個產物：

1. 一個 Dev Container Feature：devcontainer-t3code
2. 一支放在 WSL 的小工具 t3-dev(在同一個 repo 裡)
3. 一份繁體中文版的 T3 Code 文件

先說在前面，這篇從頭到尾都還在「實驗」階段，我還沒有拿它正式開發過專案(現在才要開始嘗試)，所以好不好用、穩不穩，等之後用久了有心得再來補(?)

事前準備

如果你想跟著玩，需要：

• Windows + WSL2，且 Docker 是裝在 WSL2 裡面
• VS Code 與 Dev Containers 擴充功能
• T3 Code 桌面版(本文測試時是 0.0.45)
• 一個 Claude 或其他 Provider 的訂閱

這篇的環境比較特定，如果你是 macOS 或是直接在 Linux 上開發，Feature 本身還是能用，但 t3-dev 這支小工具是針對「Docker 在 WSL、T3 Code 在 Windows」寫的；等有空再拿起 Mac 來做實驗補充。

為什麼不是 herdr

在找工具的時候，其實有兩個候選：herdr 和 T3 Code。

其實 herdr 也能解決我的主要問題：一樣可以同時開很多個專案，每個 Agent 現在的狀態也是一目了然。

單就主要需求來說，兩個都做得到，差別在於 herdr 是 TUI，T3 Code 是 GUI。

所謂工欲善其事，必先利其器，但「利」不代表一定要選比較硬派的那個(?)。除非 TUI 更能解決我的需求，或是這件事只有在終端機才做得到，不然有 GUI 能解決需求、操作又簡單，我覺得也算是符合 KISS 原則(?)，像是看 diff 這種事情我還是習慣有個畫面。

所以最後選了 T3 Code。

補充：herdr 我只看過官方文件，並沒有實際使用，所以這段比較的只是「工具的型態」，不是在評論它好不好。

T3 Code 是什麼

T3 Code 簡單說就是一個幫你管理多個 Coding Agent 的 GUI，它本身不是 Agent，而是去操作你已經安裝好的 CLI(例如 Claude Code、Codex)，所以用的是你自己的訂閱。

它的功能其實不少，這裡列一些我在文件和實驗中看到的(有些我只有稍微試一下，有些只看過文件)：

• 多個專案、多個 Thread 在同一個視窗，哪個在跑、哪個在等你一目了然
• Queue 與 Steer：Agent 還在跑的時候可以先排下一句話，或是直接插話修正方向
• Worktree：同一個專案開多條線同時做，互不干擾
• Diff 面板：可以看工作目錄的變更、整個分支的變更，或是只看最近一輪對話改了什麼
• 多種 Provider：同一個介面可以切換不同家的 Agent
• 遠端：除了本機之外，也可以連到別台機器上的環境，方式包含 SSH、區域網路配對、Tailscale，以及官方提供的 T3 Connect
• 手機：有原生的 App，可以用手機連回電腦看進度、回覆 Agent
• 其他像是 PR 相關的操作、用量頁面、排程任務等等

題外話：興沖沖地想裝手機 App 的時候才發現它要求 iOS 18，而我的手機還是 iPhone 8 Plus(iOS 16)，直接被擋在門外。不過看起來還有其他方式可以從手機連回去，這部分之後再來實驗。

至於架構上，它分成兩個部分：

┌───────────────┐          ┌────────────────────────┐
│ 桌面程式(GUI) │ ───────► │ server + 你的 Agent CLI │
└───────────────┘          └────────────────────────┘
                              ↑ 這一包叫做 environment

桌面程式負責畫面，真正去跑 Agent 的是一支叫做 server 的程式，而 server 所在的地方就稱為一個 environment。

平常你只裝桌面版的話，它會在背景自己跑一個 server，那就是「本機」這個 environment；而所謂的遠端，其實就是在另一個地方再跑一個同樣的 server，然後讓桌面程式連過去。

換句話說，只要想辦法讓 server 跑在 Dev Container 裡面，Agent 就會乖乖待在容器裡了。

聽起來很簡單對吧

用之前，先看了一下安全性

畢竟這類工具需要登入自己的 Agent 帳號，又會碰到我的專案，而我自己也算是比較在意資安的人，所以在安裝之前，先請 AI 幫忙把整個 codebase 掃過一輪，做了一點調查。

而且我連「掃 codebase」這件事都不太敢直接來，因為用 VS Code 打開一個不熟的專案然後按下信任，本身就有點風險，更何況還要放 Agent 進去讀。

所以我的做法是：程式碼從頭到尾都不落在宿主環境，把專案只在 Dev Container 開起來，Agent 也只在這個容器裡面讀，這樣不管 repo 裡有什麼，都被隔在容器內。

至於調查的結果，先講結論：

在我的 Agent 看的範圍內，沒有看到惡意行為，也沒有看到主動把 prompt 或程式碼上傳的程式。

不過還是有幾點是我自己使用時會留意的，這裡保守地提一下，並不是要說它不好：

• 預設權限偏寬鬆：新的 Thread 預設是 Full access，建議自己改成比較保守的模式。
• T3 Connect：這是官方提供的遠端連線服務，很方便，但連線會經過官方的基礎設施，似乎並不是端對端加密，等於需要多信任一方。它預設是關閉的，不登入就不會啟用，所以我目前選擇先不用，有遠端需求的話會先考慮其他方式。
• Agent 碰得到的範圍：Agent 能讀寫的範圍，基本上就是 server 所在的那個環境。直接用本機的話，那就是我在電腦上碰得到的所有東西；而把 server 放進容器之後，範圍就只剩那個容器，而且每個專案各自有一個 server，彼此也是分開的。這也是我想讓它住進 Dev Container 的主要原因。

另外要強調幾件事：

1. 這只是請 AI 讀原始碼的靜態檢查，沒有實際做攻擊測試，我也不是資安專家。
2. T3 Code 還在非常早期的 Alpha 版本，變動很快，上面這些很可能過一陣子就不一樣了。

所以請把這段當成「我自己的使用筆記」就好。能這樣把原始碼攤開來讓人看，本身就是開源專案最好的地方，也希望它之後越來越好。

踩坑紀錄

如果你只想知道怎麼用，可以直接跳到下一段。

第一版：每個容器開一個 Port

最直覺的做法：在容器裡把 server 跑起來，把 port 發布出來，然後在 T3 Code 用配對連結加進去。

兩個專案的時候看起來很美好，直到某一次連不上。

查了一下抓到兇手：VS Code 會自己去佔用它覺得需要轉發的 port，連別的視窗的容器的 port 也一起佔，而且視窗關掉、容器停掉之後還繼續佔著。

這大概也只有在 Windows + WSL2 這種組合才會遇到，中間多轉了一手，Windows 雷就是特別多 XD

再加上每個專案都要自己記一個 port、每個容器都要配對一次，專案一多肯定會亂掉，所以這條路就放棄了。

第二版：改用 SSH

T3 Code 有另一個連線方式是 SSH，它會自己連進去、自己把 server 裝好跑起來。

但我的容器又沒有開 SSH，而且我也不想為了這個在每個容器裡跑一個 sshd、再去管金鑰。

後來想到一件事：既然我本來就能 docker exec 進容器，那 SSH 的連線直接走 docker exec 的標準輸入輸出就好了：

Host t3-myproject
    User vscode
    ProxyCommand wsl.exe -d Ubuntu -- docker exec -i -u root <container> <啟動一次性的 sshd>

這樣容器不用開任何 port，也沒有常駐的 sshd，更不需要金鑰 —— 畢竟能 docker exec 的人本來就已經能對容器為所欲為了，再加一把金鑰也擋不住誰。

第三版：Diff 面板是空的

SSH 連上了，Agent 也會動了，結果 Diff 面板顯示沒有變更，但 git status 明明就有。

這裡的主角是前面提到的 server(容器裡的那一個，不是桌面版在本機背景跑的那個)：它只會提供「自己啟動時所在目錄」底下的 diff。

而 T3 Code 透過 SSH 幫你啟動 server 時，是從家目錄啟動的，但 Dev Container 的專案通常不會放在家目錄底下(以 VS Code 來說預設是掛在 /workspaces)，於是就看不到了。

好在 T3 Code 連進去時，如果發現已經有 server 在跑就會直接沿用，所以解法就是：在容器啟動時，先自己從 / 把 server 跑起來，這樣不管專案放在容器的哪裡都涵蓋得到。

看到「從根目錄啟動」可能會有點怕，這裡稍微解釋一下：

• 啟動目錄影響的只是 server 願意提供 diff 的範圍，並不會改變 Agent 的工作目錄，每個專案還是在自己的資料夾裡做事。
• server 一樣是用容器裡的一般使用者身分執行，不是 root，權限沒有變大。
• 這個 / 是「容器的」根目錄，範圍還是在容器裡面，而容器裡的東西 Agent 本來就都讀得到。

所以實際上並沒有多開放什麼，只是讓 Diff 面板能正常運作。

到這裡東西已經多到不適合再用腳本複製貼上了，於是就決定包成 Dev Container Feature。

最後的做法

整理一下最後長這樣：

Windows                    WSL2                        Dev Container
┌──────────┐  ssh.exe  ┌──────────┐  docker exec  ┌──────────────────────┐
│ T3 Code  │ ────────► │  t3-dev  │ ────────────► │ t3 server + Agent    │
└──────────┘           └──────────┘               │ (只聽 127.0.0.1)     │
                                                  └──────────────────────┘

• Feature(t3-server)：裝在每個 Dev Container 裡，負責安裝 server、容器啟動時把它跑起來
• t3-dev：裝在 WSL，負責把每個容器登記成 Windows 看得到的 SSH 主機

1. 專案加上 Feature

在專案的 devcontainer.json 加上：

"features": {
  "ghcr.io/laijunbin/devcontainer-t3code/t3-server:0": {}
}

這個 Feature 只負責 T3 Code 的 server，並不會幫你裝 Agent 的 CLI，因為不是每個人都用同一家，要裝哪個應該由專案自己決定。

以我用的 Claude Code 來說，官方已經有現成的 Feature，加在一起就好：

"features": {
  "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {},
  "ghcr.io/laijunbin/devcontainer-t3code/t3-server:0": {}
}

2. 在 WSL 安裝 t3-dev

只需要做一次：

curl -fsSLO https://github.com/laijunbin/devcontainer-t3code/releases/latest/download/t3-dev
bash t3-dev setup && rm t3-dev

它會在 Windows 的 .ssh/config 加上一行 Include(原本的檔案會先備份)，並且裝一個背景服務，之後容器啟動、停止時清單都會自動更新。

3. 在 T3 Code 加入

重建容器之後，到 T3 Code 的 Settings → Connections → Add environment → SSH，下拉選單裡就會出現 t3-<資料夾名稱>，選下去就好了。

想知道目前有哪些容器可以連：

$ t3-dev list
  HOST              T3 CODE NAME      STATE    CONTAINER     FOLDER
  t3-my-blog        t3-my-blog        running  2cf4fc878917  /home/user/my-blog
  t3-my-api         t3-my-api         running  613da7c37803  /home/user/my-api

每個專案都自動套用

如果你跟我一樣懶得每個專案都去改 devcontainer.json，可以直接寫在 VS Code 的使用者設定：

"dev.containers.defaultFeatures": {
  "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {},
  "ghcr.io/laijunbin/devcontainer-t3code/t3-server:0": { "strict": false }
}

strict: false 的意思是遇到不支援的映像(例如 Alpine)就跳過，而不是讓整個容器建置失敗。

其他的選項、相容性與疑難排解都寫在 README 裡了，有中文版。

懶人包：之後我打算怎麼用

上面的設定都做完之後(t3-dev 裝一次、VS Code 的預設 Feature 設一次)，之後開新專案的流程預計會是這樣：

$ wsl
$ cd ~
$ mkdir my-project
$ code my-project

1. 在 WSL2 的原生檔案系統建立專案資料夾，用 VS Code 打開(理由請看上一篇)。
2. 加上 devcontainer.json，然後 Reopen in Container。因為有設定預設 Feature，這一步就會順便把 Agent 的 CLI 和 T3 Code 的 server 都裝好。
3. 第一次進容器時，在終端機登入 Agent(例如執行 claude)。
4. 打開 T3 Code，Add environment → SSH，選 t3-my-project。
5. 進到這個環境的設定，把新 Thread 的預設權限改成自己放心的模式。
6. 在 T3 Code 裡 Add project，選容器裡的專案資料夾，然後就可以開始丟工作了。

之後同一個專案只要容器有在跑，打開 T3 Code 就能直接接著用。

第 3 步的登入預設是存在容器裡的，重建容器就要重新登入。如果不想每次都登入，需要自己把登入資料放到 volume，這部分跟 T3 Code 無關，就不在這篇展開了，實際上也可以自己包一個專門的 Feature 一樣掛在使用者設定裡，就可以無痛地保留登入狀態，我自己有包，可是畢竟比較敏感，就不特別公開了，雖然只是單純的掛 volume..。

那 VS Code 的 Agents 視窗呢

其實很早就知道 VS Code 偷偷在上面放了一個 Open in Agents 的按鈕可以打開 Agents 視窗，定位看起來跟我的需求很像，只是一直沒有認真去試，這次就順便試了一下。

首先是 Dev Container 的部分，它在 Agents 視窗裡目前還是實驗性的功能，我這邊也確實遇到了一些問題，像是它找不到容器、或是容器起不來，試了好幾次、換了幾種開啟方式，最後才總算成功跑起來，也能在裡面跟 Claude 對話。

不過跑起來之後才發現更大的問題：它的 Claude 是個有點奇怪的版本，預設情況下請求是經過 Copilot 轉送的，計費也是算在 Copilot 那邊，而不是我自己的 Claude 訂閱。

後來查到 VS Code 那邊也有人回報一樣的狀況，並且後續有對應的修正，看說明是可以改成直接使用自己的憑證，但需要額外設定，而且似乎還有些問題QQ..

所以至少在我寫這篇的當下，它還不太符合我「在 Dev Container 裡、直接用自己的訂閱」的需求，就先放著，搞不好過幾個月這段就過時了。

當時參考到的資料：

• Use the Agents window
• Choose and use an agent harness
• Allow Claude Agent to run through Anthropic subscription instead of Copilot quota (microsoft/vscode #314952)
• Claude agent native transport (microsoft/vscode #323037)