Open Claude Cowork 評測：把 Claude Code 裝進桌面 Electron 介面

Facebook Line Messenger Telegram

Open Claude Cowork 把 Claude Code 從終端機搬進桌面 Electron 視窗，讓你看得到 AI 讀檔、寫檔、跑指令的每一步。概念很吸引人，原始碼也真的把這件事做出來了。實際把 repo 走一次後，本文記下兩個 README 沒說清楚但讀者安裝前應該先知道的事實：README 標榜的「敏感操作需明確批准」與 src/electron/libs/runner.ts 的實際設定有落差；README 與官網都印 MIT，但 GitHub 倉庫沒有 LICENSE 檔。再扣掉專案已六個月沒有新 commit、作者把心力轉到新產品 OpenAgen 的事實，這篇會給你一個明確的判斷：概念對、實作尚可、定位屬概念驗證，要實際裝來用有更穩的選擇。

把 Web 介面塞進桌面殼的思路有 Electron 與 Tauri 兩條路徑：Open Claude Cowork 走 Electron，若想看 Tauri v2 案例可參考我們整理的微信讀書桌面版評測——同樣是「網頁拉出成獨立視窗」，但安裝檔只有 4MB。

先給結論。Open Claude Cowork（以下簡稱 OCC）適合兩種人：想研究 Claude Agent SDK 怎麼從終端機介面包成桌面 app 的開發者，以及想親眼看到 AI 對檔案做每一步動作的使用者。如果你要的是日常可靠、有持續維護、權限機制有實際把關的桌面代理，同樣在 TechMoon 介紹過的 Coworker（accomplish-ai/coworker）才是更該裝的那一個。它 v0.5.17、MIT 授權、十倍以上的星數、有真團隊與法人、有實際的權限對話框。OCC 與它名字像、定位像，但是兩個完全不同的專案。

先分清楚：OCC 不是 TechMoon 先前介紹過的那個 Coworker

名字最容易搞混。OCC 的 repo 是 caiqinghua/Open-Claude-Cowork，282 顆星、42 個 fork、9 個 issue 全部 open、0 個 closed，作者 caiqinghua 一個人就佔了 8 次 commit。TechMoon 先前寫過的「Coworker 開源 AI 桌面代理」是 accomplish-ai/coworker（前身 Accomplish），10,879 顆星、MIT 授權、v0.5.17、有真團隊、法人 Accomplish Inc、授權對話框是真實作的。兩個專案都把 Claude Code 那套 AI 代理搬上桌面，都是「把終端機工具裝進圖形視窗」的概念，但規模、授權、成熟度、權限設計完全不同。

這條 cluster 我們已經寫過幾次。MindPocket 用 BYOK 模型把書籤變成知識庫、巴菲特股東信知識庫用 Claude Code 兩天搭出雙鏈檢索站，都是同一條「AI 代理 + 本地優先 + 自帶模型 Key」的設計脈絡。OCC 是這條脈絡裡規模最小的成員之一，定位在概念驗證，不是生產工具。

Open Claude Cowork GitHub 倉庫首頁，截至 2026 年 7 月顯示 282 顆星、42 個 fork，根目錄無 LICENSE 檔。 — Open Claude Cowork 的 GitHub 倉庫首頁（截至 2026-07-27），282 stars／42 forks，根目錄列表無 LICENSE 檔。

README 寫的，跟原始碼跑的不一樣

OCC 在 README 與官網都列出一段「Tool Permission Control」三句話：Explicit approval required for sensitive actions／Allow or deny per tool／Full control over what Claude is allowed to do（官網中文版譯為「敏感操作需明確批准／完全掌控 AI 行為」）。字面解讀是：AI 要動你的檔案、跑 shell 指令、寫新檔之前，會先跳一個對話框問你。讀者看到這段，自然會把它當成安全護欄。

把 src/electron/libs/runner.ts 抓出來看，實際行為與這段描述有顯著落差。OCC 透過官方 @anthropic-ai/claude-agent-sdk 啟動每次查詢，設定是這樣的：

permissionMode: "bypassPermissions",
allowDangerouslySkipPermissions: true,
canUseTool: async (toolName, input, { signal }) => {
  if (toolName === "AskUserQuestion") { /* 跳對話框等使用者回應 */ }
  // Auto-approve other tools
  return { behavior: "allow", updatedInput: input };
}

