Parallel coding agents have an ordinary mechanical problem before they have an intelligence problem. If two sessions edit one checkout, one session’s file write changes the other session’s view; one git add changes the shared index; one branch switch can invalidate the other session’s assumptions. A model can reason perfectly about an obsolete snapshot and still produce the wrong patch.
A Git worktree gives each session a distinct working directory and branch context. That makes a large class of collisions less likely and makes the resulting diff easier to attribute. Qwen Code’s new Web Shell path turns this existing Git mechanism into a product affordance: create an isolated task with one click, mark it visibly, and restore its location after a daemon restart.
The word “isolated,” however, needs a precise object. Here it describes file and index separation. It does not automatically isolate network credentials, package caches, databases, browser sessions, cloud accounts, local services, environment variables, or the human decision to merge. An agent in a separate directory can still call the same API, write to the same database, deploy the same Worker, or delete a remote resource if its tools and credentials allow it.
The release moves worktrees into the normal session model
The official 23 July update says Qwen Code shipped three stable releases with more than 220 merged pull requests. Its Web Shell now offers a “New Worktree Task” action. The daemon creates the worktree below the repository at .qwen/worktrees/<slug>, changes the session’s working directory, marks the session with a purple worktree badge, and withholds the option for non-Git directories. source ↓
This is more than a convenience button. The product now has to preserve an identity relationship among a conversation, a filesystem location, a branch, and the main checkout from which the task began. If any one of those drifts, a session can accurately remember its conversation while operating on the wrong files.
The same release notes name fixes for artifacts resolving to the wrong location in worktree sessions and for running worktree sessions failing to open. Those fixes are useful evidence about the boundary itself: path routing and lifecycle restoration are not incidental details. They are part of whether isolation is real in use.
Separate checkout does not mean separate system
A worktree provides a new place for tracked files and an independent index. That is the correct control for concurrent source edits. It supports narrow attribution: a team can inspect which branch a task used, what changed there, and whether the main checkout stayed untouched.
It does not clone the world around the repository. A dependency directory may be linked from the main checkout. A build may reuse a global cache. Tests may point at the same local port. Two agents may read the same untracked configuration or credential store. A relative output path can be isolated while an absolute path writes to one shared location.
The editorial consequence is simple: record the resource being isolated. “This task ran in a worktree” supports a claim about checkout interference. It does not support a claim that the task was sandboxed, that secrets were hidden, that outbound traffic was blocked, or that production was protected.
Creating the boundary is itself an authorized change
Qwen’s design record says the session-level worktree tools should respond to an explicit request such as “start a worktree,” not infer creation from a generic instruction to fix a bug. It also specifies that exit may keep the worktree or remove both the directory and its branch; removal with uncommitted changes is refused unless discard is explicitly enabled. source ↓
That design choice preserves an important distinction. “Use a worktree” authorizes creation of a repository-side structure and branch for the task. “Fix the bug” states an outcome but does not necessarily authorize extra branch or directory lifecycle. The product may offer autonomous worktree selection for a subagent, but the parent task’s effect scope still governs what that subagent can do inside it.
Cleanup deserves the same care. A clean directory is not necessarily disposable: it may contain a useful commit not yet reviewed or pushed. An uncommitted directory is not necessarily valuable: it may be a failed experiment. The safe decision depends on a receipt that binds the task, branch, base commit, diff, commits, and acceptance state. File cleanliness alone cannot make that decision.
The branch boundary does not widen permission
A worktree can prevent one agent from staging another agent’s file changes. It cannot grant either agent permission to stage, commit, push, deploy, send a message, change a database, or call a paid service. Those are effect decisions governed by the current task and the capabilities exposed to the process.
This matters most when concurrency feels safe. Once file collisions disappear, teams are tempted to run more agents with broader tools. Parallelism then multiplies the number of actors that can touch shared systems even though their source directories are separate. The failure moves from “two agents edited the same file” to “two agents deployed different branches to the same target” or “both tests mutated the same account.”
A robust agent platform therefore needs two independent maps. The workspace map answers where the session may read and write files. The effect map answers which external systems, commands, credentials, and irreversible actions it may use. Worktree isolation improves the first map. It does not replace the second.
Persistence preserves context, not truth
The release says worktree information is persisted to a sidecar and rebuilt when a session is restored. The design record describes stored fields for the slug, path, branch, original directory, and original branch. It also documents that some resume combinations across different worktrees or the main checkout cannot be found because session storage is keyed from the current working directory. source ↓
Restoring the recorded directory is necessary but not sufficient. While the session was stopped, another actor may have advanced the target branch, changed the main branch, deleted a remote ref, modified credentials, upgraded dependencies, or changed the issue requirements. A remembered path is historical context. Before mutation resumes, the agent should re-read the current branch, HEAD, status, staged diff, relevant files, and effect authority.
The release’s visible badge is valuable because location should be inspectable. But a badge is a presentation of stored state, not a cryptographic proof of current repository identity. High-risk workflows should compare the live path and Git common directory, then bind the result to the session receipt.
Isolation is the start of integration, not its verdict
Worktrees make parallel work easier to produce. They do not make parallel outputs compatible. Two individually clean patches can change the same interface, rely on contradictory assumptions, or each pass tests against a base that no longer exists after the other patch lands.
Acceptance therefore happens against an integration candidate, not against the isolated branch alone. Rebase or merge onto the intended live base, inspect the resulting diff, run the relevant build and tests, and verify any runtime or public effect in the exact target system. A successful branch test is evidence for that branch snapshot; it is not a certificate for the later combined tree.
Nor should an agent silently integrate its own work merely because its worktree is clean. The right output may be a preserved branch and a report, a patch ready for review, or an approved merge. The current instruction determines which terminal state is allowed.
What a team should prove before scaling parallel agents
The sources document product mechanics, not an organization’s acceptance policy. The following gates are editorial consequences of the distinction between workspace isolation and effect authority:
- 01Bind each task to a live base.
Record repository identity, worktree path, branch, base commit, current HEAD, status, staged diff, and the instruction that created the task. Revalidate them after resume.
- 02Name the isolation domain.
State whether the boundary covers tracked files, the Git index, dependency directories, caches, ports, databases, secrets, browsers, cloud accounts, and network access. Treat every unlisted resource as shared until tested.
- 03Keep authority outside the branch.
Expose only the tools and credentials the task needs. A worktree does not imply permission to commit, push, deploy, delete, purchase, message, or mutate another system.
- 04Test the integration tree.
After combining accepted changes, rerun builds, tests, static checks, and target-system acceptance. Preserve the exact integrated commit or artifact that produced the result.
- 05Make cleanup a reviewed outcome.
Report retained branches, uncommitted changes, commits, unpublished refs, and generated artifacts. Remove a worktree only when the authorized lifecycle and evidence record permit it.
Qwen Code reduces file and index interference and makes the active worktree visible.
Teams still need explicit boundaries for credentials, services, network calls, and destructive actions.
Only the combined tree and exact target-system checks establish that parallel work can safely ship.
What the checked record does not establish
The official pages do not prove that every Qwen Code entry point has identical worktree behavior, that every external tool respects the selected directory, or that dependency links and shared services are isolated. The design page mixes implemented phases, future items, and known storage limits; the 23 July release establishes the named Web Shell behavior, not every design aspiration.
Limit
This issue reads Qwen’s official 23 July product update and its worktree design record as checked on 27 July 2026. China AI Desk did not run Qwen Code, inspect the merged implementation, or test multi-session failure modes for this issue. Claims about authority, shared resources, and integration gates are editorial analysis, not product documentation.
What would change this assessment
A published threat model for worktree sessions; target-specific sandbox and credential boundaries; end-to-end tests showing which tools and paths remain shared; signed receipts binding session, base, diff, and integration result; or evidence that deployment and other external effects are independently scoped per task rather than merely per directory.
A worktree can separate edits. It cannot decide whether the agent was allowed to make them, whether shared systems were protected, or whether the resulting branch should become real.