I was on a video call, sharing my screen, working through a backend feature. Someone interrupted: "wait, hold on -- what is that you're using?"
I said Claude Code. They'd heard of it but hadn't seen anyone working in it that way before.
The interface they were looking at was Claudx. And it's the reason I still get that question regularly from people who catch a glimpse of my screen.
The background
I moved over to Claude Code maybe six months ago. It replaced most of what I was doing in Cursor and VS Code. The workflow is faster, the context management is better, and for backend work especially it removed a lot of the friction I was used to dealing with.
But I kept missing one thing: the Codex interface. Not the model -- the layout. The way you could see your prompt on the left, the file tree, the diff, the output, all at once without jumping around.
Claude Code runs in the terminal. That's the point -- it's lean, it stays out of the way. But the terminal is also one-dimensional. You're reading output sequentially, you're not getting a spatial view of what's happening.
In the terminal you're tracking a lot of that mentally. Which files changed. What the current task is. What the last few outputs were. It works, but it uses cognitive overhead that I'd rather spend on the actual problem.
So I built the UI I wanted
Claudx is Claude Code with a Codex-style interface. The goal wasn't to add features -- it was to make what Claude Code already does visible. File tree, prompt history, diff view, all in the same window.
You can check it out at https://www.claudx.org. It works on top of your existing Claude Code setup -- no new config, no new API keys, no new workflow to learn.
A few things I learned building it
First: layout matters more than I expected. The same terminal output reads differently when it's spatially organized. Your brain processes it faster when it has a consistent place to look.
Second: the "just wrap Claude Code" framing undersells it. The hard part wasn't the wrapping -- it was figuring out which parts of the terminal experience were actually important and which parts people just tolerated because there was no alternative.
Third: the people who get it fastest are already Claude Code users. They immediately see what's different. People who haven't used Claude Code yet sometimes get lost in the meta-question of why they'd use this over an existing IDE.
The reaction so far
The first comment I got when I posted about it: "why not just use Cursor?" Fair question. Cursor is great. But Cursor is a full IDE replacement. Claudx is for people who are already running Claude Code and want a better way to see what it's doing. Different thing.
The second most common reaction is people sending me screenshots of their setup. Which is its own kind of validation. When someone goes from "what is this" to "here's how I'm using it" in 20 minutes, that's the best signal you can get.
Back to the call
The person who asked what I was using went to claudx.org that afternoon. Came back the next day with a question about multi-file diffs. That's the version of word-of-mouth that I care about -- not retweets, not upvotes, just someone finding it useful enough to go deeper.
If you're using Claude Code and spending meaningful time in the terminal trying to track what's happening across files, give it a look: https://www.claudx.org. It might be what your setup has been missing.
Top comments (0)