FR version is available. Content is displayed in original English for accuracy.
Claudraband wraps a Claude Code TUI in a controlled terminal to enable extended workflows. It uses tmux for visible controlled sessions or xterm.js for headless sessions (a little slower), but everything is mediated by an actual Claude Code TUI.
One example of a workflow I use now is having my current Claude Code interrogate older sessions for certain decisions it made: https://github.com/halfwhey/claudraband?tab=readme-ov-file#s...
This project provides:
- Resumable non-interactive workflows. Essentially `claude -p` with session support: `cband continue <session-id> 'what was the result of the research?'` - HTTP server to remotely control a Claude Code session: `cband serve --port 8123` - ACP server to use with alternative frontends such as Zed or Toad (https://github.com/batrachianai/toad): `cband acp --model haiku`. - TypeScript library so you can integrate these workflows into your own application.
This exists cause I was using `tmux send-keys` heavily in a lot of my Claude Code workflows, but I wanted to streamline it.
Discussion (38 Comments)Read Original on HackerNews
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.
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
You'd think so, but I guess they don't.
But they're not well designed, and some things just have to go in through the terminal interface like slash commands (i.e. `/clear`)
This needs to support at least Gemini CLI, Codex and OpenCode as well, preferably by being generic as much as possible.
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
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.
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.
Is there any evidence that supports this claim?
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
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.