Qwen precheck requires maintainer approval before automated triage/review.

Head SHA: f041bb5768d0dd5e4367f58ceb583cf48ff4eefd

Reason:

• sensitive_diff:secret_logging
• secret_value:assignment

A maintainer with write access can inspect the PR and manually request a run with @qwen-code /triage or @qwen-code /review. A new push requires a fresh precheck.

@qwen-code /resolve

Qwen Code resolved the merge conflicts and pushed the branch update.

Merge Conflict Resolution Summary — PR #6606

Branch: qwen-resolve/pr-6606 merged with origin/main

Conflicted Files

1. packages/cli/src/serve/run-qwen-serve.ts (3 conflict regions)

Root cause: PR #6606 adds credentialStore as a property on workspace service creation calls (to support credential-store-aware settings loading). Meanwhile, origin/main added skillInstallEnv as a new property on the same calls (to pass the runtime effective env for skill installation). Both changes touch the same object literal locations.

Resolution: Kept both properties in all three workspace service creation sites:

• Primary workspace (~line 3443): added credentialStore, and skillInstallEnv: runtimeEffectiveEnv,
• Secondary workspace (~line 3773): kept createWorkspaceSkillsStatusProvider(credentialStore) (PR), added credentialStore, and skillInstallEnv: secondaryEnv.effectiveEnv,
• Dynamic workspace (~line 4163): kept createWorkspaceSkillsStatusProvider(credentialStore) (PR), added credentialStore, and skillInstallEnv: wsEnv.effectiveEnv,

2. packages/cli/src/serve/workspace-skills-status.ts (1 conflict region)

Root cause: PR #6606 passes credentialStore through createWorkspaceSkillsStatusProvider to buildWorkspaceSkillsStatus (for credential-store-aware disabled-skill reads). Meanwhile, origin/main refactored the return value to attach an invalidate method to the provider (allowing cache invalidation of the skill manager per workspace).

Resolution: Combined both changes — the provider now:

