Using Claude Channels can make it easy to inject prompts and get just the response back without having to identify it in the terminal output or fight with the TUI.
But they're not well designed, and some things just have to go in through the terminal interface like slash commands (i.e. `/clear`)
It looks like it shouldn’t be an issue… it is just a wrapper around CLI calls to the official Claude code. It would be indistinguishable from the Anthropic side, and it isn’t even doing anything hacky or impersonating the official client.
This is my interpretation as well, Anthropic wants to be in full control of the connection between the client and their servers, and that's compatible with what
I'm trying to do.
And that's the beauty of open source and code. You can share it freely and easily. There's no thing that can be made for everyone.
Maybe some irony is everyone tells me they "just care that it works". Yet it can work and you'll always have the comments like above because it works for the reason it was made but not for things it wasn't made for. But it's open, so modify the code and put in what you want ¯\_(ツ)_/¯
I guess I should clarify its source available, not "Open Source". There's no license on the project so it's default theirs. But no harm if you're just editing it yourself. @OP should put up some license to let others know how what is allowed and what isn't
Agree on the source-available clarification — this exact
distinction matters on HN and I learned it the hard way recently.
I just went through the licensing decision for my own project
and landed on BSL 1.1 with a 4-year conversion to Apache 2.0.
Framing it as "source-available, auto-converts to Apache 2.0
in 2030" reads as transparent intent rather than "fake open
source."
That said, BSL/FSL really only make sense if you plan to
monetize a hosted version yourself. For wrapper tools like
Claudraband that sit on top of an existing product ecosystem,
MIT or Apache 2.0 might fit better — you're not protecting a
competing SaaS, you're just sharing code.
Opencode too. These tools are already so programmable and embeddable, it's just Claude Code is a sticking point. But maybe it would be useful to provide a unified CLI and Daemon for all of them.
They have ACP servers but they might apply different rate limits or policies if they notice ACP use, while a solution like yours would not trigger that unless it becomes popular enough to specifically detect. It also seems this provides more features them just an ACP server.
https://github.com/ehrlich-b/wingthing - Here's my version of this idea which is agent agnostic. Not exactly the same idea, "sandbox'ed persistent agent", in my case available over the web with xterm.js (though you can also just run locally).
This looks very cool! My concern is just that it's a lot of things bundled in one and I kind of have to trust you for all of them. I would prefer something that puts together a stack of better known components, like a docker compose of agent-sandbox and tailscale or something equivalent, etc ... ideally with each of those swappable.
Can't you just tell your AI tool of choice to just port it? One thing I like about AI is that now I can easily roll my own or take an open-source project and customize it really fast with very little commitment on my end. Instead of everyone having to use the exact same tools, now we can customize it to our liking--at least for now
I’ve made something very similar that is almost backend-agnostic: https://github.com/ayourtch-llm/tttt - and it does auto inject the MCP in case of Claude, but it is trivial to adapt to other backends.
What cursor has learned, very painfully, is that making a complex gui, even with the help of ai, is a lot fucking harder than a cli tool. Anthropic is wisely staying out of that space and sticking to more basic ui’s like cowork.
There is a LOT of work buried in your statement “all it would take”.
All one has to do is look at the evolution of cursor to confirm my statement. Compare v1 of cursor to v3 and see how much more insanely simplified the ui has become in v3 - it’s essentially a glorified cowork interface now
Is that something anyone wants? It seems like being able to plug into other editors works well. What are the experiences people are trying to get but currently can't build because ACP sucks or whatever?
The extra stuff is that you can automate interactions with Claude Code sessions using a CLI (which just tmux send-keys under the hood), an HTTP server, and ACP server (so you can embed claude code in other IDEs), and typescript library. So it's meant to make CC more embeddable in your workflows.
Some people open a claude code session and just talk with it. And some use hooks, custom commands, agent-teams..and so on. You can definitely be a power user. But I’m sure whether that translates to actual “power” is up for debate.
Using Claude Channels can make it easy to inject prompts and get just the response back without having to identify it in the terminal output or fight with the TUI.
But they're not well designed, and some things just have to go in through the terminal interface like slash commands (i.e. `/clear`)
Any idea of how this interacts with Anthropic's ToS for subscription-based use?
It looks like it shouldn’t be an issue… it is just a wrapper around CLI calls to the official Claude code. It would be indistinguishable from the Anthropic side, and it isn’t even doing anything hacky or impersonating the official client.
This is my interpretation as well, Anthropic wants to be in full control of the connection between the client and their servers, and that's compatible with what I'm trying to do.
I love how aligned with traditional hacker culture this. Fantastic job, 10/10!
Nor is it flooding servers with open claw type use.
That's cool but by only supporting Claude Code you are contributing to the Anthropic lock-in problem.
This needs to support at least Gemini CLI, Codex and OpenCode as well, preferably by being generic as much as possible.
It isn't ones duty to develop for everybody. If someone makes something for their own use case and shares it, that's fine.
And that's the beauty of open source and code. You can share it freely and easily. There's no thing that can be made for everyone.
Maybe some irony is everyone tells me they "just care that it works". Yet it can work and you'll always have the comments like above because it works for the reason it was made but not for things it wasn't made for. But it's open, so modify the code and put in what you want ¯\_(ツ)_/¯
I guess I should clarify its source available, not "Open Source". There's no license on the project so it's default theirs. But no harm if you're just editing it yourself. @OP should put up some license to let others know how what is allowed and what isn't
Agree on the source-available clarification — this exact distinction matters on HN and I learned it the hard way recently.
I just went through the licensing decision for my own project and landed on BSL 1.1 with a 4-year conversion to Apache 2.0. Framing it as "source-available, auto-converts to Apache 2.0 in 2030" reads as transparent intent rather than "fake open source."
That said, BSL/FSL really only make sense if you plan to monetize a hosted version yourself. For wrapper tools like Claudraband that sit on top of an existing product ecosystem, MIT or Apache 2.0 might fit better — you're not protecting a competing SaaS, you're just sharing code.
MIT License added
Codex and Gemini have ACP servers already:
https://github.com/zed-industries/codex-acp https://geminicli.com/docs/cli/acp-mode/
In fact Codex, in OpenAI fashion, have their own protocol as well:
https://developers.openai.com/codex/app-server
Opencode too. These tools are already so programmable and embeddable, it's just Claude Code is a sticking point. But maybe it would be useful to provide a unified CLI and Daemon for all of them.
They have ACP servers but they might apply different rate limits or policies if they notice ACP use, while a solution like yours would not trigger that unless it becomes popular enough to specifically detect. It also seems this provides more features them just an ACP server.
That's a good point, I'll look into tackling this soon
> they might apply different rate limits or policies if they notice ACP use
Is there any evidence that supports this claim?
Is there an example of this?
https://github.com/ehrlich-b/wingthing - Here's my version of this idea which is agent agnostic. Not exactly the same idea, "sandbox'ed persistent agent", in my case available over the web with xterm.js (though you can also just run locally).
This looks very cool! My concern is just that it's a lot of things bundled in one and I kind of have to trust you for all of them. I would prefer something that puts together a stack of better known components, like a docker compose of agent-sandbox and tailscale or something equivalent, etc ... ideally with each of those swappable.
Looks cool! What's a roost? Is that just a name for the server to go with the whole egg analogy some technology that I haven't heard of before?
Can't you just tell your AI tool of choice to just port it? One thing I like about AI is that now I can easily roll my own or take an open-source project and customize it really fast with very little commitment on my end. Instead of everyone having to use the exact same tools, now we can customize it to our liking--at least for now
I’ve made something very similar that is almost backend-agnostic: https://github.com/ayourtch-llm/tttt - and it does auto inject the MCP in case of Claude, but it is trivial to adapt to other backends.
This is really cool.
I did something similar with gemini cli by just wrapping it in tmux and building some extensions.[0]
Eventually that wasnt enough so I ended up forking it and adding REST endpoints to inject commands and read the screen.[1]
Your solution is much cleaner! I'll probably replace mine with it. Thanks for sharing!
[0] https://github.com/stevenAthompson/self-command
[1] https://github.com/stevenAthompson/gemini-cli-remote-control
For someone paying nothing for something that costs nothing, you have way more than nothing to complain about. Not appropriate.
Like this? http://nemesis8.nuts.services
Opencode already supports continuing old sessions with ctrl-x, l.
It's interesting how Anthropic haven't shipped their own IDE for more vertical integration.
All it would take is implementing their own forked version of VSCode (like Cursor did) and making Claude the default choice.
Obviously I'm simplifying here, but they definitely have the capability to do it.
What cursor has learned, very painfully, is that making a complex gui, even with the help of ai, is a lot fucking harder than a cli tool. Anthropic is wisely staying out of that space and sticking to more basic ui’s like cowork.
There is a LOT of work buried in your statement “all it would take”.
All one has to do is look at the evolution of cursor to confirm my statement. Compare v1 of cursor to v3 and see how much more insanely simplified the ui has become in v3 - it’s essentially a glorified cowork interface now
Is that something anyone wants? It seems like being able to plug into other editors works well. What are the experiences people are trying to get but currently can't build because ACP sucks or whatever?
Claude Code Desktop is as close as I can see them getting as it seems the big bet is that the IDE is on its way out as models improve.
> they definitely have the capability to do it.
You'd think so, but I guess they don't.
If xterm.js is slower than tmux, why don't you just use tmux for the headless sessions as well? How is tmux not headless enough?
Not everyone has tmux. I default to tmux if you have it and fallback to xterm.js
Ah, ah, got it. So you get a kind of graceful degradation if the optional dependency is missing. Nice!
And, I guess, it's headless in the sense that you can't attach to it even if you want to. I get what you meant now.
License? I see none listed in the repo.
Fixed
I’m very dumb. How is this different than starting Claude Code in a tmux and then connecting to that?
The extra stuff is that you can automate interactions with Claude Code sessions using a CLI (which just tmux send-keys under the hood), an HTTP server, and ACP server (so you can embed claude code in other IDEs), and typescript library. So it's meant to make CC more embeddable in your workflows.
[dead]
[dead]
[dead]
Isn't "Claude Code power user" an oxymoron or am I confused?
Are you asking if it is possible to be a power user of Claude Code? Because it very much is - what's the oxymoron?
I thought Claude Code _is_ for power users. How much more powerful do you need to be to use this?
Some people open a claude code session and just talk with it. And some use hooks, custom commands, agent-teams..and so on. You can definitely be a power user. But I’m sure whether that translates to actual “power” is up for debate.
I would simply ask the claude code to use the hooks and custom commands and agent teams for me.
In order to ask it to use them, you should be first aware of them. Non-power users aren't.
I would ask the claude code what I should be aware of if I was a power user.