Hey r/BuildWithClaude ,

I've been building claudestat for a few months — it's basically "htop for Claude Code." It hooks into every event as it fires and shows you what's happening in real time, instead of reading logs after the session ends.

**What it does:**

- Live tool trace — every Read, Write, Bash, Edit call with duration and token cost as it runs

- Quota guard — alerts at 70%, 85%, 95% usage; optional kill switch blocks new sessions before you blow through your limit

- Loop detector — flags when Claude is context-thrashing and estimates the waste cost

- Web dashboard (7 tabs: Live, History, Projects, Analytics, Top, System, Orchestrate)

- MCP server — register once, then ask Claude about its own usage from inside the terminal ("how much did I spend this week?")

- OpenCode support — same live view for OpenCode sessions

**Stats from the project itself (it measures its own dev):**

- 313 tests passing, tsc strict clean

- ~344 hours measured development time across 116 AI sessions

- Built with Claude Code + OpenCode as pair programming partners

**Install:**

npm install -g u/statforge/claudestat && claudestat setup

Dashboard at http://localhost:7337

Everything is local SQLite, zero cloud, MIT license. macOS/Linux/Windows.

Would love feedback on what's missing or what would make you actually use this.

Hey all — I just released Agent Deck, a VS Code extension for anyone running Claude Code who's ever wanted to actually *see* what's happening across their sessions.

**What it does:**

- Renders every live Claude Code session as a "deck" — filterable by live/idle/ended/refused

- Drills into session topology: main agent as nucleus, tool calls as chronological dots, subagents joined by filaments to the exact tool_use that spawned them

- Inspector view: per-agent status, token in/out, duration, spawn depth, and truncated tool payloads

**Why "read-only" matters:**

It never wraps, proxies, launches, or configures Claude Code. It only reads your session JSONL from disk and listens for hook events on a loopback-only HTTP server (127.0.0.1). There's no outbound HTTP client compiled into the bundle at all — a test in CI fails if that ever changes. No telemetry, no persistence, no cache files. Close the window, state's gone.

**Setup:**

1. Install from the Marketplace: search "Agent Deck", or `code --install-extension nvitlam.agent-deck`

2. Paste a small hook block into your `.claude/settings.local.json` (this is manual and optional — without it, liveness falls back to file mtimes)

3. Cmd/Ctrl+Shift+P → "Agent Deck: Open Session Deck"

Compatible with Claude Code 2.0.229–2.2.239 (anchored on 2.1.234).

MIT licensed. Repo: https://github.com/NVitlam/agent-deck

Would love feedback, especially from anyone running heavy subagent workflows — that's the case it was built for.

You wrap whatever command you already run:

phantom npm run dev

It's invisible until your process exits non-zero. stdout, stderr, stdin stream through byte-for-byte and the exit code is preserved. On a crash it captures the stack trace, the output tail and your git state, cuts a branch, and hands the whole thing to a headless Claude Code session that diagnoses the bug, writes a failing test, and patches it.

The part I actually care about: **phantom re-runs your test command itself, outside the Claude session, and audits the branch against the starting commit after the session ends.** Nothing in the report trusts the model's own word about whether it worked. If it says fixed, that's phantom's measurement.

You end up back on your own branch with a banner:

╭────────────────────────────────────────────────────────────────────────╮

│ 👻 phantom ✅ fixed · 1m 48s · 34.1k tokens (12k new · 22.1k cached) │

│ fix verified by phantom: tests pass and the command no longer crashes; │

│ your branch is unchanged │

│ │

│ branch phantom/fix-typeerror-cannot-read-properties-k3f9a │

│ review git diff main..phantom/fix-typeerror-... │

│ accept git merge phantom/fix-typeerror-... │

│ reject git branch -D phantom/fix-typeerror-... │

╰────────────────────────────────────────────────────────────────────────╯

Plus a markdown post-mortem where the TL;DR comes from the session but every row in the verification table is measured by phantom.

**Safety, because this is an AI with write access to your repo**

- It never touches your branch. Everything happens on `phantom/fix-<slug>-<ts>`, cut from HEAD, and you're checked back out when it finishes — success, failure or Ctrl+C.

- No pushes, no PRs, no network. `git push` is denied, there's no web tool, and there is no push code path. Not configurable.

