claude-devtools: A Visual Inspector for Claude Code's Hidden Session Logs
The missing DevTools for Claude Code — inspect session logs, tool calls, token usage, subagents, and context window in a visual UI. Free, open source.
At a glance
- What is it?
- claude-devtools reads the local Claude Code logs under ~/.claude/ and turns opaque terminal summaries into a structured UI with file paths, diffs, and token attribution. It is a free, MIT-licensed Electron app aimed at developers who need to debug what Claude actually did.
- Who is it for?
- Adopt claude-devtools if you run Claude Code regularly and need to audit file edits, token consumption, or subagent behavior beyond the collapsed terminal output. Skip it if you never feel the need to look past the one-line summaries or if you are comfortable with --verbose JSON dumps.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 125 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap it fills: Claude Code's opaque output since v2.1.20
The README claims zero configuration and no API keys. That is plausible because the tool only parses local files. The main requirement is that you have run Claude Code at least once so that logs exist. For someone debugging a failed refactor or a runaway token bill, this is the missing middle ground between the collapsed terminal and the raw --verbose output.
How it reconstructs context from local logs
This is a local parser, not a live debugger. The data flow is one-way: Claude Code writes logs, claude-devtools reads them. That means you cannot see a session that is still running unless the logs are flushed, and you cannot inspect sessions from another machine unless you copy the logs over. The README does not specify whether it watches for new log files or requires a manual refresh, so that detail is unconfirmed. The value is in the reconstruction: the terminal hides the details, but the log file retains them, and this tool surfaces them in a filterable UI.
Installation and first run across platforms
The Docker path is notable because it suggests the tool can run as a standalone service, not only as a desktop app. The README links to a section called "Docker & Standalone Deployment," though the truncated material does not show the full instructions. If you want to avoid installing an Electron app, Docker is a viable route, as long as the container has access to the host's ~/.claude directory. The Homebrew cask is the simplest for macOS users who already use Homebrew.
What the UI exposes that the terminal hides
There is also a memory feature. Claude Code stores per-project memory in ~/.claude/projects/.../memory/, and claude-devtools renders MEMORY.md as a clickable index of layers, letting you open any layer in your editor. That is a practical feature for teams that rely on memory files to persist context across sessions. The copy-and-paste improvement is also real: terminal output often has wrapped lines, ANSI codes, and broken Markdown. The tool provides selectable text and one-click copy for messages and code blocks. This is a user-facing quality-of-life fix that matters when you need to paste a snippet into an issue or a PR comment.
Limitations and cases where it is the wrong tool
It is the wrong tool if you need real-time monitoring or if you want to see sessions from a remote CI environment without copying logs. It is also not a replacement for reading the code yourself; it shows what Claude did, not whether that was the right thing to do. For trivial sessions where the terminal summary is enough, installing an Electron app adds overhead for little gain. The README itself notes that the only alternative before this tool was --verbose, which dumps raw JSON and internal system prompts. If you are comfortable parsing that JSON yourself, you may not need a GUI.
Alternatives: --verbose and log parsing versus a visual UI
The difference in approach is that --verbose and manual parsing are developer-driven and ephemeral: you run a command, you get a dump, you filter it yourself. claude-devtools is a persistent, interactive tool that reconstructs the session into a navigable interface. The trade-off is that you trust the tool's parser to interpret the logs correctly. If the parser misreads a field, you may see wrong token counts or missing tool calls. With raw logs, you can always go back to the source. The README does not mention any export or raw log view within the tool, so for deep verification you may still need the original files.
Maintenance, license, and upgrade considerations
Upgrade cost is low for a desktop app: you download a new binary or run brew upgrade claude-devtools. The Docker deployment would require pulling a new image and restarting the container. There is no mention of a plugin system or configuration files, so customizing behavior may be limited to what the UI offers. The main risk is not the tool itself but the upstream dependency on Claude Code's log format. If you rely on this for debugging, you should check the release notes after each Claude Code update to see if claude-devtools has released a compatible version.
Editorial conclusion
Adopt claude-devtools if you run Claude Code regularly and need to audit file edits, token consumption, or subagent behavior beyond the collapsed terminal output. Skip it if you never feel the need to look past the one-line summaries or if you are comfortable with --verbose JSON dumps. Before relying on it, verify that it parses the log format of your current Claude Code version, since the tool depends on log structures that can change between releases. Check the changelog for v0.5.0 and later to confirm compatibility with your installed version.
Community notes