Claudraband - persistent, resumable Claude Code sessions over HTTP and ACP

Claudraband is a thin wrapper that turns Claude Code's terminal session into something you can leave running, attach back to, and drive over HTTP. Not "Claude Code in API form" - the actual TUI keeps running underneath. The wrapper just exposes session lifecycle, prompt-answering, and a daemon you can talk to.

The reason this matters: Claude SDK gives you a fresh non-interactive session per call. Claudraband gives you a persistent session you can reconnect to, answer pending approvals on, and integrate via HTTP or ACP - while the underlying agent keeps its full interactive surface.

276 stars, 10 releases (currently v0.7.2), MIT, by halfwhey.

What it actually wraps

The pitch reduces to three capabilities the SDK doesn't give you out of the box:

• Resumable non-interactive workflows - start a session, walk away, come back, answer the approval that's been waiting, continue. The SDK's print-mode kills sessions on every call.
• HTTP daemon - one endpoint to spawn, list, drive, and tear down sessions from outside the terminal. Useful for headless servers, CI runners, anything that wants Claude Code without sitting at a TTY.
• ACP (Agent Code Protocol) server - editor integrations like Zed and Toad speak ACP; Claudraband is the bridge that lets them drive a real Claude Code session rather than re-implementing one.

Install

# global npm install
npm install -g @halfwhey/claudraband

# one-shot run via npx
npx @halfwhey/claudraband

# Docker
docker run -it ghcr.io/halfwhey/claudraband

Requires Node.js or Bun, plus an authenticated Claude Code on the same machine. The wrapper drives the real CLI - no separate auth, no separate model config.

Why this is different from the SDK

The Claude SDK is "build your own agent on top of the API." Claudraband is "drive the real Claude Code from outside." Different problem.

Concretely: if you want a process that knows how to use the user's existing Claude Code skills, slash commands, hooks, MCP servers, and approval flows - and lets you trigger sessions remotely - the SDK won't get you there without re-implementing each of those pieces. Claudraband sidesteps the rebuild by letting the real CLI do the work and exposing a remote control surface.

The trade-off is honest: anything Claude Code itself doesn't expose, Claudraband can't either. It's a transport, not a re-implementation.

When to reach for it

• You want to drive Claude Code from a headless server, CI job, or webhook handler without losing access to your full local config.
• You're building an editor integration and want ACP support without writing the protocol layer yourself.
• You need sessions that survive across calls - long-horizon tasks where the agent has to wait for human approval mid-flight.

When not to

• You're building an agent product on top of the API. Use the SDK; the wrapper buys you nothing.
• You want a fully programmatic agent that never blocks on humans. Claudraband's value is the interactive surface, including approvals; if you want pure non-interactive batch, claude --print is fine.
• You don't need remote control. If everything happens at one terminal, the upstream CLI already does what you need.

Trade-offs

It's a wrapper. When Claude Code's CLI changes (and Anthropic ships fast), the wrapper has to track. The 10-release cadence is a reassuring signal but worth knowing - you're betting on halfwhey's velocity matching upstream's.

The HTTP daemon is local-by-default. Exposing it on a network is something you do deliberately, with auth in front; the README is clear that it's not designed as a hardened multi-tenant service. For team use, run one daemon per machine, not one for the org.

ACP is still an evolving protocol. Editor integration works for the editors that speak the spec today (Zed, Toad). If your editor doesn't, you're back to the HTTP daemon, which works fine but is less idiomatic for editor flows.