意思是：除了 Claude 自己呼叫 AskUserQuestion（AI 反過來問使用者某個問題）這一個工具會跳對話框外，所有寫檔案、刪檔案、跑 shell 指令的工具呼叫都會被自動同意。也就是說，AI 真的要刪你授權資料夾裡的檔案、要跑系統指令、要覆寫程式碼，OCC 都不會在執行前問你。README 寫的「explicit approval required」只對 AskUserQuestion 這一個工具成立，對其他工具不成立。

GitHub Issue #11 由使用者於 2026-07-08 獨立回報，指出 README 的 Tool Permission Control 段落與 runner.ts 的 bypassPermissions 設定不符。 — GitHub Issue #11（2026-07-08 開立，截至 2026-07-27 仍未回應）由一位讀者獨立發現並回報同一個矛盾。

這個結論不是只有我讀到。GitHub Issue #11 由一位法語讀者在 2026-07-08 獨立開出，標題就是「README claims explicit approval for sensitive actions, but code uses bypassPermissions」，內文附上同一段程式碼，問作者能否「更新 README 反映實際行為」或「實作真正的確認對話框」。到本文撰寫為止，這個 issue 仍未獲作者回應。也就是說，這個落差至少被兩位獨立讀者（issue 回報者與我）從不同路徑各自發現。

並不是說「自動同意」就一定是錯。Claude Code 自己在終端機模式下也是這樣設計，使用者要自己看著辦。問題在於 README 與官網明確給了「敏感操作需批准」的承諾，這個承諾與原始碼不一致。如果你照 README 的字面意思，把 OCC 當成一個「會在 AI 動手前先問我」的工具來用，那麼你對安全護欄的假設就是錯的。要 OCC 真的把護欄做起來，作者需要在 canUseTool 函式裡把寫檔、刪檔、跑 shell 這幾類工具也接上互動決策面板，而不是只接 AskUserQuestion。

README 寫的 MIT，與倉庫裡的 LICENSE 檔

實際把 repo 走一次會發現，倉庫根目錄沒有 LICENSE 檔。GitHub 的 license API 回 None；根目錄列表只有 README、package.json、bun.lock、electron-builder.json、src 等，沒有 LICENSE。package.json 裡也沒有 "license" 欄位，而且最上面寫 "private": true。法律上的實情是：原始碼公開陳列，但權利狀態未經有效文件授予。口頭說 MIT 不等同於有效授權，因為 MIT 的效力來自 LICENSE 檔全文（含版權聲明與免責條款）實際存在於 repo 裡。

這條軸我們在 Agent Battery 那篇談過：「GitHub 公開 ≠ 授權」。如果你想 fork OCC 改來做內部產品、甚至商用散佈，目前的法律追溯鏈是斷的。你只能假設「作者宣稱是 MIT」，但沒有有效文件可佐證。作者補一個 LICENSE 檔上去就解決，但截至本文撰寫，這個檔還沒有出現。

這個專案已經六個月沒有新 commit

活動度是另一個讀者該知道的事實。OCC 的 repo 在 2026-01-14 建立，main 分支最後一次 commit 是 2026-01-22（commit 訊息 add skill install times），之後將近六個月沒有新程式碼。中間雖然 GitHub 的 updated_at 一直在動，那是 star 數變動造成的 metadata 更新，不是實際程式碼推進。

Releases 頁面只有一個版本：v0.1.0，發布日期就是建倉當天 2026-01-14，且只有 mac 與 linux 兩個 binary asset。Windows 使用者要照 README 自己跑 bun run dist:win 編譯，沒有官方下載包。Issue #3（2026-01-23）就是 Windows 使用者問「為什麼沒有 Windows 安裝包」，至今未獲回應。

9 個 issue 從 2026-01-21 一路開到 2026-07-21，0 個 closed、0 個作者回應。最近一個 issue（#12，2026-07-21）是「claude desktop collapses and won’t stay open」，視窗打開就崩。這是讀者裝來實際跑會遇到的狀況，但目前沒有作者修。其他 issue 還包括 #4 讀者反映執行階段出錯、#6「JavaScript error」、#8「Failed to get session title error」、#11「README claims explicit approval… but code uses bypassPermissions」，從安裝、執行到文件一致性都有人反映問題，全部掛著無人理。

Open Claude Cowork 官方網站 openclaudecowork.com 中文版首頁，頂部 hero 區已改推新產品 OpenAgen，OCC 介紹退居頁面下半部。 — openclaudecowork.com/zh 首頁頂部 hero 區塊已改推新產品 OpenAgen（openagen.com），Open Claude Cowork 的介紹退居頁面下半部。

