fix(serve): Allow approved external built-in text writes - #8852

E2E test report

Environment: macOS, Node.js 24.12.0, repository package 0.21.8, locally built dist/cli.js, fake OpenAI server, and a real qwen serve/ACP child. The external target was outside the test HOME, workspace, /tmp, and all managed read roots.

Baseline with the global 0.21.8 CLI:

• allow_once emitted one permission request, then the final write_file call failed with path escapes workspace; the file was absent.
• reject_once canceled the tool before the final write and left the file absent.
• YOLO emitted no permission request but still failed at the delegated workspace boundary; the file was absent.

Verification with this PR:

• allow_once completed the built-in write_file, produced exact sentinel content, and made no shell call.
• reject_once sent no final write, reported the tool as canceled, and left the file absent.
• YOLO emitted no permission request, completed the exact write, and made no shell call.
• The targeted real-daemon integration test passed: 1 test passed, 5 unrelated tests skipped.
• Core targeted tests passed 564/564; CLI targeted tests passed 336/336.
• Full build and full workspace typecheck passed, along with targeted ESLint, Prettier, and git diff --check.

The deterministic assertions use tool completion status plus exact file readback, not model-input content, so the tool input itself cannot produce a false positive.

Diagnosed the Check serve fast-path bundle closure failure on this PR — it's a known failure class of that gate, and the trigger here is one line.

What the gate guards: qwen serve's fast startup path requires the pre-listen module closure to stay lean — no static reach into the settings machinery (glob, @iarna/toml, …), or cold start regresses. The gate's output shows the violation:

Serve fast-path bundle closure includes pre-listen runtime modules:
- glob vendor package
- @iarna/toml vendor package (×N)
  static path: run-qwen-serve-*.js -> chunk-LRZX6RV5.js (5,453,094 bytes)

The trigger in this PR — packages/cli/src/serve/bridge-file-system-adapter.ts:

import { parseToolWriteOriginMeta } from '@qwen-code/qwen-code-core';

That's a static top-level import of the core barrel, and bridge-file-system-adapter.ts sits in the serve pre-listen graph — so the whole 5.4 MB chunk (core + glob + toml) becomes statically reachable from run-qwen-serve for the sake of one small pure function.

The gate's established fix is a dynamic import at the use site:

const { parseToolWriteOriginMeta } = await import('@qwen-code/qwen-code-core');

parseToolWriteOriginMeta is only needed while handling a write request — long past listen — so the dynamic form costs nothing. (Alternative: export the function through a small core subpath module and import that statically, avoiding the barrel.)

You can reproduce locally with npm run check:serve-fast-path-bundle.

import { parseToolWriteOriginMeta } from '@qwen-code/qwen-code-core';

_{Handled with Claude Code (Opus 5, 1M context).}

Thanks — agreed and fixed in 6829bf2. The provenance helpers now live behind the dependency-light @qwen-code/qwen-code-core/toolWriteOrigin subpath, so the serve pre-listen graph no longer reaches the core barrel or the 5.45 MB tool-runtime chunk. On the current SHA, Test (ubuntu-latest, Node 22.x) (including check:serve-fast-path-bundle), real daemon E2E, Serve A/B, and the remaining required CI checks have passed. This addresses the old-SHA CHANGES_REQUESTED diagnosis and @wenshao’s suggested subpath alternative; no dynamic import was needed.

Rebased onto current main (4bc75c2bdb) and resolved the docs/users/qwen-serve.md conflict by preserving both the expanded main-branch loader-environment hardening list and this PR’s updated read/write boundary documentation. New head: f6d74568c2. Verification after rebase: full build and workspace typecheck passed; core targeted tests 564/564; CLI targeted tests 325/325; serve fast-path bundle guard passed; Prettier and git diff --check passed. Two clean audit passes found no remaining conflict or semantic drift; range-diff shows only the expected documentation reconciliation.

Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration.

@qwen-code /triage

Local verification on a real stack — PR 8852

I rebuilt this PR and its merge base into two independent bundles and ran both against a real qwen serve daemon (real ACP child, real Web Shell UI, scripted OpenAI-compatible backend), plus a wire-level ACP probe. The behaviour change reproduces exactly as described, and every security boundary I could reach stayed closed.

Verdict: works as advertised, boundaries hold. LGTM from a verification standpoint. Three non-blocking notes for reviewers at the end.

Setup

Bundle sanity: qwen-code/tool-write-origin is present in the head bundle chunks and absent from the base bundle, so the A/B really compares the two code paths.

A/B: the authorization loop actually closes

Same scripted model, same prompt, same approval action — only the bundle differs.

New files land as 0600; existing files keep their mode (0640 / 0644 both verified). No shell tool call appeared in any event stream.

Screenshots — real Web Shell UI, identical user action

1. Head — the approval request for a path outside the bound workspace

2. Head — after Yes, allow once: the tool completes and the external file is edited

On-disk readback: -rw------- 109 release-notes.md, content byte-identical to what the model sent.

3. Base — same prompt, same approval: Failed, and the target never exists

Security boundaries (all on head)

Repo tests

• PR's own integration test on the head bundle: passes (qwen serve — same-host external built-in text writes, 3.1 s). Copied verbatim onto the base bundle: fails at readFileSync(externalPath) → the test really guards this change.
• Touched CLI unit files (adapter, WFS, run-qwen-serve, bridge wiring, ACP filesystem): 445/445 passed.
• Touched core unit files (tool-write-origin, write-file, edit, notebook-edit): 202/202 passed.
• npm run typecheck: clean. npm run check:serve-fast-path-bundle: Startup bundle closure checks passed. (confirms the last commit's fix).

Notes for reviewers (non-blocking)

1. The provenance marker is visible on the wire to third-party ACP clients. I ran the built CLI as a plain ACP agent (--experimental-acp) behind a minimal stdio client and dumped the fs/write_text_file params:

// head
"_meta": { "bom": false, "qwen-code/tool-write-origin": { "version": 1, "source": "write_file" } }
// base
"_meta": { "bom": false }

It is inert for a generic client (their own fs policy still decides), which matches the PR's framing. But an editor integration such as Zed now sees a new vendor _meta key on every built-in write. Worth an explicit line in packages/acp-bridge/README.md so integrators know it is informational and must not be treated as authorization.

2. The external writer does not recover existing-file metadata from disk. writeSameHostToolTextOutsideWorkspace calls mergeWriteMeta(undefined, request.meta ?? {}), while the workspace path (writeTextOverwrite) falls back to readExistingTextMeta. Today all four origins pass encoding/lineEnding/bom explicitly, so nothing regresses — I verified CRLF and mode survive an external overwrite. It is only a note that a future write path forgetting _meta would silently normalize an external file to UTF-8/LF instead of inheriting from disk, where the internal path would not.

3. The opt-in asymmetry in run-qwen-serve.ts is safe but reads oddly. The primary adapter gates on deps.fsFactory === undefined while the secondary and per-workspace runtimes pass true unconditionally. Those two always build their factory via resolveBridgeFsFactory with no injection point, and the adapter additionally requires factory.writeSameHostToolText to exist, so an injected factory fails closed either way. A short comment on the two unconditional sites would save the next reader the trace.

Residual risk already acknowledged in the PR description (approval→write path races on parent directories) is unchanged by this verification; I did not attempt to exercise it.

// head
"_meta": { "bom": false, "qwen-code/tool-write-origin": { "version": 1, "source": "write_file" } }
// base
"_meta": { "bom": false }