OpenCode 分析：安全性漏洞與架構缺陷

OpenCode 是一款在 GitHub 上擁有超過 161k stars 的熱門開源 AI 編碼代理工具，但它存在嚴重的安全性漏洞與架構效率低下問題，使其在本地機器上使用時非常危險。該工具的安全機制僅基於對 bash 指令進行表面的文本過濾，而非強大的系統級沙箱機制，這導致其防禦能力不足，容易遭受輕易的遠端程式碼執行 (RCE) 與未經授權的檔案系統存取。

關鍵安全性漏洞

OpenCode 的安全模型存在根本性缺陷，它依賴於基於正則表達式 (regex) 的命令列字串過濾，而非限制實際的可執行檔或系統權限。

無效的 Bash 指令過濾

OpenCode 試圖透過使用 tree-sitter 將 bash 指令解析為 AST，並將節點與 regex 進行比對來防止特定指令（例如 git）執行。這種方法很容易被標準的 shell 技術繞過：

• 別名與環境變數繞過： 如 env git status 或 GIT=git && $GIT status 等指令可以繞過過濾器。
• 編碼繞過： 將 base64 編碼的字串透過管道傳遞給 bash（例如 echo Z2l0... | base64 -d | bash）可以執行被禁止的指令。
• 間接執行： 使用 python3 -c 呼叫 subprocess.run 來進行 git 操作，可以完全繞過過濾器。
• 路徑繞過： 使用絕對路徑 /usr/bin/git 而非指令名稱，可以避免被偵測。

損壞的檔案權限管理

OpenCode 實作了一套假設會存取檔案的指令「白名單」（FILES 列表），其中包括 rm、cp、mv 與 cat。任何不在該列表中的指令都被視為對檔案系統不會產生副作用。這使得代理工具可以執行 python3 -c 'import shutil; shutil.rmtree("/")' 而不會觸發權限請求，因為 python3 並不在 FILES 列表中。

此外，shell 重定向（例如 echo foo > bar.txt）在 AST 中被視為與指令同級的節點，這意味著路徑驗證邏輯並未應用於重定向目標，從而允許未經授權的檔案寫入。

遠端程式碼執行 (RCE) 風險

該工具過去曾出現嚴重的 RCE 漏洞。CVE-2026-22812 曾暴露了一個預設開啟且具有寬鬆 CORS 標頭的 HTTP 伺服器，並提供用於執行任意 shell 指令與讀取檔案的 API。雖然該伺服器現在預設已停用，但開發者先前曾建議為其自有網域維持 CORS 例外，以便在使用者機器上進行遠端執行。

效能與架構缺陷

除了安全性之外，OpenCode 對上下文管理 (context management) 的實作導致了嚴重的效能退化，特別是對使用本地 LLM 的使用者而言。

Prompt Cache Misses (提示詞快取失效)

本地 LLM 伺服器依賴提示詞快取 (prompt caching) 來避免昂貴的「預填充」(prefill) 計算。OpenCode 經常透過低效的提示詞建構方式導致這些快取失效：

• 動態系統提示詞： 在 turn-0 的系統提示詞中包含當前日期，會導致日期變更時（例如在午夜時分）發生完全的快取失效。

• 頻繁重新讀取： 該工具在每次 SSE turn 時都會重新讀取 AGENTS.md，如果檔案被修改，則會強制進行重新評估。

• 激進的修剪 (Pruning)： 在超過 40k token 閾值後修剪工具呼叫結果，往往會在代理與使用者之間的轉換期間刪除關鍵的早期對話上下文（例如規格說明），迫使模型運作時缺乏必要的資訊。

資源利用率低下

該工具的 TUI (Text User Interface) 以極高的資源浪費著稱，據報導使用高達 1GB 的 RAM 來渲染文字。此外，它也存在基本的 UX 失敗，例如訊息框中的換行處理錯誤，以及處理長訊息時呈現二次方級別的渲染效能問題。

代理互動與工具化

OpenCode 的代理功能通常不穩定或不符合直覺：

• 子代理管理： 使用者無法直接與子代理溝通；如果子代理進入了「兔子洞」(rabbit hole)，唯一的選擇就是終止該程序，並因此失去所有累積的上下文資訊。
• 權限疲勞： 系統會針對每一次在專案目錄之外的檔案存取請求使用者的權限。由於沒有「永不」選項——只有「是」、「否」或「總是」——使用者往往會習慣性地點擊「總是」，進而為該指令前綴（例如 echo）保留了永久的權限，從而製造了長期的安全性漏洞。

社群意向與反對觀點

雖然技術批判很嚴厲，但 Hacker News 上的社群回饋顯示，安全性著重於開發者與生產力導向的使用者之間存在分歧：

• 生產力 vs. 安全性： 部分使用者回饋 OpenCode 是他們使用過最有效率的工具架構，認為指令過濾是為了「引導」模型而非提供硬性的安全性邊界。

• 問題的普遍性： 幾位評論者指出，提示詞快取失效與基本的代理功能失敗，是許多 AI 工具架構（包括 Codex 與 Claude CLI）中常見的問題，暗示這這些是目前 AI 工具開發中的系統性問題，而非 OpenCode 特有的 Bug。

• 開發者回應： OpenCode 團隊的代表表示，許多最明顯的問題（包括工具呼叫修剪）正在 v2 版本中解決，並計畫透過新的系統提示詞方法來避免快取失效。

"I use (a particular version of) OpenCode for my own work, because it is so much better. Reading this post makes me sad. Because everything matches and explains the oddities I've seen and forgiven."

替代方案與緩解措施

作者主張反對將 Docker 成為編碼代理工具的主要安全性層級，理由是 root-service 風險與防火牆漏洞。相反，作者建議使用原生 OS 建構塊，如 Landlock、Seatbelt 或 Restricted Tokens。其他社群成員建議使用 Flatpak/Bubblewrap/Flatseal 來限制代理環境的目錄權限。