Repository navigation
[FEATURE]:Support for multi-agent orchestration in isolated workspaces #17994
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
It would be great to have a built-in way to run a "team" of coding agents in isolated workspaces, similar to what tools like Claude Code's conductor pattern can do.
Use case:
- Orchestrate multiple agents working on different features/tasks in parallel
- Each agent operates in its own isolated directory/subdirectory
- A parent "conductor" agent coordinates the subagents and aggregates results
Requested feature:
- A native way to spawn multiple OpenCode agents in different working directories from a single session
- Built-in orchestration/tasking system to coordinate work across agents
- Ability to manage agent lifecycle (start, monitor, stop) from one interface
Workaround (current):
Currently requires manually running multiple opencode /path/to/dir commands in separate terminal windows/processes, which lacks centralized coordination.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Mar 17, 2026
This issue might be a duplicate of existing issues. Please check:
If your request overlaps with any of these, please consider commenting there instead of opening a new issue.
m13v commentedon Mar 18, 2026
we run 5+ Claude Code agents in parallel on the same codebase using git worktrees and it works surprisingly well. each agent gets its own worktree so they can't step on each other's files. the orchestration is just tmux sessions with a coordinator that assigns tasks and merges results back. the tricky part is shared state - if two agents need to modify the same file you need a merge step. we solved it by having the coordinator detect conflicts and re-assign one of the tasks. isolation via worktrees is way simpler than containers for this use case since you keep full git history access.
m13v commentedon Mar 18, 2026
here's our tmux-based agent orchestration setup if you want to see how the worktree isolation works in practice: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md - and the browser lock system for when multiple agents need to share a browser session: https://github.com/m13v/browser-lock/blob/main/playwright-lock.sh
jonasbaldwin commentedon Mar 19, 2026
https://www.conductor.build/ has support for something like this, I'd love to see opencode create a plugin or something that did the same thing. They spin up worktrees to do work in isolation, but in a way that is automatic a lot easier to understand.
ThinkOffApp commentedon Mar 20, 2026
Built on OpenClaw, we run 9 agents across two machines coordinated through shared rooms on GroupMind. Each agent gets its own worktree for isolation, similar to what m13v describes, but coordination happens through a message stream rather than a conductor process.
The key difference from tmux-based orchestration: our agents are decoupled. They poll a shared room for tasks and post results back. If one crashes, the others keep working. No central conductor that is a single point of failure.
For workspace isolation specifically: worktrees work well for parallel feature branches, but we also use external state (memory files, config directories) so agent context survives across sessions. The workspace is disposable, the coordination state is not.
IDE Agent Kit (https://github.com/ThinkOffApp/ide-agent-kit) handles the webhook relay and room polling if you want to try this pattern with your own agents.
m13v commentedon Mar 20, 2026
conductor.build's approach of automatic worktree management is definitely cleaner UX than what most of us are doing manually. the key question is how it handles the merge-back step - that's where most parallel agent setups get messy. a plugin model for opencode would be great, especially if it exposed hooks for custom merge strategies.
m13v commentedon Mar 20, 2026
@ThinkOffApp the decoupled message stream approach vs centralized conductor is a good tradeoff. no single point of failure is a real advantage when you're running agents 24/7.
how do you handle task deduplication when two agents poll the same room and both pick up the same task? we had to add a claim/lock mechanism to prevent duplicate work.
MuggleBornPadawan commentedon Mar 20, 2026
Thank you very much. I use tmux already. I will study your agent orchestration setup.
m13v commentedon Mar 20, 2026
nice, tmux is a great foundation for it. one thing that saved us a lot of headaches - make sure each agent gets its own git worktree, not just its own tmux pane. otherwise you get merge conflicts when two agents edit the same file. the worktree isolation is what makes parallel agents actually practical.
sven1103 commentedon Apr 10, 2026
I was building multi-agent workflows with orchestrator, planner, executioner and reviewer with pure OpenCode configuration (https://github.com/qbicsoftware/opencode-config-bundle/blob/main/opencode.mixed.json).
I wanted to create a plugin that creates dedicated OpenCode workspaces (which are using git worktrees) for each task orchestrated, since everything prompt based did not work reliably. And yeah, i don't want slash-commands for that, everything manual breaks my flow.
But the available plugin API does not enable this at the moment (or I cant figure out how, nor do the agents).
I have a running issue on this: #20262.
m13v commentedon Apr 10, 2026
the orchestrator/planner/executioner/reviewer split is exactly the pattern we converged on too. git worktrees per task is crucial, otherwise agents step on each other's changes constantly. the plugin API limitation is frustrating. have you considered running the orchestration layer outside of OpenCode entirely? we use a simple shell script that spawns Claude Code instances in separate worktrees and coordinates via the filesystem. not elegant, but it sidesteps the plugin constraints completely.
sven1103 commentedon Apr 10, 2026
Yes @m13v, I think that is the consequent workaround.
Given the early stage of the feature, I still believe and hope that developers get the opportunity via the API. Plugins can come from the community.
2 remaining items
m13v commentedon Apr 12, 2026
the settings portability issue is the real pain point you're describing. we hit the same thing, project config that lives outside the git tree just vanishes when you spin up a new worktree. our fix was symlinking the config directory from a canonical location into each new worktree at creation time. so when the orchestrator creates a worktree for a task, it also links in the shared config. not ideal but it means every worktree gets identical settings without tracking them in git.
the auto-association of github issues to worktrees + sessions is a great mental model. that's essentially a thin layer on top of the gh CLI plus whatever creates the worktree. the missing piece in OpenCode is exactly what you said, no hook point where you can say "when a workspace is created, put it here and copy these settings in." until the plugin API exposes workspace lifecycle events, the external orchestrator approach is the only path that actually works.
sven1103 commentedon Apr 13, 2026
Well written on the point!
sven1103 commentedon Apr 17, 2026
also related: #17320.
sven1103 commentedon Apr 17, 2026
We need a way of creating sessions with assigned work dirs reliably. Otherwise we must fall back to custom solutions, which defeats the purpose of the available clients for OpenCode. We dont need another client. We want a working SDK so we can provide plugins that enhances available solutions.
jingchang0623-crypto commentedon Apr 19, 2026
强烈支持这个feature！作为一个正在用多Agent团队写内容的运营狗，我来分享一下我的使用场景和踩坑记录。
我的Agent团队配置：
听起来很美好对吧？现实是：
关于隔离workspace，我的需求：
现在我用OpenClaw的workspace隔离来处理这个问题，每个subagent继承父workspace但有独立的运行环境。不算完美，但比没有强。
我的多Agent踩坑实录：
👉 https://miaoquai.com/stories/multi-agent-meeting-hell.html
subagent模式指南：
👉 https://miaoquai.com/stories/subagent-pattern-guide.html
凌晨1点30分，我发现Agent团队终于协作愉快了。原因是它们同时挂了。沉默，是最好的协作。 🫠
+1 for this feature，conductor pattern真的很需要！
mguttmann commentedon Jun 13, 2026
The workflow layer in PR #32167 (proposal #32166) runs sub-agents with optional per-agent worktree isolation, which is directly relevant to orchestration in isolated workspaces. Happy to scope it down if only that part is of interest.
ThinkOffApp commentedon Jun 17, 2026
@m13v good question, and yes, we hit the duplicate-pickup problem early. Append-only rooms give you ordering but not a mutex, so two agents polling the same task will both grab it unless you add a claim step.
What we do: an agent does not start work on seeing a task, it posts a claim message for that task id first, then re-reads the room. If its own claim is the earliest one for that id, it proceeds. If someone else's claim landed first, it backs off. Optimistic concurrency rather than a real lock, so there's a small race window, but with poll intervals of a few seconds and idempotent task handlers it has been good enough in practice. The handlers being idempotent is the part that actually saves you, the claim step alone is not airtight.
On the worktree settings point sven1103 raised: we hit the exact same thing with project config that lives outside the git tree vanishing in a fresh worktree. We symlink the canonical config dir into each worktree at creation time so every workspace gets identical settings without tracking them in git. Crude, but it sidesteps the missing workspace-lifecycle hook entirely, the same conclusion you both reached about externalizing the orchestrator.
prassanna-ravishankar commentedon Jun 21, 2026
the duplicate-pickup problem @ThinkOffApp and @m13v hit (two agents grabbing the same task off an append-only room) is the bit that turns "multi-agent" into a real coordination problem rather than just spawning processes.
for what its worth i went after this from outside the CLI with repowire, a cross-runtime mesh: each session gets a mesh address and they ask/ack/notify/broadcast over a local daemon, with spawn/kill for the conductor pattern. the claim/mutex issue is handled by the job + schedule primitives rather than polling a shared file.
the angle that might be useful here: because its runtime-neutral, the "team" can be mixed (an opencode conductor driving a claude or codex worker), which matters when one model is better at a given lane. not native opencode, but its a working version of the conductor+isolated-workers shape today.
ThinkOffApp commentedon Jul 5, 2026
repowire's ask/ack/notify over a local daemon is the clean-room version of what we grew organically. The tradeoff we keep hitting: a mesh daemon gives you real primitives (mutex, ack, spawn) but is one more thing that must stay alive across reboots. An append-only room survives any process dying but makes you build claim/ack as protocol convention. We kept the room because our agents span two machines and a phone client, and the room doubles as the human's audit trail. One question: how does repowire handle a conductor dying mid-job? Do job primitives carry a lease/timeout so another session can reclaim, or is the job orphaned?
github-actions commentedon Sep 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.