A few months ago I started running AI coding agents in parallel: one fixing a bug, one updating docs, one trying a refactor. The agents were fine. My repo was not.
Every agent CLI works in your working tree. Two agents on the same repo means they edit the same files, stage each other's changes, and occasionally commit on top of one another. The "solution" I kept seeing was manual git worktrees: create one per agent, remember the branch names, remember where you put them, clean them up later. It works, but it's fiddly enough that I kept not doing it.
So I wrote the thing I wanted: taskpods, a small Python CLI that wraps git worktrees into disposable "pods".
pip install taskpods
What a pod is
A pod is a git worktree plus a branch, managed as one unit. One command creates it and drops your agent inside:
taskpods start fix-auth --agent "claude -p 'fix the token refresh bug'"
That creates .taskpods/fix-auth/ as a worktree on branch pods/fix-auth and runs the agent there. --agent takes any command, so it works with claude, codex, gemini, opencode, a shell script, whatever you use. Start a second pod and the two agents never see each other's files:
taskpods start docs-update --agent "claude -p 'document the config options'"
taskpods list
The lifecycle
When an agent finishes, I review the diff like I would for a junior dev:
git -C .taskpods/fix-auth diff main
If it's good:
taskpods done fix-auth -m "fix: token refresh" --remove
That commits, pushes the branch, opens a PR if you have gh installed, and removes the worktree. If it's bad:
taskpods abort fix-auth
and the pod never existed. Abort refuses to delete work you've already pushed, which has saved me once already.
Design choices I cared about
-
Zero config. No daemon, no TUI, no config file to learn. It's one Python file over plain
git worktreecommands. If you know git, you already know what it's doing. - Agent-agnostic. Claude Code has a native worktree flag now, but it's Claude-only. I wanted the same workflow regardless of which agent I'm using that week, and I wanted the lifecycle (list / done / abort) in one place instead of in my shell history.
-
Boring on purpose. Pods are real worktrees with real branches. Nothing is hidden in a database somewhere; you can
cdinto a pod and use git normally.
What's next
It's MIT-licensed and on PyPI: github.com/yanairon/taskpods. v0.4.0 just shipped with the --agent launcher. I'd genuinely like to hear how other people run parallel agents - if you have a workflow that works better, tell me about it in the comments.
Top comments (2)
The idea of encapsulating git worktrees into disposable "pods" is quite innovative, especially for managing parallel AI agents. This approach not only simplifies the workflow but also minimizes the risk of agents interfering with each other, which can be a significant pain point. One potential improvement could be adding a feature to visualize the status or health of each pod, perhaps with a simple command, to enhance oversight during agent operations. If you’re looking for help with expanding features or optimizing the existing implementation, I’d be happy to discuss a paid collaboration! How has the community responded to using taskpods so far?
Thanks! There's already a lightweight status overview via taskpods list, which shows active pods and their paths. I'm keeping taskpods intentionally small and daemon-free, but richer status output could fit that direction. It's still early - I just launched v0.4.0, so I'm collecting feedback now and will let real usage guide what comes next.