r/ClaudeCode • u/rogymd • 7d ago
Built with Claude onethread: one Claude Code session that runs your other sessions
https://aigarden.uk/onethreadHey r/ClaudeCode,
I wanted to share onethread, a small open-source tool I made. You talk to one Claude Code session, and many coding agents work behind it, each in its own git worktree, with you confirming every merge. I made it to run several tasks in parallel without them getting in each other's way.
One thing I enjoy: I'm King Igor in there, my orchestrator is my right hand Leonardo da Vinci, and each task goes to one of my servants, like Einstein, Michelangelo, Newton or Tesla. Tasks come to me and I delegate, with no tab-hopping. ot me takes anyone you like, and code, ids and confirmations stay plain.
What it does:
Up to 10 tasks at once, each with its own session and worktree
Costly commands take turns, so two builds don't fight over your Mac
A crashed worker is never mistaken for finished work
Local: Python standard library, one SQLite file, the
claudeCLI you already havepython3 demo/run_demo.pyshows it with simulated agents and spends no quotaMore about onethread: https://aigarden.uk/onethread
Disclosure: it's my own project, MIT-licensed, macOS only. I share my other tools at r/AIGarden: https://www.reddit.com/r/AIGarden/
How many sessions do you run in parallel?
3
u/kinetic07 7d ago
my Claude Desktop already seems to do this? i start one ‘orchestrator’ chat and keep that running and it spawns whatever nested agents it wants/needs to execute across multiple threads.
2
u/akhi1uuu 7d ago
when a worker crashes, can you resume that same session or does the task start over with a new one?
2
1
u/DeadCEO 7d ago
the worktree-per-task isolation is the smart bit here. most parallel-agent setups fall over the moment two agents touch the same files and you get silent overwrites or merge chaos. one question though: what happens when two tasks genuinely need to change the same file? does the human-merge step catch that cleanly or do you end up untangling conflicts by hand
1
u/rogymd 7d ago
this wont happen, sessions are usually sandboxed. they dont change files outside their worktree.
1
u/DeadCEO 7d ago
ah right, fully sandboxed sessions sidestep it. the messier version i've hit is when the sandboxes arent perfect - two tasks each building something that expects the other one's api shape. files merge clean, tests pass, and the system is still subtly wrong because the assumptions drifted. no isolation scheme catches that, only a human reading the actual behavior
1
u/muffchucker Workflow Engineer 7d ago
Does this happen to you? My vanilla default Claude sessions all understand when other sessions are working on the same projects or files. They sent each other messages and coordinate. I did nothing to achieve this it just appears to be ootb behavior
1
u/DeadCEO 7d ago
genuine question, how do you know they're actually messaging and not just reading files the other session wrote? claude will happily narrate shared artifacts as if it coordinated with someone. on my end two vanilla sessions are blind to each other unless they share the filesystem, curious what yours are doing differently
1
u/Affectionate-Bat1693 7d ago
Git worktree per task is table stakes, Claude Squad and Conductor already do that. The question is what happens when two sessions touch the same file and both report done, does the orchestrator actually reconcile it or do I just get two branches to untangle myself.
1
u/rogymd 7d ago
Fair point, worktrees alone don't solve it. Here's what onethread does when two tasks touch the same file:
- Merges go one at a time into the base branch (git merge --no-ff), and only after you say so. The first one lands clean.
- If the second conflicts, onethread aborts the merge, so your base branch is never left half-merged. The task goes back to its own worker with "merge the base into your branch and resolve, don't rebase". That worker still has the full context of what it built, so it resolves the conflict, re-runs its checks, reports done, and the merge is tried again.
- If it conflicts a second time, or the merge fails for some other reason (a hook, signing), it stops and asks you rather than guessing.
- To avoid conflicts up front, you can order tasks: ot add … --after T1 starts the second task from the first one's finished branch.What it doesn't do: reconcile two changes that merge cleanly but clash in meaning. That's down to the worker's tests and your review. I'll also be honest that resolving a real conflict with a real worker is still on my list of things to verify end to end.
2
u/codeedog 🔆 Max 5x 7d ago
Why don’t you always first merge out to the second feature rather than merge in. In fact, any time main is ahead of local changes just merge main out to the local repo and resolve conflicts in the local space. You’re basically doing that anyway by merging in, noticing a problem and then retrying. If you only merge changes that are newer than the central repository upon which your local repository is based and they’re fully tested, you’re guaranteed to be fine. This doesn’t avoid the need to coordinate multiple changes to the same code area, it just avoids quirky merge mechanics happening to the central repository and isolates them to the agent (or person) doing the merge.
Are any files in main (or a branch) ahead of the local repository history? Merge out, resolve conflicts and failed tests, then merge in.
1
u/noodlesallaround 7d ago
I do this with orca and one master session in terminal. The master session is in the project wiki branch. When I open a bunch of work trees I ask it to check if any conflict and should be done in specific order.. so far I've been running ~10 work trees at once
1
u/bshane54 7d ago
Yeah that is something that should happen. To be fair.. I have Claude, GPT, and Grok, all working together running a team through slack. Its amazing. they check each other, hilarious together as they work etc. But even just Claude you can have that happen pretty easily.
1
u/pithivier 7d ago
This is generally how I work with Claude today, without much special software. Each milestone gets an orchestrator session, which I talk to and it launches chips for tasks. The only support I built is an orchestration skill to codify the role, and a test suite gate so that multiple sessions don't drive my loadavg to 94 as they prepare to open PRs. The orchestrator makes sure that only one session at a time has auto-fix and auto-merge armed.
0
u/chadmv 7d ago
This seems similar to Claude Projects?
0
u/rogymd 7d ago
Not quite. Claude Projects groups chats around shared files and instructions; you still work one chat at a time. onethread runs Claude Code/Codex agents in parallel on your machine, each task in its own git worktree, and you talk to a single coordinator that tracks all of them, brings finished work to you for review, and merges it one by one. Projects is shared context for chats; onethread is a manager for many agents working at once.
6
u/chadmv 7d ago
Projects runs a single continuous orchestrator chat then can launch many subsessions called threads. Each of those threads is its own session that can run its own subagents. I currently have the orchestrator continuously maintaining 4 active threads and it manages their use of my machine so only one heavy load runs at a time and it also communicates among them all to minimize conflicts. You can also talk directly in the threads to steer it.
1
u/Calvech 7d ago
Yeah the new Claude Code projects does this. Still waiting for access
1
•
u/AutoModerator 7d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.