1. Passes credentialStore through to buildWorkspaceSkillsStatus (PR's intent)
2. Returns a provider object with the invalidate method (main's intent)

Commit

merge: resolve conflicts between credential store and skill install env features

🩺 serve daemon A/B

Built the PR base vs this PR head f041bb5, drove a fixed endpoint set against each, and diffed the JSON responses. Only fields that changed are shown.

✅ No response changes against the PR base across 4 scenario(s).

— Qwen Code · serve A/B

@qwen-code /resolve

Qwen Code resolved the merge conflicts and pushed the branch update.

Merge Conflict Resolution Summary

PR: #6606 — fix(core): Sanitize internal daemon secrets from shell subprocess environments
Base branch: main
Commit: merge: resolve conflicts between daemon secret sanitization and test runtime isolation

Conflicted file

packages/cli/src/serve/run-qwen-serve.test.ts

Conflict: The vitest import line at the top of the file.

• HEAD (PR branch): imported beforeEach (added by PR's test cases at lines 8335, 8408) but not afterAll.
• origin/main: imported afterAll (added by main's test runtime dir isolation cleanup at line 74) but not beforeEach.

Resolution: Combined both sides — the import now includes both beforeEach and afterAll:

import { describe, it, expect, vi, afterEach, beforeEach, afterAll } from 'vitest';

Both symbols are actively used in the file, so neither side could be dropped.

Auto-merged file (no manual intervention needed)

• packages/cli/src/serve/run-qwen-serve.ts — Git auto-merged cleanly.

Round-5 re-verification @ 2de8c5d13

Re-verified all 11 findings from my 2026-07-19 review plus the round-3 items, on Linux against the current head. 10 of 11 are fixed and verified. One Critical from the previous round is still present despite the "Fixed" reply, and qqqys's fast-path bundle blocker is also still present — now reproduced by CI on this exact head. Two blocking items total; details below.

Status of previous findings

Round-3 Critical (persistDisabledSkillsFn without store) is also fixed, with a non-vacuous test (run-qwen-serve.test.ts writes a workspace .env custom key and asserts process.env stays clean).

[Critical A] prepareSettingWrite still re-leaks custom keys into the daemon's OS-visible env

packages/cli/src/serve/routes/workspace-settings.ts:185 — unchanged from my previous review:

const existing =
  loadSettings(workspace).forScope(scope).settings.mcpServers ?? {};

The reply on that thread says "Fixed in the updated persistence path", but the fix only covered the persistSetting/persistSettings closures in run-qwen-serve.ts. prepareSettingWrite is a different call site and is reached from both the primary route (workspace-settings.ts:391, POST /workspace/settings) and the qualified route (workspace-settings.ts:581) whenever the key is mcpServers.

Failure scenario, unchanged from before: daemon boots → scrubDaemonProcessEnv() removes QWEN_CUSTOM_API_KEY_* from process.env → a client writes the mcpServers setting → loadSettings(workspace) runs loadEnvironment(…, undefined) → for a custom key present in the workspace .env or settings.env (which is exactly where applyProviderInstallPlan persists installed provider keys), readEnvKey sees it unset and writeEnvKey(key, value, undefined) falls back to process.env — the credential re-enters /proc/<pid>/environ / ps eww, defeating the boot scrub.

Fix: thread credentialStore into prepareSettingWrite and call loadSettings(workspace, { credentialStore }) — or { skipLoadEnvironment: true }, since this call only reads mcpServers from settings scopes and doesn't need env application at all.

[Critical B] check:serve-fast-path-bundle fails on this head — qqqys's blocker is unaddressed

packages/cli/src/serve/run-qwen-serve.ts:48-51 still has the module-scope value import:

import {
  createCredentialStore,
  createCredentialProvider,
} from '@qwen-code/qwen-code-core';

run-qwen-serve.ts is one of the checker's SERVE_PRE_LISTEN_ROOTS, and the core public barrel statically re-exports from forbidden modules (e.g. packages/core/src/index.ts:175 re-exports from ./tools/shell.js) and drags the forbidden vendor packages. This is not hypothetical — on this exact head (2de8c5d13), Test (ubuntu-latest, Node 22.x) now gets past all test steps (the editor.test.ts fix worked) and fails at precisely the "Check serve fast-path bundle closure" step:

Serve fast-path bundle closure includes pre-listen runtime modules:
- glob vendor package
  input: node_modules/glob/node_modules/brace-expansion/index.js
  static path: dist/chunks/run-qwen-serve-K6TPFIRT.js -> dist/chunks/chunk-P4NFORE5.js
- @iarna/toml vendor package
  input: node_modules/@iarna/toml/lib/parser.js
  static path: dist/chunks/run-qwen-serve-K6TPFIRT.js -> dist/chunks/chunk-P4NFORE5.js
  ... (5,747,889-byte chunk pulled into the pre-listen closure)

The type-only imports (CredentialStore) are fine — they erase at compile time. The value import is the problem. Since captureDaemonCredentialStore() runs pre-listen, a post-listen dynamic import isn't the right shape either. credential-provider.ts is dependency-free (pure functions over a Map), so the clean fixes are: add a slim subpath export (e.g. @qwen-code/qwen-code-core/credentials → models/credential-provider.js) and import from that, or lift the three tiny factories into a module the fast path is allowed to reach.

New findings (this round)

[Important] ide-client.ts:1083 widens the IDE stdio child env instead of narrowing it. On main, new StdioClientTransport({ command, args }) passes no env, so the MCP SDK uses getDefaultEnvironment() — only HOME/LOGNAME/PATH/SHELL/TERM/USER (plus the Windows equivalents), i.e. zero credentials. This PR changes it to the full process.env minus the 4 internal Qwen keys, so the IDE companion child now inherits OPENAI_API_KEY, GH_TOKEN, AWS_*, and everything else it never saw before — the opposite of this PR's goal, and the updated test (ide-client.test.ts asserting OPENAI_API_KEY is preserved) locks the widening in. Fix: drop the env option (the SDK default is already credential-free), or pass scrubChildEnv(getDefaultEnvironment(), …) if you want the scrub to be explicit.

[Suggestion] Primary-workspace voice env is a boot-time snapshot; qualified routes re-merge per request. In createServeApp the primary route gets env: mergeCredentialStore(getRuntimeEffectiveEnv(primaryRuntime.env), deps.credentialStore) evaluated once, and workspace-voice.ts then uses that frozen deps.env for validation (:448) and transcription (:568). A provider installed or a key rotated after boot updates the store but never reaches the primary route's env, while /workspaces/:workspace/voice/* rebuilds via createRuntimeVoiceDeps per request and stays fresh. In practice readApiKey's settings.env fallback rescues installed providers, so this is consistency rather than breakage — but a per-request merge (mirroring createRuntimeVoiceDeps) would remove the asymmetry. Related nit: resolve-voice-config.ts:96 still calls loadSettings(workspaceCwd, options.env ? { skipLoadEnvironment: true } : true) without credentialStore; harmless today because every daemon caller supplies env, but it's the same class as Critical A if a daemon path ever calls it without one.

[Suggestion] Desktop ACP children lose QWEN_CUSTOM_API_KEY_* with no re-injection path. buildQwenAcpEnv (desktop qwen-agent.ts) scrubs the custom-key pattern and scrubChildEnv refuses override re-introduction — but unlike the CLI daemon's ACP spawn (which injects credentialStore.snapshot() into sourceEnv precisely because ACP children are agents that call models), the desktop has no equivalent. The child normally recovers the keys from its own settings.env at boot, so the standard install flow works; a key that exists only in the parent environment (manually exported) now silently breaks custom-provider auth in desktop sessions. Worth a comment in buildQwenAcpEnv documenting the recovery assumption, or aligning with the ACP policy of the CLI path.

Verification evidence

• Head greps confirming each fixed call site (workspace-service/index.ts:508/515/522/592/669/708, all ~20 loadSettings sites in run-qwen-serve.ts carry credentialStore, qualified voice/WS merges, desktop client/validation override order).
• Local test runs on the PR head: editor.test.ts 152 ✅, child-env-scrub.test.ts 11 ✅, credential-provider.test.ts 29 ✅, child-env-scrub.integration.test.ts (real node -e spawns through ShellExecutionService, both PTY and child_process paths) 7 ✅, acp-bridge spawnChannel.test.ts 32 ✅.
• CI on head 2de8c5d13: every test step green; sole failure is the fast-path closure step quoted above.

The scrub direction is right on every other spawn path I audited (each strictly narrows the child env), the two-context ACP-vs-shell policy documentation in spawnChannel.ts is genuinely useful, and the test coverage — Windows case-insensitivity, override-smuggling, real-spawn integration — is exemplary. Once A and B are fixed (both are small, well-localized changes) this is mergeable from my side.

Addressed the remaining Round-5 blockers in e0293d2:

• Critical A: prepareSettingWrite now receives the daemon credentialStore and calls loadSettings(workspace, { credentialStore }); both the primary and qualified workspace settings routes supply it. Added a regression test for the MCP-settings read path.
• Critical B: moved the two runtime credential factories off the core public barrel to the new dependency-free @qwen-code/qwen-code-core/credentials subpath, with explicit type/import exports.
• IDE stdio finding: removed the explicit env from StdioClientTransport, restoring the MCP SDK default minimal environment. Updated both file-config and environment-config stdio tests.

Verified locally:

• packages/cli: workspace-settings.test.ts — 15 passed
• packages/core: ide-client.test.ts — 65 passed
• git diff --check

I could not complete the local full typecheck / serve-fast-path bundle run because the installed local ink package is missing getFrameController and related exports used by the existing CLI selection UI. This is outside the changed paths; CI will provide the clean-environment bundle verification.

@qwen-code /resolve

Qwen Code resolved the merge conflicts and pushed the branch update.

Merge conflict resolution for PR #6606

Root cause

PR #6606 (fix(core): Sanitize internal daemon secrets from shell subprocess environments) introduced a scrubChildEnv + collectSensitiveShellEnvKeys API in child-env-scrub.ts and threaded credentialStore/credentialProvider through the daemon's settings-loading and workspace-service construction paths. Meanwhile, origin/main independently introduced a parallel but simpler sanitizeChildEnv API in sanitize-child-env.ts (commit for issue #6601), plus a large workspace-trust feature (workspaceTrusted, generationGuard, assertGenerationOpen, loadSettingsForPersistence, trust-gated routes) that touched many of the same files.

The two changes collided on 28 files: every spawn site, every loadSettings() call in the serve layer, and every interface/type that carries daemon configuration.

Textual or semantic

Both textual and semantic. The core env-sanitization conflicts are semantic — both sides replace the same env construction at spawn sites but with different APIs:

// PR (#6606): parameterized denylist + anti-reintroduction guard
env: scrubChildEnv(
  normalizePathEnvForWindows(process.env),
  collectSensitiveShellEnvKeys(process.env),
  { QWEN_CODE: '1', TERM: 'xterm-256color', ...overrides },
),

// Base (#6601): simple delete-list spread
env: {
  ...normalizePathEnvForWindows(sanitizeChildEnv(process.env)),
  QWEN_CODE: '1', TERM: 'xterm-256color', ...overrides,
},

Resolution: kept the PR's scrubChildEnv form everywhere (6 spawn sites in shellExecutionService.ts, hookRunner.ts, mcp-client.ts, monitor.ts, tool-registry.ts). The PR's API is strictly more defensive — scrubChildEnv prevents overrides from re-introducing scrubbed keys, which the base's spread-based approach cannot guarantee.

The remaining ~22 conflicts are textual — both sides added new fields to the same interfaces or new parameters to the same function calls (credentialStore from the PR, workspaceTrusted/generationGuard/etc. from the base). All were resolved by keeping both sets of additions.

What is load-bearing

1. scrubChildEnv must be used at every spawn site, not sanitizeChildEnv. The PR's child-env-scrub.ts covers a broader denylist (including QWEN_CODE_SIMPLE and QWEN_CUSTOM_API_KEY_* regex) and enforces anti-reintroduction. If any spawn site regresses to sanitizeChildEnv, custom API keys could leak to subprocesses.

2. credentialStore must be threaded alongside workspaceTrusted in every loadSettings() call. The loadSettingsForPersistence helper in run-qwen-serve.ts was updated to include both. If credentialStore is dropped from any persistence path, QWEN_CUSTOM_API_KEY_* values will be written to process.env instead of the store.

3. createSpawnChannelFactory sourceEnv must remain a callback (() => ({...env, ...credentialStore.snapshot()})), not a static object. ACP children need fresh credential snapshots on each spawn.

4. package.json exports: ./credentials (PR) must coexist with ./transcriptRecords, ./goalWire, ./package.json, ./dist/*, ./src/* (base). All six entries are present.

What I could not verify

No build, typecheck, lint, or tests were run. Specific risks:

• loadSettings option type: the merged code passes credentialStore alongside skipLoadEnvironment, skipWorkspaceSettings, and workspaceTrusted in a single options object. If the LoadSettingsOptions interface doesn't accept all these fields simultaneously, TypeScript will reject it. The interface was updated in settings.ts to include all fields, but the implementation may have validation logic that rejects unknown combinations.

• createWorkspaceSkillsStatusProvider signature: the PR passes credentialStore as a direct argument while the base passes { workspaceTrusted }. The merged code passes { credentialStore, workspaceTrusted } — if the function only accepts one shape, this will fail.

• Test files (hookRunner.test.ts, mcp-client.test.ts, workspace-settings.test.ts): the merged tests assert both QWEN_SERVER_TOKEN and QWEN_DAEMON_TOKEN are scrubbed while GH_TOKEN passes through. If the test mocks don't match the current scrubChildEnv behavior for these specific keys, tests will fail.

• Non-conflicted callers: files that import sanitizeChildEnv from origin/main but were NOT in conflict (e.g., packages/core/src/index.ts re-exports) may still reference the old sanitize-child-env module alongside the PR's child-env-scrub module. Both files exist in the working tree.