Qwen Code 0.24.0 adds a bwrap sandbox: verify Linux isolation before rollout

Quick answer

Qwen Code 0.24.0 adds an opt-in Bubblewrap (bwrap) sandbox backend for Linux. It runs without a container image, daemon, or root, and mounts the host filesystem read-only outside a calculated set of writable roots. Enable it explicitly with QWEN_SANDBOX=bwrap; the release does not change the default sandbox choice on Linux or any other platform.

Do not promote it after seeing only the label bwrap. Run QWEN_SANDBOX=bwrap qwen sandbox from the target repository, then run QWEN_SANDBOX=bwrap qwen sandbox --verify. Confirm the workspace is writable, an outside write fails with EROFS, the expected Git metadata roots are present, and the chosen network mode matches the workload. Treat full as filesystem-mount enforcement—not isolation from host processes or Unix sockets.

Who this is for

This checklist is for teams running Qwen Code on Linux workstations, shared build machines, rootless CI, or hosts where Docker and Podman are too heavy or unavailable. It is especially useful when agents work in linked Git worktrees and still need to commit while writes elsewhere on the host are denied.

It is not a claim that Bubblewrap is a VM or a universal security boundary. If your threat model requires hiding host processes, devices, sockets, or a complete Linux userland, compare a container or VM instead of equating a read-only root with total isolation.

What changed, and why it matters now

The official v0.24.0 release, published September 16, 2026 at commit 56b003be0785412ed06673948f781dc70a686b5a, includes the new Linux kernel sandbox. The merged implementation keeps it explicit by name, checks whether the installed bwrap can actually start, and fails loudly when the host disables the required unprivileged user namespaces.

The backend re-executes Qwen Code behind a read-only host root. It keeps the current workspace, system temporary directory, cache, Qwen state/runtime directories, and the current checkout's Git directories writable. Linked worktrees need that last grant because their index, refs, and logs live outside the worktree directory.

Qwen Code also ships a qwen sandbox inspection command with this backend. It reports the selected backend, enforcement level, network mode, target directory, and writable roots. Its verification battery checks one allowed workspace write, one denied outside write, PID-namespace behavior, and network-interface visibility.

Understand the boundary before enabling it

Surface	v0.24.0 behavior	What it does not prove
Host filesystem	Read-only outside resolved writable roots	Unix sockets beneath the host tree may still accept connections
Workspace	Writable	A broad or misplaced workspace is not automatically safe
Linked worktree Git data	Resolved Git directory and common directory are writable	Git config and hooks in those directories can affect later unconfined Git commands
Network open	Host interfaces remain visible	No egress restriction
Network closed	A private network namespace is requested	Host pathname sockets can remain reachable; DNS may still resolve through one
PID namespace	Deliberately shared with the host	No host-process isolation
/dev	Replaced by a minimal synthetic device tree	Audio, GPU, KVM, and shared-memory devices are not available

The implementation refuses a writable root equal to the user's home directory or one of its ancestors. Extra included directories inside the home directory are also rejected unless already covered by a built-in trusted root. This is a useful fail-closed behavior: do not “fix” it by making the project root broader.

Seven-step rollout workflow

1. Pin the candidate

Record Qwen Code 0.24.0, the executable path, Node version, Linux distribution, kernel, Bubblewrap version, repository path, and whether the checkout is a linked worktree. A version string without the resolved executable can still point at the wrong installation.

2. Inspect from outside the sandbox

From the exact repository directory, run:

QWEN_SANDBOX=bwrap qwen sandbox

Archive the report. Require Backend: bwrap, Enforcement: full, the expected target directory, a bounded writable-root list, and the intended network mode. An inspection launched from another directory can report a different boundary.

3. Run the built-in verification battery

QWEN_SANDBOX=bwrap qwen sandbox --verify

Require a terminal success for every case. If Bubblewrap is installed but cannot create the namespaces, the explicit request must fail instead of continuing unconfined. Do not accept “Backend: none” or a missing report as a pass.