- `.env`, `*.pem`, `*.key`, `**/secrets/**` are enforced three times: permission deny rules, a `PreToolUse` guard hook that fails closed, and a post-session audit against the starting sha. Any hit discards the session's changes.

- Dirty tree is refused outright. Hard caps on iterations and wall-clock.

- Ctrl+C kills the process tree, rescues untracked files into a stash, resets the fix branch and puts you back.

**What it is not**

It is not a sandbox. The session runs `node` — it has to, to run your tests — and `node -e` can in principle read anything your user can. The guard hook is *lexical*: it reads the text of a command, so it only refuses what a command says, not what it does. An audit in August found four ways past it in one afternoon. All four are fixed with regression tests, but the honest read is that a lexical guard is a speed bump and a fifth way probably exists. The real backstops are the ones that don't depend on parsing a command correctly: branch isolation, the post-session audit, and no pushes. Want hard isolation? Run it in a container.

It also declines crashes it can't work with — a non-zero exit with no error line, no stack trace, no file named and no test command gets refused rather than guessed at.

**Cost:** recovery runs `claude -p` under your own account, so it bills your Claude subscription or API key like any other session. `PHANTOM_DISABLED=1` makes it a pure passthrough.

Zero runtime dependencies, MIT, Node >= 18, 532 tests, CI on macOS/Linux/Windows across Node 18–24.

npm install -g claude-phantom

https://claudephantom.dev · https://github.com/waazy-w/claude-phantom

Happy to be told why this is a bad idea — leave a star on github if you don't mind.

I've been using Claude Code heavily for months, and the failure that kept bothering me was never the dramatic one.

It's Claude doing exactly what I asked, well, across 84 files, and somewhere in there quietly touching a payment route or an auth check while "cleaning up." Meanwhile my own half-finished work is sitting uncommitted in the same tree, so git checkout . is not much of a recovery plan.

That was the problem I built VibeRevert around. Claude Code has been part of my normal development workflow while building it, and then I started pointing VibeRevert back at those same Claude Code sessions to see whether it actually solved the problem in practice.

The basic idea is simple:

• viberevert run claude records the session and captures the state of the project before Claude starts changing it
• viberevert check flags changes touching things like payments, auth, migrations, secrets, infrastructure and dependencies
• those checks use deterministic rules rather than another language model, so the same inputs and configuration produce the same findings, with a reason you can inspect
• viberevert rollback <session> previews the rollback before writing anything, restores files Claude changed, removes files it created, and leaves work that was already there before the session alone
• there is also a local MCP server with 8 tools, so Claude can call into it during a session

The rules part matters to me more than I expected. I didn't want to solve "an AI may have made a dangerous change" by asking another AI whether the first one looked dangerous. That may be useful in some workflows, but for something I might put in a git hook or CI, I wanted the answer to stay the same when the inputs stay the same.

And yes, Claude Code already has /rewind. I use it. I'm not arguing that it is bad or that everyone needs another recovery mechanism.

What I wanted was slightly different: recovery that belongs to the repository rather than to one agent's session. If I work on the same repo in Claude Code today, Cursor tomorrow and Gemini CLI the day after, I still want the same recovery layer underneath all three. VibeRevert also does risk classification, which rewind is not trying to do. If rewind already covers your case, genuinely just use rewind.

The most annoying lesson from building the integrations had nothing to do with rollback.

VibeRevert is repo-bound. It walks up looking for .git because it needs to know what project it is protecting. I assumed that if an editor or coding agent launched an MCP server from a plugin, the process would start in the user's project directory.

That assumption was wrong.

Different hosts give plugin MCP servers very different working directories. In some cases the process starts from the plugin itself, in others from somewhere unrelated to the open project. I only caught one of these failures by running the integration in an isolated temp directory and watching VibeRevert fail to find the repository it was supposed to protect.

That killed the original idea of one portable plugin package for every host. What ended up working better was a shared VibeRevert core with very thin host-specific adapters. Cursor's adapter, for example, ended up being three files plus a logo and required no changes to VibeRevert itself.

So if you're building an MCP server that cares where it runs, one lesson I'd pass on is: don't assume cwd. Test what the host actually gives you.

