Really good idea, I’ll have to try it out. The thing I really want is to have the ability to give a recipe for a new Claude code instance - spin up a docker image with code, data, and a running server and then let Claude work against that.
Does this sandbox the agents? All I want is a way to keep the agents from writing to and reading from arbitrary places on the filesystem. I want that enforced using operating system primitives rather than a pinky promise with an LLM.
It already worries me that the Cursor agents occasionally try to perform operations with full absolute paths, which they wouldn't be able to know if they were properly sandboxed to the current directory.
I wrote https://github.com/anoek/sandbox for that exact purpose, it uses overlayfs to protect your system from LLMs making unwanted changes and optionally masks out places you don't want it to be able to read from.
Not sure what problem it solves on top of Claude Code. I tried it a while back when this was posted but didn't find it very useful. This being a desktop app didn't make sense to me.
On the one hand, it's good that we're seeing a lot of exploration in this space.
On the other, the trend seems to be everyone developing a million disparate tools that largely replicate the same functionality with the primary variation being greater-or-lesser lock-in to a particular set of services.
This is about the third tool this week I've taken a quick look at and thought "I don't see what this offers me that I don't already have with Roo, except only using Claude."
We're going to have to hit a collapse and consolidation cycle eventually, here. There's absolutely room for multiple options to thrive, but most of what I've seen lately has been "reimplement more or less the same thing in a slightly different wrapper."
I tried it some weeks ago, but I went back to the CLI. Honestly, I've been a GUI app for most of my life, preferring proper GUI tools to Terminal tools, including running the GUI versions of VIM and Emacs (during my brief emacs stint). However, over the past 2 weeks I've slowly transitioned to a full cli development setup with wezterm, neovim, lazygit, fzf, fish & Claude Code. I enjoy working like this so much.
I get that some people go that way, but to me, the fact that Claude Code is a standalone terminal app is a strength, not a weakness. I don't really want or need a GUI here. "From Terminal Chaos to Visual Clarity" doesn't resonate with me; terminals to me are simpler and more structured.
At most, I've been thinking about installing one of the extensions to integrate Claude Code into (neo)vim, but even that I'm not sure I really want or need.
But for people who arm themselves to the teeth with GUIs and IDEs, I guess I can see the appeal.
interesting, does it let you manage multiple claude code agents without having to spin up different git worktrees? we were discussing the other day how that's an annoying limitation of claude code compared to codex, and the friction in having to manage those different worktrees feels just not quite worth it.
Doesn’t make any sense to me. GUIs are discoverability tools. LLMs are essentially a runtime with a natural language interface. Why would it need a GUI wrapper? By definition its discoverability is already 100%.
One thing that I'm missing from all of those Claude Code wrappers is the ability to search/replace and edit code. I'm mostly "vibing" nowadays, but often I face situations that editing the code by myself is faster than explaining it the AI.
Personally I like the UI for https://conductor.build/ a lot more than this, although I'll have to give it a try.
I see a lot of commenters asking why a GUI is necessary. When you're running several agents in parallel it becomes very handy compared to the terminal. I can easily see the status of each which I haven't found a good equivalent for when using terminal tabs. Also it handles automatically creating git worktrees for each agent which is great.
69 comments
[ 3.0 ms ] story [ 68.9 ms ] thread(Super rapid zooming in and out, flying all over screen at 3x speed, must cover eyes!!)
It already worries me that the Cursor agents occasionally try to perform operations with full absolute paths, which they wouldn't be able to know if they were properly sandboxed to the current directory.
On the other, the trend seems to be everyone developing a million disparate tools that largely replicate the same functionality with the primary variation being greater-or-lesser lock-in to a particular set of services.
This is about the third tool this week I've taken a quick look at and thought "I don't see what this offers me that I don't already have with Roo, except only using Claude."
We're going to have to hit a collapse and consolidation cycle eventually, here. There's absolutely room for multiple options to thrive, but most of what I've seen lately has been "reimplement more or less the same thing in a slightly different wrapper."
Yes, please :)
At most, I've been thinking about installing one of the extensions to integrate Claude Code into (neo)vim, but even that I'm not sure I really want or need.
But for people who arm themselves to the teeth with GUIs and IDEs, I guess I can see the appeal.
I’d really love to know what specifically about this is beautiful.
Steve Jobs says it and for 20+ years every tech bro parrots it mindlessly. “Oh do I think I did a good job on this? It must be beautifully designed.”
I see a lot of commenters asking why a GUI is necessary. When you're running several agents in parallel it becomes very handy compared to the terminal. I can easily see the status of each which I haven't found a good equivalent for when using terminal tabs. Also it handles automatically creating git worktrees for each agent which is great.