4. Add a worktree canary

In a disposable linked worktree, make a harmless tracked-file change and create a local commit inside the confinement. Verify that both the worktree Git directory and common directory appeared in the report. This closes a gap the four built-in checks intentionally do not cover.

5. Test real workload dependencies

Run one bounded task that exercises the tools you actually need. Check browser opening, SSH-agent access, local MCP servers, IDE companions, and any device-dependent command separately. Closed networking removes loopback, while the minimal /dev tree can make voice, GPU, or virtualization tools unavailable.

6. Prove a negative boundary

Use a harmless path outside every writable root and verify that a write is rejected as a read-only filesystem. Also confirm that a workspace write succeeds. EACCES alone may come from ordinary Unix permissions; the built-in test requires EROFS because that is evidence of the mount boundary.

7. Promote with an explicit residual-risk receipt

Roll out to a small host group first. Record the writable roots, network mode, worktree result, outside-write result, required host sockets, and rollback command. Re-run the receipt when the project path, include-directory settings, Qwen home, temporary directory, or network mode changes.

Acceptance matrix

Canary	Pass	Stop condition
Backend selection	Backend: bwrap	Backend missing, unknown, or silently unconfined
Built-in verify	Every case passes	Any missing or failed assertion
Workspace write	New temporary file succeeds and is removed	Workspace unexpectedly read-only
Outside write	Fails with EROFS	Write succeeds or denial cannot be attributed to the mount
Linked worktree commit	Commit succeeds; Git roots are reported	Git metadata missing or overly broad
Closed network	Private network interface view matches report	Required local service breaks or unexpected route remains
Host-service review	Required sockets are named and accepted	Team assumes filesystem enforcement blocks all IPC

Copyable rollout receipt

date:
host_group:
qwen_version: 0.24.0
qwen_executable:
release_commit: 56b003be0785412ed06673948f781dc70a686b5a
linux_distribution:
kernel:
bwrap_version:
checkout: normal | linked-worktree
backend_reported:
enforcement_reported:
network_mode:
writable_roots:
builtin_verify: pass | fail
worktree_commit_canary: pass | fail | not-applicable
outside_write_erosf: pass | fail
required_host_sockets:
device_or_gui_exceptions:
result: promote | hold | rollback
owner:

For broader agent permission decisions, pair this with the Qwen Code workspace-trust precedence checklist. If you need a comparison across operating systems and fallback backends, use the DeepSeek Harness sandbox execution pipeline as a separate architecture reference.

Common mistakes

The most dangerous mistake is reading Enforcement: full as “fully isolated.” In v0.24.0 it describes filesystem mount enforcement. Host PID visibility remains, Unix sockets can remain reachable, and writable repository metadata can influence later host Git commands. Other mistakes include enabling bwrap without inspecting the resolved roots, treating installation as proof the kernel permits it, testing only a normal checkout, using a broad home directory as the workspace, and selecting closed networking without checking local MCP or IDE dependencies.

Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.

FAQ

Does Qwen Code 0.24.0 use bwrap by default on Linux?

No. The merged change says the backend is opt-in by name and changes no default on any platform. Select it explicitly with QWEN_SANDBOX=bwrap.

Does qwen sandbox --verify prove Internet blocking?

No. Its network check uses interface visibility. The official design states that the check does not prove Internet reachability or proxy behavior.

Why are Git directories outside a worktree writable?

Linked worktrees store critical Git metadata outside the working directory. Without those roots, commits fail on the read-only host mount. Review the residual risk from writable config and hooks before promotion.

Can I add ~/.ssh as a writable directory?

The new resolver rejects extra home-internal writable roots. Keep sensitive home paths read-only and redesign the workflow around narrower, non-home grants or a different isolation backend.

Sources

• Qwen Code v0.24.0 official release
• Qwen Code PR #11614 — bwrap backend and reviewer test plan
• Commit-pinned Linux kernel sandbox design
• Commit-pinned qwen sandbox implementation

---

Originally published on IndieSeek.