Qwen Code has moved its Linux Bubblewrap sandbox from around the whole application to around supported tool execution. The change merged September 22 in QwenLM/qwen-code lets the trusted application keep its model connection, authentication and session storage on the host while commands run under a separate policy.
But the consequential detail is in the follow-up. An open hardening issue records a brief settings-save window in which a new session can mistake an existing confinement policy for no policy. The sandbox can enforce the rules it receives; startup must first receive them.
Two different meanings of “closed”
The new tools.executionSandbox object separates filesystem permission from command networking. An operator can allow workspace writes while closing ordinary IP networking for commands. That does not disconnect the model: the host application’s traffic sits outside the command boundary.
The user documentation makes another important limit explicit. Reads remain broad; this mode does not promise to hide host secrets or isolate pathname Unix sockets. A closed command network is therefore a specific control, not a general claim that project data cannot leave the machine.
Policy belongs to user or administrator settings, not the project being worked on. A workspace cannot replace it, even if the project is trusted. Approval and YOLO mode do not widen it. Changes require a new runtime, so the policy is meant to stay fixed for the lifetime of that runtime.
That consistency has a visible price. This first public integration supports ordinary headless use and both terminal interfaces, but rejects ACP and qwen serve. MCP, executable extensions, worktree management and other unported paths are disabled or rejected. Keeping those features available would require carrying the same boundary through their effects. Silently letting them run on the host would defeat the design.
The race that was fixed—and the one left open
The review initially found a settings loader that could read valid policy, read the file again during an in-place rewrite, then recover from the damaged second read by continuing with empty settings. The fourth review round reports that this torn-read failure was fixed: damaged operator settings now stop startup. It also reports successful boundary probes. Those results are meaningful counterevidence to any claim that the new sandbox simply does not work.
The remaining race is different. The settings writer first writes a temporary file, then renames the existing settings file to a backup, then renames the replacement into place. Between those last two operations, the expected settings pathname is absent.
The policy reader treats an absent settings file as an empty scope. If startup observes the gap and no other scope supplies the policy, it can proceed without the intended boundary. A missing file does not trigger the malformed-JSON refusal.
In the third-round report, a reviewer repeatedly exercised the real writer while starting sessions and reported two unconfined starts out of 100. A copy-based backup avoided the observed gap in that experiment. These are the reviewer’s stress-test results, not an estimate of everyday failure rates, and we did not independently reproduce the race.
The author’s follow-up issue preserves it as pre-existing work still to fix. It also calls for checking crash safety and Windows replacement behavior before choosing the write sequence. The public record supports a concrete unresolved mechanism; it does not establish exploitation, affected deployment counts or a universally correct one-line repair.
The useful question before migration
For a team adopting this mode, the review changes the acceptance question. Testing that a command cannot write outside its workspace is only half the job. A disposable test should also establish that saving operator settings while another session starts cannot make the policy disappear.
The change removes the old whole-CLI Bubblewrap selection and gives it migration errors; Docker, Podman and Seatbelt retain their separate paths. We inspected the merged code, documentation and review, rather than mapping this behavior to an installed release or running a full Linux isolation test. Treat the new boundary as a source-level contract to verify in the version you use.
The next decisive signal is a settings writer that keeps policy continuously visible, backed by a concurrent reader-and-writer regression. Until then, the most interesting boundary in this sandbox story is the brief space between two file renames.