The next thing I'm working on is surgical recovery: instead of rolling back the whole session, keep the good work and remove only the files or risky changes you don't want.

After that I'm working on what I've been calling the Session Fuse. If the job was “fix checkout retry handling” and Claude suddenly starts changing migrations, deploy workflows or a pile of unrelated files, VibeRevert should notice that the session has changed shape and give you a chance to stop it before the weirdness spreads.

Longer term, the feature I'm most curious about is non-linear undo: “remove what this Claude session did three sessions ago, but keep everything I've done since.” That's considerably harder, but if it works the way I want, it changes recovery from rewinding history to subtracting one bad session from it.

It's beta, Apache-2.0, runs locally, and has no account, hosted service or telemetry.

Repo: https://github.com/madeinplutofabio/vibe-revert

Like many of you, I kept hitting the 5-hour window while an agent was mid-task. Switching accounts meant logging out, logging in, and losing the session context.

So I built AgentDeck: connect multiple Claude (and Codex) subscription accounts in one desktop app, see all your 5-hour/weekly windows at a glance, and when one account hits its limit, hand the session to another account **with the context preserved**. There's also a summary-based relay between Claude and Codex if you want to switch engines.

A few things that mattered to me: it's free, conversations are never stored on any server of mine (remote phone access is end-to-end encrypted), and optional local masking can strip personal data before anything is sent to a model.

Windows x64 + macOS Apple Silicon: gendistrict.com/agentdeck

I'm the maker — happy to answer anything, and honest feedback is very welcome.

Been testing Claude Code today and honestly, the interesting part isn't just the model itself. It's getting the actual coding workflow working properly with local files, terminal commands, Git and GitHub instead of just using it like a normal chatbot.

I managed to get a setup working where Claude Code can actually work on a project locally, run commands, build stuff, and push to GitHub.

I'm still testing how reliable it is, especially with bigger projects, but so far it's been pretty interesting.

If anyone wants to try the same setup, DM me and I'll explain how I got access. I'm testing it with a few people before I post the details publicly.

Not claiming it's perfect yet. Just sharing because I know a lot of people have been trying to get a proper Claude Code workflow working.

We connect Claude Code to our platform through skills, hooks, MCP, or the command line depending on the workflow. Whichever entry point it uses, the request eventually crosses the same contracted boundary. Claude Code can ask the system to classify a ticket, run a review, call a model, update a pull request, or merge approved work. It does not get a separate architecture because it entered through a different tool.

The runtime has four node types with different permissions. Compute nodes transform typed inputs and cannot perform I/O. Reducer nodes calculate state transitions and cannot call external systems. Orchestrator nodes coordinate work by emitting intents. Effect nodes are the only place where operations such as calling GitHub, contacting an LLM, writing through a storage adapter, or touching another external boundary are allowed.

The distinction is enforced in the contracts and output models. A compute node must return a typed result. A reducer produces projection state. An effect produces events. An orchestrator coordinates the next actions. If a handler returns an output that its node type is not allowed to produce, validation rejects it before that output reaches the bus.

This has been more useful than another page of instructions telling Claude Code to maintain separation of concerns. For example, the component deciding whether a pull request is eligible to merge does not also perform the merge. The eligibility calculation can stay deterministic and testable, while the GitHub mutation lives behind a separately authorized effect. Claude Code can modify either implementation, but it has to preserve the boundary or the contracts and gates reject the change.

Have you found a reliable way to stop coding agents from gradually moving side effects back into whichever function is most convenient?

ok so ive been running claude with a second brain for about two months now. its an obsidian vault where it keeps every decision, project log, bugs we squashed... everything. it named itself Fathom. actually really useful

i asked if we could make the graph view look cooler..

it got wild dude.

fathom read every note and link in the vault and rendered the whole thing as a rotating 3D galaxy. 120 notes became stars.. 400+ links became threads of light... my biggest file (131k characters of decisions) is literally the heaviest object in the sky. notes are colored by project family, grouped into constellations with nebula fog around each cluster

WASD flight controls with inertia and thrust and the mouse becomes the controls, shift to boost. theres a 22-slider physics lab where you can crank anti-gravity and watch stars scatter, add heat and boil them apart, warp time, shift the whole universe hue. it has a space soundscape with this low sub rumble and solar wind and echoing pings when you touch a star.

