By September 2026, more than 40% of pull requests on GitHub began with an agent's first draft, according to GitHub's Octoverse report. The report counted 110 million such pull requests in that month. When agents produce work at that scale, the bottleneck shifts: developers need useful ways to run tasks side by side without losing track of their changes.
Two tools have recently added features that speak to this problem, but they solve different parts of it. Qwen Code 0.27.0 added richer child-question handling in managed-agent sessions. OpenCode 2.2.6 added scripted runs in Git worktrees and optional shared MCP connections. Comparing them as if they were interchangeable agent brands misses the useful question: do you need help coordinating questions inside a managed session, or cleanly isolating separate coding runs?
This comparison is based on the projects' public release notes and documentation, not a hands-on benchmark. The versions discussed are Qwen Code 0.27.0 and OpenCode 2.2.6, released November 7 and November 6, 2026 respectively. Check the current release notes before adopting them, since both projects move quickly. (Qwen Code release notes, OpenCode release notes)
The key difference: questions versus workspaces
Qwen Code's 0.27.0 release describes managed-agent sessions that can hold multiple child questions at once. The questions can be answered in any order, and drafts and errors remain separate per child. This is useful when an agent needs clarification on several independent points and the session should preserve each answer distinctly.
OpenCode's 2.2.6 release focuses on the execution environment. Its opencode run --worktree option starts a scripted session in a new Git worktree, and --worktree=<name> lets you name that worktree. The same release adds --archived for scripted sessions that should stay out of the regular session list. It also adds opt-in MCP connection pooling for compatible setups.
These are not direct substitutes. Child questions help manage a conversation. Worktrees isolate file changes. One does not automatically give you the other.
What parallel agent work actually needs
“Run agents in parallel” often compresses several separate requirements into one phrase:
- Task independence: Can each task be expressed with a clear scope and completion condition?
- Filesystem isolation: Can one run edit files without colliding with another run?
- Question handling: Can the agent ask for missing information without mixing answers?
- Tool reuse: Do multiple sessions need the same MCP service, and can that service safely share connections?
- Reviewability: Can a developer identify what each run changed and test it before integrating the work?
A tool may help with one or two of these without solving the whole workflow. A feature list is not a concurrency guarantee, and a Git worktree is not a safe permission boundary by itself.
Where Qwen Code 0.27.0 fits
Qwen Code's headline additions are aimed at managed-agent and channel workflows. Alongside the child-question behavior, the release added a repository filter in the GitHub channel editor, with allowlist and blocklist modes, and improved delivery of pull-request-bound and plain comments. The release notes also mention reliability and security-related changes in the managed-agent runtime. (Qwen Code 0.27.0 release)
That makes Qwen Code worth evaluating when agent work is organized through managed sessions or connected GitHub conversations. If a session pauses for several clarifications, separate pending questions can make it easier to provide answers without confusing one prompt with another. Repository filters can also help limit which repositories the GitHub channel processes.
But be precise about what the feature says. The release notes do not claim that child questions create separate worker agents, separate branches, or isolated worktrees. They describe multiple pending child questions in a managed-agent session. Treating that as “parallel coding agents” would overstate the documented behavior.
The repository filter is also not a complete security model. The official documentation warns that repository and sender policies have distinct behaviors, and that some configurations on public repositories can allow GitHub users to submit prompts that drive the agent in its working directory. Review the actual policy and permissions for your setup rather than assuming a filter alone constrains every action. (Qwen Code GitHub channel security notes)
Where OpenCode 2.2.6 fits
OpenCode's worktree option is more directly useful when you want a scripted task to work in a separate Git worktree. Separate worktrees can reduce accidental edits to the same checked-out files when you are handling independent tasks. The release also allows naming the worktree and starting the session archived, which can make automation output easier to keep out of a normal interactive session list.
There are important boundaries. The release notes say --worktree cannot be combined with --continue or --session. This option creates an isolated working directory; it does not prove that the task is independent, that two agents will avoid conflicting changes, or that the resulting patches are correct. You still need review and tests.
MCP pooling is a separate optimization. OpenCode says enabling pool: true can share a connection to an MCP server across projects using the same setup, reducing process count and startup time. That can matter in environments with many sessions, but it is opt-in and should be used only when the server's connection-sharing behavior is appropriate for your use case. (OpenCode 2.2.6 release notes)
A fair comparison by workflow
If the challenge is unanswered questions: Qwen Code 0.27.0 documents multiple pending child questions with separate drafts and errors. That is the more relevant feature when a managed session needs several clarifications.
If the challenge is file collisions: OpenCode 2.2.6 documents a command-line option to begin a scripted run in a Git worktree. That maps more directly to isolating file edits between runs.
If the challenge is GitHub channel scope: Qwen Code's new repository filters are relevant, but they must be paired with carefully reviewed sender and permission policies.
If the challenge is repeated MCP startup: OpenCode's opt-in pooling is relevant when its compatibility and sharing assumptions fit the MCP server.
If the challenge is broad agent autonomy: Neither release note establishes a complete security boundary. You still need to control credentials, network access, command execution, repository permissions, and review.
This is a comparison of documented capabilities, not a verdict on model quality, speed, or output accuracy. Neither release announcement provides a controlled benchmark for those questions.
A small, safer way to test either tool
Start with two independent, low-risk tasks in a disposable clone or a repository with a clean rollback path. Do not begin with production credentials or deployment permissions.
- Write down the task boundary. Give each run a distinct goal, allowed paths, and a testable finish condition.
- Choose the feature that addresses the actual bottleneck. Use Qwen Code's child-question handling for clarification-heavy managed sessions. Use OpenCode's worktree option when separate working directories are the goal.
- Keep tasks separate in Git. Name branches or worktrees clearly. Avoid assigning two agents overlapping files unless the overlap is intentional and reviewed.
- Limit capabilities. Give the agent only the repository and tools needed for the task. Keep secrets and production access outside the environment unless essential and explicitly controlled.
- Inspect the diff. Review every changed file, run the project's tests, and check generated commands or dependencies before merging.
- Record what failed. Note setup friction, repeated questions, merge conflicts, abandoned sessions, and review time. A workflow that creates more integration work may not be faster.
For OpenCode's documented scripted worktree mode, the command shape is:
opencode run --worktree=task-a "Add validation for the import endpoint and run the focused tests"
The release documents --worktree=<name> as an option. The task text above is an illustrative prompt, not an official example or a claim that the command was executed here. Before using it in automation, check the installed version's help output, configure a timeout, and test how the tool behaves when a command or background job does not finish. The 2.2.6 notes specifically say scripted runs wait for background jobs started by the prompt, so a long-running process can keep a run open.
Qwen Code's release note describes a Web Shell “Ask for details” side task for pending question panels. That is a UI action, not a command-line equivalent to the OpenCode example. Keep the comparison honest: one documented capability helps collect clarifications; the other creates a worktree for a scripted run.
Which one should you choose?
Choose Qwen Code for evaluation if your work already uses its managed-agent sessions or GitHub channel and your friction is handling several pending clarifications or narrowing repository scope. Review channel permissions carefully, especially on public repositories.
Choose OpenCode for evaluation if you want scripted sessions to begin in named Git worktrees, keep automation runs archived, or reuse eligible MCP connections across projects. Add timeouts to automated runs and inspect the resulting worktree and diff.
Choose neither based on a headline alone if your real need is fully autonomous parallel implementation. First verify that the agent's worker model, workspace isolation, permission system, and integration path match that need. A feature named “child questions” is not the same as parallel workers; a worktree is not a complete sandbox.
Save-worthy decision rule: clarify the agent's uncertainty with a session feature; isolate its edits with a workspace feature. Then review both the permissions and the diff. If you cannot state which layer a feature controls, do not rely on it as a safety boundary.
The larger trend is not simply that agents write more code. GitHub's September data shows more pull requests starting from agent drafts, and its report also notes that agent-started pull requests more often touch multiple files. That makes task boundaries and review discipline more important, not less. The statistics are GitHub's own platform data, and the report defines agent-started PRs using detected agent involvement, so they should be read as platform-specific measurements rather than a census of every developer's workflow. (GitHub Octoverse 2026)
I write about practical AI engineering and developer tools. Subscribe for more comparisons and implementation guides. Have you tried Qwen Code or OpenCode for multi-session work? Which part of the workflow saved time, or created more review work?
Top comments (0)