更有意思的是，作者 caiqinghua 已經把心力轉到新產品。官方域 openclaudecowork.com/zh 頂部的 hero 區現在主打「認識 Agent Computer OpenAgen」，引流到 openagen.com 與 Discord；OCC 的介紹退居首頁下半部。同一個人或團隊行銷重心轉移到新產品本身沒有錯，但這說明 OCC 已經進入維護停滯期，不是仍在迭代的活躍專案。讀者搜「Open Claude Cowork」時會以為這是一個仍在更新的產品，實際上它停在 2026 年 1 月。

不過 OCC 的 App 層確實是本地優先

讀到這裡會覺得 OCC 一無是處，並不公平。它有做對一件事：app 層的本地優先在原始碼層級是真的。把 src/electron/main.ts 整個抓出來看，它就是純粹的 Electron 視窗加 IPC，沒有 auto-updater、沒有 Google Analytics、沒有 Sentry、沒有 PostHog、沒有 Firebase。grep 整個 repo 找 analytics、telemetry、tracking、Sentry、PostHog、UMeng、Firebase 全部 0 個 hit。也就是 OCC 不會把你的對話內容、操作紀錄、機器資訊回傳給作者。

AI 呼叫全部走官方 @anthropic-ai/claude-agent-sdk（package.json 指明版本 ^0.2.6），讀你電腦裡既有的 ~/.claude/settings.json。這是 OCC 在設計上最聰明的地方：你已經設定好的 Claude Code 環境（API key、base URL、模型偏好），OCC 直接用，零學習成本。所有 AI 請求都從你的機器出發，目的端完全由你的 settings 決定。它支援 Anthropic 官方模型，也支援任何 Anthropic-compatible 的第三方模型，README 列出的包括智譜 GLM 4.7、MiniMax 2.1、Moonshot Kimi、DeepSeek 等。

這條本地優先要打個但書。所謂「本地」是 app 層本地，不是模型層本地。如果你接的是 DeepSeek、GLM、Kimi 這類雲端模型，對話內容仍然會過那些 provider 的 API。這跟 MindPocket 講過的「資料儲存私有 ≠ AI 處理私有」是同一條邊界。要真正做到 AI 處理也本地，得把 OCC 接到 Ollama 或 LM Studio 跑本地模型。OCC 的 README 沒特別強調這條路由，但 Claude Code 的設定機制本來就支援。TechMoon 先前介紹的 Coworker（accomplish-ai）已經把 Ollama 與 LM Studio 列為正式支援的 provider，這是它比 OCC 更成熟的一個面向。

技術棧與架構：閱讀起來相當清爽

OCC 的 repo 很小（根目錄加 src 合計約 314 KB），技術棧現代，README 的架構表列得清楚：Electron 39 當外殼、React 19 加 Tailwind CSS 4 當 UI、Zustand 管狀態、better-sqlite3（WAL mode）存 session 歷史、Vite 與 electron-builder 打包。資料層是 SQLite，存的是 session 對話與訊息內容，不上傳任何外部資料庫。src/electron/libs/ 下四個檔案構成核心：runner.ts 負責呼叫 Claude Agent SDK，session-store.ts 負責 session 持久化，skills.ts 負責 Claude Code skill 管理，claude-settings.ts 讀取既有 settings。想研究「官方 SDK 如何從零整合進桌面 app」的開發者，這個 repo 是一份很好的閱讀教材，因為它沒有多餘抽象層。

OCC 還有幾個有意思的設計。一是 session 工作目錄自訂：每次開新 session 你可以指定一個資料夾當工作目錄，AI 的所有檔案操作都限制在那個資料夾裡，這是天然的邊界。二是 即時 token 流式輸出：你看得到 Claude 的推理過程與工具呼叫狀態，比終端機模式更容易追蹤。三是 Skill 管理：最後一批 commit（2026-01-22）就是在做 skill 安裝與工作區管理，對應 Claude Code 的 skills 機制。這些都是「把終端機體驗裝進桌面視窗」這個概念真正付諸實作的部分。

誰該裝 OCC、誰該跳過

把上面幾件事兜起來，OCC 的定位就很清楚了。它是「把 Claude Code Agent SDK 包進 Electron」這個概念的單人實作練習。介面美、概念對、技術棧現代、原始碼好讀，適合用來研究「官方 SDK 怎麼從無到有做成桌面 app」。

幾種讀者可以考慮裝來玩：

想學 @anthropic-ai/claude-agent-sdk 怎麼整合進 Electron 的開發者，repo 小、依賴清楚、沒有多餘抽象層。
本來就在用 Claude Code、想看看「可視化版本」長什麼樣子的使用者，OCC 的對話視窗、token 流式輸出、session 管理介面是真的做出來了。
想貢獻 open source 並承接一個規模適中專案的工程師，作者轉做 OpenAgen，OCC 等於是個等接手的坑。

