claude-devtools：把 Claude Code 藏起來的 session log 攤開來看
The missing DevTools for Claude Code — inspect session logs, tool calls, token usage, subagents, and context window in a visual UI. Free, open source.
秒懂
- 它是什麼？
- 它讀取 ~/.claude/ 底下既有的 session transcript，用 Electron 介面重建工具呼叫、thinking、token 歸屬與 subagent 執行樹。免設定、免 API key，但前提是你接受它只做「事後檢視」，而且目前只有 macOS 以外的平台得靠手動安裝。
- 適合誰用？
- 如果你已經在用 Claude Code，而且遇過「Read 3 files」這種摘要卻查不出到底讀了哪三個檔，claude-devtools 值得裝來試；它不碰你的 API 額度，只讀本機 log，風險低。反過來說，如果你要的是跨機器、跨團隊的長期追蹤，或需要 CI 內自動化的觀測，這個工具的定位是單機桌面檢視器，不是那一類方案。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 125 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
它要解的是終端機把細節收起來之後留下的空白
README 開頭直接點名問題：Claude Code 從 v2.1.20 起，把原本詳細的輸出換成不透明的摘要，例如 Read 3 files、Searched for 1 pattern、Edited 2 files，沒有檔案路徑、沒有內容、沒有行號。專案把這件事描述成「Claude 在盲寫程式」，而唯一的官方替代路徑是 --verbose，README 的說法是它會倒出原始 JSON、內部 system prompt 和數千行雜訊，兩者之間沒有中間選項。
這個工具鎖定的讀者很明確：已經在用 Claude Code、而且需要知道某一次 session 究竟發生什麼事的人。不是要寫 agent 框架的人，也不是要接 API 自己造觀測層的人。README 的措辭是它讀取「機器上已經存下來的 Claude Code log 與 session transcript」，也就是說它不攔截、不代理、不改寫你的請求，只是把既有檔案重新呈現。
機制：讀 ~/.claude/ 的紀錄，而不是掛進 Claude Code 的執行流程
從 README 能確認的架構是這樣：Claude Code 把 session 寫進 ~/.claude/，claude-devtools 讀這些檔案，再重建出終端機折疊掉的資訊。它是一個 Electron 桌面應用（topics 裡同時有 electron、desktop-app、macos-app），也可以走 Docker 以 standalone 形式部署，README 給的入口是 http://localhost:3456。
重建出來的東西分成幾類。工具呼叫層面，README 的對照表寫的是：Read 3 files 會展開成確切檔案路徑、帶行號且語法高亮的內容；Searched for 1 pattern 會展開成正規表達式、每一個命中的檔案與命中行；Edited 2 files 會展開成行內 diff，標出新增與刪除。thinking 層面，README 說 chain-of-thought 在終端機完全不可見，這裡則完整顯示。subagent 層面，README 描述為每個 agent 的完整執行樹，含工具追蹤、token、時長與成本。
context window 那一塊值得單獨講，因為它是這個專案最有結構性的設計。README 說它做的是「per-turn token attribution across 7 categories」，七類分別是 CLAUDE.md（全域、專案、目錄三種層級）、skills、@-mentioned files、tool I/O、thinking、team overhead、user text，並且搭配 compaction 視覺化。終端機只給三段式進度條，這裡給的是每一輪對話中，token 被誰吃掉的分解。還有一個容易被忽略的功能：per-project 的 Claude memory 藏在 ~/.claude/projects/.../memory/，README 說 MEMORY.md 會被渲染成可點擊的層級索引，任一層可以直接用你的編輯器打開。
安裝路徑：Homebrew、四種發行包、以及 Docker
macOS 使用者最短路徑是 Homebrew cask：
brew install --cask claude-devtools
不走 Homebrew 的話，README 要你去 releases 頁面依平台挑 asset。macOS 分 Apple Silicon 的 arm64 與 Intel 的 x64 兩種 .dmg，拖進 Applications 後首次啟動要右鍵 → 打開。Linux 提供 .AppImage、.deb、.rpm、.pacman 四種格式，按發行版選。Windows 是 .exe 標準安裝檔，README 提醒可能觸發 SmartScreen，要點「More info」→「Run anyway」。
Docker 路線對應 README 的 Docker / Standalone deployment 一節，指令是 docker compose up，起來之後開 http://localhost:3456。這一節在提供的素材裡被截斷，所以掛載 volume 的具體寫法、連接埠能不能改、有沒有環境變數可以指定 log 目錄，我無法從現有資料確認，要用的話得直接看 repo 裡的 compose 檔。
README 反覆強調的是「Zero configuration. No API keys. No wrappers.」這三句在架構上說得通：既然資料來源是本機檔案，確實不需要憑證，也不需要把 Claude Code 包一層。
真正的限制：它是事後檢視器，不是執行期觀測
最該講清楚的一點是資料來源決定了一切。claude-devtools 讀的是已經寫到磁碟的 session log，所以它看到的是「已經發生的事」。如果你的問題是「這個 agent 現在卡在哪裡」，或想在工具呼叫發生前攔下來、改寫參數、加一道審批，這個工具幫不上忙，因為它不在請求路徑上。
第二個限制是平台成熟度不對稱。topics 裡有 macos-app，README 的 macOS 段落寫得最具體（arm64 與 x64 分開、首次啟動要右鍵開啟），Windows 段落只有一句 SmartScreen 提醒。這不代表 Windows 不能用，但從文件密度看不出 Windows 上的實際體驗被驗證到什麼程度。
第三，Docker 部署那節在素材中不完整，所以遠端或團隊共用的情境我無法評估。如果 log 不在執行容器的那台機器上，就得靠 volume 掛載，而掛載的成敗完全取決於 ~/.claude/ 的實際路徑，這一點必須自己驗證。
還有一個不是缺陷但會被誤解的地方：README 說「Works with every session you've ever run」。這句話成立的前提是那些 session 還在 ~/.claude/ 裡、沒有被清掉。歷史紀錄被刪或輪替掉之後，這個工具沒有東西可以讀。
替代方案：ccusage 與 Langfuse，走的是完全不同的路
如果你要的只是花費與 token 的數字，ccusage 這類命令列工具是更輕的選擇。它同樣讀本機的 Claude Code 紀錄，但輸出是終端機裡的表格與統計，不開視窗、不裝 Electron。差別在於觀測的粒度：ccusage 回答「這個月花了多少、哪個專案最貴」，claude-devtools 回答「這一輪對話裡，是哪一類東西吃掉了 context」。前者是帳務視角，後者是除錯視角，兩者不衝突。
另一個方向是 Langfuse 這類 LLM observability 平台。它的做法是在應用端埋 SDK，把 trace、span、generation 送到伺服器，換來跨服務的關聯、團隊共享的儀表板與長期保存。代價是你得改程式碼、要有後端、資料會離開本機。claude-devtools 走的是完全相反的路：零整合、零後端、資料不離開機器，換來的是它只能看見 Claude Code，而且只能看見已經落地的紀錄。選哪一邊，取決於你要的是單機除錯還是組織級的追蹤。
維護成本、授權與版本節奏
授權是 MIT，這對內部工具或商業環境的採用門檻很低。要注意的是 MIT 授權的是這個 repo 的程式碼，不涉及 Claude Code 本身或你 session log 裡的內容；log 裡可能含原始碼片段、檔案路徑與 prompt，這些資料的處理責任在使用者身上，尤其走 Docker 部署時。這裡不構成法律意見。
版本節奏從 release 列表看得出相當密集：v0.4.15 在 2026-04-30、v0.4.16 在 2026-05-06、v0.5.0 在 2026-05-13，三週內三個版本，而且 0.x 的版號代表介面與行為仍可能變動。對桌面工具來說，這意味著升級前值得看一下 release notes，特別是 v0.5.0 這種 minor 跳版。
Homebrew 安裝的好處是升級走 brew upgrade 就好；直接下載 .dmg 或 .exe 的話，每次都得手動重抓，這在版本密集期是實際的摩擦。Docker 路線則取決於 image tag 怎麼定，而這部分素材沒有提供。
誰該裝，誰該等
該裝的情況：你每天用 Claude Code，遇過摘要看不出所以然，而且願意花十分鐘裝一個桌面應用來換取可讀的 session 檢視。特別是 context window 那七類歸屬，對常撞到 context 上限、想搞清楚到底是 CLAUDE.md、skills 還是 tool I/O 在吃預算的人，是終端機給不了的資訊。
該等的情況：你需要的是執行期的攔截與控制，或需要跨機器、跨團隊的集中追蹤，或你的環境不允許安裝桌面應用而 Docker 路線又還沒驗證過。這幾種情況下，claude-devtools 的架構起點就不對，勉強用只會失望。
決定採用前，先確認三件事：你的 ~/.claude/ 路徑與讀取權限、你的平台對應哪個 release asset、以及 Docker 部署時 compose 檔的 volume 掛載是否指向正確目錄。這三項確認完，再開一個你最近跑過、且對內容還有印象的 session 來比對，看它重建出來的工具呼叫與你記憶中的是否一致。
編輯結論
如果你已經在用 Claude Code，而且遇過「Read 3 files」這種摘要卻查不出到底讀了哪三個檔，claude-devtools 值得裝來試；它不碰你的 API 額度，只讀本機 log，風險低。反過來說，如果你要的是跨機器、跨團隊的長期追蹤，或需要 CI 內自動化的觀測，這個工具的定位是單機桌面檢視器，不是那一類方案。安裝前先確認兩件事：你的 ~/.claude/ 目錄實際路徑與權限（Docker 部署時掛載點必須對上），以及你的平台要抓哪個 release asset（macOS 分 arm64 與 x64，Linux 分 AppImage、deb、rpm、pacman）。Docker 路線請以 http://localhost:3456 開啟後，先確認它讀到的是你預期的專案目錄，再決定要不要繼續用。
社群筆記