Running Parallel Autonomous Claude Instances From a Phone via tmux
An automation system that runs multiple Claude Code instances in tmux sessions, each on its own project, controllable and monitorable remotely over Telegram.
This project answers a specific frustration: claude -p single-shot mode gives you an answer but strips away the full tool loop. I wanted Claude Code with real Read, Write, Edit, and Bash access, running unattended, on several projects at once, controllable from my phone. The trick that makes all of that possible is almost embarrassingly simple: run Claude Code inside a tmux session and send it messages programmatically.
Why tmux is the whole architecture
Putting Claude in a persistent tmux session preserves the full interactive tool experience while making the process scriptable. Shell scripts can inject messages, and a Telegram bot can do the same from anywhere. That single decision unlocks the rest of the system. Each project gets its own tmux session named per project, its own dedicated log directory, and its own independent automation loop, so multiple Claude instances work different codebases simultaneously without stepping on each other.
Because the sessions are addressable, targeting a specific one is just a matter of environment variables pointing commands at the right session. You can start a new project, kick off a continuous development loop for it, send commands to one session in particular, and monitor all of them at once.
Remote control and routing
The remote piece is where it earns its keep. Monitoring and steering happen over Telegram, which means the whole fleet is reachable from a phone. On top of the raw control there is a routing layer with a Manager Claude and codex integration to direct work, plus autonomous development loops that keep an instance grinding on a task until it completes rather than stopping after a single turn.
The stack is deliberately polyglot. The general workflow auto-detects the project stack, and the system explicitly supports Node, Python, Rust, React, and Web3 and Solana projects, so the same control plane drives very different codebases.
Being honest about the ceiling
I labeled this production-ready for simple and medium tasks, and I meant the qualifier. The hard, honest limitation is that complex iterative debugging can be challenging, because Claude tends to pause and ask for permission instead of pushing forward autonomously. That tension, autonomy versus asking, is the real open problem in this class of tool, and pretending it is solved would be dishonest. It remains an internal tool, actively used to manage my own projects.
The lesson worth keeping is that you do not need exotic infrastructure to get parallel autonomous agents. A persistent terminal multiplexer, per-project sessions, and a chat bot for control get you surprisingly far. The remaining hard part is not the plumbing, it is coaxing genuine autonomy out of a model that would rather check in.
Have something that needs building, or stabilizing?
These notes are the work log. The paid work runs through Moonshine Labs, my product and engineering studio. Tell us what you're building, or grab a call.
Work with us →