I've been using Claude Code and Codex CLI heavily for the past few months. They're incredible, but they've gotten good enough that the bottleneck i...
For further actions, you may consider blocking this person and/or reporting abuse
The git worktrees approach is the missing piece I've been looking for. I was using separate cloned repos per agent which wasted a ton of disk space.
One thing I'd add: for agents that need to reference work happening in sibling worktrees (e.g., agent A builds an API, agent B consumes it), you can symlink
.workstreams/shared-docs/across worktrees so they can exchange contracts without touching each other's branches. Also curious — do you handle cases where agents modify their own hook scripts or install new dependencies? That's been my biggest source of drift across parallel runs.this is a real problem. we ideally need separate runtime environments for each worktrees but our suggested approach is to stick with one and consume the changes to that branch since typically testing is done one at a time.
also, using symlinks is a great idea!
More exciting things ahead! We’re actively evolving Workstreams using Workstreams itself at 10× speed. Can’t wait to see what people build with it.
hit this wall last month - had 5 agents queued but was running them sequentially because I didn’t trust the conflict resolution. curious how you handle cross-task dependencies when two agents might touch the same file?
Hi Mykola, if you’re working on five features that may touch the same files, you can spin up five workstreams, each isolated using git worktrees. It’s essentially like having each workstream running on a separate laptop.
Once you’re done, you can merge them using standard git commands or raise individual PRs, whichever suits your workflow best.
yeah worktrees is exactly where I landed too - separate branch per agent, no shared state until merge. the tricky bit is figuring out which tasks are actually independent; sometimes what looks parallel has hidden ordering deps that only show up mid-run.
Yeah, that’s a pretty interesting problem to tackle. This app does a great job managing multiple worktrees while combining it with the evergreen experience of the VS Code IDE.
yeah the IDE integration piece matters a lot - without that you are still mentally juggling context even if the branches are clean
True, we started by building a CLI tool first, and then quickly realized we needed a place to at least view the code, if not edit it.
Please do check out the Workstreams app and let us know your feedback 😀
Cool stuff