Qwen Code 0.21.8: verify nested workspace trust before loading project env
Quick answer
Qwen Code 0.21.8, released August 8, 2026, fixes a workspace-trust precedence bug. Before the fix, a nested workspace explicitly marked DO_NOT_TRUST could still inherit TRUST_FOLDER from a parent. Qwen Code could then load the nested project's .qwen/settings.json or .env even though the user had rejected trust.
Version 0.21.8 changes the rule to most-specific path wins. Distrust also wins a same-depth tie, and the shared resolver is used by the regular CLI path, daemon policy, and qwen serve fast path. Upgrade every launcher, then prove the behavior with disposable sentinels before restoring auto-acceptance or unattended serving.
Do not read this as “every project-env boundary is fixed.” A separate, still-open change at publication time covers the reverse topology: a trusted child loading an .env from a distrusted ancestor. The rollout gate below tests both directions and fails closed if either sentinel crosses the boundary.
Who this is for
This guide is for developers who enabled Qwen Code Trusted Folders, keep multiple repositories under a trusted parent, run Qwen from subdirectories, or expose workspaces through qwen serve. The risk is highest when an automation assumes “Don't trust” means project settings and environment files cannot influence the process.
Trusted Folders is disabled by default. If you never enabled security.folderTrust.enabled, first decide whether the feature fits your workflow; installing 0.21.8 does not enable it automatically.
What changed in 0.21.8
The official Trusted Folders documentation says an untrusted workspace runs in safe mode: workspace settings and project .env files are ignored, extension management is restricted, tool auto-acceptance is disabled, and automatic memory loading is disabled. The bug made that promise inconsistent for nested paths.
| Rule set | Workspace being opened | Before 0.21.8 | 0.21.8 expected result |
|---|---|---|---|
/projects trusted; /projects/vendor distrusted |
/projects/vendor |
Could inherit trust | Untrusted |
| Same rules | /projects/vendor/pkg |
Could inherit trust | Untrusted; deeper distrust contains the path |
/projects distrusted; /projects/owned trusted |
/projects/owned |
Policy depended on duplicated resolution paths | Trusted; the more-specific rule wins |
| Equal-depth trusted and distrusted match | Matching descendant | Order-sensitive risk | Distrust wins |
| No matching rule | Unrelated workspace | Unknown / prompt path | Unchanged |
The fix consolidates precedence into one resolver: compare every matching rule by path depth, choose the deepest, and prefer untrusted if two matches have equal depth. That removes persisted JSON insertion order from the decision.
Why project env loading makes this security-sensitive
The linked report demonstrated the impact through qwen serve. A nested repository could provide QWEN_SERVER_TOKEN through a project .env; if inherited parent trust won, the fast path could accept that value as the daemon bearer token. The issue also notes mitigating conditions: the user owns the central trust file, project env does not overwrite an already-set variable, and the default bind is loopback.
Those mitigations reduce exposure, but they do not make a failed distrust decision acceptable. The safer invariant is simple: a repository marked untrusted must not supply project settings, environment values, extensions, automatic memory, or tool-acceptance policy.
Six-canary rollout workflow
1. Upgrade every entry point
Inventory global npm installs, desktop or IDE launchers, CI images, daemon services, and long-lived shells. Then update the CLI and verify the binary each launcher resolves:
npm install -g @qwen-code/qwen-code@0.21.8
qwen --version
Do not infer a daemon upgraded because an interactive shell did. Restart persistent services after verifying their package path.
2. Snapshot intent without copying secrets
Use /permissions to review the current folder decision and inspect ~/.qwen/trustedFolders.json for conflicting parent and child rules. Record only paths and trust levels; do not copy project .env contents into the audit.
Build the lab with harmless names such as INDIESEEK_PARENT_SENTINEL and INDIESEEK_CHILD_SENTINEL. Never test with a production API key or daemon token.
3. Prove explicit child distrust
Mark a disposable parent TRUST_FOLDER and its nested repository DO_NOT_TRUST. Start Qwen from the nested repository and from a deeper packages/demo directory. Both runs must stay in safe mode and must not observe the child sentinel from .env or .qwen/settings.json.
This is the exact topology fixed by 0.21.8. Test the interactive CLI and qwen serve separately because both previously had their own resolution path.
4. Prove the reverse topology
Now mark the parent DO_NOT_TRUST and a child repository TRUST_FOLDER. Put different sentinels in the parent and child .env files. The child sentinel may load; the parent sentinel must not.
This catches a separate ancestor-walk boundary tracked by the open PR linked in Sources. If the parent sentinel appears, keep secrets out of project .env files, pass required values from the operator shell or service manager, and do not call the rollout complete.
5. Prove order and path parity
Repeat the two rule sets with their entries reversed in the disposable trust file. Results must not change. Also test the exact repository path, a descendant path, a symlink-resolved path used by your launcher, and the daemon workspace route. A UI badge is not enough; observe whether the sentinel was actually loaded.
6. Restore automation only after negative evidence
Re-enable extensions, auto-acceptance, background agents, or unattended qwen serve one control at a time. Keep the untrusted-repository sandbox checklist and MCP unknown-outcome reconciliation: workspace trust decides which configuration can load, not whether every loaded tool or write is safe.
Copyable acceptance record
Launcher / resolved qwen path / version:
Trusted Folders enabled: yes / no
Parent rule and path:
Child rule and path:
Exact child safe-mode result:
Descendant child safe-mode result:
Interactive project-env sentinel result:
qwen serve project-env sentinel result:
Reverse parent-env sentinel result:
Rule-order reversal result:
Symlink / canonical-path result:
Persistent service restarted:
Controls restored:
Owner and rollback trigger:
Decision: blocked / limited / accepted
Acceptance requires absence where data must not load. “The command started” or “the dialog looked right” is not boundary evidence.
Common mistakes
Upgrading only the terminal CLI. IDEs and daemons may resolve another installation and preserve the vulnerable behavior until restarted.
Testing only the exact nested folder. The 0.21.8 resolver intentionally applies the deepest rule to descendants. Test a subdirectory because agents often launch below the repository root.
Treating the release as a blanket env audit. The selected fix covers trust precedence. The reverse trusted-child/distrusted-parent env walk is a separate boundary and needs its own canary.
Using a real secret as the sentinel. The test asks whether a value crosses a boundary, not whether a credential works. Use disposable text.
FAQ
Does 0.21.8 automatically enable Trusted Folders?
No. The feature remains disabled by default and is enabled through the user setting security.folderTrust.enabled.
Should a trusted child override a distrusted parent?
Under the 0.21.8 most-specific-rule policy, yes: the deeper matching rule wins. That does not authorize loading the parent's own project .env; test each candidate directory separately.
Is this only a qwen serve issue?
No. The precedence decision affects regular workspace trust and daemon policy too. qwen serve makes the impact concrete because its fast path loads environment configuration before serving sessions.
Top comments (0)