幾種讀者建議直接跳過：

要在生產環境把 AI 代理跑給團隊用的人，OCC 還在 v0.1.0、9 issues 0 回應、無活躍維護。
特別重視「AI 動手前要先問我」這條安全護欄的人，README 寫了但原始碼沒實作。
需要把專案 fork 改作商業產品的人，LICENSE 檔不在 repo 裡，授權追溯鏈是斷的。
單純想找一個好用的 Claude Code 桌面介面的人，Coworker（accomplish-ai/coworker）更穩、更成熟、授權清楚。

限制與風險一次列清楚

權限護欄與文件不一致：README 與官網稱敏感操作需批准，runner.ts 實際對所有工具（除 AskUserQuestion 外）自動同意。
無有效授權檔：README 與官網稱 MIT，repo 根目錄無 LICENSE 檔，package.json 無 license 欄位且標 private。
專案凍結：main 最後 commit 2026-01-22，9 個 issue 0 回應，無 Windows 官方下載包。
作者重心已轉移：官網首頁 hero 區改推新產品 OpenAgen。
BYOK 雲端邊界：app 層無遙測，但接雲端模型（DeepSeek、GLM、Kimi、Anthropic 等）時，對話內容會過那些 provider。
未親自部署實測：本篇第一手來源是原始碼、GitHub API、issue、官網渲染層級的觀察，不是裝起來跑任務的體驗紀錄。

授權與專案狀態

OCC 的程式碼公開陳列於 github.com/caiqinghua/Open-Claude-Cowork，README 與官網皆標示 MIT，但倉庫無 LICENSE 檔，package.json 亦未帶 license 欄位。專案活躍度方面，建立於 2026-01-14，main 分支最後 commit 2026-01-22，最新（且唯一）release 為 v0.1.0（2026-01-14），9 個 issue 全部 open。官方網站 openclaudecowork.com 仍上線，但首頁重心已轉向新產品 OpenAgen。

常見問題

Open Claude Cowork 跟 TechMoon 先前介紹的 Coworker 是同一個專案嗎？

不是。OCC 的 repo 是 caiqinghua/Open-Claude-Cowork，282 stars、單人作者、v0.1.0。TechMoon 先前介紹的 Coworker 開源 AI 桌面代理是 accomplish-ai/coworker（前身 Accomplish），10,879 stars、MIT 授權、v0.5.17、有真團隊。名字像、概念像，但規模、授權、成熟度差距很大。

OCC 真的會在我敏感操作前先問我嗎？

不會。雖然 README 與官網這樣寫，src/electron/libs/runner.ts 的實際設定是 permissionMode: "bypassPermissions"，除了 Claude 自己呼叫 AskUserQuestion（AI 反問你問題）外，其他工具呼叫（寫檔、刪檔、跑 shell）全部自動同意。這個落差在 GitHub Issue #11 已被獨立讀者回報。

OCC 是 MIT 開源嗎？

README 與官網都標 MIT，但 GitHub 倉庫沒有 LICENSE 檔，package.json 沒有 license 欄位且標示 "private": true。法律上屬於「原始碼公開但授權狀態未明確」，要用於商業或衍生產品建議先請作者補上 LICENSE 檔。

OCC 還在維護嗎？

main 分支自 2026-01-22 後沒有新 commit，9 個 issue 全部 open、0 個 closed。作者 caiqinghua 已把官方網站首頁重心轉向新產品 OpenAgen（openagen.com）。OCC 進入維護停滯期。

OCC 跟 Claude Code 的差別是什麼？

Claude Code 是 Anthropic 官方的終端機 AI 代理工具，OCC 是把 Claude Code 的底層引擎（透過官方 @anthropic-ai/claude-agent-sdk）包進桌面 Electron 介面的第三方實作。OCC 直接讀你的 ~/.claude/settings.json，所以 API key、base URL、模型偏好都共用。Claude Code 能做的事 OCC 大致都能做，差別在介面：OCC 有圖形視窗、token 流式輸出視覺化、session 管理介面；Claude Code 是純終端機。

相關閱讀：想看成熟的開源 AI 桌面代理，請讀 Coworker 開源 AI 桌面代理評測。同一條 BYOK 邊界在 MindPocket 開源 AI 書籤系統也討論過。對 Claude Code 生態有興趣，可參考巴菲特股東信知識庫用 Claude Code 兩天搭出雙鏈檢索站。