Show HN: I built a tool to un-dumb Claude Code's CLI output (Local Log Viewer)
69 points| matt1398 | 16 days ago |github.com
I built this because I got tired of the Claude Code CLI hiding details from me.
Recent updates have replaced critical output with summaries like "Read 3 files" or "Edited 2 files". To see what actually happened, I was forced to use `--verbose`, which floods the terminal with unreadable JSON and system prompts.
I wanted a middle ground: *Full observability without the noise.*
`claude-devtools` is a local Electron app that tails the session logs in `~/.claude/` to reconstruct the execution trace in real-time.
*Unlike wrappers, it solves the visibility gap in your native terminal workflow:* 1. *Real Diffs:* It shows inline diffs (red/green) the moment files are edited, instead of just a checkmark. 2. *Context Forensics:* It breaks down token usage by File vs Tool Output vs Thinking (so you know exactly why your context window is full). 3. *Agent Trees:* It visualizes sub-agent execution paths which are usually interleaved and confusing in the CLI.
It’s 100% local, and works with the logs already on your machine. No API keys required.
Repo: https://github.com/matt1398/claude-devtools (Screenshots and diff viewer demo are in the README)
miroljub|13 days ago
Opencode is great as a full replacement. Works out of the box.
Pi code agent[1] is even better, if you spend some time in it, you can customize is to your liking. It's a vi and Emacs combined for agents.
[1] https://pi.dev
azuanrb|13 days ago
Claude Code is not developer friendly.
eurekin|13 days ago
zontyp|13 days ago
kzahel|13 days ago
mentalgear|13 days ago
syabro|13 days ago
cjonas|13 days ago
matt1398|13 days ago
khoury|13 days ago
matt1398|13 days ago
But regarding khoury's original point about the actual "gas in the tank" (billing/account balance)—no, my tool doesn't show that either.
Since `claude-devtools` strictly parses your local `~/.claude/` logs and makes zero network calls, it doesn't have access to your Anthropic account to pull your actual dollar balance.
What it does provide is high-resolution context usage. Instead of just a total session count, it breaks down tokens per-turn (e.g., how many tokens were eaten by reading a specific file vs. the tool output). It helps you manage your context window locally, but for billing, you're unfortunately still stuck checking the web dashboard.
unknown|13 days ago
[deleted]
itsmevictor|13 days ago
virtualritz|13 days ago
eurekin|13 days ago
I think there are quite a few bugs lingering in those agent-cli's and observability, would help a lot with reporting. Taking yours for a spin this evening, thank you!
matt1398|13 days ago
Thanks for giving it a spin tonight! Let me know if you run into any issues.
KingMob|13 days ago
matt1398|13 days ago
Also, this isn't a wrapper—it’s a passive viewer. I built it specifically to keep the native terminal workflow intact.
It’s especially useful when you're running multiple parallel sessions. Have you ever tried digging through raw JSON logs to retroactively debug passed sessions at once, since the session is already shut down? It’s nearly impossible without a proper UI. This tool is for those "post-mortem" moments, not just for watching a single stream.
joelschw|12 days ago
jimmySixDOF|12 days ago
"claude-trace" Record all your interactions with Claude Code as you develop your projects. See everything Claude hides: system prompts, tool outputs, and raw API data in an intuitive web interface.
https://github.com/badlogic/lemmy/tree/main/apps/claude-trac...
iamleppert|12 days ago
gregoriol|13 days ago
matt1398|13 days ago
1. Cross-platform distribution: Shipping an Electron app across macOS (ARM/Intel), Linux (AppImage/deb/rpm), Windows, and maintaining a standalone Docker/Node server just requires a lot of platform-specific build configs and overrides (especially for electron-builder).
2. Agentic coding guardrails: As I built most of this project using Claude Code itself, I wanted strict boundaries when it writes code
The ESLint, Prettier, strict TS, Knip (dead code detection), and Vitest configs act as quality gates. They are what keep the AI's output from drifting into unmaintainable spaghetti code. Without those strict constraints, agentic coding falls apart fast.
I'd rather have 20 config files enforcing quality than a clean root directory with an AI running wild. That said, I totally take your point—I should probably consolidate some of these into package.json to clean things up.
osener|13 days ago
6LLvveMx2koXfwn|13 days ago
matt1398|13 days ago
But it turns out Claude Code's official VS Code extension is built to read these exact same local `.jsonl` files. So unless Anthropic decides to intentionally break their own first-party extension, it should remain relatively stable.
Of course, they will add new payload types (like the recent "Teams" update), but when that happens, it's pretty trivial to just add a new parser handler for it—which I've already been doing as they update the CLI.
So far, it's been surprisingly easy to maintain!
kzahel|13 days ago
I have a similar project that started out as just a log viewer but is now a full session manager etc (https://github.com/kzahel/yepanywhere). My approach was to occasionally run zod schema validations against all my local sessions to make sure the frontend has a pretty faithful schema. I've noticed sometimes when I run claude cli it modifies some jsonl files, it might be doing some kind of cleanup or migration, I haven't looked too deeply into it (yepanywhere detects when files change so I see those sessions as "unread, externally tracked")
igravious|13 days ago
xyzsparetimexyz|12 days ago
benreesman|13 days ago
https://www.youtube.com/watch?v=9ZLgn4G3-vQ
unknown|16 days ago
[deleted]
small_model|13 days ago
matt1398|13 days ago
It's more like standard observability. You don't watch your server logs all day, but when an error spikes, you need deep tracing to find out why.
I use this when the agent gets stuck on a simple task or the context window fills up way faster than expected. The tool lets me "drill down" into the tool outputs and execution tree to see exactly where the bad loop started.
If you're running multiple parallel sessions across different terminal tabs, trying to grep through raw logs to find a specific failure is a massive productivity sink. This is for when things go sideways and you need to solve it in seconds, not for babysitting every keystroke.
Grimblewald|13 days ago
UqWBcuFx6NV4r|13 days ago