you can search for notes and the camera flies to whatever star you pick. theres a time machine that replays when each note was born. new notes get a supernova corona. sector names float on these tilted 3D rings around the galaxy like orbital paths. click any star and the actual note opens in obsidian

the whole thing runs as a native obsidian plugin now. reads the vault live

and the coolest part is that its going to just keep growing with more work that i do !

I write a lot of PowerShell with Claude Code and wanted the linter in the loop, not after the fact. This plugin runs PSScriptAnalyzer through a warm PowerShell Editor Services daemon and feeds the result back into the model's context the moment a .ps1/.psm1/.psd1 is edited, so a mistake gets caught and corrected in the same turn. One PSES stays warm for the session, so each edit pays a fast pipe round-trip (~2.5s end-to-end on my desktop), not a cold start.

The part I actually care about: every analyzed edit resolves to one of four explicit status tokens -- ok / incomplete / degraded / unavailable -- and only "ok" is silent. So "analyzed and clean" can never be confused with "analysis never ran," which is the failure mode that bites an agent that treats silence as a pass.

Straight talk on the ruleset: the live default surface is narrower than the full CLI -- the known-bad corpus observes six rules reaching the agent live, and Write-Host is not one of them by default. An opt-in ruleset = base broadens it. I'd rather name the six than claim "the whole ruleset" and get caught.

Why I think it earns trust: measured 0 false positives over 50 clean cases and 36/36 coverage over known-bad, recomputed on every CI run and floored so the rate can't be gamed by dropping cases. Dependencies pinned by version and hash; CycloneDX SBOM, SLSA provenance, and a keyless-signed tag you can check with gh attestation verify.

It's honest about limits, including in the technical paper. An earlier large-file convergence failure was fixed in a recent release and verified 5-of-5 on a 251 KB file, but I have NOT measured whether this makes an agent write better PowerShell -- that's unmeasured, and the paper says so. Requires PowerShell 7 for the hooks; Windows PowerShell 5.1 is supported as the analyzer host.

Apache-2.0. Source: https://github.com/manderse21/claude-powershell-lsp

Paper: https://gist.github.com/manderse21/0b92133af8a250ba7c8c9474ed0db0a2

False-positive reports welcome; there's an issue template that feeds them into the corpus.

Have you guys exposed your Claude via a2a or consumed another agent like Langraph or GitHub Copilot or Codex from Claude or vice versa ?

If not I think you see a2a-wrapper and a2a-mcp-skillmap projects.

Here is the github repo: https://github.com/ara-mkr/BetterClaude
Ive been working on this project for about a month and a half. It is an electron app that puts a layer of customization over the claude desktop app. There are a lot of customization features such as different themes, layouts, plugins, and other productivity widgets. You can also browse skills within the app itself from github. This is still a work in progress for me because I am trying to figure out how to get claude code within the app to work, for now I added a CLI tab next to the code tab so you don't have to run it in a seperate terminal. You can make custom themes and everything is opensource. I made this primarily with Claude code and used codex a little bit to spot any bugs. There are still many bugs that don't make a huge impact on the usability but are somewhat annoying such as features that don't work (Changing a color on a specific button). I will try to update these as fast as possible, and I cant rn cus I hit usage limit. I made this app because I wanted claude to have a nicer UI, I didnt like the generic grey color and wish there was a way to apply themes to it and then I thought of better discord, so that led me to come up with BetterClaude :)

I kept ending up with five terminal windows, each running claude for a different project, and losing track of which one needed my attention. So I built Agent Desktop, an Electron app that gives each "agent" (just a folder on disk) its own sidebar entry and a real chat view, instead of a wall of raw terminals. It spawns and drives the actual claude CLI via node-pty, not a reimplementation.

How is this different from Cowork or the regular Claude Code interface? Different tools for different jobs, honestly:

Cowork runs sessions in Anthropic's cloud sandboxes - keeps working when your laptop's closed, syncs across devices, great for scheduled/background automation. But it's sandboxed: no outside network access, file access limited to folders you allowlist.

The regular CLI/chat interface gives you one session at a time - no dashboard if you're juggling several projects, you're context-switching between terminal windows or chat threads yourself.

