PaPoo
cover

Claude Code, but turned into a little ops platform

What surprised me is not that someone wrapped Claude Code in a fleet manager. It’s that they took the idea seriously enough to build all the boring parts around it: persistence, scheduling, chat surfaces, sender allowlists, guardrails against burning through plan windows, even a control room that watches tokens stream in. That’s the difference between a toy demo and something an actual developer might leave running.

The part I’m most interested in is the architectural choice to lean on the plain claude CLI instead of an API path. That makes the whole thing feel oddly parasitic in a good way: Spool isn’t trying to replace Claude Code, it’s trying to orchestrate it. If you already trust your Claude subscription more than a fresh API integration, I can see the appeal. No API keys, no SDK glue, no extra billing layer. Just loops, sessions, and a scheduler wrapped around them.

I’m also a little wary of the “persistent coworkers” framing. It’s clever branding, but it can hide the fact that you’re still managing autonomous-ish processes that can drift, chat, wake up on timers, and talk to each other. The repo seems aware of that risk — the “storm-guarded” loop-to-loop chains and the plan guardrails are there for a reason — but I’d still want to see how it behaves after a week of real work, not just a polished demo video. Persistence is useful right up until it becomes a garbage pile of half-finished context.

The containment story is stronger than I expected from a project like this. Container per loop, egress allowlist, no direct route to the machine besides the hub port. That’s the right instinct. Still, I don’t think “contained” should be read as “safe” in any absolute sense. The README itself seems careful on that point, which I appreciate. And the bare-process mode is honest about being uncontained, which is better than pretending a convenience flag is a security boundary.

If I were trying this, I wouldn’t start by giving it real production work. I’d pick one annoying, bounded task: maybe a docs cleanup or a small internal refactor, then see whether the Telegram/Slack layer actually helps or just turns the agent into a noisier version of a terminal session. The interesting test isn’t whether it can code. Claude already can. The question is whether adding persistence, coordination, and human-facing chat makes the whole thing feel less fragile, or just more elaborate.

Reference: GitHub - enes-alatas/spool: fleet of persistent Claude Code coworkers you talk to in Telegram and Slack. Each in its own container, on your own plan without API costs.

同じ著者の記事