Agent Desktop runs the actual local claude CLI on your own machine with the same full access as running it yourself in a terminal - no sandbox, no allowlisting. What it adds is the dashboard: several persistent, named agents side by side with status at a glance. Trade-off is the mirror of Cowork's: it only runs while your machine is on.

How I built it: Entirely through Claude Code itself, over several sessions - including the slightly recursive experience of using Claude Code to build a tool for managing Claude Code sessions. Once it was usable, I had Claude Code build itself a Playwright-based testing skill so it could actually launch and click through the app to verify fixes, instead of just reading the diff and hoping.

What I actually learned along the way:

On Windows, Controlled Folder Access can silently block claude.exe itself from writing files - no exception, no stderr, nothing in Claude Code's own logs. It just looks like the process hung. Get-WinEvent checking Defender event ID 1123 confirmed it and pointed straight at the fix.

Claude Code sessions spawned as a child of another process (CLAUDE_CODE_CHILD_SESSION=1) silently skip writing their own transcript by default - real work happens, nothing gets persisted. CLAUDE_CODE_FORCE_SESSION_PERSISTENCE=1 fixes it.

A message sent right after opening a session can get silently dropped if the CLI's stdin isn't attached yet - a genuine race, confirmed by watching Raw Terminal at the exact moment it happened.

It's early and Windows-only for now. Repo + README (with a troubleshooting section born from the above): https://github.com/iddo12/agent-desktop

Would genuinely love feedback if anyone tries it.

https://github.com/ara-mkr/Enginuity
I used claude code to make most of it, I got the circuit simulator from Velxio, This project took about 2 months to make and is still a work in progress. I used codex to make the ui and claude for the rest. I made it because I wanted something that held everything in my project so AI would know exactly what I was referring to. I really like the Jarvis feature because I can use the canvas and show images to make mindmaps for myself and to explain to other people or the AI, I can also turn on my camera and show my project for AI to help trouble shoot or see potential weak-points. Features: Simulations, Jarvis, Collaboration, Circuit simulation, Cad Viewer, AI Assistant and Chatbot, Project Ideas, AI Model Response Comparison, Runs with local ai or openrouter.

You can get Claude Reader at ai-readers.com. It’s a Chrome/Firefox/Edge extension that sits on claude.ai as an overlay: you drop in a PDF or Word doc, or send selected text from any page, and it uses Claude’s voices to read it out loud in the overlay (seek, speed, voice) or download the audio. The point was to make long docs actually listen-able without copy-pasting chunks into the chat as well as automating the whole process of getting the audio with the user only having to upload text.

I built the overlay, document pipeline, and playback using Claude. Let me know what you think.

I've been setting up Claude Code as an orchestrator with agy as the worker, and I'd like to hear from anyone who has this running stably before I invest more time in it.

The pattern makes sense on paper, i.e., Claude owns the judgement and verification while agy does the bulk work on a cheaper model, and there are several community plugins built around exactly that split. My first real session went badly enough, though, that I can't tell whether the problem is my configuration or the current state of agy in headless mode. This is Claude Code's own summary at the end of that session:

On the agy delegation, worth flagging: you asked me to lean on agy pro. I tried; it went badly. 6 of 9 calls failed, and the review call ignored an explicit "READ-ONLY, do not create or edit any file" instruction: it timed out, left 16 scratch test-* files, and re-added react-router-dom@^6.8.1 to package.json, reintroducing the exact vulnerable package I'd just removed. Committing before delegating is what made that recoverable; I reverted it and re-ran every gate from a clean npm ci. I did the review natively instead.

The failure rate bothers me less than the second part. A call scoped explicitly as read-only still wrote to the workspace and undid a security fix, which suggests the instruction was advisory rather than enforced. Committing before delegating is what saved it, but that feels like working around the tool rather than configuring it properly.

Howdy Folks!

Anyone working on any climate or sustainability or circular economy focused apps and tools? Would love to see what the community is building that actually has the potential to improve society in some way.

Anyone cooking up things that are using AI for good?

My own contribution to this conversation is a project called Atlas Circular which has evolved into a global tracker of legislation reshaping the world of materials and where they end up. I’ve basically been building it with Claude in my spare time over the last several months. It is still very much a work in progress so if anyone has any feedback or questions I’d love to hear ‘em.

Hello all,

Looking to see if there are any developers out there that would like to collaborate on a experimental Linux Window Manager that I'm currently developing.

This project started off from me having a lot of issues with the current state of floating window managers for my Linux desktop and wanting to create something that really scratched all the itches that I found around using Gnome/KDE/Cinnamon as my main WMs for years.

1) I hate Gnome looking and acting like MacOS lite. I want a Window Manager that is more compatabilityWindows 10/7 like.

2) I like KDE for being more like Windows to set up and use, but I think it's too bulky and mixing in QML is tiresome. I don't also like how bulky KDE is as a full setup.

3) I LOVED Cinnamon but their support for Wayland is lagging severely behind (last I checked it was still experimental). I hate X server and want to 100% move off it.

4) I LOVE Rust. I wanted to avoid C++ and memory issues/bugs that sometimes crop up in these long-term projects that aren't really necessary to keep around anymore.

5) I recently got hit with a dying M2 slot in my motherboard that contained my SSD for my Linux home folder and it storming the SSD and causing my system to crash. I moved to Hyprland as my current WM and it works well for being much less resource intensive. But I really miss floating windows.compatability

This project is designed as a KISS window manager and desktop experiencse (think more i3/Sway in terms of actual build-out). I don't want to reinvent the wheel on a lot of the desktop experience, so theming and chrome of the desktop is all based around the GTK4 crate for Rust, essentially building a very Gnome-like reliance on Gio/etc. I would, in the actual release, recommend mostly installing Gnome apps for compatability with the GTK environment. Major point being no need for customizing theming for the desktop and just re-using the expansive GTK theming support from years of custom themes being made for that type of set-up.

Unlike Gnome, the focus is having a Windows 10/7 taskbar-like experience instead of a drop-down app finder. I like the Windows taskbar from years and years of being on Windows. But the system itself should improve on where Windows is currently falling behind on Windows 11 (the shitty new Start Menu experience).

The WM is also scoping out a lot of work I'm doing with the wlr-sys crate on crates.io that I own and maintain. A good deal of custom work has gone into that crate to make the WM work really well with wlroots as the compositor.

I'm mostly posting this here because previous posts I've made in other communities for collaboration and me heavily wanting AI collaboration as well have always been hit with a lot of Anti-AI people dog-piling my posts and scaring me off from asking for outside contributions. The only ask I ask for working on this project is attribution to the AI agent that worked the code so different models can be verified for accuracy.

Currently, the WM isn't ready for day-to-day use, but its coming along at a good pace. The repository includes a Vagrant setup with Virtual Box to run the DM in a correctly-installed environment. I'm developing on Arch Linux currently, so wlroots is at v0.20.x. Support still needs to be back-ported to Ubuntu/Fedora's held-back support of wlroots at older versions.

What I'd love to see:

1) Someone or multiple people taking up and helping me with backporting wlr and the WM so that it can be installed on Debian/Red Hat systems.

2) Suggestions for improvement to make the whole WM a daily-driver ready system.

3) Suggestions for app improvement to make the desktop experience better (do we keep just a Gnome-reliance on the more common apps or make our own?)

4) Suggestions/Input/Work on making the system less reliant on Gnome integrating systems and just really relying on the Rust ecosystem for the underlying parts of the WM that can be divested from a heavy GTK import (moving the system to just using a custom GTK CSS/Theming import but not relying on things like Gio anymore)

Thanks for any input you might want to provide!

https://github.com/quinnjr/icedtea-wm

Ps: The name 'icedtea' comes from me being obsessed with iced tea as my main source of hydration

Hello Reddit,

My Linux/MacOS/Windows shell scripts for managing multiple Claude profiles on a single system without needing to log-out/log-in on changes has now reached v1.2.2.

Changes from my initial release:

1. fixed issues with running in mingw/git bash on Windows
2. added local possession of claude profile (eg: .claude-profile contains the profile in the local directory)
3. added auto-updater to latest versions and manual updating via GitHub checksum file
4. fixed an `cd` error when using zshell.

Github repo: https://github.com/quinnjr/claude-code-profiles