Skip to content

fix(serve): post-merge P2 corrections from Codex review on #4282#4297

Merged
doudouOUC merged 11 commits into
daemon_mode_b_mainfrom
post-pr17-codex-p2-fixes
May 19, 2026
Merged

fix(serve): post-merge P2 corrections from Codex review on #4282#4297
doudouOUC merged 11 commits into
daemon_mode_b_mainfrom
post-pr17-codex-p2-fixes

Conversation

@doudouOUC

@doudouOUC doudouOUC commented May 18, 2026

Copy link
Copy Markdown
Collaborator

Summary

Follow-up to PR #4282 (Wave 4 PR 17 — feat(serve): approval / tools / init / MCP-restart mutation routes) addressing four P2-severity issues flagged by Codex's /review after the squash-merge to main. All four are real correctness bugs in the code shipped via #4282; none can be reproduced by the existing test suite, so the fixes ship with five new unit tests.

Issues fixed

P2-1 — Read workspace context.fileName for POST /workspace/init. The daemon parent never calls loadCliConfig, so the process-global getCurrentGeminiMdFilename() stays on the default QWEN.md even when the workspace's merged settings configure context.fileName: 'AGENTS.md'. runQwenServe now snapshots the value at boot and forwards via BridgeOptions.contextFilename, so init writes the same file the ACP child reads. (packages/cli/src/serve/{httpAcpBridge,runQwenServe}.ts)

P2-2 — Restart MCP servers with a fresh disabledTools snapshot. Config.disabledTools was private readonly and frozen at construction time; setWorkspaceToolEnabled only updated settings.json. The documented "toggle + restart" workflow re-registered the just-disabled MCP tool because discoverMcpToolsForServer walks ToolRegistry.registerTool, which consults the bootstrap snapshot. Added Config.setDisabledTools() plus a re-read at the ACP restart handler so the next discovery honors the latest set. Already-registered tools still aren't retroactively unregistered (matches the existing documented contract). (packages/core/src/config/config.ts, packages/cli/src/acp-integration/acpAgent.ts)

P2-3 — Match the SDK restartMcpServer timeout to the daemon's 5-minute restart budget. Bridge-side MCP_RESTART_TIMEOUT_MS is 300s; SDK helper used the client-wide 30s fetchTimeoutMs default. Slow but valid stdio reconnects appeared to fail client-side while the daemon kept working. Plumbed a per-call timeoutMs through fetchWithTimeout, defaulting restartMcpServer to 5 minutes; callers can pass tighter or 0-to-disable when their threat model differs. (packages/sdk-typescript/src/daemon/DaemonClient.ts)

P2-4 — Reject symlinked parent directories before init writes. lstat(target) only checked the final path component. With context.fileName: 'docs/AGENTS.md' and docs -> /tmp as a symlink, writeFile would follow the parent link and create or truncate outside boundWorkspace. Added canonicalizeExistingAncestor (walks up through ENOENT/ENOTDIR to the deepest extant ancestor, then realpaths) and verifies the canonical parent stays within the canonical workspace. (packages/cli/src/serve/httpAcpBridge.ts)

Tests added

File Test
packages/cli/src/serve/httpAcpBridge.test.ts honors contextFilename from BridgeOptions (P2-1)
packages/cli/src/serve/httpAcpBridge.test.ts rejects writes when a parent directory symlinks outside the workspace (P2-4)
packages/cli/src/serve/httpAcpBridge.test.ts accepts writes when a parent directory is a real subdir (P2-4)
packages/sdk-typescript/test/unit/DaemonClient.test.ts survives a slow daemon response longer than the client default timeout (P2-3)
packages/sdk-typescript/test/unit/DaemonClient.test.ts honors a caller-provided timeoutMs override (P2-3)

P2-2 is exercised structurally by the new Config.setDisabledTools setter plus the existing acpAgent extMethod test surface; the live re-read path is acceptance-tested via the daemon end-to-end harness.

Test plan

  • npm run typecheck --workspace packages/cli --workspace packages/sdk-typescript --workspace packages/core — clean
  • npx vitest run packages/cli/src/serve/ packages/cli/src/acp-integration/ packages/sdk-typescript/test/unit packages/core/src/tools/tool-registry.test.ts packages/core/src/config/config.test.ts — 1604/1604
  • CI lint + full unit + integration sweep (per repo pre-merge gate)
  • Manual smoke: configure a workspace with context.fileName: 'AGENTS.md', hit POST /workspace/init, verify AGENTS.md (not QWEN.md) is created
  • Manual smoke: POST /workspace/tools/Bash/enable {enabled:false} then POST /workspace/mcp/<server>/restart — verify the disabled tool stays unregistered
  • Manual smoke: confirm a slow stdio MCP server (e.g. ~60s reconnect) no longer surfaces a client-side timeout

Roll-forward / roll-back

  • New behavior is opt-in via field presence (contextFilename, timeoutMs) — passing undefined reproduces the pre-fix shape exactly.
  • Config.setDisabledTools is additive; pre-existing callers are unaffected.
  • Reverting is a single git revert <commit> away.

🤖 Generated with Qwen Code


📝 描述准确性更新(2026-05-31,作者自查)

补充:本 PR 除初版 4 个 P2 外还含 fold-in 1/2/3/5/7/9/10;P2-2 表述需更正——重启经 discoverToolsForServer 确实会清除被禁用工具。

Copilot AI review requested due to automatic review settings May 18, 2026 16:39
@github-actions

Copy link
Copy Markdown
Contributor

📋 Review Summary

This PR addresses four P2-severity issues identified by Codex's /review after the squash-merge of PR #4282 to main. All fixes are correctness bugs in shipped code, and none were reproducible by the existing test suite. The implementation is thorough, well-documented with inline comments referencing the issues, and includes comprehensive test coverage for three of the four fixes (P2-2 is exercised structurally).

🔍 General Feedback

  • Strong documentation: Each fix includes detailed inline comments explaining the root cause, the fix approach, and any limitations. The comments reference the specific issue (e.g., "feat(serve): approval / tools / init / MCP-restart mutation routes (#4175 Wave 4 PR 17) #4282 fold-in 5 P2-1") making traceability excellent.
  • Defensive programming: The fixes consistently add validation layers (symlink checks, timeout overrides, settings re-reads) without breaking existing functionality.
  • Test coverage: Five new unit tests cover the critical paths, with both negative and positive test cases for the symlink escape prevention.
  • Backward compatibility: All fixes maintain backward compatibility through fallbacks (e.g., contextFilename optional with fallback to process-global, timeout overrides defaulting to client-wide value).
  • Pattern consistency: The code follows existing patterns in the codebase for error handling, settings loading, and timeout management.

🎯 Specific Feedback

🟡 High

  • File: packages/cli/src/serve/httpAcpBridge.ts:4075-4105 — The canonicalizeExistingAncestor function walks up the directory tree on ENOENT/ENOTDIR errors, but the loop termination condition (parent === current) could be more explicit. Consider adding a safeguard counter or max-depth check to prevent potential infinite loops in edge cases with malformed paths (e.g., path traversal attacks with repeated .. segments). While the path.dirname behavior makes this unlikely, an explicit guard would strengthen the defense-in-depth approach.

🟢 Medium

  • File: packages/cli/src/serve/runQwenServe.ts:318-326 — The fallback logic for contextFilenameForInit handles both string and array types for configuredFilename, but the array handling (configuredFilename[0]) seems unusual for a fileName setting. If this is intentional to handle legacy configs, consider adding a comment explaining why arrays might appear here and whether this is a temporary compatibility shim.

  • File: packages/cli/src/acp-integration/acpAgent.ts:1527-1540 — The settings re-read on MCP restart is wrapped in a try-catch that silently falls through on failure. While the comment explains this is non-fatal, consider adding a debug-level log or telemetry marker so operators can detect when settings sync is skipped. This would help diagnose issues where users toggle tools but don't see the expected behavior.

🔵 Low

  • File: packages/sdk-typescript/src/daemon/DaemonClient.ts:266-272 — The timeout override logic uses Number.isFinite(perCallTimeoutMs) && perCallTimeoutMs > 0 which is correct, but the comment mentions "non-finite / non-positive values are coerced to 'use the client default'". Consider extracting this validation into a small helper function (e.g., isValidTimeoutMs()) for reusability and clarity, especially if timeout validation appears elsewhere in the codebase.

  • File: packages/core/src/config/config.ts:763-764 — The comment states "Already-registered tools are NOT retroactively unregistered" which matches the documented contract. Consider adding a TODO or FIXME comment referencing any future work that might address this limitation, or link to documentation where this behavior is described for users.

  • File: packages/cli/src/serve/httpAcpBridge.test.ts:4674-4699 — The symlink escape test creates a temp directory outside the workspace and cleans it up in a finally block. Consider using a test fixture helper or test setup/teardown pattern if this pattern appears elsewhere, to reduce boilerplate and ensure consistent cleanup across tests.

✅ Highlights

  • Excellent security fix (P2-4): The symlink escape prevention via canonicalizeExistingAncestor is a robust solution that addresses a subtle but serious boundary escape vulnerability. The implementation correctly handles intermediate symlinks at any parent level, not just the final component.

  • Thoughtful timeout handling (P2-3): Matching the SDK timeout to the daemon's 5-minute budget while allowing per-call overrides is the right balance. The fix prevents false-negative timeouts during slow MCP rediscovery while maintaining flexibility for callers with different threat models.

  • Comprehensive test suite: The tests cover both the happy path and edge cases (real subdir vs. symlinked parent), demonstrating good test design. The timeout tests in DaemonClient.test.ts use controlled promise resolution to verify timing behavior without relying on real timers.

  • Clear traceability: Every code change includes a comment referencing the specific issue (e.g., "feat(serve): approval / tools / init / MCP-restart mutation routes (#4175 Wave 4 PR 17) #4282 fold-in 5 P2-1"), making it easy to understand the motivation and find related changes. This will help future maintainers understand the historical context.

  • Minimal invasive changes: Each fix is surgical and focused on the specific issue without refactoring unrelated code. This reduces the risk of introducing new bugs while fixing the identified problems.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR is a post-merge follow-up to #4282 that fixes several correctness issues in the qwen serve mutation routes and aligns SDK behavior with daemon budgets, with accompanying unit tests.

Changes:

  • Snapshot and plumb workspace context.fileName into POST /workspace/init so init writes the same context file the ACP child reads.
  • Refresh Config.disabledTools from workspace settings before MCP rediscovery so “toggle + restart” respects the latest disabled set.
  • Add a per-call fetch timeout override in the TypeScript SDK and default restartMcpServer to the daemon’s 5-minute restart budget; add tests.
  • Harden init writes against intermediate parent-directory symlink escapes; add tests.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file
File Description
packages/sdk-typescript/src/daemon/DaemonClient.ts Adds per-call timeout plumbing and a 5-minute default for restartMcpServer.
packages/sdk-typescript/test/unit/DaemonClient.test.ts Adds tests intended to cover slow restart and per-call timeout override behavior.
packages/core/src/config/config.ts Makes disabledTools re-syncable via setDisabledTools().
packages/cli/src/acp-integration/acpAgent.ts Re-reads workspace tools.disabled before MCP restart rediscovery to honor toggles.
packages/cli/src/serve/runQwenServe.ts Snapshots merged context.fileName at boot and forwards it to the bridge.
packages/cli/src/serve/httpAcpBridge.ts Uses bridged contextFilename and rejects init writes that escape via symlinked parents.
packages/cli/src/serve/httpAcpBridge.test.ts Adds unit tests for contextFilename plumbing and parent-symlink escape rejection/acceptance.
Comments suppressed due to low confidence (1)

packages/sdk-typescript/test/unit/DaemonClient.test.ts:1506

  • This test doesn’t currently verify that the 50ms timeoutMs override is honored: the stub rejects after 500ms regardless of whether the request was aborted by the client timeout, and it also doesn’t wire the rejection to init.signal. This can pass even if timeoutMs is ignored. Consider wiring init.signal to reject immediately on abort and asserting the thrown error is the timeout (e.g. TimeoutError) rather than a generic rejection.
      const slowFetch = vi.fn(
        () =>
          new Promise<Response>((_resolve, reject) => {
            // Never resolve — wait for the caller's timeout to kick in.
            // The AbortSignal coming through `init.signal` triggers
            // this rejection so the timer doesn't leak.
            setTimeout(
              () => reject(new DOMException('aborted', 'AbortError')),
              500,
            );
          }),

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread packages/sdk-typescript/src/daemon/DaemonClient.ts
Comment thread packages/sdk-typescript/test/unit/DaemonClient.test.ts
Comment thread packages/cli/src/serve/runQwenServe.ts Outdated
Comment thread packages/core/src/config/config.ts
@github-actions

github-actions Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Code Coverage Summary

Package Lines Statements Functions Branches
CLI 77.4% 77.4% 79.92% 79.98%
Core 79.42% 79.42% 82.02% 82.82%
CLI Package - Full Text Report
-------------------|---------|----------|---------|---------|-------------------
File               | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
-------------------|---------|----------|---------|---------|-------------------
All files          |    77.4 |    79.98 |   79.92 |    77.4 |                   
 src               |   75.73 |    69.25 |   80.55 |   75.73 |                   
  gemini.tsx       |   68.53 |     66.4 |   76.47 |   68.53 | ...29,946-949,957 
  ...ractiveCli.ts |      80 |    68.61 |   78.57 |      80 | ...1020,1058,1161 
  ...liCommands.ts |   74.51 |    73.17 |     100 |   74.51 | ...41-265,290,391 
  ...ActiveAuth.ts |     100 |     87.5 |     100 |     100 | 66-80             
 ...cp-integration |   60.55 |    64.49 |   77.77 |   60.55 |                   
  acpAgent.ts      |   61.84 |    64.59 |   82.75 |   61.84 | ...2162,2176-2184 
  authMethods.ts   |   12.19 |      100 |       0 |   12.19 | 11-31,34-38,41-50 
  errorCodes.ts    |       0 |        0 |       0 |       0 | 1-22              
  ...DirContext.ts |     100 |      100 |     100 |     100 |                   
 ...ration/service |   68.65 |    83.33 |   66.66 |   68.65 |                   
  filesystem.ts    |   68.65 |    83.33 |   66.66 |   68.65 | ...32,77-94,97-98 
 ...ration/session |   76.97 |    72.12 |   86.25 |   76.97 |                   
  ...ryReplayer.ts |   67.34 |     75.6 |   81.81 |   67.34 | ...54-269,282-283 
  Session.ts       |   76.32 |    70.86 |   88.46 |   76.32 | ...2537,2543-2546 
  ...entTracker.ts |   90.85 |    84.84 |      90 |   90.85 | ...35,199,251-260 
  index.ts         |       0 |        0 |       0 |       0 | 1-40              
  ...ssionUtils.ts |   84.21 |    77.77 |     100 |   84.21 | ...37-153,209-211 
  types.ts         |       0 |        0 |       0 |       0 | 1                 
 ...ssion/emitters |   96.01 |    90.75 |    92.3 |   96.01 |                   
  BaseEmitter.ts   |   76.92 |    66.66 |      80 |   76.92 | 23-24,39-40,55-56 
  ...ageEmitter.ts |     100 |    89.47 |     100 |     100 | 109,111           
  PlanEmitter.ts   |     100 |      100 |     100 |     100 |                   
  ...allEmitter.ts |   98.06 |     92.3 |     100 |   98.06 | 227-228,327,335   
  index.ts         |       0 |        0 |       0 |       0 | 1-10              
 ...ession/rewrite |   90.36 |    87.83 |   94.11 |   90.36 |                   
  LlmRewriter.ts   |      81 |       84 |     100 |      81 | ...,88-89,155-159 
  ...Middleware.ts |   95.83 |    85.71 |     100 |   95.83 | 119,127-129       
  TurnBuffer.ts    |     100 |      100 |     100 |     100 |                   
  config.ts        |     100 |      100 |     100 |     100 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  types.ts         |       0 |        0 |       0 |       0 | 1                 
 src/auth          |    97.7 |    94.81 |   95.45 |    97.7 |                   
  allProviders.ts  |     100 |      100 |     100 |     100 |                   
  ...iderConfig.ts |    97.6 |    95.04 |     100 |    97.6 | ...61,411,433-434 
  types.ts         |       0 |        0 |       0 |       0 | 1                 
 src/auth/install  |   98.57 |    88.88 |     100 |   98.57 |                   
  ...nstallPlan.ts |   98.57 |    88.88 |     100 |   98.57 | 80,93             
 ...viders/alibaba |   96.96 |    66.66 |   66.66 |   96.96 |                   
  ...baStandard.ts |     100 |      100 |     100 |     100 |                   
  codingPlan.ts    |   93.67 |    66.66 |   66.66 |   93.67 | 83,87-89,94       
  tokenPlan.ts     |     100 |      100 |     100 |     100 |                   
 ...oviders/custom |     100 |      100 |     100 |     100 |                   
  ...omProvider.ts |     100 |      100 |     100 |     100 |                   
 ...roviders/oauth |    91.5 |    77.03 |   97.05 |    91.5 |                   
  openrouter.ts    |   84.37 |    33.33 |     100 |   84.37 | 43-48             
  ...outerOAuth.ts |    91.9 |    79.06 |   96.87 |    91.9 | ...53-655,699-701 
 ...ers/thirdParty |     100 |      100 |     100 |     100 |                   
  deepseek.ts      |     100 |      100 |     100 |     100 |                   
  idealab.ts       |     100 |      100 |     100 |     100 |                   
  minimax.ts       |     100 |      100 |     100 |     100 |                   
  modelscope.ts    |     100 |      100 |     100 |     100 |                   
  zai.ts           |     100 |      100 |     100 |     100 |                   
 src/commands      |   47.93 |    85.71 |   43.47 |   47.93 |                   
  auth.ts          |     100 |    83.33 |     100 |     100 | 11,14             
  channel.ts       |   56.66 |      100 |       0 |   56.66 | 15-19,27-34       
  extensions.tsx   |   96.55 |      100 |      50 |   96.55 | 37                
  hooks.tsx        |   66.66 |      100 |       0 |   66.66 | 20-24             
  mcp.ts           |   94.73 |      100 |      50 |   94.73 | 28                
  review.ts        |   51.85 |      100 |       0 |   51.85 | 24-35,38          
  serve.ts         |    7.74 |      100 |       0 |    7.74 | ...51-147,149-230 
 ...mmands/channel |   39.25 |    79.45 |      50 |   39.25 |                   
  ...l-registry.ts |    8.57 |      100 |       0 |    8.57 | 6-21,24-42        
  config-utils.ts  |      92 |      100 |   66.66 |      92 | 21-26             
  configure.ts     |    14.7 |      100 |       0 |    14.7 | 18-21,23-84       
  pairing.ts       |   26.31 |      100 |       0 |   26.31 | ...30,40-50,52-65 
  pidfile.ts       |   96.34 |    86.95 |     100 |   96.34 | 49,59,91          
  start.ts         |   30.98 |       52 |   69.23 |   30.98 | ...72-475,484-486 
  status.ts        |   17.85 |      100 |       0 |   17.85 | 15-26,32-76       
  stop.ts          |      20 |      100 |       0 |      20 | 14-48             
 ...nds/extensions |    84.5 |    88.95 |   81.81 |    84.5 |                   
  consent.ts       |   71.65 |    89.28 |   42.85 |   71.65 | ...85-141,156-162 
  disable.ts       |     100 |      100 |     100 |     100 |                   
  enable.ts        |     100 |      100 |     100 |     100 |                   
  install.ts       |    75.6 |    66.66 |   66.66 |    75.6 | ...39-142,145-153 
  link.ts          |     100 |      100 |     100 |     100 |                   
  list.ts          |     100 |      100 |     100 |     100 |                   
  new.ts           |     100 |      100 |     100 |     100 |                   
  settings.ts      |   99.15 |      100 |   83.33 |   99.15 | 151               
  uninstall.ts     |    37.5 |      100 |   33.33 |    37.5 | 23-45,57-64,67-70 
  update.ts        |   96.32 |      100 |     100 |   96.32 | 101-105           
  utils.ts         |   60.24 |    28.57 |     100 |   60.24 | ...81,83-87,89-93 
 ...les/mcp-server |       0 |        0 |       0 |       0 |                   
  example.ts       |       0 |        0 |       0 |       0 | 1-60              
 src/commands/mcp  |   92.29 |    86.08 |   88.88 |   92.29 |                   
  add.ts           |     100 |    98.03 |     100 |     100 | 293               
  list.ts          |   91.22 |    80.76 |      80 |   91.22 | ...19-121,146-147 
  reconnect.ts     |   76.72 |    71.42 |   85.71 |   76.72 | 35-48,153-175     
  remove.ts        |     100 |       80 |     100 |     100 | 21-25             
 ...ommands/review |   11.57 |      100 |       0 |   11.57 |                   
  cleanup.ts       |   17.94 |      100 |       0 |   17.94 | ...01-106,108-109 
  deterministic.ts |   13.75 |      100 |       0 |   13.75 | ...22-738,740-741 
  fetch-pr.ts      |   11.36 |      100 |       0 |   11.36 | ...80-201,203-204 
  load-rules.ts    |   11.32 |      100 |       0 |   11.32 | ...41-153,155-156 
  pr-context.ts    |    6.22 |      100 |       0 |    6.22 | ...97-312,314-315 
  presubmit.ts     |    9.35 |      100 |       0 |    9.35 | ...62-287,289-290 
 ...nds/review/lib |      30 |      100 |       0 |      30 |                   
  gh.ts            |   22.58 |      100 |       0 |   22.58 | ...49,53-54,62-69 
  git.ts           |   22.72 |      100 |       0 |   22.72 | 15-18,29-39,43-44 
  paths.ts         |   52.94 |      100 |       0 |   52.94 | ...26,37-38,42-43 
 src/config        |   92.79 |    85.18 |   88.09 |   92.79 |                   
  auth.ts          |   86.98 |    80.32 |     100 |   86.98 | ...26-227,243-244 
  config.ts        |   88.31 |    84.87 |      80 |   88.31 | ...1841,1843-1851 
  keyBindings.ts   |   96.55 |       50 |     100 |   96.55 | 193-196           
  ...idersScope.ts |      92 |       90 |     100 |      92 | 11-12             
  sandboxConfig.ts |   61.64 |    71.87 |   66.66 |   61.64 | ...54-68,73,77-89 
  settings.ts      |   85.76 |    87.25 |   89.18 |   85.76 | ...1148,1153-1156 
  ...ingsSchema.ts |     100 |      100 |     100 |     100 |                   
  ...tedFolders.ts |   96.22 |       94 |     100 |   96.22 | ...88-190,205-206 
 ...nfig/migration |   94.89 |    78.94 |   83.33 |   94.89 |                   
  index.ts         |   94.87 |    88.88 |     100 |   94.87 | 91-92             
  scheduler.ts     |   96.55 |    77.77 |     100 |   96.55 | 19-20             
  types.ts         |       0 |        0 |       0 |       0 | 1                 
 ...ation/versions |   94.74 |       96 |     100 |   94.74 |                   
  ...-v2-shared.ts |     100 |      100 |     100 |     100 |                   
  v1-to-v2.ts      |   81.75 |    90.19 |     100 |   81.75 | ...28-229,231-247 
  v2-to-v3.ts      |     100 |      100 |     100 |     100 |                   
  v3-to-v4.ts      |     100 |      100 |     100 |     100 |                   
 src/core          |     100 |      100 |     100 |     100 |                   
  auth.ts          |     100 |      100 |     100 |     100 |                   
  initializer.ts   |     100 |      100 |     100 |     100 |                   
  theme.ts         |     100 |      100 |     100 |     100 |                   
 src/dualOutput    |   63.09 |    64.51 |   55.55 |   63.09 |                   
  ...tputBridge.ts |   62.94 |    65.51 |   56.25 |   62.94 | ...22-323,331-334 
  ...utContext.tsx |     100 |      100 |     100 |     100 |                   
  index.ts         |       0 |        0 |       0 |       0 | 1-8               
 src/export        |       0 |        0 |       0 |       0 |                   
  index.ts         |       0 |        0 |       0 |       0 | 1-7               
 src/generated     |     100 |      100 |     100 |     100 |                   
  git-commit.ts    |     100 |      100 |     100 |     100 |                   
 src/i18n          |   81.47 |    75.94 |   65.71 |   81.47 |                   
  index.ts         |   63.68 |    69.56 |   53.84 |   63.68 | ...70-271,281-286 
  languages.ts     |   96.92 |    86.66 |     100 |   96.92 | 134-135,167,184   
  ...nslateKeys.ts |     100 |      100 |     100 |     100 |                   
  ...lationDict.ts |   93.33 |    66.66 |     100 |   93.33 | 15                
 src/i18n/locales  |     100 |      100 |     100 |     100 |                   
  ca.js            |     100 |      100 |     100 |     100 |                   
  de.js            |     100 |      100 |     100 |     100 |                   
  en.js            |     100 |      100 |     100 |     100 |                   
  fr.js            |     100 |      100 |     100 |     100 |                   
  ja.js            |     100 |      100 |     100 |     100 |                   
  pt.js            |     100 |      100 |     100 |     100 |                   
  ru.js            |     100 |      100 |     100 |     100 |                   
  zh-TW.js         |     100 |      100 |     100 |     100 |                   
  zh.js            |     100 |      100 |     100 |     100 |                   
 ...nonInteractive |   72.57 |    71.12 |   74.07 |   72.57 |                   
  session.ts       |   76.64 |     69.4 |   85.71 |   76.64 | ...23-824,833-843 
  types.ts         |    42.5 |      100 |   33.33 |    42.5 | ...80-581,584-585 
 ...active/control |   77.04 |    88.23 |      80 |   77.04 |                   
  ...rolContext.ts |    7.14 |        0 |       0 |    7.14 | 49-84             
  ...Dispatcher.ts |   91.66 |    91.83 |   88.88 |   91.66 | ...54-372,388,391 
  ...rolService.ts |       8 |        0 |       0 |       8 | 46-179            
 ...ol/controllers |    7.04 |       80 |   13.33 |    7.04 |                   
  ...Controller.ts |   19.32 |      100 |      60 |   19.32 | 81-118,127-210    
  ...Controller.ts |       0 |        0 |       0 |       0 | 1-56              
  ...Controller.ts |    3.96 |      100 |   11.11 |    3.96 | ...61-379,389-494 
  ...Controller.ts |   14.06 |      100 |       0 |   14.06 | ...82-117,130-133 
  ...Controller.ts |    5.21 |      100 |       0 |    5.21 | ...21-433,442-471 
 .../control/types |       0 |        0 |       0 |       0 |                   
  serviceAPIs.ts   |       0 |        0 |       0 |       0 | 1                 
 ...Interactive/io |   97.98 |    93.72 |   95.18 |   97.98 |                   
  ...putAdapter.ts |   97.89 |    92.82 |   98.07 |   97.89 | ...1303,1398-1399 
  ...putAdapter.ts |      96 |    91.66 |   85.71 |      96 | 51-52             
  ...nputReader.ts |     100 |    94.73 |     100 |     100 | 67                
  ...putAdapter.ts |   98.28 |      100 |      90 |   98.28 | 81-82,122-123     
  index.ts         |     100 |      100 |     100 |     100 |                   
 src/patches       |       0 |        0 |       0 |       0 |                   
  is-in-ci.ts      |       0 |        0 |       0 |       0 | 1-17              
 src/remoteInput   |   86.98 |       75 |   85.71 |   86.98 |                   
  ...utContext.tsx |     100 |      100 |     100 |     100 |                   
  ...putWatcher.ts |   88.12 |    76.08 |   91.66 |   88.12 | ...21-222,233-236 
  index.ts         |       0 |        0 |       0 |       0 | 1-8               
 src/serve         |   80.63 |    79.09 |   93.47 |   80.63 |                   
  auth.ts          |   88.49 |    88.63 |     100 |   88.49 | ...49-150,153-155 
  capabilities.ts  |     100 |     90.9 |     100 |     100 | 264               
  ...usProvider.ts |   67.01 |    51.42 |     100 |   67.01 | ...40-245,278-286 
  debugMode.ts     |     100 |      100 |     100 |     100 |                   
  demo.ts          |     100 |      100 |     100 |     100 |                   
  envSnapshot.ts   |    92.3 |       84 |     100 |    92.3 | 108-111,170-177   
  eventBus.ts      |     100 |      100 |     100 |     100 |                   
  httpAcpBridge.ts |   82.21 |    79.12 |   97.61 |   82.21 | ...4488,4519-4560 
  ...oryChannel.ts |     100 |      100 |     100 |     100 |                   
  index.ts         |       0 |        0 |       0 |       0 | 1-116             
  loopbackBinds.ts |     100 |      100 |     100 |     100 |                   
  runQwenServe.ts  |   74.57 |    86.51 |      60 |   74.57 | ...78-794,819-821 
  server.ts        |   87.39 |    83.52 |   90.62 |   87.39 | ...2507,2572-2581 
  status.ts        |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
  ...paceAgents.ts |   64.87 |    70.45 |    90.9 |   64.87 | ...1306,1316-1326 
  ...paceMemory.ts |   87.13 |    78.46 |     100 |   87.13 | ...54-361,421-428 
 src/serve/auth    |   86.54 |    78.75 |   93.75 |   86.54 |                   
  deviceFlow.ts    |   96.33 |    79.51 |    97.5 |   96.33 | ...1526,1630,1700 
  ...owProvider.ts |   45.23 |    74.07 |      75 |   45.23 | ...90-359,375,379 
 src/serve/fs      |   84.85 |    79.75 |     100 |   84.85 |                   
  audit.ts         |     100 |    96.15 |     100 |     100 | 201               
  errors.ts        |     100 |      100 |     100 |     100 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  paths.ts         |   77.82 |    77.08 |     100 |   77.82 | ...64,493-497,510 
  policy.ts        |   90.32 |    89.18 |     100 |   90.32 | 142-150           
  ...FileSystem.ts |   83.55 |    76.22 |     100 |   83.55 | ...1859,1886-1887 
 src/serve/routes  |   89.41 |       70 |     100 |   89.41 |                   
  ...ceFileRead.ts |   94.41 |    76.92 |     100 |   94.41 | ...28-329,390-392 
  ...eFileWrite.ts |    82.1 |    60.52 |     100 |    82.1 | ...42-244,247-249 
 src/services      |   91.67 |    91.21 |   97.56 |   91.67 |                   
  ...mandLoader.ts |     100 |    93.75 |     100 |     100 | 93                
  ...killLoader.ts |     100 |    96.15 |     100 |     100 | 47                
  ...andService.ts |    98.7 |      100 |     100 |    98.7 | 107               
  ...mandLoader.ts |   86.83 |    83.87 |     100 |   86.83 | ...30-335,340-345 
  ...omptLoader.ts |   75.84 |    80.64 |   83.33 |   75.84 | ...10-211,277-278 
  ...mandLoader.ts |     100 |      100 |     100 |     100 |                   
  ...nd-factory.ts |   91.42 |    91.66 |     100 |   91.42 | 128,137-144       
  ...ation-tool.ts |     100 |    95.45 |     100 |     100 | 125               
  ...ndMetadata.ts |   98.21 |    96.66 |     100 |   98.21 | 83,87             
  commandUtils.ts  |      96 |     90.9 |     100 |      96 | 48                
  ...and-parser.ts |   90.69 |    85.71 |     100 |   90.69 | 63-66             
  ...ionService.ts |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
 ...ght/generators |    85.9 |    85.61 |   90.47 |    85.9 |                   
  DataProcessor.ts |   85.63 |     85.6 |   92.85 |   85.63 | ...1122,1126-1133 
  ...tGenerator.ts |   98.21 |    85.71 |     100 |   98.21 | 46                
  ...teRenderer.ts |   45.45 |      100 |       0 |   45.45 | 13-51             
 .../insight/types |       0 |       50 |      50 |       0 |                   
  ...sightTypes.ts |       0 |        0 |       0 |       0 |                   
  ...sightTypes.ts |       0 |        0 |       0 |       0 | 1                 
 ...mpt-processors |   97.27 |    94.04 |     100 |   97.27 |                   
  ...tProcessor.ts |     100 |      100 |     100 |     100 |                   
  ...eProcessor.ts |   94.52 |    84.21 |     100 |   94.52 | 46-47,93-94       
  ...tionParser.ts |     100 |      100 |     100 |     100 |                   
  ...lProcessor.ts |   97.41 |    95.65 |     100 |   97.41 | 95-98             
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/services/tips |   97.35 |    83.07 |     100 |   97.35 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  tipHistory.ts    |   92.45 |       70 |     100 |   92.45 | ...22,144,151,160 
  tipRegistry.ts   |     100 |    95.23 |     100 |     100 | 33                
  tipScheduler.ts  |     100 |    91.66 |     100 |     100 | 55                
 src/test-utils    |   93.75 |    83.33 |      80 |   93.75 |                   
  ...omMatchers.ts |   69.69 |       50 |      50 |   69.69 | 32-35,37-39,45-47 
  ...andContext.ts |     100 |      100 |     100 |     100 |                   
  render.tsx       |     100 |      100 |     100 |     100 |                   
 src/ui            |   66.51 |    73.28 |   57.89 |   66.51 |                   
  App.tsx          |     100 |      100 |     100 |     100 |                   
  AppContainer.tsx |   65.03 |    64.98 |   52.94 |   65.03 | ...2951,2955-2959 
  ...tionNudge.tsx |    9.58 |      100 |       0 |    9.58 | 24-94             
  ...ackDialog.tsx |   29.23 |      100 |       0 |   29.23 | 25-75             
  ...tionNudge.tsx |    7.69 |      100 |       0 |    7.69 | 25-103            
  colors.ts        |   52.72 |      100 |   23.52 |   52.72 | ...52,54-55,60-61 
  constants.ts     |     100 |      100 |     100 |     100 |                   
  keyMatchers.ts   |   95.91 |    97.05 |     100 |   95.91 | 25-26             
  ...tic-colors.ts |     100 |      100 |     100 |     100 |                   
  ...inePresets.ts |   98.17 |    88.88 |     100 |   98.17 | ...12,239,387-389 
  textConstants.ts |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/ui/auth       |   55.06 |    51.13 |   35.48 |   55.06 |                   
  AuthDialog.tsx   |   64.26 |    44.44 |   16.66 |   64.26 | ...59,366-388,392 
  ...nProgress.tsx |       0 |        0 |       0 |       0 | 1-64              
  ...etupSteps.tsx |    39.5 |       32 |   38.46 |    39.5 | ...69,472,478,481 
  useAuth.ts       |   76.63 |    68.29 |     100 |   76.63 | ...48,493-499,560 
  ...rSetupFlow.ts |   44.61 |    33.33 |      50 |   44.61 | ...57-378,395-438 
 src/ui/commands   |   73.46 |    81.23 |   81.61 |   73.46 |                   
  aboutCommand.ts  |     100 |      100 |     100 |     100 |                   
  agentsCommand.ts |   83.78 |      100 |      60 |   83.78 | 30-32,42-44       
  ...odeCommand.ts |     100 |      100 |     100 |     100 |                   
  arenaCommand.ts  |   62.81 |    58.73 |   65.21 |   62.81 | ...91-596,681-689 
  authCommand.ts   |     100 |      100 |     100 |     100 |                   
  branchCommand.ts |     100 |      100 |     100 |     100 |                   
  btwCommand.ts    |   95.59 |    71.42 |     100 |   95.59 | 72,154-159        
  bugCommand.ts    |   81.13 |    71.42 |     100 |   81.13 | 60-69             
  clearCommand.ts  |      92 |    76.47 |     100 |      92 | 43-44,72-73,91-92 
  ...essCommand.ts |    64.7 |       50 |      75 |    64.7 | ...48-149,163-166 
  ...extCommand.ts |   34.78 |    22.22 |   45.45 |   34.78 | ...86-521,532-533 
  copyCommand.ts   |   98.28 |    94.89 |     100 |   98.28 | ...80,280,321,327 
  deleteCommand.ts |     100 |      100 |     100 |     100 |                   
  diffCommand.ts   |   99.02 |    86.11 |     100 |   99.02 | 222,226           
  ...ryCommand.tsx |   68.09 |    77.77 |   77.77 |   68.09 | ...56-261,315-323 
  docsCommand.ts   |     100 |    88.88 |     100 |     100 | 25                
  doctorCommand.ts |   95.06 |    88.28 |     100 |   95.06 | ...92-293,320-321 
  dreamCommand.ts  |      75 |    66.66 |   66.66 |      75 | 22-27,44-47       
  editorCommand.ts |     100 |      100 |     100 |     100 |                   
  exportCommand.ts |   98.25 |    91.02 |     100 |   98.25 | ...81,198-199,364 
  ...onsCommand.ts |   48.66 |     90.9 |   63.63 |   48.66 | ...05-109,159-211 
  forgetCommand.ts |   26.82 |      100 |      50 |   26.82 | 18-51             
  goalCommand.ts   |   91.25 |    83.33 |      90 |   91.25 | ...83-186,198-201 
  helpCommand.ts   |     100 |      100 |     100 |     100 |                   
  hooksCommand.ts  |    20.4 |       40 |      40 |    20.4 | ...48-180,204-205 
  ideCommand.ts    |   60.75 |    64.28 |   41.17 |   60.75 | ...05-306,310-324 
  initCommand.ts   |   84.33 |    72.72 |     100 |   84.33 | 68,82-87,89-94    
  ...ghtCommand.ts |   74.56 |    68.42 |     100 |   74.56 | ...31-245,250-273 
  ...ageCommand.ts |   92.17 |    82.69 |     100 |   92.17 | ...43,164,173-183 
  lspCommand.ts    |     100 |    86.95 |     100 |     100 | 31,101-102        
  ...elsCommand.ts |     100 |      100 |     100 |     100 |                   
  mcpCommand.ts    |     100 |      100 |     100 |     100 |                   
  memoryCommand.ts |     100 |      100 |     100 |     100 |                   
  modelCommand.ts  |   75.09 |    78.18 |      75 |   75.09 | ...20-225,262-267 
  ...onsCommand.ts |     100 |      100 |     100 |     100 |                   
  planCommand.ts   |   78.82 |    76.92 |     100 |   78.82 | 30-35,51-56,68-73 
  quitCommand.ts   |     100 |      100 |     100 |     100 |                   
  recapCommand.ts  |   21.81 |      100 |      50 |   21.81 | 24-73             
  ...berCommand.ts |   32.43 |      100 |      50 |   32.43 | 23-57             
  renameCommand.ts |   85.71 |    86.04 |     100 |   85.71 | ...02-209,216-221 
  ...oreCommand.ts |    92.3 |    87.87 |     100 |    92.3 | ...,83-88,129-130 
  resumeCommand.ts |     100 |      100 |     100 |     100 |                   
  rewindCommand.ts |      80 |      100 |      50 |      80 | 19-21             
  ...ngsCommand.ts |     100 |      100 |     100 |     100 |                   
  ...hubCommand.ts |   81.43 |    65.21 |      80 |   81.43 | ...70-173,176-179 
  skillsCommand.ts |   15.04 |      100 |      25 |   15.04 | ...90-106,109-136 
  statsCommand.ts  |   88.19 |    84.21 |     100 |   88.19 | ...,58-61,143-146 
  ...ineCommand.ts |     100 |      100 |     100 |     100 |                   
  ...aryCommand.ts |    6.46 |      100 |      50 |    6.46 | 31-329            
  tasksCommand.ts  |   77.22 |    72.13 |     100 |   77.22 | ...46-150,172-177 
  ...tupCommand.ts |     100 |      100 |     100 |     100 |                   
  themeCommand.ts  |     100 |      100 |     100 |     100 |                   
  toolsCommand.ts  |     100 |      100 |     100 |     100 |                   
  trustCommand.ts  |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
  vimCommand.ts    |   54.54 |      100 |      50 |   54.54 | 19-29             
 src/ui/components |   65.63 |    75.02 |   69.74 |   65.63 |                   
  AboutBox.tsx     |     100 |      100 |     100 |     100 |                   
  AnsiOutput.tsx   |   65.57 |      100 |      50 |   65.57 | 69-90             
  ApiKeyInput.tsx  |       0 |        0 |       0 |       0 | 1-97              
  AppHeader.tsx    |   89.39 |       75 |     100 |   89.39 | 35,37-42,44       
  ...odeDialog.tsx |     9.7 |      100 |       0 |     9.7 | 35-47,50-182      
  AsciiArt.ts      |     100 |      100 |     100 |     100 |                   
  ...Indicator.tsx |   14.63 |      100 |       0 |   14.63 | 18-56             
  ...TextInput.tsx |   77.01 |       76 |     100 |   77.01 | ...20,234-236,263 
  Composer.tsx     |    80.8 |     64.7 |     100 |    80.8 | ...85,103,154,167 
  ...entPrompt.tsx |     100 |      100 |     100 |     100 |                   
  ...ryDisplay.tsx |   75.89 |    62.06 |     100 |   75.89 | ...,88,93-108,113 
  ...geDisplay.tsx |   68.42 |    57.14 |     100 |   68.42 | 16-17,31-32,42-50 
  ...ification.tsx |   28.57 |      100 |       0 |   28.57 | 16-36             
  ...gProfiler.tsx |       0 |        0 |       0 |       0 | 1-36              
  ...ogManager.tsx |    12.2 |      100 |       0 |    12.2 | 64-490            
  ...ngsDialog.tsx |    8.44 |      100 |       0 |    8.44 | 37-195            
  ExitWarning.tsx  |     100 |      100 |     100 |     100 |                   
  ...hProgress.tsx |    87.8 |    33.33 |     100 |    87.8 | 28-31,56          
  ...ustDialog.tsx |     100 |      100 |     100 |     100 |                   
  Footer.tsx       |   79.54 |    54.54 |     100 |   79.54 | ...05-109,133-134 
  ...ngSpinner.tsx |   68.42 |       80 |      50 |   68.42 | 35-52,73,80-81    
  GoalPill.tsx     |   76.19 |    81.81 |     100 |   76.19 | 24-30,46-50       
  Header.tsx       |   98.62 |    94.28 |     100 |   98.62 | 162,164           
  Help.tsx         |   98.32 |    89.88 |     100 |   98.32 | ...24,381,447-448 
  ...emDisplay.tsx |    61.7 |       36 |     100 |    61.7 | ...42,345,348-354 
  ...ngeDialog.tsx |     100 |      100 |     100 |     100 |                   
  InputPrompt.tsx  |   82.75 |    78.96 |   83.33 |   82.75 | ...1425,1490,1540 
  ...Shortcuts.tsx |   20.87 |      100 |       0 |   20.87 | ...6,49-51,67-125 
  ...Indicator.tsx |     100 |    91.42 |     100 |     100 | 65,74             
  ...firmation.tsx |   91.42 |      100 |      50 |   91.42 | 26-31             
  MainContent.tsx  |   81.75 |       75 |     100 |   81.75 | ...70-274,282-286 
  ...elsDialog.tsx |   71.05 |    69.11 |   72.72 |   71.05 | ...77,590,601-603 
  MemoryDialog.tsx |    55.1 |    54.54 |   57.14 |    55.1 | ...56,368,381-383 
  ...geDisplay.tsx |       0 |        0 |       0 |       0 | 1-41              
  ModelDialog.tsx  |   80.12 |    63.55 |     100 |   80.12 | ...39-555,612-616 
  ...tsDisplay.tsx |     100 |    97.22 |     100 |     100 | 270               
  ...fications.tsx |   18.18 |      100 |       0 |   18.18 | 15-58             
  ...onsDialog.tsx |    2.13 |      100 |       0 |    2.13 | 62-133,148-1004   
  ...ryDisplay.tsx |     100 |      100 |     100 |     100 |                   
  ...icePrompt.tsx |   92.64 |    85.71 |     100 |   92.64 | 102-106,134-139   
  PrepareLabel.tsx |   91.66 |    77.27 |     100 |   91.66 | 73-75,77-79,110   
  ...atePrompt.tsx |    8.57 |      100 |       0 |    8.57 | 24-55,58-134      
  ...geDisplay.tsx |     100 |      100 |     100 |     100 |                   
  ...ngDisplay.tsx |   21.42 |      100 |       0 |   21.42 | 13-39             
  ...hProgress.tsx |   85.25 |    88.46 |     100 |   85.25 | 121-147           
  ...dSelector.tsx |   41.26 |    61.53 |   71.42 |   41.26 | ...74-472,476-520 
  ...ionPicker.tsx |   83.66 |    72.13 |     100 |   83.66 | ...96,402,444-466 
  ...onPreview.tsx |   92.42 |    84.37 |     100 |   92.42 | ...,70-71,143-145 
  ...ryDisplay.tsx |     100 |      100 |     100 |     100 |                   
  ...putPrompt.tsx |   72.56 |       80 |      40 |   72.56 | ...06-109,114-117 
  ...ngsDialog.tsx |   66.27 |    71.16 |      75 |   66.27 | ...12-820,826-827 
  ...ionDialog.tsx |    87.8 |      100 |   33.33 |    87.8 | 36-39,44-51       
  ...putPrompt.tsx |    15.9 |      100 |       0 |    15.9 | 20-63             
  ...Indicator.tsx |   57.14 |      100 |       0 |   57.14 | 12-15             
  ...MoreLines.tsx |      28 |      100 |       0 |      28 | 18-40             
  ...ionPicker.tsx |   17.59 |      100 |       0 |   17.59 | 55-172            
  StatsDisplay.tsx |     100 |      100 |     100 |     100 |                   
  ...ineDialog.tsx |   93.69 |    83.92 |     100 |   93.69 | ...11,273,293-295 
  ...yTodoList.tsx |   94.17 |       80 |     100 |   94.17 | 56-57,131-134     
  ...nsDisplay.tsx |   87.25 |       64 |     100 |   87.25 | ...45-147,154-156 
  ThemeDialog.tsx  |   89.95 |    46.15 |      75 |   89.95 | ...71-173,243-245 
  Tips.tsx         |   93.54 |       75 |     100 |   93.54 | 39-40             
  TodoDisplay.tsx  |     100 |      100 |     100 |     100 |                   
  ...tsDisplay.tsx |     100 |     87.5 |     100 |     100 | 31-32             
  TrustDialog.tsx  |     100 |    81.81 |     100 |     100 | 71-86             
  ...ification.tsx |   36.36 |      100 |       0 |   36.36 | 15-22             
  ...ackDialog.tsx |    7.84 |      100 |       0 |    7.84 | 24-134            
 ...nts/agent-view |   38.33 |    70.83 |   36.36 |   38.33 |                   
  ...atContent.tsx |    8.79 |      100 |       0 |    8.79 | 53-265,271-273    
  ...tChatView.tsx |   21.05 |      100 |       0 |   21.05 | 21-39             
  ...tComposer.tsx |    9.95 |      100 |       0 |    9.95 | 57-308            
  AgentFooter.tsx  |   17.07 |      100 |       0 |   17.07 | 28-66             
  AgentHeader.tsx  |   15.38 |      100 |       0 |   15.38 | 27-64             
  AgentTabBar.tsx  |    87.8 |    27.27 |     100 |    87.8 | ...,85,98-106,124 
  ...oryAdapter.ts |     100 |    91.83 |     100 |     100 | 103,109-110,138   
  index.ts         |       0 |        0 |       0 |       0 | 1-12              
 ...mponents/arena |   45.72 |    70.53 |   60.86 |   45.72 |                   
  ArenaCards.tsx   |   73.06 |    71.79 |   85.71 |   73.06 | ...83-185,321-326 
  ...ectDialog.tsx |   83.48 |    69.86 |   88.88 |   83.48 | ...88-392,409-410 
  ...artDialog.tsx |   10.15 |      100 |       0 |   10.15 | 27-161            
  ...tusDialog.tsx |    5.63 |      100 |       0 |    5.63 | 33-75,80-288      
  ...topDialog.tsx |    6.17 |      100 |       0 |    6.17 | 33-213            
 ...ackground-view |   75.63 |    84.44 |   85.29 |   75.63 |                   
  ...sksDialog.tsx |   70.92 |    80.39 |   76.19 |   70.92 | ...1118,1194-1196 
  ...TasksPill.tsx |   63.75 |    86.95 |     100 |   63.75 | 44,86-106,114-122 
  ...gentPanel.tsx |   99.53 |    93.18 |     100 |   99.53 | 123               
 ...nts/extensions |   45.28 |    33.33 |      60 |   45.28 |                   
  ...gerDialog.tsx |   44.31 |    34.14 |      75 |   44.31 | ...71-480,483-488 
  index.ts         |       0 |        0 |       0 |       0 | 1-9               
  types.ts         |     100 |      100 |     100 |     100 |                   
 ...tensions/steps |   54.88 |    94.23 |   66.66 |   54.88 |                   
  ...ctionStep.tsx |   95.12 |    92.85 |   85.71 |   95.12 | 84-86,89          
  ...etailStep.tsx |    6.18 |      100 |       0 |    6.18 | 17-128            
  ...nListStep.tsx |   88.43 |    94.73 |      80 |   88.43 | 52-53,59-72,106   
  ...electStep.tsx |   13.46 |      100 |       0 |   13.46 | 20-70             
  ...nfirmStep.tsx |   19.56 |      100 |       0 |   19.56 | 23-65             
  index.ts         |     100 |      100 |     100 |     100 |                   
 ...mponents/hooks |   68.67 |    69.07 |   69.56 |   68.67 |                   
  ...etailStep.tsx |   74.68 |    66.66 |   66.66 |   74.68 | ...71-184,188-201 
  ...etailStep.tsx |    87.4 |    73.68 |     100 |    87.4 | 41-42,99-113,119  
  ...abledStep.tsx |     100 |      100 |     100 |     100 |                   
  ...sListStep.tsx |     100 |      100 |     100 |     100 |                   
  ...entDialog.tsx |   34.51 |    47.05 |   42.85 |   34.51 | ...78,482-495,499 
  constants.ts     |     100 |      100 |     100 |     100 |                   
  index.ts         |       0 |        0 |       0 |       0 | 1-13              
  types.ts         |     100 |      100 |     100 |     100 |                   
 ...components/mcp |   20.98 |    86.36 |   83.33 |   20.98 |                   
  ...ealthPill.tsx |   68.42 |    85.71 |     100 |   68.42 | 40-46             
  ...entDialog.tsx |    3.64 |      100 |       0 |    3.64 | 41-717            
  constants.ts     |     100 |      100 |     100 |     100 |                   
  index.ts         |       0 |        0 |       0 |       0 | 1-30              
  types.ts         |     100 |      100 |     100 |     100 |                   
  utils.ts         |   95.83 |    88.88 |     100 |   95.83 | 16,20,109-110     
 ...ents/mcp/steps |   26.74 |    54.54 |   42.85 |   26.74 |                   
  ...icateStep.tsx |    5.88 |      100 |       0 |    5.88 | 40-55,58-296      
  ...electStep.tsx |   10.95 |      100 |       0 |   10.95 | 16-88             
  ...etailStep.tsx |    5.26 |      100 |       0 |    5.26 | 31-247            
  ...rListStep.tsx |   75.18 |    59.37 |     100 |   75.18 | ...53-158,169-173 
  ...etailStep.tsx |   10.41 |      100 |       0 |   10.41 | ...1,67-79,82-139 
  ToolListStep.tsx |   69.02 |       50 |     100 |   69.02 | ...22,125,134-143 
 ...nents/messages |   82.44 |    79.55 |    72.6 |   82.44 |                   
  ...ionDialog.tsx |   80.84 |     77.6 |    62.5 |   80.84 | ...98,516,534-536 
  BtwMessage.tsx   |     100 |      100 |     100 |     100 |                   
  ...upDisplay.tsx |   97.67 |    83.72 |     100 |   97.67 | 119,142,150       
  ...onMessage.tsx |   91.93 |    82.35 |     100 |   91.93 | 57-59,61,63       
  ...nMessages.tsx |   79.06 |      100 |      70 |   79.06 | ...51-264,268-280 
  DiffRenderer.tsx |   93.19 |    86.17 |     100 |   93.19 | ...09,237-238,304 
  ...tsDisplay.tsx |   97.82 |    77.27 |     100 |   97.82 | 87,89             
  ...usMessage.tsx |   76.31 |     42.1 |   66.66 |   76.31 | ...99,101,124,155 
  ...ssMessage.tsx |    12.5 |      100 |       0 |    12.5 | 18-59             
  ...edMessage.tsx |   16.66 |      100 |       0 |   16.66 | 22-38             
  ...sMessages.tsx |   55.67 |       40 |   28.57 |   55.67 | ...20-125,133-145 
  ...ryMessage.tsx |   14.28 |      100 |       0 |   14.28 | 23-62             
  ...onMessage.tsx |   81.02 |    69.23 |   33.33 |   81.02 | ...24-426,433-435 
  ...upMessage.tsx |      84 |    93.61 |     100 |      84 | ...56-383,405-420 
  ToolMessage.tsx  |   88.84 |    75.71 |    92.3 |   88.84 | ...44-749,776-778 
 ...ponents/shared |   85.36 |    78.48 |   95.77 |   85.36 |                   
  ...ctionList.tsx |   99.03 |    95.65 |     100 |   99.03 | 85                
  ...tonSelect.tsx |     100 |      100 |     100 |     100 |                   
  EnumSelector.tsx |     100 |    96.42 |     100 |     100 | 58                
  MaxSizedBox.tsx  |   83.01 |    86.25 |   88.88 |   83.01 | ...12-513,618-619 
  MultiSelect.tsx  |   84.31 |    74.19 |     100 |   84.31 | ...37,193-195,205 
  ...tonSelect.tsx |     100 |      100 |     100 |     100 |                   
  ...eSelector.tsx |     100 |       60 |     100 |     100 | 40-45             
  TextInput.tsx    |   77.01 |    48.78 |      80 |   77.01 | ...08-212,224-230 
  ...apsedTime.tsx |     100 |      100 |     100 |     100 |                   
  ...Indicator.tsx |     100 |      100 |     100 |     100 |                   
  text-buffer.ts   |   83.68 |    78.55 |   97.61 |   83.68 | ...2270-2272,2368 
  ...er-actions.ts |   86.71 |    67.79 |     100 |   86.71 | ...07-608,809-811 
 ...ents/subagents |   30.87 |        0 |       0 |   30.87 |                   
  constants.ts     |     100 |      100 |     100 |     100 |                   
  index.ts         |       0 |        0 |       0 |       0 | 1-11              
  reducers.tsx     |    12.1 |      100 |       0 |    12.1 | 33-190            
  types.ts         |     100 |      100 |     100 |     100 |                   
  utils.ts         |   10.95 |      100 |       0 |   10.95 | ...1,56-57,60-102 
 ...bagents/create |    9.13 |      100 |       0 |    9.13 |                   
  ...ionWizard.tsx |    7.28 |      100 |       0 |    7.28 | 34-299            
  ...rSelector.tsx |   14.75 |      100 |       0 |   14.75 | 26-85             
  ...onSummary.tsx |    4.26 |      100 |       0 |    4.26 | 27-331            
  ...tionInput.tsx |    8.63 |      100 |       0 |    8.63 | 23-177            
  ...dSelector.tsx |   33.33 |      100 |       0 |   33.33 | 20-21,26-27,36-63 
  ...nSelector.tsx |    37.5 |      100 |       0 |    37.5 | 20-21,26-27,36-58 
  ...EntryStep.tsx |   12.76 |      100 |       0 |   12.76 | 34-78             
  ToolSelector.tsx |    4.16 |      100 |       0 |    4.16 | 31-253            
 ...bagents/manage |   21.51 |    59.52 |   27.27 |   21.51 |                   
  ...ctionStep.tsx |   10.25 |      100 |       0 |   10.25 | 21-103            
  ...eleteStep.tsx |   20.93 |      100 |       0 |   20.93 | 23-62             
  ...tEditStep.tsx |   25.53 |      100 |       0 |   25.53 | ...2,37-38,51-124 
  ...ctionStep.tsx |   35.42 |    59.52 |     100 |   35.42 | ...20-432,437-439 
  ...iewerStep.tsx |   13.72 |      100 |       0 |   13.72 | 18-73             
  ...gerDialog.tsx |    6.74 |      100 |       0 |    6.74 | 35-341            
 ...mponents/views |   42.16 |    69.23 |   21.42 |   42.16 |                   
  ContextUsage.tsx |     4.7 |      100 |       0 |     4.7 | ...52-167,170-456 
  DoctorReport.tsx |     9.8 |      100 |       0 |     9.8 | 25-54,57-131      
  ...sionsList.tsx |   87.69 |    73.68 |     100 |   87.69 | 65-72             
  McpStatus.tsx    |   89.53 |    60.52 |     100 |   89.53 | ...72,175-177,262 
  SkillsList.tsx   |   27.27 |      100 |       0 |   27.27 | 18-35             
  ToolsList.tsx    |     100 |      100 |     100 |     100 |                   
 src/ui/contexts   |   77.11 |    77.66 |   80.35 |   77.11 |                   
  ...ewContext.tsx |    64.7 |    85.71 |      50 |    64.7 | ...22-225,231-241 
  AppContext.tsx   |      80 |       50 |     100 |      80 | 19-20             
  ...ewContext.tsx |   95.18 |    67.56 |      50 |   95.18 | ...94-195,222-226 
  ...deContext.tsx |     100 |      100 |     100 |     100 |                   
  ...igContext.tsx |   81.81 |       50 |     100 |   81.81 | 15-16             
  ...ssContext.tsx |   81.88 |    82.26 |     100 |   81.88 | ...1153,1159-1161 
  ...owContext.tsx |   89.28 |       80 |   66.66 |   89.28 | 34,47-48,60-62    
  ...deContext.tsx |     100 |      100 |      50 |     100 |                   
  ...onContext.tsx |   43.28 |     62.5 |    62.5 |   43.28 | ...56-259,263-266 
  ...gsContext.tsx |   83.33 |       50 |     100 |   83.33 | 17-18             
  ...usContext.tsx |     100 |      100 |     100 |     100 |                   
  ...ngContext.tsx |   71.42 |       50 |     100 |   71.42 | 17-20             
  ...utContext.tsx |   85.71 |      100 |   66.66 |   85.71 | 13-14             
  ...nsContext.tsx |   88.23 |       50 |     100 |   88.23 | 113-114           
  ...teContext.tsx |   86.66 |       50 |     100 |   86.66 | 177-178           
  ...deContext.tsx |   76.08 |    72.72 |     100 |   76.08 | 47-48,52-59,77-78 
 src/ui/daemon     |   90.76 |    73.73 |   95.45 |   90.76 |                   
  ...TuiAdapter.ts |   90.76 |    73.73 |   95.45 |   90.76 | ...53,771-772,858 
 src/ui/editors    |   93.33 |    85.71 |   66.66 |   93.33 |                   
  ...ngsManager.ts |   93.33 |    85.71 |   66.66 |   93.33 | 49,63-64          
 src/ui/hooks      |   82.48 |    82.56 |   86.66 |   82.48 |                   
  ...dProcessor.ts |   83.12 |    82.56 |     100 |   83.12 | ...88-389,408-435 
  keyToAnsi.ts     |    3.92 |      100 |       0 |    3.92 | 19-77             
  ...dProcessor.ts |    94.8 |    70.58 |     100 |    94.8 | ...76-277,282-283 
  ...dProcessor.ts |   75.75 |    63.01 |   61.53 |   75.75 | ...84,908,927-931 
  ...amingState.ts |   12.22 |      100 |       0 |   12.22 | 54-157            
  ...agerDialog.ts |   88.23 |      100 |     100 |   88.23 | 20,24             
  ...ationFrame.ts |      32 |       60 |     100 |      32 | 42-44,51-90       
  ...odeCommand.ts |   58.82 |      100 |     100 |   58.82 | 28,33-48          
  ...enaCommand.ts |      85 |      100 |     100 |      85 | 23-24,29          
  ...aInProcess.ts |   19.81 |    66.66 |      25 |   19.81 | 57-175            
  ...Completion.ts |   92.77 |    89.09 |     100 |   92.77 | ...86-187,220-223 
  ...ifications.ts |   92.07 |    96.29 |     100 |   92.07 | 116-124           
  ...tIndicator.ts |     100 |    93.75 |     100 |     100 | 63                
  ...waySummary.ts |   96.22 |    69.69 |     100 |   96.22 | 125-127,169       
  ...ndTaskView.ts |   94.21 |    76.08 |     100 |   94.21 | 122-126,213,219   
  ...ketedPaste.ts |    23.8 |      100 |       0 |    23.8 | 19-37             
  ...nchCommand.ts |   94.36 |    74.35 |     100 |   94.36 | ...60,168-169,209 
  ...ompletion.tsx |   95.95 |    82.75 |     100 |   95.95 | ...22-223,225-226 
  ...dMigration.ts |   90.62 |       75 |     100 |   90.62 | 38-40             
  useCompletion.ts |    92.4 |     87.5 |     100 |    92.4 | 68-69,93-94,98-99 
  ...nitMessage.ts |     100 |      100 |     100 |     100 |                   
  ...extualTips.ts |   76.92 |       50 |     100 |   76.92 | 55,68,71-75,88-96 
  ...eteCommand.ts |   78.53 |    88.57 |     100 |   78.53 | ...96-104,112-113 
  ...ialogClose.ts |   15.38 |      100 |     100 |   15.38 | 83-148            
  ...oublePress.ts |   53.12 |       75 |     100 |   53.12 | 33-35,41-54       
  ...orSettings.ts |     100 |      100 |     100 |     100 |                   
  ...Completion.ts |   99.12 |     97.7 |     100 |   99.12 | 182-183           
  ...ionUpdates.ts |   93.45 |     92.3 |     100 |   93.45 | ...83-287,300-306 
  ...agerDialog.ts |   88.88 |      100 |     100 |   88.88 | 21,25             
  ...backDialog.ts |   54.47 |       50 |   33.33 |   54.47 | ...69-171,193-194 
  useFocus.ts      |     100 |      100 |     100 |     100 |                   
  ...olderTrust.ts |     100 |      100 |     100 |     100 |                   
  ...ggestions.tsx |   89.15 |     62.5 |      50 |   89.15 | ...22-124,149-150 
  ...miniStream.ts |    77.7 |    74.93 |   91.66 |    77.7 | ...2497,2510-2518 
  ...BranchName.ts |    90.9 |     92.3 |     100 |    90.9 | 19-20,55-58       
  ...oryManager.ts |   93.15 |    93.75 |     100 |   93.15 | 44,107-110        
  ...ooksDialog.ts |    87.5 |      100 |     100 |    87.5 | 19,23             
  ...stListener.ts |     100 |      100 |     100 |     100 |                   
  ...nAuthError.ts |   76.19 |       50 |     100 |   76.19 | 39-40,43-45       
  ...putHistory.ts |   92.59 |    85.71 |     100 |   92.59 | 63-64,72,94-96    
  ...storyStore.ts |     100 |    94.11 |     100 |     100 | 69                
  useKeypress.ts   |     100 |      100 |     100 |     100 |                   
  ...rdProtocol.ts |   36.36 |      100 |       0 |   36.36 | 24-31             
  ...unchEditor.ts |    9.67 |      100 |       0 |    9.67 | 11-32,39-90       
  ...gIndicator.ts |     100 |      100 |     100 |     100 |                   
  useLogger.ts     |   21.05 |      100 |       0 |   21.05 | 15-37             
  useMCPHealth.ts  |   63.15 |       75 |      50 |   63.15 | 42-52,64-67       
  ...elsCommand.ts |     100 |      100 |     100 |     100 |                   
  useMcpDialog.ts  |    87.5 |      100 |     100 |    87.5 | 19,23             
  ...moryDialog.ts |    87.5 |      100 |     100 |    87.5 | 19,23             
  ...oryMonitor.ts |     100 |      100 |     100 |     100 |                   
  ...ssageQueue.ts |     100 |      100 |     100 |     100 |                   
  ...delCommand.ts |     100 |       75 |     100 |     100 | 22                
  ...raseCycler.ts |   84.74 |    76.47 |     100 |   84.74 | ...49,52-53,69-71 
  ...derUpdates.ts |   86.38 |    77.19 |     100 |   86.38 | ...22,281-293,341 
  useQwenAuth.ts   |     100 |      100 |     100 |     100 |                   
  ...lScheduler.ts |    84.7 |    93.33 |     100 |    84.7 | ...71-276,372-382 
  ...oryCommand.ts |       0 |        0 |       0 |       0 | 1-7               
  ...umeCommand.ts |   97.08 |    83.33 |     100 |   97.08 | 103-104,133       
  ...ompletion.tsx |   90.59 |    83.33 |     100 |   90.59 | ...01,104,137-140 
  ...ectionList.ts |   96.98 |    95.65 |     100 |   96.98 | ...83-184,238-241 
  ...sionPicker.ts |   92.87 |    90.35 |     100 |   92.87 | ...99-501,503-505 
  ...earchInput.ts |     100 |      100 |     100 |     100 |                   
  ...ngsCommand.ts |   18.75 |      100 |       0 |   18.75 | 10-25             
  ...ellHistory.ts |   91.74 |    79.41 |     100 |   91.74 | ...74,122-123,133 
  ...oryCommand.ts |       0 |        0 |       0 |       0 | 1-73              
  ...Completion.ts |   82.67 |    85.41 |   94.73 |   82.67 | ...68-670,678-714 
  ...tateAndRef.ts |     100 |      100 |     100 |     100 |                   
  useStatusLine.ts |   97.67 |    91.66 |     100 |   97.67 | ...28-332,344-347 
  ...eateDialog.ts |   88.23 |      100 |     100 |   88.23 | 14,18             
  ...tification.ts |     100 |    85.71 |     100 |     100 | 47                
  ...alProgress.ts |   53.06 |       50 |   66.66 |   53.06 | ...53,61-68,79-85 
  ...rminalSize.ts |   76.19 |      100 |      50 |   76.19 | 21-25             
  ...emeCommand.ts |   67.01 |    29.41 |     100 |   67.01 | ...10-111,115-116 
  useTimer.ts      |   88.09 |    85.71 |     100 |   88.09 | 44-45,51-53       
  ...lMigration.ts |       0 |        0 |       0 |       0 |                   
  ...rustModify.ts |     100 |      100 |     100 |     100 |                   
  ...elcomeBack.ts |   87.36 |     90.9 |     100 |   87.36 | ...,94-96,114-115 
  vim.ts           |   83.77 |    80.31 |     100 |   83.77 | ...55,759-767,776 
 src/ui/layouts    |   89.72 |     87.5 |     100 |   89.72 |                   
  ...AppLayout.tsx |   89.88 |     87.5 |     100 |   89.88 | 51-53,93-98       
  ...AppLayout.tsx |   89.47 |     87.5 |     100 |   89.47 | 58-63             
 ...i/manageModels |   93.61 |       48 |     100 |   93.61 |                   
  manageModels.ts  |   93.61 |       48 |     100 |   93.61 | ...63-166,179,209 
 src/ui/models     |   80.24 |    79.16 |   71.42 |   80.24 |                   
  ...ableModels.ts |   80.24 |    79.16 |   71.42 |   80.24 | ...,61-71,123-125 
 ...noninteractive |     100 |      100 |   14.28 |     100 |                   
  ...eractiveUi.ts |     100 |      100 |   14.28 |     100 |                   
 src/ui/state      |   94.91 |    81.81 |     100 |   94.91 |                   
  extensions.ts    |   94.91 |    81.81 |     100 |   94.91 | 68-69,88          
 src/ui/themes     |   98.53 |    70.58 |     100 |   98.53 |                   
  ansi-light.ts    |     100 |      100 |     100 |     100 |                   
  ansi.ts          |     100 |      100 |     100 |     100 |                   
  atom-one-dark.ts |     100 |      100 |     100 |     100 |                   
  ayu-light.ts     |     100 |      100 |     100 |     100 |                   
  ayu.ts           |     100 |      100 |     100 |     100 |                   
  color-utils.ts   |     100 |      100 |     100 |     100 |                   
  default-light.ts |     100 |      100 |     100 |     100 |                   
  default.ts       |     100 |      100 |     100 |     100 |                   
  ...inal-theme.ts |   88.59 |    85.96 |     100 |   88.59 | ...57-261,266-270 
  dracula.ts       |     100 |      100 |     100 |     100 |                   
  github-dark.ts   |     100 |      100 |     100 |     100 |                   
  github-light.ts  |     100 |      100 |     100 |     100 |                   
  googlecode.ts    |     100 |      100 |     100 |     100 |                   
  no-color.ts      |     100 |      100 |     100 |     100 |                   
  qwen-dark.ts     |     100 |      100 |     100 |     100 |                   
  qwen-light.ts    |     100 |      100 |     100 |     100 |                   
  ...tic-tokens.ts |     100 |      100 |     100 |     100 |                   
  ...-of-purple.ts |     100 |      100 |     100 |     100 |                   
  theme-manager.ts |   87.98 |    82.89 |     100 |   87.98 | ...48-357,362-363 
  theme.ts         |     100 |    38.02 |     100 |     100 | ...34-449,457-461 
  xcode.ts         |     100 |      100 |     100 |     100 |                   
 src/ui/utils      |   83.92 |    82.91 |   92.56 |   83.92 |                   
  ...Colorizer.tsx |   79.53 |    83.78 |     100 |   79.53 | ...51-152,249-275 
  ...nRenderer.tsx |   68.83 |    70.14 |      50 |   68.83 | ...52-254,274-293 
  ...wnDisplay.tsx |   86.01 |    87.41 |     100 |   86.01 | ...87,704,729-754 
  ...idDiagram.tsx |   87.79 |    95.34 |     100 |   87.79 | 156-179           
  ...eRenderer.tsx |   92.08 |    80.45 |      95 |   92.08 | ...76-679,723-728 
  ...dWorkUtils.ts |     100 |      100 |     100 |     100 |                   
  ...boardUtils.ts |   59.61 |    58.82 |     100 |   59.61 | ...,86-88,107-149 
  commandUtils.ts  |    95.9 |    88.42 |     100 |    95.9 | ...62,164-165,289 
  computeStats.ts  |     100 |      100 |     100 |     100 |                   
  customBanner.ts  |   90.68 |    91.22 |     100 |   90.68 | ...13,324-327,334 
  displayUtils.ts  |   88.37 |    72.22 |     100 |   88.37 | 23,25,29,31,33    
  formatters.ts    |   95.23 |    98.27 |     100 |   95.23 | 117-120           
  gradientUtils.ts |     100 |      100 |     100 |     100 |                   
  highlight.ts     |     100 |      100 |     100 |     100 |                   
  ...oryMapping.ts |     100 |    94.28 |     100 |     100 | 29,51             
  historyUtils.ts  |   94.11 |       94 |     100 |   94.11 | 94-97             
  isNarrowWidth.ts |     100 |      100 |     100 |     100 |                   
  ...olDetector.ts |    8.23 |      100 |       0 |    8.23 | ...31-132,135-136 
  latexRenderer.ts |   94.95 |     73.8 |     100 |   94.95 | ...76-178,184-187 
  layoutUtils.ts   |     100 |      100 |     100 |     100 |                   
  ...ightLoader.ts |     100 |    89.47 |     100 |     100 | 81,110            
  ...nUtilities.ts |   69.84 |    85.71 |     100 |   69.84 | 75-91,100-101     
  ...ToolGroups.ts |   98.66 |    96.77 |     100 |   98.66 | 48-49             
  ...geRenderer.ts |   86.23 |    69.06 |   95.12 |   86.23 | ...1284,1324-1330 
  ...alRenderer.ts |   86.69 |     71.9 |     100 |   86.69 | ...1476,1513-1519 
  ...lsBySource.ts |     100 |    95.23 |     100 |     100 | 84                
  osc8.ts          |   94.71 |    87.41 |     100 |   94.71 | ...43,428,432-433 
  ...mConstants.ts |     100 |      100 |     100 |     100 |                   
  restoreGoal.ts   |   98.98 |    97.05 |     100 |   98.98 | 98                
  ...storyUtils.ts |   61.89 |    69.87 |      90 |   61.89 | ...76,424,429-451 
  ...ickerUtils.ts |     100 |      100 |     100 |     100 |                   
  ...izedOutput.ts |   94.94 |      100 |   88.88 |   94.94 | 112-117           
  ...wOptimizer.ts |     100 |    96.77 |     100 |     100 | 69                
  terminalSetup.ts |    4.37 |      100 |       0 |    4.37 | 44-393            
  textUtils.ts     |   97.35 |    94.38 |   91.66 |   97.35 | ...50-251,386-387 
  todoSnapshot.ts  |   89.11 |    93.33 |     100 |   89.11 | ...,66-78,180-181 
  updateCheck.ts   |     100 |    80.95 |     100 |     100 | 30-42             
 ...i/utils/export |   56.77 |     40.8 |   79.41 |   56.77 |                   
  collect.ts       |   55.92 |    50.58 |   86.36 |   55.92 | ...25-640,642-647 
  index.ts         |     100 |      100 |     100 |     100 |                   
  normalize.ts     |   57.47 |    20.51 |      80 |   57.47 | ...09-310,324-359 
  types.ts         |       0 |        0 |       0 |       0 | 1                 
  utils.ts         |      40 |      100 |       0 |      40 | 11-13             
 ...ort/formatters |    3.38 |      100 |       0 |    3.38 |                   
  html.ts          |    9.61 |      100 |       0 |    9.61 | ...28,34-76,82-84 
  json.ts          |      50 |      100 |       0 |      50 | 14-15             
  jsonl.ts         |     3.5 |      100 |       0 |     3.5 | 14-76             
  markdown.ts      |    0.94 |      100 |       0 |    0.94 | 13-295            
 src/utils         |   76.06 |    89.52 |   93.82 |   76.06 |                   
  acpModelUtils.ts |     100 |      100 |     100 |     100 |                   
  apiPreconnect.ts |   96.72 |    97.14 |     100 |   96.72 | 165-168           
  checks.ts        |   33.33 |      100 |       0 |   33.33 | 23-28             
  cleanup.ts       |   84.12 |    93.33 |      80 |   84.12 | 75,106-115        
  commands.ts      |     100 |      100 |     100 |     100 |                   
  commentJson.ts   |   87.17 |     90.9 |     100 |   87.17 | 64-73             
  ...Calculator.ts |     100 |      100 |     100 |     100 |                   
  deepMerge.ts     |     100 |       90 |     100 |     100 | 41-43,49          
  ...ScopeUtils.ts |   97.56 |    88.88 |     100 |   97.56 | 67                
  doctorChecks.ts  |   71.06 |       75 |     100 |   71.06 | ...95-301,325-341 
  ...putCapture.ts |   90.65 |    86.17 |     100 |   90.65 | ...72,370,372-373 
  ...arResolver.ts |   94.28 |    88.46 |     100 |   94.28 | 28-29,125-126     
  errors.ts        |   98.67 |    96.36 |     100 |   98.67 | 67-68             
  events.ts        |     100 |      100 |     100 |     100 |                   
  gitUtils.ts      |   91.91 |    84.61 |     100 |   91.91 | 78-81,124-127     
  ...AutoUpdate.ts |   90.76 |    93.33 |   88.88 |   90.76 | 103-114           
  ...lationInfo.ts |     100 |      100 |     100 |     100 |                   
  languageUtils.ts |   97.89 |    96.42 |     100 |   97.89 | 132-133           
  math.ts          |       0 |        0 |       0 |       0 | 1-15              
  ...iagnostics.ts |   94.57 |    83.01 |   88.88 |   94.57 | ...05,311,315-317 
  ...onfigUtils.ts |     100 |      100 |     100 |     100 |                   
  ...iveHelpers.ts |   96.79 |    93.28 |     100 |   96.79 | ...76-477,575,588 
  osc.ts           |    97.5 |      100 |   88.88 |    97.5 | 195-196           
  package.ts       |   88.88 |       80 |     100 |   88.88 | 33-34             
  processUtils.ts  |     100 |      100 |     100 |     100 |                   
  readStdin.ts     |   79.62 |       90 |      80 |   79.62 | 33-40,52-54       
  relaunch.ts      |   98.07 |    76.92 |     100 |   98.07 | 70                
  resolvePath.ts   |   66.66 |       25 |     100 |   66.66 | 12-13,16,18-19    
  sandbox.ts       |       0 |        0 |       0 |       0 | 1-1047            
  settingsUtils.ts |   82.89 |    90.67 |   89.47 |   82.89 | ...52-663,670-678 
  spawnWrapper.ts  |     100 |      100 |     100 |     100 |                   
  ...upProfiler.ts |   98.46 |    94.52 |     100 |   98.46 | 130-131,305       
  ...upWarnings.ts |     100 |      100 |     100 |     100 |                   
  stdioHelpers.ts  |     100 |       60 |     100 |     100 | 23,32             
  systemInfo.ts    |   95.12 |    89.06 |     100 |   95.12 | ...43-244,249-253 
  ...InfoFields.ts |   87.61 |       65 |     100 |   87.61 | ...22-123,144-145 
  ...iffPreview.ts |   94.11 |    83.33 |     100 |   94.11 | 13                
  ...entEmitter.ts |     100 |      100 |     100 |     100 |                   
  ...upWarnings.ts |   91.17 |    82.35 |     100 |   91.17 | 67-68,73-74,77-78 
  version.ts       |     100 |       50 |     100 |     100 | 11                
  windowTitle.ts   |     100 |      100 |     100 |     100 |                   
  ...WithBackup.ts |   63.15 |    81.25 |     100 |   63.15 | 93,118-157        
-------------------|---------|----------|---------|---------|-------------------
Core Package - Full Text Report
-------------------|---------|----------|---------|---------|-------------------
File               | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
-------------------|---------|----------|---------|---------|-------------------
All files          |   79.42 |    82.82 |   82.02 |   79.42 |                   
 src               |     100 |      100 |     100 |     100 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
 src/__mocks__/fs  |       0 |        0 |       0 |       0 |                   
  promises.ts      |       0 |        0 |       0 |       0 | 1-48              
 src/agents        |   87.58 |    79.07 |   91.76 |   87.58 |                   
  ...transcript.ts |   92.25 |    85.71 |     100 |   92.25 | ...87,306-307,438 
  ...ent-resume.ts |    82.5 |     71.5 |   77.41 |    82.5 | ...1035-1039,1042 
  ...ound-tasks.ts |    95.4 |    86.48 |     100 |    95.4 | ...55-756,827-828 
  index.ts         |     100 |      100 |     100 |     100 |                   
 src/agents/arena  |   76.54 |    66.87 |   78.72 |   76.54 |                   
  ...gentClient.ts |   79.47 |    88.88 |   81.81 |   79.47 | ...68-183,189-204 
  ArenaManager.ts  |   75.37 |    63.37 |   78.26 |   75.37 | ...1860,1866-1867 
  arena-events.ts  |   64.44 |      100 |      50 |   64.44 | ...71-175,178-183 
  diff-summary.ts  |    87.5 |    72.34 |     100 |    87.5 | ...32-133,137-138 
  index.ts         |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
 ...gents/backends |   76.29 |    86.15 |   73.04 |   76.29 |                   
  ITermBackend.ts  |   97.97 |    93.93 |     100 |   97.97 | ...78-180,255,307 
  ...essBackend.ts |   91.25 |    90.62 |   86.66 |   91.25 | ...94,249-269,328 
  TmuxBackend.ts   |    90.7 |    76.55 |   97.36 |    90.7 | ...87,697,743-747 
  detect.ts        |   31.25 |      100 |       0 |   31.25 | 34-88             
  index.ts         |     100 |      100 |     100 |     100 |                   
  iterm-it2.ts     |     100 |     92.1 |     100 |     100 | 37-38,106         
  tmux-commands.ts |    6.64 |      100 |    3.03 |    6.64 | ...93-363,386-503 
  types.ts         |     100 |      100 |     100 |     100 |                   
 ...agents/runtime |   81.14 |     76.7 |   71.42 |   81.14 |                   
  agent-context.ts |     100 |      100 |     100 |     100 |                   
  agent-core.ts    |   76.49 |    72.35 |   60.86 |   76.49 | ...1608,1635-1682 
  agent-events.ts  |     100 |      100 |     100 |     100 |                   
  ...t-headless.ts |   81.19 |    71.73 |   60.86 |   81.19 | ...98-399,402-403 
  ...nteractive.ts |   79.71 |    79.62 |      75 |   79.71 | ...54,456,458,461 
  ...statistics.ts |   98.19 |    82.35 |     100 |   98.19 | 127,151,192,225   
  agent-types.ts   |     100 |      100 |     100 |     100 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
 src/agents/tasks  |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/config        |   78.34 |     81.3 |   65.53 |   78.34 |                   
  config.ts        |   76.15 |       80 |   60.81 |   76.15 | ...3700,3711-3723 
  constants.ts     |     100 |      100 |     100 |     100 |                   
  models.ts        |     100 |      100 |     100 |     100 |                   
  storage.ts       |   95.01 |     90.9 |   90.47 |   95.01 | ...71-372,375-376 
 ...nfirmation-bus |   98.29 |    97.14 |     100 |   98.29 |                   
  message-bus.ts   |   98.14 |    97.05 |     100 |   98.14 | 42-43             
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/core          |   86.91 |    82.83 |    89.9 |   86.91 |                   
  baseLlmClient.ts |   92.35 |    80.85 |   86.66 |   92.35 | ...34,342-356,495 
  client.ts        |   86.49 |    80.29 |   85.29 |   86.49 | ...1836,1875-1878 
  ...tGenerator.ts |    72.1 |    61.11 |     100 |    72.1 | ...63,365,372-375 
  ...lScheduler.ts |   83.06 |    81.67 |   93.47 |   83.06 | ...2447,2499-2503 
  geminiChat.ts    |   89.32 |     84.8 |   91.48 |   89.32 | ...1454,1521-1522 
  geminiRequest.ts |     100 |      100 |     100 |     100 |                   
  ...htProtocol.ts |    9.09 |      100 |       0 |    9.09 | 34-42,45-49,52-87 
  logger.ts        |   87.33 |    87.02 |     100 |   87.33 | ...61-565,611-625 
  ...tyDefaults.ts |     100 |      100 |     100 |     100 |                   
  ...olExecutor.ts |   92.59 |       75 |      50 |   92.59 | 41-42             
  ...on-helpers.ts |   85.71 |    70.58 |     100 |   85.71 | ...90-191,205-214 
  ...issionFlow.ts |   98.59 |    94.73 |     100 |   98.59 | 93                
  prompts.ts       |   89.16 |    86.41 |   76.92 |   89.16 | ...-965,1168-1169 
  tokenLimits.ts   |     100 |    89.47 |     100 |     100 | 51-52             
  ...okTriggers.ts |   99.31 |    90.41 |     100 |   99.31 | 124,135           
  turn.ts          |   96.44 |    88.88 |     100 |   96.44 | ...08,421-422,470 
 ...ntentGenerator |   94.92 |    82.59 |   93.87 |   94.92 |                   
  ...tGenerator.ts |   96.48 |    84.28 |   92.59 |   96.48 | ...01,919-923,963 
  converter.ts     |   94.51 |    80.72 |     100 |   94.51 | ...06-607,617,823 
  index.ts         |       0 |        0 |       0 |       0 | 1-21              
  usage.ts         |     100 |      100 |     100 |     100 |                   
 ...ntentGenerator |   91.53 |    71.64 |   93.33 |   91.53 |                   
  ...tGenerator.ts |      90 |    70.96 |   92.85 |      90 | ...80-286,304-305 
  index.ts         |     100 |       80 |     100 |     100 | 50                
 ...ntentGenerator |   93.32 |    80.28 |   90.32 |   93.32 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...tGenerator.ts |    93.3 |    80.28 |   90.32 |    93.3 | ...99,909-910,938 
 ...ntentGenerator |   81.66 |    84.08 |    90.9 |   81.66 |                   
  constants.ts     |     100 |      100 |     100 |     100 |                   
  converter.ts     |   76.88 |    82.25 |    87.5 |   76.88 | ...1589,1610-1616 
  errorHandler.ts  |     100 |      100 |     100 |     100 |                   
  index.ts         |   52.38 |    44.44 |      50 |   52.38 | ...77,81-85,89-93 
  ...tGenerator.ts |    66.4 |    70.58 |   88.88 |    66.4 | ...51-157,168-169 
  pipeline.ts      |   93.67 |     84.9 |     100 |   93.67 | ...80-481,489,554 
  ...ureContext.ts |     100 |      100 |     100 |     100 |                   
  ...ingOptions.ts |       0 |        0 |       0 |       0 | 1                 
  ...CallParser.ts |   90.66 |    88.57 |     100 |   90.66 | ...15-319,349-350 
  ...kingParser.ts |     100 |    96.87 |     100 |     100 | 42                
  types.ts         |       0 |        0 |       0 |       0 | 1                 
 ...rator/provider |   96.69 |    89.17 |   95.45 |   96.69 |                   
  dashscope.ts     |   97.29 |    89.77 |   93.33 |   97.29 | ...81-282,358-359 
  deepseek.ts      |   95.55 |    90.56 |     100 |   95.55 | ...31-132,145-146 
  default.ts       |   94.62 |    86.36 |   85.71 |   94.62 | 86-87,157-159     
  index.ts         |     100 |      100 |     100 |     100 |                   
  minimax.ts       |     100 |      100 |     100 |     100 |                   
  mistral.ts       |   96.07 |    73.33 |     100 |   96.07 | 32-33             
  modelscope.ts    |     100 |      100 |     100 |     100 |                   
  openrouter.ts    |     100 |      100 |     100 |     100 |                   
  types.ts         |       0 |        0 |       0 |       0 |                   
 src/extension     |   60.56 |    79.46 |    78.4 |   60.56 |                   
  ...-converter.ts |   62.35 |    47.82 |      90 |   62.35 | ...90-791,800-832 
  ...ionManager.ts |   47.04 |    82.06 |    65.9 |   47.04 | ...1398,1408-1427 
  ...onSettings.ts |   93.46 |    93.05 |     100 |   93.46 | ...17-221,228-232 
  ...-converter.ts |   54.88 |    94.44 |      60 |   54.88 | ...35-146,158-192 
  github.ts        |   44.94 |    88.52 |      60 |   44.94 | ...53-359,398-451 
  index.ts         |     100 |      100 |     100 |     100 |                   
  marketplace.ts   |   97.29 |    93.75 |     100 |   97.29 | ...64,184-185,274 
  npm.ts           |   48.66 |    76.08 |      75 |   48.66 | ...18-420,427-431 
  override.ts      |   94.11 |    88.88 |     100 |   94.11 | 63-64,81-82       
  settings.ts      |   66.26 |      100 |      50 |   66.26 | 81-108,143-149    
  storage.ts       |     100 |      100 |     100 |     100 |                   
  ...ableSchema.ts |     100 |      100 |     100 |     100 |                   
  variables.ts     |   88.75 |    83.33 |     100 |   88.75 | ...28-231,234-237 
 src/followup      |   46.91 |     92.3 |   71.87 |   46.91 |                   
  followupState.ts |      96 |    89.74 |     100 |      96 | 159-161,218-219   
  index.ts         |     100 |      100 |     100 |     100 |                   
  overlayFs.ts     |   95.06 |       84 |     100 |   95.06 | 78,108,122,133    
  speculation.ts   |   13.22 |      100 |   16.66 |   13.22 | 88-458,518-568    
  ...onToolGate.ts |     100 |    96.29 |     100 |     100 | 93                
  ...nGenerator.ts |    38.4 |    95.12 |   33.33 |    38.4 | ...16-318,353-383 
 src/generated     |       0 |        0 |       0 |       0 |                   
  git-commit.ts    |       0 |        0 |       0 |       0 | 1-10              
 src/goals         |   89.57 |    83.45 |   94.44 |   89.57 |                   
  ...eGoalStore.ts |    85.1 |    95.45 |   84.61 |    85.1 | ...63-166,174-182 
  goalHook.ts      |   97.26 |    91.48 |     100 |   97.26 | 100-105           
  goalJudge.ts     |   84.33 |    74.28 |     100 |   84.33 | ...57-358,366-368 
  index.ts         |     100 |      100 |     100 |     100 |                   
 src/hooks         |   83.48 |    84.87 |   86.83 |   83.48 |                   
  ...okRegistry.ts |   86.48 |    77.08 |     100 |   86.48 | ...41-344,362-369 
  ...bortSignal.ts |     100 |      100 |     100 |     100 |                   
  ...terpolator.ts |   96.66 |    93.33 |     100 |   96.66 | 66-67             
  ...HookRunner.ts |   96.68 |    87.23 |     100 |   96.68 | 110-112,231-233   
  ...Aggregator.ts |    96.4 |    90.78 |     100 |    96.4 | ...91,293-294,367 
  ...entHandler.ts |   94.56 |    83.78 |   93.33 |   94.56 | ...38,795-796,806 
  hookPlanner.ts   |   84.13 |    76.59 |      90 |   84.13 | ...38,144,162-173 
  hookRegistry.ts  |   90.17 |    83.33 |     100 |   90.17 | ...33,352,356,360 
  hookRunner.ts    |   58.56 |    71.26 |   66.66 |   58.56 | ...48-749,758-759 
  hookSystem.ts    |   84.57 |      100 |   65.85 |   84.57 | ...21-622,628-629 
  ...HookRunner.ts |   75.51 |     61.9 |      80 |   75.51 | ...05-406,424-425 
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...HookRunner.ts |   93.63 |    89.47 |      90 |   93.63 | ...45-353,427-428 
  ...SkillHooks.ts |   78.75 |       75 |   66.66 |   78.75 | 62-66,137-152     
  ...oksManager.ts |   96.66 |    91.66 |     100 |   96.66 | ...90,209-210,223 
  ssrfGuard.ts     |   77.22 |    85.36 |     100 |   77.22 | ...57,261-267,273 
  stopHookCap.ts   |     100 |      100 |     100 |     100 |                   
  trustedHooks.ts  |       0 |        0 |       0 |       0 | 1-124             
  types.ts         |   91.18 |    92.04 |   85.71 |   91.18 | ...40-441,501-505 
  urlValidator.ts  |     100 |      100 |     100 |     100 |                   
 src/ide           |   74.28 |    83.39 |   78.33 |   74.28 |                   
  constants.ts     |     100 |      100 |     100 |     100 |                   
  detect-ide.ts    |     100 |      100 |     100 |     100 |                   
  ide-client.ts    |    64.2 |    81.48 |   66.66 |    64.2 | ...9-970,999-1007 
  ide-installer.ts |   89.06 |    79.31 |     100 |   89.06 | ...36,143-147,160 
  ideContext.ts    |     100 |      100 |     100 |     100 |                   
  process-utils.ts |   84.84 |    71.79 |     100 |   84.84 | ...37,151,193-194 
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/lsp           |   41.24 |    52.14 |   51.42 |   41.24 |                   
  ...nfigLoader.ts |   70.27 |    35.89 |   94.73 |   70.27 | ...20-422,426-432 
  ...ionFactory.ts |   42.69 |    79.16 |      50 |   42.69 | ...62-413,419-436 
  ...Normalizer.ts |   23.09 |    13.72 |   30.43 |   23.09 | ...04-905,909-924 
  ...verManager.ts |   25.31 |    62.06 |   41.66 |   25.31 | ...85-704,710-740 
  ...eLspClient.ts |   32.77 |       80 |   17.64 |   32.77 | ...84-288,294-295 
  ...LspService.ts |   48.49 |    67.16 |   65.71 |   48.49 | ...1352,1369-1379 
  constants.ts     |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/mcp           |   78.69 |    75.34 |   75.92 |   78.69 |                   
  constants.ts     |     100 |      100 |     100 |     100 |                   
  ...h-provider.ts |   86.95 |      100 |   33.33 |   86.95 | ...,93,97,101-102 
  ...h-provider.ts |   73.82 |    53.92 |     100 |   73.82 | ...88-895,902-904 
  ...en-storage.ts |   98.62 |    97.72 |     100 |   98.62 | 87-88             
  oauth-utils.ts   |   70.58 |    85.29 |    90.9 |   70.58 | ...70-290,315-344 
  ...n-provider.ts |   89.83 |    95.83 |   45.45 |   89.83 | ...43,147,151-152 
 .../token-storage |   79.52 |    86.66 |   86.36 |   79.52 |                   
  ...en-storage.ts |     100 |      100 |     100 |     100 |                   
  ...en-storage.ts |   82.87 |    82.35 |   92.85 |   82.87 | ...63-173,181-182 
  ...en-storage.ts |     100 |      100 |     100 |     100 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...en-storage.ts |   68.14 |    82.35 |   64.28 |   68.14 | ...81-295,298-314 
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/memory        |   68.13 |    76.27 |   66.66 |   68.13 |                   
  const.ts         |     100 |      100 |     100 |     100 |                   
  dream.ts         |   65.65 |    73.33 |      50 |   65.65 | 50,107-148        
  ...entPlanner.ts |   57.84 |    72.72 |   33.33 |   57.84 | ...35,140-147,152 
  entries.ts       |   63.77 |    79.16 |      50 |   63.77 | ...72-180,183-189 
  extract.ts       |    95.2 |    79.16 |     100 |    95.2 | 81-86,125         
  ...entPlanner.ts |   63.08 |    65.71 |   41.17 |   63.08 | ...17,222-223,332 
  ...ionPlanner.ts |       0 |        0 |       0 |       0 | 1                 
  forget.ts        |    45.8 |    61.53 |   44.44 |    45.8 | ...04,211,214-346 
  indexer.ts       |   83.87 |    45.45 |     100 |   83.87 | ...50,56-57,69-70 
  manager.ts       |   75.31 |    81.04 |    75.6 |   75.31 | ...1278,1291-1293 
  memoryAge.ts     |   90.47 |    77.77 |     100 |   90.47 | 50-51             
  paths.ts         |   55.47 |    89.47 |   85.71 |   55.47 | ...,89-90,106-114 
  prompt.ts        |   93.36 |    71.42 |     100 |   93.36 | ...58,161,228-229 
  recall.ts        |   79.56 |    69.38 |   88.88 |   79.56 | ...40-245,269-280 
  ...ceSelector.ts |   91.86 |    77.27 |     100 |   91.86 | ...07,109-110,118 
  scan.ts          |   87.91 |    68.42 |     100 |   87.91 | ...47-48,58,82-87 
  ...entPlanner.ts |    11.5 |      100 |       0 |    11.5 | ...57-192,210-298 
  status.ts        |   10.52 |      100 |       0 |   10.52 | 41-98             
  store.ts         |   94.44 |    83.33 |     100 |   94.44 | 56-57,92-93       
  types.ts         |     100 |      100 |     100 |     100 |                   
  ...ontextFile.ts |   79.38 |    78.33 |   81.81 |   79.38 | ...58-272,286-291 
 src/mocks         |       0 |        0 |       0 |       0 |                   
  msw.ts           |       0 |        0 |       0 |       0 | 1-9               
 src/models        |   89.31 |    85.55 |    87.5 |   89.31 |                   
  constants.ts     |     100 |      100 |     100 |     100 |                   
  ...tor-config.ts |   90.24 |    91.42 |     100 |   90.24 | 142,148,151-160   
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...nfigErrors.ts |   74.22 |       44 |   84.61 |   74.22 | ...,67-74,106-117 
  ...igResolver.ts |   98.63 |    92.53 |     100 |   98.63 | 161,323,329       
  modelRegistry.ts |     100 |    98.59 |     100 |     100 | 222               
  modelsConfig.ts  |   84.57 |    82.14 |   81.57 |   84.57 | ...1223,1252-1253 
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/output        |     100 |      100 |     100 |     100 |                   
  ...-formatter.ts |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/permissions   |   71.18 |    88.76 |   48.57 |   71.18 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...on-manager.ts |   81.42 |    86.66 |      80 |   81.42 | ...29-830,837-846 
  rule-parser.ts   |   95.99 |    93.22 |     100 |   95.99 | ...-864,1013-1015 
  ...-semantics.ts |   58.28 |    85.27 |    30.2 |   58.28 | ...1604-1614,1643 
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/prompts       |   83.63 |      100 |    87.5 |   83.63 |                   
  mcp-prompts.ts   |   18.18 |      100 |       0 |   18.18 | 11-19             
  ...t-registry.ts |     100 |      100 |     100 |     100 |                   
 src/qwen          |   83.87 |    77.46 |   95.83 |   83.87 |                   
  ...tGenerator.ts |   98.64 |    98.18 |     100 |   98.64 | 105-106           
  qwenOAuth2.ts    |   80.85 |    70.74 |   90.32 |   80.85 | ...1169-1185,1215 
  ...kenManager.ts |   83.76 |    76.22 |     100 |   83.76 | ...62-767,788-793 
 src/services      |   85.34 |    83.53 |   90.93 |   85.34 |                   
  ...ionTrailer.ts |     100 |      100 |     100 |     100 |                   
  ...llRegistry.ts |   98.44 |    91.83 |     100 |   98.44 | 268-269           
  ...ionService.ts |    95.6 |    96.36 |     100 |    95.6 | ...32,400,402-406 
  ...ingService.ts |   83.91 |       83 |   83.33 |   83.91 | ...1267,1284-1285 
  ...ttribution.ts |   91.73 |    87.71 |      90 |   91.73 | ...80-685,826-827 
  ...utSlimming.ts |     100 |    96.77 |     100 |     100 | 133,182           
  cronScheduler.ts |   97.56 |    92.98 |     100 |   97.56 | 62-63,77,155      
  ...eryService.ts |   80.43 |    95.45 |      75 |   80.43 | ...19-134,140-141 
  ...oryService.ts |   86.25 |    74.35 |    92.3 |   86.25 | ...46-655,696-699 
  fileReadCache.ts |     100 |      100 |     100 |     100 |                   
  ...temService.ts |   91.27 |    82.69 |    90.9 |   91.27 | ...94,196,294-301 
  ...ratedFiles.ts |      96 |    88.23 |     100 |      96 | 119-120,146-147   
  gitInit.ts       |     100 |      100 |     100 |     100 |                   
  gitService.ts    |   68.75 |     92.3 |   55.55 |   68.75 | ...12-122,125-129 
  ...reeService.ts |   73.79 |       70 |   94.87 |   73.79 | ...1365,1393-1394 
  ...ionService.ts |   98.13 |     97.8 |   95.45 |   98.13 | ...32-333,380-381 
  ...orRegistry.ts |   96.54 |    91.73 |     100 |   96.54 | ...70-471,622-623 
  sessionRecap.ts  |   12.04 |      100 |       0 |   12.04 | 49-160            
  ...ionService.ts |   90.19 |     78.7 |   96.66 |   90.19 | ...1285,1289-1290 
  sessionTitle.ts  |   93.87 |    69.81 |     100 |   93.87 | ...33-236,267-268 
  ...ionService.ts |   81.07 |    77.92 |   89.28 |   81.07 | ...1923,1929-1934 
  ...UseSummary.ts |   94.73 |    87.71 |     100 |   94.73 | ...73-175,225-226 
  ...reeCleanup.ts |   14.56 |      100 |   33.33 |   14.56 | 58-185            
 ...icrocompaction |   98.05 |     91.8 |     100 |   98.05 |                   
  microcompact.ts  |   98.05 |     91.8 |     100 |   98.05 | ...19,289,293,391 
 src/skills        |    87.5 |    83.86 |   94.23 |    87.5 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...activation.ts |     100 |     93.1 |     100 |     100 | 93,112            
  skill-load.ts    |   92.94 |    81.63 |     100 |   92.94 | ...06,226,238-240 
  skill-manager.ts |   83.31 |    79.66 |   90.32 |   83.31 | ...1120,1127-1131 
  skill-paths.ts   |   86.74 |    77.77 |     100 |   86.74 | ...00-101,106-107 
  symlinkScope.ts  |     100 |      100 |     100 |     100 |                   
  types.ts         |     100 |      100 |     100 |     100 |                   
 src/subagents     |   83.13 |    80.24 |   95.23 |   83.13 |                   
  ...tin-agents.ts |     100 |      100 |     100 |     100 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...-selection.ts |     100 |      100 |     100 |     100 |                   
  ...nt-manager.ts |   77.21 |    72.09 |   92.85 |   77.21 | ...1180,1202-1203 
  types.ts         |     100 |      100 |     100 |     100 |                   
  validation.ts    |   92.46 |    95.18 |     100 |   92.46 | 51-56,69-74,78-83 
 src/telemetry     |   74.72 |    86.01 |   78.85 |   74.72 |                   
  config.ts        |     100 |      100 |     100 |     100 |                   
  constants.ts     |     100 |      100 |     100 |     100 |                   
  ...attributes.ts |   98.13 |       88 |     100 |   98.13 | 185-187           
  ...-exporters.ts |   46.37 |      100 |   44.44 |   46.37 | ...85,88-89,92-93 
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...t.circular.ts |       0 |        0 |       0 |       0 | 1-111             
  ...-processor.ts |   93.93 |    90.21 |   94.11 |   93.93 | ...75-280,299-300 
  ...t.circular.ts |       0 |        0 |       0 |       0 | 1-128             
  loggers.ts       |    51.9 |       64 |   57.77 |    51.9 | ...1214,1231-1251 
  metrics.ts       |    74.9 |    82.95 |   74.54 |    74.9 | ...58-978,981-992 
  sanitize.ts      |      80 |    83.33 |     100 |      80 | 35-36,41-42       
  sdk.ts           |   90.45 |    83.56 |   76.92 |   90.45 | ...17-318,338-342 
  ...on-context.ts |     100 |      100 |     100 |     100 |                   
  ...on-tracing.ts |   92.24 |    88.77 |     100 |   92.24 | ...21-424,522-525 
  ...etry-utils.ts |     100 |      100 |     100 |     100 |                   
  ...l-decision.ts |     100 |      100 |     100 |     100 |                   
  ...e-id-utils.ts |     100 |      100 |     100 |     100 |                   
  tracer.ts        |   98.61 |    89.36 |     100 |   98.61 | 53,108            
  types.ts         |   79.17 |    85.83 |   83.33 |   79.17 | ...1149,1152-1181 
  uiTelemetry.ts   |   92.97 |    96.96 |   81.25 |   92.97 | ...93-194,200-207 
 ...ry/qwen-logger |   68.24 |    79.56 |   64.91 |   68.24 |                   
  event-types.ts   |       0 |        0 |       0 |       0 |                   
  qwen-logger.ts   |   68.24 |    79.34 |   64.28 |   68.24 | ...1055,1093-1094 
 src/test-utils    |   93.16 |    95.91 |   76.47 |   93.16 |                   
  config.ts        |     100 |      100 |     100 |     100 |                   
  ...st-helpers.ts |   94.11 |       90 |     100 |   94.11 | 69-70             
  index.ts         |     100 |      100 |     100 |     100 |                   
  mock-tool.ts     |   91.19 |    97.14 |   72.41 |   91.19 | ...38,202-203,216 
  ...aceContext.ts |     100 |      100 |     100 |     100 |                   
 src/tools         |   78.56 |    81.68 |   86.78 |   78.56 |                   
  ...erQuestion.ts |   88.93 |    76.74 |    90.9 |   88.93 | ...39-340,347-348 
  cron-create.ts   |   97.75 |    88.88 |   83.33 |   97.75 | 30-31             
  cron-delete.ts   |   96.82 |      100 |   83.33 |   96.82 | 26-27             
  cron-list.ts     |   96.66 |      100 |   83.33 |   96.66 | 25-26             
  diffOptions.ts   |     100 |      100 |     100 |     100 |                   
  edit.ts          |   80.52 |    85.98 |   73.33 |   80.52 | ...15-716,803-853 
  ...r-worktree.ts |   82.43 |    68.75 |    87.5 |   82.43 | ...67-170,236-237 
  exit-worktree.ts |   83.47 |       84 |    90.9 |   83.47 | ...80-281,286-299 
  exitPlanMode.ts  |   85.09 |    85.71 |     100 |   85.09 | ...60-163,177-189 
  glob.ts          |   90.63 |    88.33 |   84.61 |   90.63 | ...28,171,302,305 
  grep.ts          |   79.19 |    85.71 |   78.94 |   79.19 | ...20,560,569-576 
  ls.ts            |   96.74 |    90.27 |     100 |   96.74 | 176-181,212,216   
  lsp.ts           |   72.77 |    60.09 |   90.32 |   72.77 | ...1211,1213-1214 
  ...nt-manager.ts |   84.36 |    82.74 |   84.21 |   84.36 | ...2099-2103,2142 
  mcp-client.ts    |   33.18 |    77.65 |   66.66 |   33.18 | ...1490,1494-1497 
  mcp-tool.ts      |   90.98 |    88.88 |   96.42 |   90.98 | ...95-596,646-647 
  memory-config.ts |       0 |        0 |       0 |       0 | 1-47              
  ...iable-tool.ts |     100 |    84.61 |     100 |     100 | 102,109           
  monitor.ts       |   92.36 |    83.94 |      92 |   92.36 | ...29,558-561,574 
  ...nforcement.ts |   82.44 |       90 |     100 |   82.44 | 174-185,234-247   
  read-file.ts     |   95.09 |    88.75 |      90 |   95.09 | ...99,293-296,299 
  ripGrep.ts       |   94.59 |    85.71 |   93.33 |   94.59 | ...60,463,541-542 
  ...-transport.ts |    6.34 |      100 |       0 |    6.34 | 47-145            
  send-message.ts  |   89.32 |    91.66 |   83.33 |   89.32 | 44-45,68-76       
  shell.ts         |   72.96 |     79.6 |    91.3 |   72.96 | ...4216,4265-4271 
  skill-utils.ts   |     100 |      100 |     100 |     100 |                   
  skill.ts         |   88.11 |    91.17 |   84.61 |   88.11 | ...95,399,422-444 
  ...eticOutput.ts |   95.12 |      100 |      80 |   95.12 | 87-88             
  task-stop.ts     |   93.14 |    96.15 |   85.71 |   93.14 | 39-40,54-64       
  todoWrite.ts     |   89.17 |    82.05 |   92.85 |   89.17 | ...41-546,568-569 
  tool-error.ts    |     100 |      100 |     100 |     100 |                   
  tool-names.ts    |     100 |      100 |     100 |     100 |                   
  tool-registry.ts |   74.85 |    76.85 |   80.95 |   74.85 | ...30-831,839-840 
  tool-search.ts   |   95.19 |    86.48 |    92.3 |   95.19 | ...47-153,208-213 
  tools.ts         |   91.98 |    90.19 |   88.88 |   91.98 | ...50-451,467-473 
  web-fetch.ts     |   88.59 |    79.48 |    92.3 |   88.59 | ...12-313,315-316 
  write-file.ts    |   82.23 |    81.17 |   83.33 |   82.23 | ...65-668,680-715 
 src/tools/agent   |   75.01 |    82.55 |   74.62 |   75.01 |                   
  agent.ts         |   75.29 |    82.86 |    75.4 |   75.29 | ...2203,2265-2272 
  fork-subagent.ts |   69.62 |    71.42 |   66.66 |   69.62 | ...04-105,140-151 
 src/utils         |   88.98 |    87.56 |   93.69 |   88.98 |                   
  LruCache.ts      |       0 |        0 |       0 |       0 | 1-41              
  ...ssageQueue.ts |     100 |      100 |     100 |     100 |                   
  ...cFileWrite.ts |   77.96 |    80.48 |     100 |   77.96 | ...35,156,173-176 
  bareMode.ts      |   27.27 |      100 |       0 |   27.27 | 9-15,18-19        
  browser.ts       |    7.69 |      100 |       0 |    7.69 | 17-56             
  bundlePaths.ts   |     100 |      100 |     100 |     100 |                   
  ...igResolver.ts |     100 |      100 |     100 |     100 |                   
  ...engthError.ts |   89.11 |    86.66 |     100 |   89.11 | ...28-129,132-133 
  cronDisplay.ts   |   42.85 |    23.07 |     100 |   42.85 | 26-31,33-45,47-54 
  cronParser.ts    |   89.74 |    85.71 |     100 |   89.74 | ...,63-64,183-186 
  debugLogger.ts   |    95.9 |    93.84 |   94.73 |    95.9 | 106-107,214-218   
  editHelper.ts    |   93.63 |    83.52 |     100 |   93.63 | ...28-429,463-464 
  editor.ts        |   97.61 |    95.71 |     100 |   97.61 | ...70-271,273-274 
  ...arResolver.ts |   94.28 |    88.88 |     100 |   94.28 | 28-29,125-126     
  ...entContext.ts |     100 |    95.45 |     100 |     100 | 83                
  errorParsing.ts  |    97.7 |    97.05 |     100 |    97.7 | 72-73             
  ...rReporting.ts |   88.46 |       90 |     100 |   88.46 | 69-74             
  errors.ts        |   70.92 |       80 |   53.33 |   70.92 | ...03-219,223-229 
  fetch.ts         |   70.18 |    71.42 |   71.42 |   70.18 | ...42,148,161,186 
  fileUtils.ts     |   91.46 |    86.19 |   95.23 |   91.46 | ...1188,1192-1198 
  forkedAgent.ts   |    78.5 |    70.73 |   85.71 |    78.5 | ...30-436,441-447 
  formatters.ts    |   81.81 |       75 |     100 |   81.81 | 15-16             
  ...eUtilities.ts |   89.21 |    86.66 |     100 |   89.21 | 16-17,49-55,65-66 
  ...rStructure.ts |   94.36 |    94.28 |     100 |   94.36 | ...17-120,330-335 
  getPty.ts        |    12.5 |      100 |       0 |    12.5 | 21-34             
  gitDiff.ts       |   92.36 |    79.53 |     100 |   92.36 | ...55-856,928-929 
  ...noreParser.ts |    92.3 |    89.36 |     100 |    92.3 | ...15-116,186-187 
  gitUtils.ts      |   56.66 |    85.71 |      75 |   56.66 | ...2,72-73,97-148 
  iconvHelper.ts   |     100 |      100 |     100 |     100 |                   
  ...rePatterns.ts |     100 |      100 |     100 |     100 |                   
  ...ionManager.ts |     100 |     90.9 |     100 |     100 | 26                
  ...lPromptIds.ts |     100 |      100 |     100 |     100 |                   
  jsonl-utils.ts   |    74.1 |    90.76 |   58.33 |    74.1 | ...23-326,336-342 
  ...-detection.ts |     100 |      100 |     100 |     100 |                   
  ...iagnostics.ts |   96.87 |    91.83 |     100 |   96.87 | 214-219,272       
  ...yDiscovery.ts |    83.9 |    79.36 |     100 |    83.9 | ...16,319,411-414 
  ...tProcessor.ts |   93.63 |       90 |     100 |   93.63 | ...96-302,384-385 
  ...Inspectors.ts |   61.53 |      100 |      50 |   61.53 | 18-23             
  modelId.ts       |   98.55 |    96.87 |     100 |   98.55 | 103               
  ...kerChecker.ts |   88.75 |    85.71 |     100 |   88.75 | 69-70,87-93       
  notebook.ts      |   94.35 |    84.78 |     100 |   94.35 | ...10,122,174-176 
  openaiLogger.ts  |   88.05 |    84.09 |     100 |   88.05 | ...44-146,169-174 
  partUtils.ts     |     100 |    98.61 |     100 |     100 | 206               
  pathReader.ts    |     100 |      100 |     100 |     100 |                   
  paths.ts         |   93.21 |    91.86 |     100 |   93.21 | ...89-390,392-394 
  pdf.ts           |   93.68 |    87.05 |     100 |   93.68 | ...96-297,321-325 
  projectPath.ts   |     100 |      100 |     100 |     100 |                   
  ...ectSummary.ts |   89.39 |    72.41 |     100 |   89.39 | ...37-142,193-196 
  ...tIdContext.ts |     100 |      100 |     100 |     100 |                   
  proxyUtils.ts    |     100 |      100 |     100 |     100 |                   
  ...rDetection.ts |   58.57 |       76 |     100 |   58.57 | ...4,88-89,95-100 
  ...noreParser.ts |   85.45 |    85.18 |     100 |   85.45 | ...59,65-66,72-73 
  rateLimit.ts     |   92.55 |    85.92 |     100 |   92.55 | ...70-272,309-310 
  readManyFiles.ts |   87.96 |    86.95 |     100 |   87.96 | ...05-207,223-234 
  retry.ts         |   89.81 |    88.05 |     100 |   89.81 | ...29,350,357-358 
  ripgrepUtils.ts  |   46.79 |    84.37 |   66.66 |   46.79 | ...45-246,258-335 
  ...sDiscovery.ts |   97.42 |    92.85 |     100 |   97.42 | ...04,182-183,202 
  ...tchOptions.ts |   81.72 |    85.04 |   95.23 |   81.72 | ...11,536,565-574 
  runtimeStatus.ts |    97.5 |    88.57 |     100 |    97.5 | 167-168           
  safeJsonParse.ts |   74.07 |    83.33 |     100 |   74.07 | 40-46             
  ...nStringify.ts |     100 |      100 |     100 |     100 |                   
  ...aConverter.ts |   90.78 |    88.23 |     100 |   90.78 | ...41-42,93,95-96 
  ...aValidator.ts |   94.57 |    80.26 |     100 |   94.57 | ...04,213-216,270 
  ...r-launcher.ts |   76.92 |     91.3 |   66.66 |   76.92 | ...34,136,157-195 
  ...orageUtils.ts |   96.89 |    85.84 |     100 |   96.89 | ...51,367,447,466 
  shell-utils.ts   |   82.93 |    89.89 |     100 |   82.93 | ...1522,1529-1533 
  ...lAstParser.ts |   95.58 |    85.79 |     100 |   95.58 | ...1059-1061,1071 
  ...nlyChecker.ts |   95.75 |    92.39 |     100 |   95.75 | ...00-301,313-314 
  sideQuery.ts     |   98.73 |    94.59 |     100 |   98.73 | 111               
  ...pEventSink.ts |     100 |       80 |     100 |     100 | 61                
  ...tGenerator.ts |     100 |      100 |     100 |     100 |                   
  ...ameContext.ts |     100 |      100 |     100 |     100 |                   
  symlink.ts       |   77.77 |       50 |     100 |   77.77 | 44,54-59          
  ...emEncoding.ts |   96.36 |    91.17 |     100 |   96.36 | 59-60,124-125     
  terminalSafe.ts  |     100 |      100 |     100 |     100 |                   
  ...Serializer.ts |   98.72 |       90 |     100 |   98.72 | 42-43,134,201-203 
  testUtils.ts     |   53.33 |      100 |   33.33 |   53.33 | ...53,59-64,70-72 
  textUtils.ts     |      60 |      100 |   66.66 |      60 | 36-55             
  thoughtUtils.ts  |     100 |    92.85 |     100 |     100 | 71                
  ...-converter.ts |   94.59 |    85.71 |     100 |   94.59 | 35-36             
  tool-utils.ts    |    93.6 |     91.3 |     100 |    93.6 | ...58-159,162-163 
  truncation.ts    |     100 |       92 |     100 |     100 | 52,71             
  windowsPath.ts   |   89.47 |    79.31 |     100 |   89.47 | ...57-58,62,90-91 
  ...aceContext.ts |   93.71 |    89.28 |   93.33 |   93.71 | ...24-225,249-251 
  xml.ts           |     100 |      100 |     100 |     100 |                   
  yaml-parser.ts   |      92 |    84.61 |     100 |      92 | 49-53,65-69       
 ...ils/filesearch |   86.21 |    81.61 |   96.42 |   86.21 |                   
  crawlCache.ts    |     100 |      100 |     100 |     100 |                   
  crawler.ts       |   82.84 |    77.49 |   94.82 |   82.84 | ...1451,1485-1486 
  fileSearch.ts    |   93.58 |    87.32 |     100 |   93.58 | ...46-247,249-250 
  ignore.ts        |     100 |      100 |     100 |     100 |                   
  result-cache.ts  |     100 |     92.3 |     100 |     100 | 46                
 ...uest-tokenizer |   56.63 |    74.52 |   74.19 |   56.63 |                   
  ...eTokenizer.ts |   41.86 |    76.47 |   69.23 |   41.86 | ...70-443,453-507 
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...tTokenizer.ts |   68.39 |    69.49 |    90.9 |   68.39 | ...24-325,327-328 
  ...ageFormats.ts |      76 |      100 |   33.33 |      76 | 45-48,55-56       
  textTokenizer.ts |     100 |      100 |     100 |     100 |                   
  types.ts         |       0 |        0 |       0 |       0 | 1                 
-------------------|---------|----------|---------|---------|-------------------

For detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run.

doudouOUC added a commit that referenced this pull request May 18, 2026
Follow-up addressing the 8 unresolved review threads opened on PR
#4282 after its squash-merge to main. Stacked on the P2 fixes
shipping in this same #4297; addresses correctness gaps + missing
test coverage that would otherwise let regressions ride into main.

Behavior fix:
- broadcastWorkspaceEvent gains a `skipSessionId` parameter; when
  `setSessionApprovalMode` runs with `persist:true`, the broadcast
  skips the requesting session so it doesn't receive the same
  `approval_mode_changed` event twice (once via session-scoped
  publish + once via broadcast). The SDK reducer's
  `approvalModeChangedCount` now increments by 1, not 2, on the
  requesting client (peers still see 1 via the broadcast).
  Addresses #3260501134.

Observability + posture:
- broadcastWorkspaceEvent now mirrors PR 16's publishWorkspaceEvent
  member: per-entry success/failure accounting + an "ALL buses
  dropped" stderr elevation. The previous local helper silently
  swallowed every publish failure. Addresses #3260501126.
- WorkspaceInitPathEscapeError + WorkspaceInitSymlinkError typed
  classes for the two boundary guards in initWorkspace, mapped to
  HTTP 400 by sendBridgeError. Previous generic `Error` fell
  through to the 500 handler, telling operators "daemon broken"
  when the actual fix was workspace-config correction. Addresses
  #3260501161.

Public surface symmetry:
- Re-export McpServerNotFoundError, McpServerRestartFailedError,
  WorkspaceInitPathEscapeError, WorkspaceInitSymlinkError from the
  serve barrel. External embeds matching these via `instanceof`
  no longer need deep imports. Addresses #3260501163.

Test coverage:
- restartMcpServer bridge tests (5): success + event broadcast,
  soft-skip + refused event, McpServerNotFoundError translation,
  McpServerRestartFailedError translation, originator clientId
  stamping. Addresses #3260501141.
- sendBridgeError mapping tests (4): McpServerNotFoundError → 404,
  McpServerRestartFailedError → 502, WorkspaceInitPathEscapeError
  → 400, WorkspaceInitSymlinkError → 400. Addresses #3260501148.
- initWorkspace boundary guard tests (2 added): symlink-at-target
  rejected, contextFilename '../outside.md' rejected. Addresses
  #3260501157.
- TrustGateError tests assert the typed class via `.toThrow(TrustGateError)`,
  not just message text. Addresses #3260501165.

Also updates the existing fold-in 4 S2 broadcast test to reflect
the new no-duplicate semantics on the requesting session.

Typecheck clean across cli / sdk-typescript / core.
1615/1615 unit tests pass.
Comment thread packages/sdk-typescript/src/daemon/DaemonClient.ts
Comment thread packages/sdk-typescript/test/unit/DaemonClient.test.ts Outdated
Comment thread packages/cli/src/acp-integration/acpAgent.ts Outdated
Comment thread packages/cli/src/serve/httpAcpBridge.ts Outdated
doudouOUC added a commit that referenced this pull request May 18, 2026
Round-2 reviewer adoption on the same PR:

Critical fixes:
- `restartMcpServer` JSDoc documents `timeoutMs: 0` as "disable the
  timeout entirely", but the `> 0` guard in `fetchWithTimeout`
  rejected `0` and silently fell back to the 30s client default.
  Loosened the guard to `>= 0` so `0` flows through to the
  no-timeout branch via the existing truthiness check; NaN /
  negative inputs still coerce to the client default. Addresses
  duplicate reports from copilot (#3260577538) and wenshao
  (#3260661833).
- TS2322 in the slow-fetch test stub: `resolveResponse` was typed
  against `import('undici-types').Response` but assigned a
  `(v: Response) => void`. Re-typed against the global `Response`
  throughout. Caught only by tsc runs that include the test
  files. Addresses #3260663072.

Test fidelity:
- Slow-fetch stub now observes `init.signal` and rejects on abort,
  so a regression that drops the per-call `timeoutMs` override
  will reliably fail the test instead of resolving after the
  timer fired (false-negative coverage). Addresses #3260577600.
- New test pinning the `timeoutMs: 0` semantics: 1ms client
  default + a stub that resolves after 50ms. Without the `>= 0`
  fix, the call would abort at 1ms; with it, the explicit
  `0` disables the timer and the call completes.

Bug fixes:
- `runQwenServe.contextFilenameForInit` previously called
  `String(arr[0])` on the array branch, producing a literal
  `"[object Object]"` filename for hand-edited bad data. Now
  validates each element with `typeof === 'string'` and falls
  back to `undefined` (so the bridge uses its
  `getCurrentGeminiMdFilename()` default) when no string is
  found. Addresses #3260577641.

Documentation drift:
- `Config.getDisabledTools()` JSDoc rewritten to describe the
  mutable-via-`setDisabledTools()` semantics introduced by P2-2,
  and the "registration-time only / no retroactive unregister"
  contract that pairs with it. Old comment claimed the set was
  frozen at construction. Addresses #3260577677.

Observability:
- `acpAgent` MCP-restart `loadSettings` failure now surfaces a
  stderr line naming the server + the underlying error, instead
  of silently swallowing it. The documented "toggle + restart"
  workflow used to break with zero diagnostic when settings.json
  was corrupted or unreadable. Addresses #3260663303.

Code organization:
- Moved `canonicalizeExistingAncestor` after `describeStatKind` so
  the latter's JSDoc is no longer orphaned (TypeScript only
  associates the last `/** ... */` block before a declaration).
  Addresses #3260668618.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.
Comment thread packages/cli/src/acp-integration/acpAgent.ts Outdated
doudouOUC added a commit that referenced this pull request May 18, 2026
Critical bug from wenshao review (#3260725526) on PR #4297:
the P2-2 acpAgent re-read narrowed `Config.disabledTools` to
`SettingScope.Workspace` alone, dropping User / System scope
entries. The bootstrap Config received `merged.tools?.disabled`
(union of all scopes), so user-level / system-level disables
worked at boot — but the first `mcp restart` would replace the
in-memory set with the workspace scope alone, silently re-enabling
any tool that was disabled at a higher scope but absent from the
workspace file.

The asymmetry vs. the persist-write path is deliberate and
documented:
- Reads (here): merged — match the bootstrap Config snapshot,
  preserve user/system policy.
- Writes (`runQwenServe.persistDisabledTools`): workspace scope —
  don't bake higher-scope entries into the workspace file
  (per-#4282 fold-in 1 H2 fix).

Two paths look alike but answer different questions.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.
@doudouOUC doudouOUC requested a review from wenshao May 18, 2026 17:28
Comment thread packages/sdk-typescript/test/unit/DaemonClient.test.ts
doudouOUC added a commit that referenced this pull request May 18, 2026
Critical follow-up from wenshao (#3260810242) on PR #4297:
the new `timeoutMs: 0` regression test (added in fold-in 2)
inherited the same flaw it was meant to prevent — the slow-fetch
stub didn't observe `init.signal`, so a regression that ignored
the `0` override would fire the AbortController at the 1ms client
default but the stub would keep the promise pending. The 50ms
`resolveResponse` would win, the test would still pass, and the
documented "0 disables timeout" contract would be unprotected.

Mirrored the listener pattern already used by the two sibling
tests in fold-in 2 — `init.signal.addEventListener('abort', () =>
reject(...))`. Now a regression that re-rejects `0` triggers the
abort, the stub rejects, the test fails.

8/8 restartMcpServer SDK tests pass; SDK typecheck clean.

@wenshao wenshao left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] toDeviceFlowStateBody (server.ts:1996) unconditionally exposes initiatorClientId to any bearer-token holder via GET /workspace/auth/device-flow/:id, while the sibling toDeviceFlowStartResponseBody (line 1968-1972) gates it behind a callerClientId === view.initiatorClientId check. Thread callerClientId into toDeviceFlowStateBody and apply the same matching logic. (Not in this PR's diff, but noticed during review.)

Comment thread packages/cli/src/acp-integration/acpAgent.ts
Comment thread packages/cli/src/serve/httpAcpBridge.ts
doudouOUC added a commit that referenced this pull request May 18, 2026
Two new critical reviews from wenshao on PR #4297:

C1 — TOCTOU between lstat and writeFile (#3260836305):
The `lstat(target)` symlink check and the subsequent `writeFile`
were two separate syscalls, leaving a race window where a local
attacker with workspace write access could substitute a symlink
between them. With `force: true`, `writeFile` would follow the
link and truncate an external target.

The `action === 'created'` path now uses `fs.open(target, 'wx')`
(O_WRONLY|O_CREAT|O_EXCL), which atomically refuses any
pre-existing inode (regular file, dir, OR symlink) at the target
path. EEXIST after the absence check most plausibly means a
race-created symlink, so we throw `WorkspaceInitSymlinkError(kind:
'target')` — same typed class the route maps to 400.

The `force: true` overwrite path retains the existing TOCTOU as a
documented limitation; closing it requires `O_NOFOLLOW`-aware open
which the post-PR18 `WorkspaceFileSystem` migration will provide.

C2 — P2-2 zero test coverage (#3260836302):
The `setDisabledTools` runtime sync was the only Wave-4 P2 fix
without a dedicated test. Added 5 Config-level tests:
- Initializes from `disabledTools` ConfigParameters
- Defaults to empty set when omitted
- `setDisabledTools` replaces the live snapshot
- Defensive copy: caller-set mutations don't leak into the live snapshot
- Accepts an empty set (clears live snapshot)

Plus a TOCTOU regression test in httpAcpBridge.test.ts that
spies fs.lstat / fs.readFile to simulate the race window:
pre-creates a symlink, makes lstat lie about it, asserts the
'wx' open catches the racing inode and throws the typed
`WorkspaceInitSymlinkError(kind: 'target')`.

1622/1622 unit tests pass; typecheck clean across cli /
sdk-typescript / core.
@doudouOUC doudouOUC self-assigned this May 18, 2026
@doudouOUC doudouOUC requested a review from wenshao May 18, 2026 17:44

@wenshao wenshao left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test

Comment thread packages/cli/src/serve/httpAcpBridge.ts Outdated

@wenshao wenshao left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ CI currently failing on windows-latest and macos-latest. Review based on static code analysis of the 11-file diff.

Critical

1. restartMcpServer throws misleading SessionNotFoundError when no ACP child process is running. packages/cli/src/serve/httpAcpBridge.ts (restartMcpServer method): When liveChannelInfo() returns undefined, the code throws new SessionNotFoundError('mcp:' + serverName) which maps to HTTP 404 with "No session with id \"mcp:docs\"". The real problem is "no ACP child process available", not "session not found." An oncall engineer would waste time investigating the wrong thing. Consider introducing a dedicated error type that maps to HTTP 503.

Suggestions

2. No stderr logging on bridge restartMcpServer failure. The catch block in the bridge's restartMcpServer method has zero writeStderrLine calls. Structured ACP errors are re-thrown; unstructured errors fall through with throw err. No diagnostic reaches stderr. The ACP-side handler in acpAgent.ts already logs disabledTools sync failures — the bridge should match this pattern.

3. setSessionApprovalMode persist failure indistinguishable from non-persist. When persist: true but persistApprovalMode throws, the route returns 200 OK with {persisted: false}. The caller cannot tell a disk write failure from "no callback wired." After daemon restart the old approval mode is restored — silent data loss.

4. canonicalizeExistingAncestor duplicates ancestor-walking logic from packages/cli/src/serve/fs/paths.ts (resolveWithinWorkspace, ~L376). The existing implementation has MAX_ANCESTOR_HOPS, inode loop detection, and full symlink chain resolution. This PR's simpler while(true) loop handles only ENOENT/ENOTDIR. Code acknowledges this is intentional (waiting for PR 18), but two parallel implementations risk divergence. Consider at minimum adding a hop limit.

— DeepSeek/deepseek-v4-pro via Qwen Code /review

Comment thread packages/cli/src/serve/httpAcpBridge.ts Outdated
doudouOUC added a commit that referenced this pull request May 18, 2026
DeepSeek review on #4297 (#3261079572):
`broadcastWorkspaceEvent` unconditionally subtracted 1 from the
`eligible` recipient count whenever `skipSessionId` was set, even
when the id matched zero live sessions (caller mistake, stale id,
or the matching session was just torn down between resolution and
broadcast). In a single-session workspace that's the difference
between `eligible = 0` (alarm suppressed) and `eligible = 1`
(alarm fires when the publish failed) — silently losing the
all-dropped breadcrumb the telemetry was meant to surface.

Today's call sites pass real session ids so the bug doesn't
manifest in practice, but the defensive shape is small: track
`skippedCount` inside the loop and subtract that, so the alarm
condition is self-consistent regardless of how the caller mis-uses
the param.

162/162 bridge tests pass; CLI typecheck clean.
@doudouOUC doudouOUC requested a review from wenshao May 18, 2026 18:21
Comment thread packages/cli/src/serve/httpAcpBridge.ts Outdated
Comment thread packages/cli/src/serve/runQwenServe.ts Outdated
Comment thread packages/cli/src/acp-integration/acpAgent.ts
Comment thread packages/cli/src/serve/runQwenServe.ts
Comment thread packages/cli/src/acp-integration/acpAgent.ts
doudouOUC added a commit that referenced this pull request May 18, 2026
Follow-up addressing the 8 unresolved review threads opened on PR
shipping in this same #4297; addresses correctness gaps + missing
test coverage that would otherwise let regressions ride into main.

Behavior fix:
- broadcastWorkspaceEvent gains a `skipSessionId` parameter; when
  `setSessionApprovalMode` runs with `persist:true`, the broadcast
  skips the requesting session so it doesn't receive the same
  `approval_mode_changed` event twice (once via session-scoped
  publish + once via broadcast). The SDK reducer's
  `approvalModeChangedCount` now increments by 1, not 2, on the
  requesting client (peers still see 1 via the broadcast).
  Addresses #3260501134.

Observability + posture:
- broadcastWorkspaceEvent now mirrors PR 16's publishWorkspaceEvent
  member: per-entry success/failure accounting + an "ALL buses
  dropped" stderr elevation. The previous local helper silently
  swallowed every publish failure. Addresses #3260501126.
- WorkspaceInitPathEscapeError + WorkspaceInitSymlinkError typed
  classes for the two boundary guards in initWorkspace, mapped to
  HTTP 400 by sendBridgeError. Previous generic `Error` fell
  through to the 500 handler, telling operators "daemon broken"
  when the actual fix was workspace-config correction. Addresses
  #3260501161.

Public surface symmetry:
- Re-export McpServerNotFoundError, McpServerRestartFailedError,
  WorkspaceInitPathEscapeError, WorkspaceInitSymlinkError from the
  serve barrel. External embeds matching these via `instanceof`
  no longer need deep imports. Addresses #3260501163.

Test coverage:
- restartMcpServer bridge tests (5): success + event broadcast,
  soft-skip + refused event, McpServerNotFoundError translation,
  McpServerRestartFailedError translation, originator clientId
  stamping. Addresses #3260501141.
- sendBridgeError mapping tests (4): McpServerNotFoundError → 404,
  McpServerRestartFailedError → 502, WorkspaceInitPathEscapeError
  → 400, WorkspaceInitSymlinkError → 400. Addresses #3260501148.
- initWorkspace boundary guard tests (2 added): symlink-at-target
  rejected, contextFilename '../outside.md' rejected. Addresses
  #3260501157.
- TrustGateError tests assert the typed class via `.toThrow(TrustGateError)`,
  not just message text. Addresses #3260501165.

Also updates the existing fold-in 4 S2 broadcast test to reflect
the new no-duplicate semantics on the requesting session.

Typecheck clean across cli / sdk-typescript / core.
1615/1615 unit tests pass.
doudouOUC added a commit that referenced this pull request May 18, 2026
Round-2 reviewer adoption on the same PR:

Critical fixes:
- `restartMcpServer` JSDoc documents `timeoutMs: 0` as "disable the
  timeout entirely", but the `> 0` guard in `fetchWithTimeout`
  rejected `0` and silently fell back to the 30s client default.
  Loosened the guard to `>= 0` so `0` flows through to the
  no-timeout branch via the existing truthiness check; NaN /
  negative inputs still coerce to the client default. Addresses
  duplicate reports from copilot (#3260577538) and wenshao
  (#3260661833).
- TS2322 in the slow-fetch test stub: `resolveResponse` was typed
  against `import('undici-types').Response` but assigned a
  `(v: Response) => void`. Re-typed against the global `Response`
  throughout. Caught only by tsc runs that include the test
  files. Addresses #3260663072.

Test fidelity:
- Slow-fetch stub now observes `init.signal` and rejects on abort,
  so a regression that drops the per-call `timeoutMs` override
  will reliably fail the test instead of resolving after the
  timer fired (false-negative coverage). Addresses #3260577600.
- New test pinning the `timeoutMs: 0` semantics: 1ms client
  default + a stub that resolves after 50ms. Without the `>= 0`
  fix, the call would abort at 1ms; with it, the explicit
  `0` disables the timer and the call completes.

Bug fixes:
- `runQwenServe.contextFilenameForInit` previously called
  `String(arr[0])` on the array branch, producing a literal
  `"[object Object]"` filename for hand-edited bad data. Now
  validates each element with `typeof === 'string'` and falls
  back to `undefined` (so the bridge uses its
  `getCurrentGeminiMdFilename()` default) when no string is
  found. Addresses #3260577641.

Documentation drift:
- `Config.getDisabledTools()` JSDoc rewritten to describe the
  mutable-via-`setDisabledTools()` semantics introduced by P2-2,
  and the "registration-time only / no retroactive unregister"
  contract that pairs with it. Old comment claimed the set was
  frozen at construction. Addresses #3260577677.

Observability:
- `acpAgent` MCP-restart `loadSettings` failure now surfaces a
  stderr line naming the server + the underlying error, instead
  of silently swallowing it. The documented "toggle + restart"
  workflow used to break with zero diagnostic when settings.json
  was corrupted or unreadable. Addresses #3260663303.

Code organization:
- Moved `canonicalizeExistingAncestor` after `describeStatKind` so
  the latter's JSDoc is no longer orphaned (TypeScript only
  associates the last `/** ... */` block before a declaration).
  Addresses #3260668618.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.
doudouOUC added a commit that referenced this pull request May 18, 2026
Critical bug from wenshao review (#3260725526) on PR #4297:
the P2-2 acpAgent re-read narrowed `Config.disabledTools` to
`SettingScope.Workspace` alone, dropping User / System scope
entries. The bootstrap Config received `merged.tools?.disabled`
(union of all scopes), so user-level / system-level disables
worked at boot — but the first `mcp restart` would replace the
in-memory set with the workspace scope alone, silently re-enabling
any tool that was disabled at a higher scope but absent from the
workspace file.

The asymmetry vs. the persist-write path is deliberate and
documented:
- Reads (here): merged — match the bootstrap Config snapshot,
  preserve user/system policy.
- Writes (`runQwenServe.persistDisabledTools`): workspace scope —
  don't bake higher-scope entries into the workspace file
  (per-#4282 fold-in 1 H2 fix).

Two paths look alike but answer different questions.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.
doudouOUC added 5 commits May 19, 2026 10:09
Critical follow-up from wenshao (#3260810242) on PR #4297:
the new `timeoutMs: 0` regression test (added in fold-in 2)
inherited the same flaw it was meant to prevent — the slow-fetch
stub didn't observe `init.signal`, so a regression that ignored
the `0` override would fire the AbortController at the 1ms client
default but the stub would keep the promise pending. The 50ms
`resolveResponse` would win, the test would still pass, and the
documented "0 disables timeout" contract would be unprotected.

Mirrored the listener pattern already used by the two sibling
tests in fold-in 2 — `init.signal.addEventListener('abort', () =>
reject(...))`. Now a regression that re-rejects `0` triggers the
abort, the stub rejects, the test fails.

8/8 restartMcpServer SDK tests pass; SDK typecheck clean.
Two new critical reviews from wenshao on PR #4297:

C1 — TOCTOU between lstat and writeFile (#3260836305):
The `lstat(target)` symlink check and the subsequent `writeFile`
were two separate syscalls, leaving a race window where a local
attacker with workspace write access could substitute a symlink
between them. With `force: true`, `writeFile` would follow the
link and truncate an external target.

The `action === 'created'` path now uses `fs.open(target, 'wx')`
(O_WRONLY|O_CREAT|O_EXCL), which atomically refuses any
pre-existing inode (regular file, dir, OR symlink) at the target
path. EEXIST after the absence check most plausibly means a
race-created symlink, so we throw `WorkspaceInitSymlinkError(kind:
'target')` — same typed class the route maps to 400.

The `force: true` overwrite path retains the existing TOCTOU as a
documented limitation; closing it requires `O_NOFOLLOW`-aware open
which the post-PR18 `WorkspaceFileSystem` migration will provide.

C2 — P2-2 zero test coverage (#3260836302):
The `setDisabledTools` runtime sync was the only Wave-4 P2 fix
without a dedicated test. Added 5 Config-level tests:
- Initializes from `disabledTools` ConfigParameters
- Defaults to empty set when omitted
- `setDisabledTools` replaces the live snapshot
- Defensive copy: caller-set mutations don't leak into the live snapshot
- Accepts an empty set (clears live snapshot)

Plus a TOCTOU regression test in httpAcpBridge.test.ts that
spies fs.lstat / fs.readFile to simulate the race window:
pre-creates a symlink, makes lstat lie about it, asserts the
'wx' open catches the racing inode and throws the typed
`WorkspaceInitSymlinkError(kind: 'target')`.

1622/1622 unit tests pass; typecheck clean across cli /
sdk-typescript / core.
DeepSeek review on #4297 (#3261079572):
`broadcastWorkspaceEvent` unconditionally subtracted 1 from the
`eligible` recipient count whenever `skipSessionId` was set, even
when the id matched zero live sessions (caller mistake, stale id,
or the matching session was just torn down between resolution and
broadcast). In a single-session workspace that's the difference
between `eligible = 0` (alarm suppressed) and `eligible = 1`
(alarm fires when the publish failed) — silently losing the
all-dropped breadcrumb the telemetry was meant to surface.

Today's call sites pass real session ids so the bug doesn't
manifest in practice, but the defensive shape is small: track
`skippedCount` inside the loop and subtract that, so the alarm
condition is self-consistent regardless of how the caller mis-uses
the param.

162/162 bridge tests pass; CLI typecheck clean.
…tics

Round-7 review on PR #4297. Three critical fixes + one suggestion
test, plus a regression test for the overwrite TOCTOU close.

C1 — force:true overwrite TOCTOU (#3262615446):
The fold-in 5 fix only closed the `'created'` action via 'wx';
the `'overwrote'` branch still used plain `fs.writeFile`, so a
local writer could swap the verified regular file to a symlink
between the lstat/readFile checks and the write and have the
forced overwrite truncate an external target. Switched to
`fs.open(target, O_WRONLY | O_TRUNC | O_NOFOLLOW)` — `O_NOFOLLOW`
makes open() fail with ELOOP on a symlink at the final component
even under race. ELOOP / ENOENT (race-deleted) translate to
`WorkspaceInitSymlinkError(kind: 'target')` so the route still
maps to a structured 400 instead of a generic 500.

C2 — settings.json corrupt blocks daemon boot (#3262625091):
`loadSettings(boundWorkspace)` at boot had no try/catch — a
corrupted, malformed, or temporarily unreadable settings file
threw synchronously and prevented daemon startup. Pre-PR this
never happened because settings were read lazily inside request
handlers. Wrapped in try/catch with stderr fallback so the daemon
keeps booting (with the bridge's default context filename) when
the file is broken.

C3 — malformed `tools.disabled` clears policy silently (#3262625101):
When `merged.tools?.disabled` is present but not an array
(boolean / string / object from a hand-edited settings.json), the
ternary `Array.isArray(...) ? ... : []` substituted an empty list
without firing the surrounding catch block. After an MCP restart
every disabled tool would silently re-register. Added an explicit
`!Array.isArray && !== undefined` check that stderr-logs the
malformed type before clearing — operators see the
misconfiguration instead of a stealth re-enable.

S1 — contextFilename extraction tested (#3262690842):
Lifted the inline `firstStringInArray` + branching into an
exported `extractContextFilename(value: unknown)` helper and
added `runQwenServe.test.ts` with 5 tests covering the four
branches the suggestion called out: non-empty string, array with
strings, array with no strings, non-string non-array.

Plus a TOCTOU regression test for the overwrite path that
verifies `O_NOFOLLOW` returns `WorkspaceInitSymlinkError(kind:
'target')` when the file is race-substituted with a symlink
behind the lstat/readFile mocks.

S2 (acpAgent restart-handler integration test #3262690845) is
deferred — Config-level coverage of `setDisabledTools` already
locks the load-bearing surface (5 tests in fold-in 5), and
adding a full acpAgent integration test requires heavy ext-method
plumbing. The new C3 stderr diagnostic plus existing tests give
us the regression signal we need without that scaffolding.

1627/1627 unit tests pass; typecheck clean across cli /
sdk-typescript / core / acp-bridge.
…path

qwen-latest review on PR #4297 (#3262861754):
The fold-in 7 ELOOP/ENOENT branch shared one error message that
said "swapped to a symlink." That's accurate for ELOOP (genuine
O_NOFOLLOW rejection — likely an attack race) but misleading for
ENOENT in the overwrite path: there `readFile` just succeeded
proving the file existed, so ENOENT means the file was DELETED
between the content check and the open — a benign race with a
concurrent writer (git checkout, editor save, lockfile rename),
NOT a symlink swap. An operator seeing the symlink language for
a benign delete would `ls -la`, see no symlink, and waste time
hunting an attack that didn't happen.

Split into two messages:
- ELOOP: "swapped to a symlink between the content check and the
  overwrite — refusing to follow it"
- ENOENT: "deleted between the content check and the overwrite
  (likely a concurrent writer) — refusing to recreate blindly"

Both still surface as `WorkspaceInitSymlinkError(kind: 'target')`
so the route maps to a structured 400; the class doubles as the
workspace-init race-condition bucket with kind='target' meaning
"target inode misbehaved at write time" generally.

Updated the existing fold-in 7 TOCTOU test to assert the ELOOP
message specifically, and added a new ENOENT race-delete test
that mocks lstat/readFile to land on the overwrote action against
a non-existent path — verifies the message says "deleted" and
NOT "swapped to a symlink."

170/170 bridge tests pass; CLI typecheck clean.
@doudouOUC doudouOUC force-pushed the post-pr17-codex-p2-fixes branch from 9140b76 to e3f3314 Compare May 19, 2026 02:10
…apper

gpt-5.5 critical review on PR #4297 (#3263088414):

The fold-in 5 P2-2 fix refreshed `Config.disabledTools` from merged
settings, but then called `manager.discoverMcpToolsForServer()`
directly — bypassing the `ToolRegistry.discoverToolsForServer`
wrapper that PURGES the server's existing `DiscoveredMCPTool`
entries (and `revealedDeferred` markers) plus its prompts before
rediscovery. Without the cleanup, `registerTool` only consulted
the refreshed `disabledTools` set for NEWLY-discovered tools —
entries already in the registry from the prior MCP boot kept
serving requests. Net effect: toggle-disable-then-restart
silently left the disabled tool live, breaking the documented
"toggle + restart" workflow that P2-2 was meant to fix.

Routed through `toolRegistry.discoverToolsForServer(serverName)`
which:
1. Removes existing `DiscoveredMCPTool` entries for this server
2. Drops their `revealedDeferred` reveal state
3. Removes the server's prompts via `removePromptsByServer`
4. THEN delegates to `manager.discoverMcpToolsForServer` for the
   actual reconnect + rediscover

The pre-discovery budget / in-flight checks still go through the
`manager` reference (which is the same object the registry
wrapper would forward to) — so soft-skip semantics for
`budget_would_exceed`, `in_flight`, `disabled` are preserved.

CLI typecheck clean; 403/403 server + bridge tests pass.
@doudouOUC

doudouOUC commented May 19, 2026

Copy link
Copy Markdown
Collaborator Author

test

@doudouOUC doudouOUC closed this May 19, 2026
@doudouOUC doudouOUC reopened this May 19, 2026
@doudouOUC doudouOUC changed the base branch from main to daemon_mode_b_main May 19, 2026 05:10
@doudouOUC doudouOUC requested a review from wenshao May 19, 2026 05:13
Comment thread packages/cli/src/serve/runQwenServe.ts
Comment thread packages/cli/src/serve/httpAcpBridge.ts
Comment thread packages/cli/src/serve/httpAcpBridge.ts Outdated
Comment thread packages/cli/src/serve/httpAcpBridge.ts Outdated
Comment thread packages/cli/src/serve/httpAcpBridge.ts
@doudouOUC doudouOUC requested a review from wenshao May 19, 2026 06:10
5 review threads from qwen-latest's late round on PR #4297 (now closed
in favor of #4313 against `daemon_mode_b_main`). 1 critical + 4
suggestions, all adopted.

C1 — extractContextFilename / getCurrentGeminiMdFilename divergence
(#3263954685): with `context.fileName: ['  ', 'AGENTS.md']`, the
daemon parent's `extractContextFilename` (which skips empty entries)
wrote `AGENTS.md`, but the ACP child's `getCurrentGeminiMdFilename`
(which returned `arr[0]` unconditionally) read `''`. The init'd file
was orphaned. Aligned `getCurrentGeminiMdFilename` to skip empty
entries with the same semantics, falling back to
`DEFAULT_CONTEXT_FILENAME` when all entries are empty.

S2 — WorkspaceInitSymlinkError reused for non-symlink races
(#3263954690): the EEXIST race-create and ENOENT race-delete cases
were surfacing as `code: 'workspace_init_symlink'`, misleading
operators into hunting symlink attacks for benign concurrent-
modification windows. Split into a sibling `WorkspaceInitRaceError`
class (`kind: 'eexist' | 'enoent'`, HTTP code
`workspace_init_race`). The genuine symlink class stays for ELOOP,
lstat-detected target symlinks, and parent-realpath escapes.

S3 — fsConstants.O_NOFOLLOW defensive `?? 0` (#3263954697): matches
the existing codebase convention in
`core/src/utils/{sessionStorageUtils,gitDiff}.ts` and
`cli/src/ui/utils/customBanner.ts`. Functionally a no-op (JS
bitwise coerces undefined to 0) but consistent.

S5 — Parent-directory TOCTOU still open (#3263954707): O_NOFOLLOW
only protects the final path component; a local writer could swap
a real parent dir for a symlink between
`canonicalizeExistingAncestor` and `fs.open`. Added
`verifyParentWithinWorkspace` post-open helper that re-realpaths
`path.dirname(target)` and refuses with
`WorkspaceInitSymlinkError(kind: 'parent')` if the parent moved.
On the create path (where we just opened with `'wx'`), the failure
also unlinks the file we just made best-effort. Residual race
window narrowed from "between pre-check and open" to "between
post-open realpath and writeFile" — sub-millisecond, documented as
accepted Stage-1 trust posture.

S4 — broadcastWorkspaceEvent vs publishWorkspaceEvent stale comment
(#3263954688): the "now removed" comment was inaccurate (5 call
sites still use the closure). Replaced with an accurate
description of why both coexist (factory closure can't `this`-call
proxy member; closure also takes `skipSessionId` for persisted
approval-mode mirror) and a TODO marker for future helper extraction.

Two existing tests updated to assert the new `WorkspaceInitRaceError`
class for EEXIST / ENOENT scenarios (the symlink-class assertions
are preserved for ELOOP / lstat / parent cases).

1759/1759 unit tests pass; typecheck clean across all 4 packages.
@doudouOUC

Copy link
Copy Markdown
Collaborator Author

Reopening — landing the work back on this PR (against main) instead of #4313 (against daemon_mode_b_main). The branch already has the latest 10 fold-ins pushed (most recent: cc99d87de fold-in 10 addressing the qwen-latest 05:45 review). All 14+ review threads from earlier rounds are still resolved.

@doudouOUC doudouOUC merged commit 066cab2 into daemon_mode_b_main May 19, 2026
10 checks passed
// throw isn't shadowed.
if (cleanup === 'create') {
await fh.close().catch(() => {});
await fs.unlink(target).catch(() => {});

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Critical] fs.unlink(target) resolves through the attacker's post-race symlink, creating an arbitrary-file-deletion primitive.

After fs.open(target, 'wx') creates the file at the real parent, an attacker with local write access swaps the parent directory for a symlink (e.g., docs/ -> /etc). verifyParentWithinWorkspace correctly detects the race — but this cleanup fs.unlink(target) re-resolves the textual path through the attacker's new symlink, deleting whatever file exists at the attacker's chosen external location.

Suggested change
await fs.unlink(target).catch(() => {});
await fh.close().catch(() => {});
// Do NOT fs.unlink(target): after a parent-directory race, `target`
// resolves through the attacker's symlink to an external location,
// potentially deleting an unrelated file. The empty file we created
// at the pre-race location is harmless (0 bytes, inside workspace).

— qwen-latest-series-invite-beta-v28 via Qwen Code /review

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Folded into F1 (#4319) as commit 7bd66c6e8fs.unlink(target) removed from the cleanup branch. The 0-byte file at the pre-race location stays (harmless: 0 bytes, inside the workspace we'd just verified) over deleting an arbitrary external file. Code in this PR can't be updated since #4297 is already MERGED, so the fix lives on F1 where the lifted code now resides (acp-bridge/src/bridge.ts). cc @wenshao for verification.

// bitwise coerces `undefined` to 0) but keeps the codebase
// consistent for the next greppy refactor.
fsConstants.O_WRONLY |
fsConstants.O_TRUNC |

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Critical] O_TRUNC causes the kernel to truncate the file to zero bytes at open(2) syscall time — before verifyParentWithinWorkspace runs. If a parent-symlink race occurred between canonicalizeExistingAncestor and this open(), the data at the attacker-redirected location is already destroyed by the time the verify detects the race.

The code's own comment at line ~4268 acknowledges this as "documented residual risk." This is exploitable: a workspace user who can win the TOCTOU race can zero out any file the daemon has write access to.

Fix: drop O_TRUNC from the open flags, call fh.truncate(0) after the verify passes. fd-based truncate doesn't re-resolve the path.

Suggested change
fsConstants.O_TRUNC |
fsConstants.O_WRONLY |
(fsConstants.O_NOFOLLOW ?? 0),

Then add await fh.truncate(0); after verifyParentWithinWorkspace returns (before writeFile).

— qwen-latest-series-invite-beta-v28 via Qwen Code /review

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Folded into F1 (#4319) as commit 7bd66c6e8O_TRUNC dropped from the open flags; truncation moved to fh.truncate(0) AFTER verifyParentWithinWorkspace succeeds. fd-based truncate doesn't re-resolve the path so a post-verify parent-symlink swap can't redirect it. Lives on F1 (acp-bridge/src/bridge.ts) where the lifted code now resides; #4297 is MERGED so can't update here. cc @wenshao for verification of the new structural ordering.

// parent would write `AGENTS.md` while the ACP child would read
// `''`, leaving the init'd file orphaned.
for (const entry of currentGeminiMdFilename) {
if (typeof entry === 'string' && entry.trim() !== '') {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Critical] New empty-entry filtering logic has no test coverage. const.test.ts only tests ['CUSTOM_CONTEXT.md', 'ANOTHER_CONTEXT.md']. The scenarios this code was specifically written to handle — ['', 'AGENTS.md'], [' ', '\n'], non-string entries — are untested.

The PR's own comments call out that getCurrentGeminiMdFilename and extractContextFilename MUST agree, yet the latter has 5 dedicated tests while the former has 0 for this new behavior. A regression silently re-introduces the exact daemon-parent/ACP-child divergence this fold-in claims to fix.

Suggested tests:

it('should skip empty/whitespace entries in an array', () => {
  setGeminiMdFilename(['', '  ', 'AGENTS.md']);
  expect(getCurrentGeminiMdFilename()).toBe('AGENTS.md');
});
it('should fall back to default when all array entries are empty', () => {
  setGeminiMdFilename(['', '  ']);
  expect(getCurrentGeminiMdFilename()).toBe('QWEN.md');
});

— qwen-latest-series-invite-beta-v28 via Qwen Code /review

let contextFilenameForInit: string | undefined;
try {
const bootSettings = loadSettings(boundWorkspace);
contextFilenameForInit = extractContextFilename(

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Critical] When extractContextFilename returns undefined (malformed context.fileName — e.g., object, number, boolean), contextFilenameForInit silently becomes undefined with zero diagnostic. The try/catch only handles loadSettings exceptions; a malformed-but-parseable value bypasses it entirely.

Contrast with the MCP restart path in acpAgent.ts:1556-1563 which explicitly logs malformed tools.disabled before falling back.

An operator whose workspace has context.fileName: { "name": "AGENTS.md" } sees init writing QWEN.md with no stderr output pointing to the misconfiguration. This is a silent correctness failure that requires reading source code to diagnose.

Suggested change
contextFilenameForInit = extractContextFilename(
contextFilenameForInit = extractContextFilename(
bootSettings.merged.context?.fileName,
);
if (
bootSettings.merged.context?.fileName !== undefined &&
contextFilenameForInit === undefined
) {
writeStderrLine(
`qwen serve: context.fileName has unexpected type ` +
`${typeof bootSettings.merged.context?.fileName}; ` +
`falling back to the default context filename.\n`,
);
}

— qwen-latest-series-invite-beta-v28 via Qwen Code /review

return await fs.realpath(current);
} catch (err) {
const code = (err as NodeJS.ErrnoException | null | undefined)?.code;
if (code !== 'ENOENT' && code !== 'ENOTDIR') throw err;

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[Suggestion] canonicalizeExistingAncestor catches ENOENT and ENOTDIR but not ELOOP. Circular symlinks in the parent path (e.g., a -> b, b -> a) cause fs.realpath to fail with ELOOP, which propagates as an unstructured HTTP 500 instead of the typed WorkspaceInitSymlinkError (400).

Suggested change
if (code !== 'ENOENT' && code !== 'ENOTDIR') throw err;
if (code !== 'ENOENT' && code !== 'ENOTDIR' && code !== 'ELOOP') throw err;

— qwen-latest-series-invite-beta-v28 via Qwen Code /review

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Folded into F1 (#4319) as commit 7bd66c6e8'ELOOP' added to the caught error codes in canonicalizeExistingAncestor alongside 'ENOENT' and 'ENOTDIR'. Walking up the parent chain on ELOOP preserves the existing "walk to the deepest extant ancestor" contract. Lives on F1 (acp-bridge/src/bridge.ts); #4297 already MERGED so can't update here.

@doudouOUC doudouOUC deleted the post-pr17-codex-p2-fixes branch May 19, 2026 11:46
doudouOUC added a commit that referenced this pull request May 19, 2026
Folds 3 unresolved review comments from the post-merge thread on #4297
(wenshao via qwen-latest agent) into F1 (#4319). All 3 touch
`acp-bridge/src/bridge.ts` — the same file F1 already moves the lifted
factory into — so consolidating here saves opening a separate
follow-up PR and keeps the security narrative in one reviewable
commit. The 2 cross-package fixes (`core/src/memory/const.ts` test
gap + `cli/src/serve/runQwenServe.ts` malformed-context fallback)
will land as their own small PRs after F1 merges.

#### Fix 1 (wenshao Critical, #4297 thread): `fs.unlink(target)`
arbitrary-file-deletion primitive in `verifyParentWithinWorkspace`
'create'-cleanup

After `fs.open(target, 'wx')` creates the empty file at the real
parent, an attacker with local workspace write access can swap the
parent directory for a symlink (`docs/` → `/etc`). The cleanup's
`fs.unlink(target)` re-resolves the TEXTUAL path through the
attacker's freshly-planted parent symlink, deleting whatever file
exists at the external location.

Fix: drop the `fs.unlink(target)` line. The 0-byte file at the
pre-race location is harmless (0 bytes, inside the workspace we'd
already verified) — leaving it over deleting an arbitrary external
file is the right safety trade. Comment block explains the
reasoning so future maintainers don't re-introduce the unlink.

#### Fix 2 (wenshao Critical): `O_TRUNC` arbitrary-file-truncation
primitive in workspace-init 'overwrite' branch

`O_TRUNC` causes the kernel to truncate the file to zero bytes AT
`open(2)` SYSCALL TIME — strictly before `verifyParentWithinWorkspace`
runs. A parent-symlink TOCTOU race between
`canonicalizeExistingAncestor` and this `open()` zeros the file at
the attacker-redirected location (arbitrary-file-truncation
primitive against any file the daemon UID can open). The pre-fix
code's own comment on `verifyParentWithinWorkspace` acknowledged
this as "Acceptable residual posture for the Stage-1 trust model";
wenshao pushed back that arbitrary-file-zeroing exceeds the
Stage-1 trust budget.

Fix: drop `O_TRUNC` from the open flags. Truncation moves to AFTER
`verifyParentWithinWorkspace` succeeds, via `fh.truncate(0)` on the
fd we already hold. fd-based truncate does NOT re-resolve the path
— an attacker swapping the parent symlink after we open can't
redirect the truncation.

#### Fix 3 (wenshao Suggestion): `canonicalizeExistingAncestor`
missing `ELOOP` catch

Circular symlinks in the parent path (`a -> b`, `b -> a`) cause
`fs.realpath` to fail with `ELOOP`. Without catching it, the error
propagates as an unstructured HTTP 500 instead of the typed
`WorkspaceInitSymlinkError` (HTTP 400) the route handler expects
from the workspace-init race-detection family.

Fix: add `'ELOOP'` to the caught error codes alongside `'ENOENT'`
and `'ENOTDIR'`. Walking up the parent chain when ELOOP hits at a
sub-component preserves the existing "walk to the deepest extant
ancestor" contract — the deepest realpath-able ancestor still
dictates the canonical prefix.

#### Why no new tests in this commit

- Fix 1 is a single-line removal: any regression that re-adds the
  unlink would be caught by reviewing the diff; existing 174-test
  `httpAcpBridge.test.ts` integration suite confirms the create-path
  still works (file is created + closed correctly; only the
  attacker-cleanup branch changes).
- Fix 2 is a structural move (truncate from open-time to post-verify);
  the existing overwrite-init integration tests confirm the
  end-to-end behavior is unchanged (file ends up empty after init).
  Adding a TOCTOU race regression test requires controlled
  filesystem-race simulation that exceeds reasonable test infra
  scope for this PR.
- Fix 3 is a one-word addition to an error code list; the
  `canonicalizeExistingAncestor` helper is module-private and the
  integration test for circular-symlink → typed 400 would require
  exporting it OR setting up a real circular-symlink workspace.
  Both routes widen scope beyond the security fix itself; the
  high-level behavior is verifiable by the existing route-error-
  mapping test pattern + diff review.

A follow-up PR can add the integration tests once the security fix
itself has shipped; the immediate priority is closing the
arbitrary-file-deletion + arbitrary-file-truncation primitives.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint clean

#### Refs

- Original review on #4297 (wenshao via qwen-latest agent), post-
  merge, currently unresolvable on #4297 itself because that PR is
  already MERGED.
- Other 2 #4297 review threads (`const.ts` test coverage,
  `runQwenServe.ts` malformed-context observability) target files
  outside F1's scope and will land as separate follow-up PRs.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
doudouOUC added a commit that referenced this pull request May 19, 2026
…zation + SDK timeout headroom (#4319)

Folds in 2 P2 findings from a Codex review run on `git diff main...HEAD`
of F1 PR #4319. Both are pre-existing in code merged into
`daemon_mode_b_main` before F1 was created (#4282 PR 17), but they're
tiny tactical fixes (~25 LOC + 1 LOC) on the same integration branch
the same reviewer (wenshao) already engages with, so folding into F1
saves an extra follow-up PR cycle.

#### Fix 1: normalize disabled tool names during MCP restart refresh

`packages/cli/src/acp-integration/acpAgent.ts:1563-1566`

The bootstrap path in `cli/src/config/config.ts:1426-1434` applies a
4-step normalization to `tools.disabled`:
  1. typeof string filter
  2. .trim()
  3. drop empty after trim
  4. dedupe via Set

The MCP-restart refresh path only did step 1, then stored the raw
strings. `ToolRegistry` checks disabled tools with EXACT
`Set.has(tool.name)`, so a tool disabled at boot as `' Foo '` (or
`'Foo\n'`) is no longer matched after `restartMcpServer` and gets
silently re-registered. This contradicts the documented "toggle +
restart" workflow that #4282 PR 17 advertised.

Fix: mirror the bootstrap normalization verbatim before
`setDisabledTools`. Adds 6 lines + a 7-line comment pointing at the
bootstrap reference for future maintainers.

#### Fix 2: add headroom to MCP restart SDK timeout

`packages/sdk-typescript/src/daemon/DaemonClient.ts:102`

The SDK's `MCP_RESTART_DEFAULT_TIMEOUT_MS` was EXACTLY 300_000ms, the
same ceiling the daemon's own `MCP_RESTART_TIMEOUT_MS` uses for the
upper bound on a single MCP rediscovery. For restarts that finish
(or fail with a typed `McpServerRestartFailedError` JSON envelope)
near 300s, the client `AbortSignal` could fire BEFORE the daemon had
finished serializing + transmitting the response, yielding a client
`TimeoutError` even though the daemon was still within its own
budget.

Fix: bump to 330_000ms (10% / 30s headroom over the daemon ceiling).
Comment updated to call out the race + the rationale for the
specific headroom value. Callers needing tighter caps still pass
their own `timeoutMs` to `restartMcpServer`.

#### Why folded into F1 vs separate follow-up PRs

These are post-merge findings on `#4282 PR 17` code, not F1-introduced
regressions. Normally we'd track as separate follow-up issues (mirror
of the #4325 / `channelInfo` decline). But:

- Both fixes are TINY (~25 LOC + ~2 LOC including comment); the bridge
  security fold-in commit `7bd66c6e8` set the precedent of folding in
  small same-branch issues when the cost-benefit favors closing them
  immediately.
- Same reviewer (wenshao via qwen-latest agent) — won't be confused
  by the scope expansion; in fact the original PR 17 commenter is
  also the one who'd review the follow-up issue's fix.
- Both fixes target `daemon_mode_b_main`-only paths (MCP restart route
  added by PR 17 lives on the integration branch).
- Saves opening 2 trivial follow-up issues that would just sit until
  someone picks them up.

#### Verification

- sdk-typescript: 424/424 tests pass (no test hardcoded the old
  300_000 default — only the constant declaration itself referenced it)
- cli acp-integration: 282/282 tests pass (no test exercised the
  exact whitespace-bearing disabled-tools scenario, so no test
  changes were strictly required; a regression test would belong in
  a separate test-coverage PR alongside the const.ts test gap from
  the #4297 unresolved-comment thread)
- typecheck clean across cli + sdk-typescript

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
pomelo-nwu pushed a commit that referenced this pull request May 19, 2026
…hanical lift + BridgeFileSystem seam) (#4319)

* refactor(acp-bridge): lift defaultSpawnChannelFactory to acp-bridge/spawnChannel (#4175 F1 step 1)

First mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves the production spawn factory + its `killChild` helper +
`SCRUBBED_CHILD_ENV_KEYS` denylist + `KILL_HARD_DEADLINE_MS` constant
from `cli/src/serve/httpAcpBridge.ts` (~283 lines) to
`@qwen-code/acp-bridge/spawnChannel`. This unblocks
`channels/base/AcpBridge.ts` and `vscode-ide-companion`'s
acpConnection from each reimplementing the child lifecycle — they can
now consume the same primitive.

Backward compatible: `cli/src/serve/httpAcpBridge.ts` imports the
lifted factory and re-exports it, so existing references in
`cli/src/serve/index.ts:90` and the factory's own internal usage
(`opts.channelFactory ?? defaultSpawnChannelFactory`) keep resolving.
Bridge tests that mock `defaultSpawnChannelFactory` via
`BridgeOptions.channelFactory` are unaffected.

Side cleanups: drops `spawn` / `ChildProcess` / `Readable` / `Writable`
/ `ndJsonStream` / `MissingCliEntryError` imports from
httpAcpBridge.ts (all only used by the lifted spawn factory).

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift BridgeClient + permission types to acp-bridge/bridgeClient (#4175 F1 step 2)

Second mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves `BridgeClient` class (~700 LOC) + `PendingPermission` interface +
`PermissionResolutionRecord` interface + `MAX_RESOLVED_PERMISSION_RECORDS`
constant + early-event capacity constants + `describeStatKind` and
`sliceLineRange` helpers from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridgeClient`.

Design choice for SessionEntry boundary: introduce a minimal
`BridgeClientSessionEntry` interface in bridgeClient.ts with only the
four fields BridgeClient actually reads from the factory's richer
`SessionEntry` (`sessionId`, `events`, `pendingPermissionIds`,
`activePromptOriginatorClientId`). The factory's `SessionEntry`
structurally satisfies it — TypeScript's structural typing enforces
the match at the `resolveEntry` callback signature, so no explicit
conversion is required and the bridge package stays free of daemon-host
session-bookkeeping types.

Cross-package writeStderrLine handling: inline the 3-line helper in
bridgeClient.ts (mirrors the spawnChannel.ts pattern from F1 step 1)
so acp-bridge has no reverse dependency on `cli/src/utils/stdioHelpers`.

httpAcpBridge.ts shrinks from 4406 LOC to 3647 LOC (-759 lines).
Removed ACP SDK imports that only BridgeClient consumed: `Client`,
`RequestPermissionRequest`, `WriteTextFileRequest`,
`WriteTextFileResponse`, `ReadTextFileRequest`, `ReadTextFileResponse`,
`SessionNotification`. Kept the ones the factory still uses
(`CancelNotification`, `PromptRequest`, `RequestPermissionResponse`,
`SetSessionModelRequest`, `SetSessionModelResponse`).

Backward compatible: httpAcpBridge.ts re-exports `BridgeClient`,
`BridgeClientSessionEntry`, `PendingPermission`,
`PermissionResolutionRecord`, and `MAX_RESOLVED_PERMISSION_RECORDS` so
the `ChannelInfo.client: BridgeClient` field declaration below + any
embedder reaching into these types keep resolving.

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- 229/229 cli server tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift createHttpAcpBridge factory to acp-bridge/bridge (#4175 F1 step 3)

Third + final mechanical lift of #4175 F1 (acp-bridge package
self-sufficiency). Moves the `createHttpAcpBridge` factory closure
(~3000 LOC) + `ChannelInfo` + `SessionEntry` interfaces + factory-only
helpers (`canonicalizeExistingAncestor`, `verifyParentWithinWorkspace`,
`withTimeout`, `isServeDebugLoggingEnabled`, `writeServeDebugLine`,
`hasControlCharacter`) + factory constants (`DEFAULT_INIT_TIMEOUT_MS`,
`MCP_RESTART_TIMEOUT_MS`, `DEFAULT_MAX_SESSIONS`, `MAX_EVENT_RING_SIZE`,
`DEFAULT_PERMISSION_TIMEOUT_MS`, `DEFAULT_MAX_PENDING_PER_SESSION`,
`MAX_DISPLAY_NAME_LENGTH`) from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridge`.

`cli/src/serve/httpAcpBridge.ts` shrinks from 3647 LOC to 97 LOC — a
pure re-export shim that preserves every existing relative import
path (`./httpAcpBridge.js`) so `server.ts`, `runQwenServe.ts`,
`workspaceAgents.ts`, `workspaceMemory.ts`, `index.ts`, plus the bridge
test suite, keep resolving without any call-site changes.

The new `bridge.ts` reuses what was already in acp-bridge (errors,
types, options, status helpers, channel types, event bus, workspace
paths) via local relative imports — no reverse dependency on `cli`.
`writeStderrLine` is inlined at the top of `bridge.ts` (same pattern as
`spawnChannel.ts` + `bridgeClient.ts` from F1 steps 1-2) so the
package self-contained promise holds.

Cumulative F1 impact across the 3 mechanical lift steps:
- httpAcpBridge.ts: 4682 LOC → 97 LOC (-4585 lines; the original file
  was 98% bridge core, 2% backward-compat re-exports)
- 3 new files in acp-bridge: spawnChannel.ts (~270 LOC), bridgeClient.ts
  (~745 LOC), bridge.ts (~3515 LOC)
- All daemon-host concerns (env snapshot, daemon preflight cells)
  remain in `cli/src/serve/daemonStatusProvider.ts` and reach the
  bridge through the `BridgeOptions.statusProvider` seam frozen by
  PR 22b/2.

- 735/735 cli serve tests pass across 17 files
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- typecheck clean across acp-bridge + cli

`packages/cli/src/serve/httpAcpBridge.test.ts` (~6600 LOC) is
intentionally NOT moved in this commit — it currently imports
`createHttpAcpBridge` / `defaultSpawnChannelFactory` / `BridgeClient`
via the cli shim and keeps passing without changes. Moving it to
`acp-bridge/src/bridge.test.ts` is a follow-up worth tracking
separately so the production-code lift can land + be reviewed cleanly.

The `BridgeFileSystem` injection seam (originally bundled into F1 as
the 22b' scope) is also deferred to a follow-up so the mechanical lift
stays mechanical — design + implementation of the fs injection is its
own discussion.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* feat(acp-bridge): add BridgeFileSystem injection seam (#4175 F1 step 5, 22b' scope)

Adds the `BridgeFileSystem` injection seam originally scoped as #4175
22b'. When a `BridgeFileSystem` is wired through
`BridgeOptions.fileSystem`, `BridgeClient.readTextFile` and
`BridgeClient.writeTextFile` delegate to it instead of running their
inline `fs.realpath` / `fs.writeFile` / `fs.readFile` proxy.

This unblocks production `qwen serve` plumbing PR 18's
`WorkspaceFileSystem` (TOCTOU guards, symlink-substitution checks,
trust gate, `.gitignore`, audit hooks) into the ACP fs methods —
closing the `ws.ts:613` follow-up thread that has been tracked since
PR 18 landed. The serve-side adapter that wraps `WorkspaceFileSystem`
+ the `runQwenServe` wiring are intentionally split into the
immediate-follow-up so this PR stays focused on the seam design.

Backward compatible: `fileSystem` is optional on `BridgeOptions`.
Tests, Mode A in-process consumers, channels (`packages/channels/base/
AcpBridge.ts`), and the VSCode IDE companion all keep working
unchanged — they omit the field and `BridgeClient` falls through to
the inline proxy that has been the Stage 1 default since #3889.

API:
- `BridgeFileSystem.readText(params: ReadTextFileRequest):
  Promise<ReadTextFileResponse>`
- `BridgeFileSystem.writeText(params: WriteTextFileRequest):
  Promise<WriteTextFileResponse>`

The interface mirrors ACP SDK request/response types directly so the
adapter does the minimum amount of translation (`{ path, content }`
↔ `WorkspaceFileSystem`'s `ResolvedPath` brand types + options bag).

- 735/735 cli serve tests pass (inline fallback path preserved)
- 44/44 acp-bridge tests pass
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): catch README + stale source comments up to F1 lift

Self-review fold-in: post-F1 the package README still said "PR 22a"
and listed `BridgeClient` / `createHttpAcpBridge` /
`defaultSpawnChannelFactory` under "What's not here yet" — both
contradicted by this PR. Updated:

- README lift-history table now shows PR 22a / 22b/1 / 22b/2 as
  merged and F1 (this PR) as the slice that closes the bridge core
  + adds `BridgeFileSystem`. F3 PR 24 row aligned to the
  feature-cohesive plan.
- "What's here today" now documents `spawnChannel`, `bridgeClient`,
  `bridge`, `bridgeFileSystem` modules.
- "What's not here yet" section removed (its 2 bullets are both
  resolved by F1).
- Subpath import list updated to enumerate all 14 subpaths.
- Backward-compat section updated to call out the 97-line shim and
  the 6 consuming files that still import via `./httpAcpBridge.js`.

Source-comment line-number drift:
- `channel.ts:12` no longer claims `defaultSpawnChannelFactory` is
  "still in cli/src/serve/httpAcpBridge.ts" — points to the lifted
  location.
- `permission.ts:33` + `permission.ts:45` no longer reference
  `httpAcpBridge.ts:1096-1106` / `httpAcpBridge.ts:1003` (file is
  now 97 lines after F1). Updated to point at the structurally-
  equivalent locations inside the lifted `bridgeClient.ts`.
- `permission.ts:7` no longer says first-responder still lives in
  `cli/src/serve/httpAcpBridge.ts` — points at the bridgeClient.ts
  location.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): adopt 3 Copilot review comments on F1 doc accuracy

Folds in 3 of 4 Copilot inline comments from #4319 review:

1. `bridgeClient.ts` writeTextFile preserveMode comment said "fall
   through to umask defaults" for new files, but the code passes
   `mode: preserveMode?.mode ?? 0o600` to `fs.writeFile`. Updated the
   "BkwQW" comment + the inner catch-block comment to clarify that
   new files actually get the `0o600` default applied at writeFile
   time (NOT umask defaults — the explicit `mode` arg bypasses umask
   for atomicity per the `Blehd` comment block).

2. `bridgeFileSystem.ts` JSDoc referenced
   `cli/src/serve/bridgeFileSystemAdapter.ts` as if the file exists,
   but it's deferred to the immediate F1 follow-up PR. Reworded as
   "the immediate follow-up PR will land a serve-side adapter" so
   reviewers don't grep for a non-existent file.

3. `bridgeOptions.ts` `fileSystem` field JSDoc had the same wording
   issue ("Production `qwen serve` wires this to..."). Same fix — now
   says "The immediate F1 follow-up will land a serve-side adapter"
   so the deferred state is obvious.

Declined from this review round:

- Copilot inline #1 (`spawnChannel.ts:155` stderr forwarder drops
  empty lines): pre-existing behavior since #3889. F1 lifted verbatim
  — not a regression introduced here. Out of scope for a lift PR.
- github-actions bot summary: most items are pre-existing notes
  (TOCTOU residual race, SCRUBBED_CHILD_ENV_KEYS allowlist concern,
  sliceLineRange benchmark threshold) on code the F1 lift moved
  verbatim. One ("httpAcpBridge.ts still has ~3700 LOC") is a false
  positive — the file is 97 LOC after F1. Others are cosmetic
  refactors (extract FIXME to tracking issue, ARCHITECTURE_DECISIONS
  doc system, deprecation timeline) that aren't worth churning the
  lift PR over.

- 44/44 acp-bridge tests pass
- typecheck clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): tighten BridgeFileSystem contract + re-export type from shim

Self-review + code-reviewer agent fold-in, two changes:

1. `cli/src/serve/httpAcpBridge.ts` shim now re-exports
   `BridgeFileSystem` from `@qwen-code/acp-bridge/bridgeFileSystem`
   so the immediate F1 follow-up adapter (in `cli/src/serve/`)
   can import it via the established `./httpAcpBridge.js` path
   like every other daemon-side bridge import does. Without this
   the adapter would need to deep-import from acp-bridge while
   every other serve file goes through the shim — inconsistent.

2. `BridgeFileSystem.readText` + `writeText` JSDoc now spells out
   the two defensive gates the inline proxy carried (non-regular-
   file rejection + 100 MiB buffered-size cap for reads;
   write-then-rename atomicity + dangling-symlink walk-through +
   mode preservation + `0o600` new-file default for writes). When
   a `BridgeFileSystem` is injected, the inline path is FULLY
   bypassed — without the contract spelled out, a future adapter
   author could silently drop the `/dev/zero` / 500 MB log RSS
   defenses the inline path established.

Note on F1 CI: this PR targets `daemon_mode_b_main` but the
`.github/workflows/ci.yml` `pull_request` trigger is scoped to
`branches: main / release/**`, so the main CI workflow (Lint /
Test on Linux/macOS/Windows / CodeQL) does NOT run on this PR.
This is a by-design side effect of the new feature-cohesive
branching strategy — `daemon_mode_b_main → main` periodic merges
will trigger the full CI matrix, providing safety net coverage
before any F-series work lands on `main`. Locally verified:
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- 735/735 cli serve tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover BridgeFileSystem injection seam + extract shared writeStderrLine (#4319 wenshao review)

Folds in wenshao review on #4319:

1. **[Critical]** zero test coverage for the F1 step 5 `BridgeFileSystem`
   delegation branches in `BridgeClient.writeTextFile` /
   `BridgeClient.readTextFile` and the factory's
   `opts.fileSystem` → constructor positional-arg forwarding.

   New `packages/acp-bridge/src/bridgeClient.test.ts` adds 6 tests
   covering:
   - writeTextFile delegates to injected fileSystem.writeText (inline
     proxy fully bypassed; `fakeFs.writeText` called with the original
     params; `readText` mock not invoked)
   - writeTextFile invalid-path call succeeds purely via the mock
     when fileSystem is injected (proof that the inline `fs.realpath`
     path doesn't run)
   - readTextFile delegates to injected fileSystem.readText
   - readTextFile propagates injection errors to the caller
   - inline-fallback regression guard: write actually hits disk via
     the inline proxy when fileSystem is omitted (real tmp file
     round-trip)
   - same for read

   Why these matter: the 7-arg `BridgeClient` constructor places
   `fileSystem` at the tail as optional. A reordering — or dropping
   the arg from `bridge.ts` factory's `new BridgeClient(..., opts.fileSystem)`
   call — would silently bypass the adapter in production and the
   inline `fs.writeFile` raw-path would run with no audit / trust /
   TOCTOU coverage. The delegation tests would catch that because
   the mock fileSystem would never be invoked.

2. **[Suggestion]** `writeStderrLine` was defined identically in
   `bridge.ts:117` and `bridgeClient.ts:30` (22 call sites across the
   two files). Both consumers live in the SAME `@qwen-code/acp-bridge`
   package, so the original "no reverse-dep on cli" justification
   doesn't apply within the package. Extracted to
   `packages/acp-bridge/src/internal/stderrLine.ts` — a single source
   of truth that future behavior changes (timestamp prefix, log
   level, structured field) can edit once. `internal/` subpath is
   intentionally not in `package.json`'s `exports`, keeping the
   helper package-private. `spawnChannel.ts` deliberately does NOT
   consume it (its stderr writes use `process.stderr.write(prefix +
   line + '\n')` directly because each line carries its own
   `[serve pid=… cwd=…]` line prefix).

- 6/6 new BridgeFileSystem-seam tests pass
- 50/50 acp-bridge total (44 existing + 6 new)
- 174/174 cli httpAcpBridge tests pass (no regression from refactor)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover defaultSpawnChannelFactory env scrubbing + fix bridge.ts comment refs (#4319 wenshao round 2)

Folds in wenshao review on #4319 round 2 — 1 Critical + 2 Suggestions:

1. **[Critical] spawnChannel.ts has 0 unit tests, security-critical
   paths untested.** Now that `defaultSpawnChannelFactory` is a public
   export of `@qwen-code/acp-bridge`, channels + IDE consumers can't
   rely on cli-package integration tests for env-scrubbing guarantees.

   Refactored the inline env-scrubbing logic into a pure exported
   helper `scrubChildEnv(source, scrubbed, overrides)`. Behavior is
   byte-identical to the pre-extraction inline implementation; the
   factory body now reads:

       const childEnv = scrubChildEnv(
         process.env, SCRUBBED_CHILD_ENV_KEYS, childEnvOverrides);

   Added `packages/acp-bridge/src/spawnChannel.test.ts` with 12 tests
   covering:
   - shallow-clone (no aliasing into live process.env)
   - QWEN_SERVER_TOKEN stripping
   - non-scrubbed vars pass through
   - override-add a new key
   - override-replace an existing key
   - override with undefined deletes the key (PR 14 fix #4247 wenshao R5)
   - override CANNOT re-introduce a scrubbed key (defense in depth)
   - override CANNOT undo the scrub by setting undefined for a scrubbed key
   - override-apply-after-scrub ordering invariant
   - empty overrides equals no overrides
   - multi-key scrub for forward-compat (the WARNING comment on
     SCRUBBED_CHILD_ENV_KEYS anticipates a future sandboxed-agent
     mode expanding the denylist; this verifies the loop already
     handles that)

   The killChild SIGTERM→SIGKILL escalation + STDERR_LINE_CAP_CHARS
   truncation are NOT covered yet — they require either real child
   processes or extensive node:child_process mocking; both are
   orthogonal to the env-scrubbing security guarantees wenshao
   explicitly called out, and can land as a follow-up if anyone
   wants the full surface tested.

2. **[Suggestion] bridge.ts comments referenced a "consolidated re-
   export block earlier in this file" that doesn't exist in acp-bridge
   (only in the cli shim).** Fixed both occurrences (~line 292, ~line
   310) to point at the actual local import + the package barrel
   re-export.

3. **[Suggestion] bridge.ts canonicalizeWorkspace re-export comment
   referenced `./fs/paths.ts`.** Updated to mention the full lift
   chain: extracted to `cli/src/serve/fs/paths.ts` in PR 18, then
   lifted here to `./workspacePaths.ts` in PR 22b/1.

- 12/12 new spawn env-scrub tests pass
- 62/62 acp-bridge total (50 existing + 12 new spawn)
- 174/174 cli httpAcpBridge tests still pass (the factory's inline
  env-scrubbing refactor preserves byte-identical behavior)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): fix 14-arg→7-arg typo in test docstring + simplify canonicalizeWorkspace re-export doc (#4319 wenshao round 3)

Folds in 2 of 3 wenshao Suggestions from #4319 round 3:

1. `bridgeClient.test.ts:20` JSDoc said "the 14-arg constructor's
   positional slot" — typo I introduced when writing the test in
   `fbc92bccf`. The same docstring correctly says "the constructor
   takes 7 positional args" at line 25. Updated to "7-arg".

2. `bridge.ts:3461` `canonicalizeWorkspace` re-export JSDoc no longer
   references the historical `cli/src/serve/fs/paths.ts` location.
   Reads cleaner as a present-tense pointer to `./workspacePaths.ts`
   (where the implementation actually lives now post-PR 22b/1).
   Git history covers the lift chain; the docstring should describe
   current state.

DECLINED + tracked separately:

- **[Critical]** `closeSession` + `killSession` use module-scoped
  `channelInfo` instead of `channelInfoForEntry(entry)` — channel-
  overlap edge case can kill the wrong channel. Wenshao explicitly
  notes "pre-existing bug preserved by the lift" — F1's mechanical-
  lift scope shouldn't carry behavior fixes, and the fix needs a
  channel-overlap regression test to land safely. Tracked as #4325.

- 62/62 acp-bridge tests pass (no regression from doc tweaks)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): polish from second-pass self-review (cross-platform test + package metadata + dead tombstones)

Five small adoptions from a second-pass code-reviewer agent review on
F1 (no new external comments — pre-emptive cleanup before reviewer
returns):

1. **`bridge.ts:290-313`** — deleted two standalone "InvalidPermission
   OptionError / WorkspaceInit* / McpServer* lifted to bridgeErrors"
   tombstone comments. Pre-22b they were load-bearing (explained why
   the class wasn't `class`-defined inline at that file location).
   Post-F1 the symbols are imported at the top of the file and the
   comments sit between unrelated code (`writeServeDebugLine` /
   `MAX_DISPLAY_NAME_LENGTH` / `DEFAULT_INIT_TIMEOUT_MS`) with no
   anchor. Dead doc — removed.

2. **`README.md`** — `spawnChannel` entry now lists `scrubChildEnv`
   alongside `defaultSpawnChannelFactory` + `killChild` +
   `SCRUBBED_CHILD_ENV_KEYS`. Channels / VSCode IDE consume the
   package barrel so the helper should be visible in the inventory.

3. **`package.json:description`** — refreshed from the PR 22a wording
   ("EventBus, AcpChannel, in-memory channel, PermissionMediator
   interface") to include F1 additions (`createHttpAcpBridge` /
   `BridgeClient` / `defaultSpawnChannelFactory` / `BridgeFileSystem`).
   Visible on `npm view`-style tooling + IDE hover so worth keeping
   current.

4. **`bridgeClient.test.ts:92-115`** — swapped `/proc/no-such-file`
   for `/this/dir/never/exists/file.txt` and reworded the comment.
   `/proc/` is Linux-only; on macOS / Windows the inline proxy's
   dangling-symlink fallback would write through to a path under
   root rather than failing. Test passed regardless (mock assertion,
   not real disk) but the comment overstated portability.

5. **`spawnChannel.test.ts:36`** — added a comment block explaining
   why the test deliberately hand-rolls the SCRUBBED set instead of
   importing the production `SCRUBBED_CHILD_ENV_KEYS`. The
   decoupling is intentional (pure-function parameterized test +
   forward-guard for future denylist expansion) but a naive reader
   would think it's an oversight.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint + pre-commit hooks clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(acp-bridge): bridge.ts security fold-in from #4297 review (3 issues)

Folds 3 unresolved review comments from the post-merge thread on #4297
(wenshao via qwen-latest agent) into F1 (#4319). All 3 touch
`acp-bridge/src/bridge.ts` — the same file F1 already moves the lifted
factory into — so consolidating here saves opening a separate
follow-up PR and keeps the security narrative in one reviewable
commit. The 2 cross-package fixes (`core/src/memory/const.ts` test
gap + `cli/src/serve/runQwenServe.ts` malformed-context fallback)
will land as their own small PRs after F1 merges.

#### Fix 1 (wenshao Critical, #4297 thread): `fs.unlink(target)`
arbitrary-file-deletion primitive in `verifyParentWithinWorkspace`
'create'-cleanup

After `fs.open(target, 'wx')` creates the empty file at the real
parent, an attacker with local workspace write access can swap the
parent directory for a symlink (`docs/` → `/etc`). The cleanup's
`fs.unlink(target)` re-resolves the TEXTUAL path through the
attacker's freshly-planted parent symlink, deleting whatever file
exists at the external location.

Fix: drop the `fs.unlink(target)` line. The 0-byte file at the
pre-race location is harmless (0 bytes, inside the workspace we'd
already verified) — leaving it over deleting an arbitrary external
file is the right safety trade. Comment block explains the
reasoning so future maintainers don't re-introduce the unlink.

#### Fix 2 (wenshao Critical): `O_TRUNC` arbitrary-file-truncation
primitive in workspace-init 'overwrite' branch

`O_TRUNC` causes the kernel to truncate the file to zero bytes AT
`open(2)` SYSCALL TIME — strictly before `verifyParentWithinWorkspace`
runs. A parent-symlink TOCTOU race between
`canonicalizeExistingAncestor` and this `open()` zeros the file at
the attacker-redirected location (arbitrary-file-truncation
primitive against any file the daemon UID can open). The pre-fix
code's own comment on `verifyParentWithinWorkspace` acknowledged
this as "Acceptable residual posture for the Stage-1 trust model";
wenshao pushed back that arbitrary-file-zeroing exceeds the
Stage-1 trust budget.

Fix: drop `O_TRUNC` from the open flags. Truncation moves to AFTER
`verifyParentWithinWorkspace` succeeds, via `fh.truncate(0)` on the
fd we already hold. fd-based truncate does NOT re-resolve the path
— an attacker swapping the parent symlink after we open can't
redirect the truncation.

#### Fix 3 (wenshao Suggestion): `canonicalizeExistingAncestor`
missing `ELOOP` catch

Circular symlinks in the parent path (`a -> b`, `b -> a`) cause
`fs.realpath` to fail with `ELOOP`. Without catching it, the error
propagates as an unstructured HTTP 500 instead of the typed
`WorkspaceInitSymlinkError` (HTTP 400) the route handler expects
from the workspace-init race-detection family.

Fix: add `'ELOOP'` to the caught error codes alongside `'ENOENT'`
and `'ENOTDIR'`. Walking up the parent chain when ELOOP hits at a
sub-component preserves the existing "walk to the deepest extant
ancestor" contract — the deepest realpath-able ancestor still
dictates the canonical prefix.

#### Why no new tests in this commit

- Fix 1 is a single-line removal: any regression that re-adds the
  unlink would be caught by reviewing the diff; existing 174-test
  `httpAcpBridge.test.ts` integration suite confirms the create-path
  still works (file is created + closed correctly; only the
  attacker-cleanup branch changes).
- Fix 2 is a structural move (truncate from open-time to post-verify);
  the existing overwrite-init integration tests confirm the
  end-to-end behavior is unchanged (file ends up empty after init).
  Adding a TOCTOU race regression test requires controlled
  filesystem-race simulation that exceeds reasonable test infra
  scope for this PR.
- Fix 3 is a one-word addition to an error code list; the
  `canonicalizeExistingAncestor` helper is module-private and the
  integration test for circular-symlink → typed 400 would require
  exporting it OR setting up a real circular-symlink workspace.
  Both routes widen scope beyond the security fix itself; the
  high-level behavior is verifiable by the existing route-error-
  mapping test pattern + diff review.

A follow-up PR can add the integration tests once the security fix
itself has shipped; the immediate priority is closing the
arbitrary-file-deletion + arbitrary-file-truncation primitives.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint clean

#### Refs

- Original review on #4297 (wenshao via qwen-latest agent), post-
  merge, currently unresolvable on #4297 itself because that PR is
  already MERGED.
- Other 2 #4297 review threads (`const.ts` test coverage,
  `runQwenServe.ts` malformed-context observability) target files
  outside F1's scope and will land as separate follow-up PRs.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix: post-merge Codex P2 fold-in — MCP restart disabled-tools normalization + SDK timeout headroom (#4319)

Folds in 2 P2 findings from a Codex review run on `git diff main...HEAD`
of F1 PR #4319. Both are pre-existing in code merged into
`daemon_mode_b_main` before F1 was created (#4282 PR 17), but they're
tiny tactical fixes (~25 LOC + 1 LOC) on the same integration branch
the same reviewer (wenshao) already engages with, so folding into F1
saves an extra follow-up PR cycle.

#### Fix 1: normalize disabled tool names during MCP restart refresh

`packages/cli/src/acp-integration/acpAgent.ts:1563-1566`

The bootstrap path in `cli/src/config/config.ts:1426-1434` applies a
4-step normalization to `tools.disabled`:
  1. typeof string filter
  2. .trim()
  3. drop empty after trim
  4. dedupe via Set

The MCP-restart refresh path only did step 1, then stored the raw
strings. `ToolRegistry` checks disabled tools with EXACT
`Set.has(tool.name)`, so a tool disabled at boot as `' Foo '` (or
`'Foo\n'`) is no longer matched after `restartMcpServer` and gets
silently re-registered. This contradicts the documented "toggle +
restart" workflow that #4282 PR 17 advertised.

Fix: mirror the bootstrap normalization verbatim before
`setDisabledTools`. Adds 6 lines + a 7-line comment pointing at the
bootstrap reference for future maintainers.

#### Fix 2: add headroom to MCP restart SDK timeout

`packages/sdk-typescript/src/daemon/DaemonClient.ts:102`

The SDK's `MCP_RESTART_DEFAULT_TIMEOUT_MS` was EXACTLY 300_000ms, the
same ceiling the daemon's own `MCP_RESTART_TIMEOUT_MS` uses for the
upper bound on a single MCP rediscovery. For restarts that finish
(or fail with a typed `McpServerRestartFailedError` JSON envelope)
near 300s, the client `AbortSignal` could fire BEFORE the daemon had
finished serializing + transmitting the response, yielding a client
`TimeoutError` even though the daemon was still within its own
budget.

Fix: bump to 330_000ms (10% / 30s headroom over the daemon ceiling).
Comment updated to call out the race + the rationale for the
specific headroom value. Callers needing tighter caps still pass
their own `timeoutMs` to `restartMcpServer`.

#### Why folded into F1 vs separate follow-up PRs

These are post-merge findings on `#4282 PR 17` code, not F1-introduced
regressions. Normally we'd track as separate follow-up issues (mirror
of the #4325 / `channelInfo` decline). But:

- Both fixes are TINY (~25 LOC + ~2 LOC including comment); the bridge
  security fold-in commit `7bd66c6e8` set the precedent of folding in
  small same-branch issues when the cost-benefit favors closing them
  immediately.
- Same reviewer (wenshao via qwen-latest agent) — won't be confused
  by the scope expansion; in fact the original PR 17 commenter is
  also the one who'd review the follow-up issue's fix.
- Both fixes target `daemon_mode_b_main`-only paths (MCP restart route
  added by PR 17 lives on the integration branch).
- Saves opening 2 trivial follow-up issues that would just sit until
  someone picks them up.

#### Verification

- sdk-typescript: 424/424 tests pass (no test hardcoded the old
  300_000 default — only the constant declaration itself referenced it)
- cli acp-integration: 282/282 tests pass (no test exercised the
  exact whitespace-bearing disabled-tools scenario, so no test
  changes were strictly required; a regression test would belong in
  a separate test-coverage PR alongside the const.ts test gap from
  the #4297 unresolved-comment thread)
- typecheck clean across cli + sdk-typescript

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): wenshao review round 4 — 3 Suggestion fold-ins (#4319)

1. **bridge.ts:2270 stale line refs in `publishWorkspaceEvent` JSDoc**
   — comment said `permission_resolved at line 1717` (actual: line 682)
   and `broadcastWorkspaceEvent closure at ~line 2127` (actual: line
   1281). Line numbers drifted across the lift commits. Replaced both
   with function-name refs (`in resolvePending`, `declared above in
   this factory body`) that survive future edits.

2. **`ws.ts:613` opaque references in bridgeFileSystem.ts:20 +
   bridgeOptions.ts:267** — no `ws.ts` file exists in the repo; the
   ref came from an internal review thread on PR 18 that future
   readers can't locate. Replaced with a self-contained description
   ("post-PR-18 follow-up thread about BridgeClient's inline fs proxy
   bypassing WorkspaceFileSystem (originally raised in #4250 review)")
   plus a cross-reference to the FIXME(stage-1.5, chiga0 finding 4)
   already lifted into this package.

3. **bridge.ts:3503 duplicate `canonicalizeWorkspace` re-export** —
   `index.ts:11` already does `export * from './workspacePaths.js'`
   which exposes `canonicalizeWorkspace` through the package barrel.
   The bridge.ts re-export was a leftover from the lift that just
   duplicated the symbol at the barrel level (`bridge.ts` then re-
   exports it again via `index.ts`'s `export * from './bridge.js'`).
   Removed; `canonicalizeWorkspace` stays available via the package
   barrel + the `@qwen-code/acp-bridge/workspacePaths` subpath, which
   is what the cli shim already imports from.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(acp-bridge): wenshao round 5 — killChild deadline log + stale line-ref cleanup (#4319)

Folds in 1 of 3 wenshao Suggestions on F1 PR #4319 round 5; 2 declined
with tracking issues opened (#4329, #4330).

**Adopted:** `spawnChannel.ts:323` — `killChild` hard deadline now
emits a stderr warning before abandoning a stuck child. Pre-fix the
`setTimeout(KILL_HARD_DEADLINE_MS)` silently resolved the promise,
letting `bridge.shutdown()` claim graceful shutdown while a `qwen
--acp` zombie still held FDs / memory / locks. Under systemd/k8s
supervision this lets the daemon respawn race the orphan for the
same workspace. New warning is a single line on the daemon's stderr
(`qwen serve: killChild hard deadline (10000ms) reached; child
pid=... still alive (uninterruptible sleep?) — abandoning. Operator
should check for zombie qwen --acp processes...`) so monitoring/log
aggregators catch the zombie signal.

**Partial adopt:** `acpAgent.ts:1564` — replaced the
hard-coded `cli/src/config/config.ts:1426-1434` line-number cross-
reference (will drift when config.ts is edited) with a content-anchor
pointer ("search for `disabledTools` array population around the
`tools.disabled` settings read"). Same class of stale-line-ref
cleanup F1 already did across `bridge.ts` / `permission.ts` /
`bridgeClient.test.ts`.

**Declined** for F1 scope, both with tracking issues:

- `acpAgent.ts:1564` — extract a shared `normalizeDisabledToolList()`
  helper for the boot path + restart path so future enhancements
  (case-folding, Unicode normalization, plugin-name aliasing) only
  edit one site. Tracked as #4329.
- `DaemonClient.ts:112` — enforce SDK/server MCP-restart timeout
  coupling so a future bump on either side doesn't silently
  re-introduce the race that `b78de2719` fixed. Tracked as #4330
  (shared constant vs cross-package integration test vs startup
  assertion — three options enumerated).

Both extractions have real merit but are structural refactors that
sit outside F1's "mechanical lift + targeted security/doc fixes"
scope. Folding either would add new shared-utility / shared-package
plumbing the lift PR explicitly avoids.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(cli): extract normalizeDisabledToolList helper — fold-in for wenshao #4319 round 5 (closes #4329)

Folds in wenshao Suggestion from #4319 round 5 (originally declined as
out-of-scope, opened as #4329 for follow-up tracking). User pushed back
that the helper is small enough + same package as the duplicate sites,
so doing it inline rather than as a separate follow-up PR closes the
review thread completely.

## Change

New file `packages/cli/src/config/normalizeDisabledTools.ts`:

```typescript
export function normalizeDisabledToolList(raw: unknown): string[]
```

4-step normalization (`typeof string` filter + `.trim()` + drop empty +
dedupe preserving first-occurrence order). Non-array `raw` short-
circuits to `[]` so callers can pass arbitrary settings-shaped input
without `Array.isArray` boilerplate.

Replaces two byte-identical inline implementations:

- `packages/cli/src/config/config.ts:1426-1434` (bootstrap path) —
  was 9 lines of inline trim+dedupe loop.
- `packages/cli/src/acp-integration/acpAgent.ts:1571-1591` (MCP
  restart refresh path) — was 10 lines + an `Array.isArray` gate +
  20 lines of explanatory comment about why it had to mirror the
  bootstrap path.

Both call sites now just call `normalizeDisabledToolList(raw)`.

## Why it matters

`ToolRegistry.has(tool.name)` is an exact-string match. A hand-edited
`tools.disabled: ['  Foo  ', '', 'Foo']` settings entry must produce
`Set(['Foo'])` at boot AND after every `restartMcpServer` — otherwise
the boot-disabled tool gets silently re-registered after the next MCP
restart (the bug Codex P2 originally caught in `b78de2719`). Sharing
the helper makes future enhancements (Unicode normalization, plugin-
name aliasing, case-folding decisions) edit exactly one site.

## Tests

New `packages/cli/src/config/normalizeDisabledTools.test.ts` (16 tests)
covering:

- non-array short-circuit (undefined, null, object, number, string, bool)
- typeof-string filter (drops mid-array non-strings without aborting)
- trim + empty-skip (whitespace-only entries dropped)
- dedupe (exact match, whitespace variants collapse to first
  occurrence, case NOT folded)
- boot/restart parity scenarios (the BkwQW class the helper was
  written to prevent)
- order preservation across trim + dedupe

## Refs

- Closes #4329
- F1 PR #4319, originally tracked the helper extraction as deferred
  (commit `5f6b55e80` round 5 reply); now folded in here.
- Original duplicate introduction was `b78de2719` (Codex P2 fold-in
  for MCP restart normalization).

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
chiga0 added a commit that referenced this pull request May 27, 2026
* fix(serve): post-merge fixes for #4291 review (7 threads) (#4305)

* fix(serve): address qwen-latest review on merged #4291 (7 threads)

Seven post-merge findings from the qwen-latest review on #4291,
all real. Most are tightening fixes for issues introduced by the
earlier rounds of #4291 — the same security / DRY / observability
classes the original review surfaced, applied to surfaces that
weren't covered initially.

#1 (deviceFlow.ts:1179) — late-poll observer closure retained the
entire entry by reference (deviceCode/pkceVerifier BrandedSecrets +
cancelController) for the lifetime of the daemon if `provider.poll()`
never settled. Memory leak + indefinite secret retention. Destructure
the four fields the closure actually needs (deviceFlowId, providerId,
initiatorClientId, audit sink) so the entry is GC-eligible the
moment runPollTick returns.

#2 (server.ts) — `callerIsInitiator` was duplicated verbatim across
three locations: GET handler, toDeviceFlowStartResponseBody,
toDeviceFlowStateBody. The exact bug class #4291 was fixing was
"POST and GET diverged on the same redaction policy" — duplicating
the gate recreated the preconditions for divergence. Extracted to
shared `callerIsDeviceFlowInitiator(view, callerClientId)` helper
with the consolidated threat-model JSDoc. All three sites now call
the helper.

#3 (deviceFlow.ts:1110) — timeout callback constructed two separate
`DeviceFlowPollTimeoutError` instances (one for `signal.reason`, one
for the wrapper rejection). Each capture its own V8 stack trace,
and `signal.reason.stack` would diverge from the caught rejection's
stack — confusing for operators inspecting both. Build the sentinel
ONCE per timer fire and pass the same instance to both sites.

#4 (qwenDeviceFlowProvider.ts:273) — `Error.name` is a freely
assignable string property; a hostile fetch wrapper could set
`e.name = 'X\n[serve] FAKE LINE\x1b[31m'` to inject log lines or
ANSI sequences via the same vector we already closed for `oauthError`.
The non-OAuth catch path interpolated `${err.name}` raw. Apply the
same `sanitizeForStderr()` helper.

#5 (deviceFlow.ts:1551) — on the timeout path, `rawProviderError`
is undefined (deliberately, to skip the misleading
`provider.poll() threw (raw): ...` audit template), but that left
the audit hint field omitted entirely. Operators reading the
durable audit trail saw `errorKind: 'upstream_error'` with no signal
whether it was a hung IdP or a generic provider failure. Use
`result.hint` (which already carries the timeout-specific
`provider.poll() timed out after Nms; check IdP connectivity` text
built in the catch) so the audit matches the SSE event.

#6 (server.ts) — the `QWEN_SERVE_DEBUG` env-var check was inlined
in the GET route handler, duplicating the `isServeDebugMode()`
helper from `./debugMode.js` that workspaceAgents and
workspaceMemory already use. The inline copy also had a dead `?? ''`
fallback (the value is guaranteed truthy at that point per the
preceding check). Use the canonical helper.

#7 (deviceFlow.ts:1217) — late-rejection observer interpolated the
raw `lateErr.message` into the audit hint (truncated to 256 bytes,
but RFC 8628 `device_code` values fit comfortably in 256 bytes).
The provider's catch already uses the `name + length` redaction
pattern to prevent WAF-echoed `device_code`/PKCE leaks; the
registry layer was undoing that hardening because the same failure
settled late. Apply the same `name + length` pattern at the late-
rejection site.

Tests:
- Existing late-rejection test reseeded with a `device-code-secret-*`
  substring inside the long detail; hard-negative-asserts the seeded
  secret is absent from the audit + asserts the new
  `Error (message N bytes; raw suppressed)` shape.
- Existing poll-timeout test now also asserts: hint IS defined on
  the audit (not omitted), hint contains `'timed out after'` /
  `'check IdP connectivity'`, and `signal.reason instanceof
  DeviceFlowPollTimeoutError` (proves the single sentinel is
  shared between abort and reject).
- New `sanitizes control characters in attacker-controlled
  err.name` test in qwenDeviceFlowProvider.test.ts pins the round-4
  #4 fix with a hostile `e.name` containing `\n` + `\x1b[31m...`.

cli serve 702/702 (was 686, +16 — additional tests imported via
the acp-bridge package lift on main); sdk 421/421; typecheck clean
across all 4 workspaces; eslint --max-warnings 0 clean on touched
files.

Refs: #4175, #4255, #4291

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): address deepseek-v4-pro review on #4305 (4 threads)

Round-5 fold-in. Four findings from the deepseek-v4-pro review on
PR #4305 — all real, three are sister fixes for the same security
classes that #4305 already closed at adjacent surfaces.

#1 (deviceFlow.ts) — `pollTimedOut` race correctness. The flag was
set unconditionally inside the timer callback. If the provider
settled the wrapper at 29.9s, `finally` would call
`clearScheduled(pollTimer)` — but if the timer callback was already
queued for execution before the clear landed (a real possibility
in Node's event-loop ordering, even if not always observed in
practice), this branch could still run and incorrectly mark
`pollTimedOut`. Move the flag assignment to the catch block where
the settled cause is unambiguous via `instanceof
DeviceFlowPollTimeoutError`. New test pins the negative: provider
beats the timeout → no spurious `lost_late_poll_after_timeout`
audit even after ticking 2× the ceiling.

#2 (deviceFlow.ts) — late-rejection observer interpolated raw
`lateErr.name` into the audit hint without sanitization. Same
attacker-controlled vector closed at the provider layer for
`err.name` in round-4. Route through `sanitizeForStderr`.

#3 (deviceFlow.ts) — late-success observer interpolated
`latePollResult.kind` directly into the audit template. While the
typed shape is `'pending' | 'slow_down' | 'success' | 'error'`, a
non-conforming provider could return an arbitrary string. Same
log-injection vector. Route through `sanitizeForStderr`.

#4 (qwenDeviceFlowProvider.ts → deviceFlow.ts) —
`sanitizeForStderr` only stripped ASCII C0/C1 + DEL; bypass via
Unicode lookalikes:
  - U+2028/U+2029: LINE/PARAGRAPH SEPARATOR (newline-equivalent in
    most Unicode-aware terminals — most direct log-forging vector)
  - U+200B–U+200F: zero-width chars + LRM/RLM
  - U+202A–U+202E: bidirectional override controls
  - U+FEFF: BOM / ZWNBSP

A malicious IdP returning `slow_down
[serve] FAKE` in
`oauthError` would otherwise still forge log lines.

Architectural change: `sanitizeForStderr` was previously private to
`qwenDeviceFlowProvider.ts`. To address #2/#3, the registry layer
needs to call it too. Lifted into `deviceFlow.ts` (the foundation
module) and re-imported from the provider. Single source of truth;
the regex is now a module-level constant compiled once with explicit
`\uXXXX` escapes (via `String.raw` so the source is greppable, not
literal-Unicode-laden).

Tests:
- `does NOT attach late-poll observer when the provider beats the
  timeout` — N1 race regression
- `sanitizes hostile latePollResult.kind in late-observer audit` — N3
- `sanitizes hostile lateErr.name in late-rejection observer audit` — N2
- `sanitizes Unicode lookalike controls (U+2028 LINE SEPARATOR,
  bidi, ZWNBSP) in oauthError` — N4

cli serve 706/706 (was 702, +4 — all new round-5 tests); sdk
421/421; typecheck clean; eslint --max-warnings 0 clean on touched
files.

Refs: #4175, #4255, #4291, #4305

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): address gpt-5.5 + qwen-latest review on #4305 round-5 (5 threads)

Round-6 fold-in. Five findings split between maintainability,
security hardening, and a real defensive bug.

#1 (qwenDeviceFlowProvider.test.ts) — gpt-5.5: round-5 #4 test
embedded U+2028 / U+200E / U+FEFF as literal characters in source.
Invisible in GitHub diffs / most editors; the negative
`not.toContain('')` looked like an empty-string check. Rewrote
the payload + assertions to use named `\uXXXX`-bound constants.
Also added a companion test exercising U+2066–U+2069 (round-6 #5
below).

#2 (deviceFlow.ts) — qwen-latest: the late-poll observer's
`void tracked.then(...)` was missing a terminal `.catch(() => {})`.
A synchronous throw inside either handler (e.g., a misbehaving
`audit.record`: backpressure, malformed payload, sink out-of-disk)
would reject the derived promise unhandled. On Node 22's default
`--unhandled-rejections=throw`, that crashes the daemon. Added the
terminal `.catch(() => {})` matching the persist-tracker pattern.
New test injects a poison audit sink that throws specifically on
the `lost_late_poll_after_timeout` call; asserts `flushAsync()`
resolves cleanly.

#3 (deviceFlow.ts) — qwen-latest: the `case 'error'` audit-record
hint interpolated `rawProviderError` (raw `err.message`) without
`sanitizeForStderr`. Per ES2019+ `JSON.stringify` no longer escapes
U+2028/U+2029 — those would still forge log lines downstream
through file/stdout audit sinks. Apply the same sanitizer used on
every other provider-controlled audit path. New test pins a hostile
provider message containing U+2028 + ANSI escape and asserts
neither survives.

#4 (deviceFlow.ts) — qwen-latest: the round-5 #1 comment claimed
"`DeviceFlowPollTimeoutError` isn't exported as a public DeviceFlow
contract", but it IS `export class` (the test file constructs it
directly for fixtures). With `pollTimedOut = true` keyed solely on
`instanceof`, a future provider that imports + throws the class
would spoof the registry's "I caused the timeout" signal —
attaching a phantom late-poll observer.

Fix: introduce a runtime brand `_isRegistryTimeout: boolean` on the
class (default `false`) plus an internal-only
`makeRegistryPollTimeoutError(ms)` helper that sets the brand to
`true`. The brand is set ONLY at the registry's race-timer
construction site. Both gates updated:
  - `if (err instanceof X && err._isRegistryTimeout === true)` in
    the catch (for `pollTimedOut`)
  - `if (lateErr instanceof X && lateErr._isRegistryTimeout === true)`
    in the late-rejection self-filter

A provider-thrown brand-false instance now flows through the
generic provider-throw audit path — correctly auditing the misuse
rather than silently swallowing it. Repurposed the original "no
double-audit when registry's own DeviceFlowPollTimeoutError is
late-rejected" test (which was actually exercising the brand-false
path) into the inverted assertion: brand-false provider throw IS
audited as a real failure. Removed the orphaned old assertion; the
brand-true happy path is implicitly covered by the hanging-provider
test (which exercises the registry-built timeout end-to-end).

#5 (deviceFlow.ts) — qwen-latest: `sanitizeForStderr` regex covered
U+202A–U+202E (bidi embedding/override) but missed U+2066–U+2069
(LRI/RLI/FSI/PDI). These are the primary CVE-2021-42574
("Trojan Source") attack vectors — a hostile IdP swapping U+2066
for U+202D achieves the same visual reordering and would have
bypassed the round-5 filter entirely. Extended the regex range and
JSDoc; new test exercises U+2066/U+2068/U+2069 in `oauthError` and
asserts none survive while substantive ASCII parts remain.

cli serve 713/713 (was 710, +3 round-6 tests + the round-5 #4
rewrite + the round-6 #5 companion); typecheck clean across all 4
workspaces; eslint --max-warnings 0 clean on touched files.

Refs: #4175, #4255, #4291, #4305

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): replace literal U+2028 with explicit 
 escape in round-6 #3 test

PR #4312 review (Copilot): the round-6 #3 test (sanitizes
rawProviderError) regressed back to embedding a literal U+2028
character in source via `const U_2028 = ' '`. That's the same
maintainability anti-pattern round-6 #1 was fixing in the sister
test. Internal-consistency fix: switch to the explicit `
`
escape so the constant is greppable and reviewable in GitHub diffs.

Refs: #4291, #4305, #4312

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): post-merge P2 corrections from Codex review on #4282 (#4297)

* fix(serve): post-merge P2 corrections from Codex review on #4282

Follow-up to PR #4282 (Wave 4 PR 17) addressing four P2 issues
flagged by Codex's `/review` after the squash-merge to main:

P2-1 — Read the workspace context filename for init
  `qwen serve` parent never goes through `loadCliConfig`, so the
  process-global `getCurrentGeminiMdFilename()` stays on the default
  `QWEN.md` even when the workspace configures
  `context.fileName: 'AGENTS.md'`. `runQwenServe` now snapshots the
  workspace's merged setting at boot and forwards via
  `BridgeOptions.contextFilename`, so init writes the same file the
  ACP child reads.

P2-2 — Restart MCP servers with a fresh disabledTools snapshot
  `Config.disabledTools` was frozen at construction time;
  `setWorkspaceToolEnabled` only updated settings.json. The
  documented "toggle + restart" workflow re-registered just-disabled
  tools because rediscovery still saw the bootstrap snapshot. Added
  `Config.setDisabledTools()` plus a re-read at the ACP restart
  handler so `discoverMcpToolsForServer` honors the latest set.

P2-3 — Match the SDK timeout to the daemon's restart budget
  Bridge waits up to 300s for stdio MCP discovery; SDK helper used
  the client-wide 30s default and aborted valid slow restarts.
  Added a per-call `timeoutMs` plumbed through `fetchWithTimeout`,
  defaulting `restartMcpServer` to 5 minutes.

P2-4 — Reject symlinked parent directories before init writes
  `lstat(target)` only checked the final component; a symlinked
  parent (e.g. `docs -> /tmp` with `context.fileName:
  'docs/QWEN.md'`) would let `writeFile` follow the link and create
  / truncate outside `boundWorkspace`. Added
  `canonicalizeExistingAncestor` (walks up through ENOENT to the
  deepest extant ancestor, then `realpath`s) and verifies the
  canonical parent stays within the canonical workspace.

5 new tests (4 bridge / 2 SDK):
- contextFilename snapshot honored
- parent-symlink escape rejected
- nested real subdir accepted
- restartMcpServer survives 1.2s response with 1s default timeout
- restartMcpServer honors a 50ms caller override

Typecheck clean across cli / sdk-typescript / core.
1604/1604 unit tests pass.

* fix(serve): fold-in 1 — address 16:32:44-round review on #4282

Follow-up addressing the 8 unresolved review threads opened on PR
shipping in this same #4297; addresses correctness gaps + missing
test coverage that would otherwise let regressions ride into main.

Behavior fix:
- broadcastWorkspaceEvent gains a `skipSessionId` parameter; when
  `setSessionApprovalMode` runs with `persist:true`, the broadcast
  skips the requesting session so it doesn't receive the same
  `approval_mode_changed` event twice (once via session-scoped
  publish + once via broadcast). The SDK reducer's
  `approvalModeChangedCount` now increments by 1, not 2, on the
  requesting client (peers still see 1 via the broadcast).
  Addresses #3260501134.

Observability + posture:
- broadcastWorkspaceEvent now mirrors PR 16's publishWorkspaceEvent
  member: per-entry success/failure accounting + an "ALL buses
  dropped" stderr elevation. The previous local helper silently
  swallowed every publish failure. Addresses #3260501126.
- WorkspaceInitPathEscapeError + WorkspaceInitSymlinkError typed
  classes for the two boundary guards in initWorkspace, mapped to
  HTTP 400 by sendBridgeError. Previous generic `Error` fell
  through to the 500 handler, telling operators "daemon broken"
  when the actual fix was workspace-config correction. Addresses
  #3260501161.

Public surface symmetry:
- Re-export McpServerNotFoundError, McpServerRestartFailedError,
  WorkspaceInitPathEscapeError, WorkspaceInitSymlinkError from the
  serve barrel. External embeds matching these via `instanceof`
  no longer need deep imports. Addresses #3260501163.

Test coverage:
- restartMcpServer bridge tests (5): success + event broadcast,
  soft-skip + refused event, McpServerNotFoundError translation,
  McpServerRestartFailedError translation, originator clientId
  stamping. Addresses #3260501141.
- sendBridgeError mapping tests (4): McpServerNotFoundError → 404,
  McpServerRestartFailedError → 502, WorkspaceInitPathEscapeError
  → 400, WorkspaceInitSymlinkError → 400. Addresses #3260501148.
- initWorkspace boundary guard tests (2 added): symlink-at-target
  rejected, contextFilename '../outside.md' rejected. Addresses
  #3260501157.
- TrustGateError tests assert the typed class via `.toThrow(TrustGateError)`,
  not just message text. Addresses #3260501165.

Also updates the existing fold-in 4 S2 broadcast test to reflect
the new no-duplicate semantics on the requesting session.

Typecheck clean across cli / sdk-typescript / core.
1615/1615 unit tests pass.

* fix(serve): fold-in 2 — copilot + wenshao review on #4297

Round-2 reviewer adoption on the same PR:

Critical fixes:
- `restartMcpServer` JSDoc documents `timeoutMs: 0` as "disable the
  timeout entirely", but the `> 0` guard in `fetchWithTimeout`
  rejected `0` and silently fell back to the 30s client default.
  Loosened the guard to `>= 0` so `0` flows through to the
  no-timeout branch via the existing truthiness check; NaN /
  negative inputs still coerce to the client default. Addresses
  duplicate reports from copilot (#3260577538) and wenshao
  (#3260661833).
- TS2322 in the slow-fetch test stub: `resolveResponse` was typed
  against `import('undici-types').Response` but assigned a
  `(v: Response) => void`. Re-typed against the global `Response`
  throughout. Caught only by tsc runs that include the test
  files. Addresses #3260663072.

Test fidelity:
- Slow-fetch stub now observes `init.signal` and rejects on abort,
  so a regression that drops the per-call `timeoutMs` override
  will reliably fail the test instead of resolving after the
  timer fired (false-negative coverage). Addresses #3260577600.
- New test pinning the `timeoutMs: 0` semantics: 1ms client
  default + a stub that resolves after 50ms. Without the `>= 0`
  fix, the call would abort at 1ms; with it, the explicit
  `0` disables the timer and the call completes.

Bug fixes:
- `runQwenServe.contextFilenameForInit` previously called
  `String(arr[0])` on the array branch, producing a literal
  `"[object Object]"` filename for hand-edited bad data. Now
  validates each element with `typeof === 'string'` and falls
  back to `undefined` (so the bridge uses its
  `getCurrentGeminiMdFilename()` default) when no string is
  found. Addresses #3260577641.

Documentation drift:
- `Config.getDisabledTools()` JSDoc rewritten to describe the
  mutable-via-`setDisabledTools()` semantics introduced by P2-2,
  and the "registration-time only / no retroactive unregister"
  contract that pairs with it. Old comment claimed the set was
  frozen at construction. Addresses #3260577677.

Observability:
- `acpAgent` MCP-restart `loadSettings` failure now surfaces a
  stderr line naming the server + the underlying error, instead
  of silently swallowing it. The documented "toggle + restart"
  workflow used to break with zero diagnostic when settings.json
  was corrupted or unreadable. Addresses #3260663303.

Code organization:
- Moved `canonicalizeExistingAncestor` after `describeStatKind` so
  the latter's JSDoc is no longer orphaned (TypeScript only
  associates the last `/** ... */` block before a declaration).
  Addresses #3260668618.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.

* fix(serve): fold-in 3 — read merged scope on MCP restart refresh

Critical bug from wenshao review (#3260725526) on PR #4297:
the P2-2 acpAgent re-read narrowed `Config.disabledTools` to
`SettingScope.Workspace` alone, dropping User / System scope
entries. The bootstrap Config received `merged.tools?.disabled`
(union of all scopes), so user-level / system-level disables
worked at boot — but the first `mcp restart` would replace the
in-memory set with the workspace scope alone, silently re-enabling
any tool that was disabled at a higher scope but absent from the
workspace file.

The asymmetry vs. the persist-write path is deliberate and
documented:
- Reads (here): merged — match the bootstrap Config snapshot,
  preserve user/system policy.
- Writes (`runQwenServe.persistDisabledTools`): workspace scope —
  don't bake higher-scope entries into the workspace file
  (per-#4282 fold-in 1 H2 fix).

Two paths look alike but answer different questions.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.

* fix(test): fold-in 4 — wire timeoutMs:0 stub to init.signal

Critical follow-up from wenshao (#3260810242) on PR #4297:
the new `timeoutMs: 0` regression test (added in fold-in 2)
inherited the same flaw it was meant to prevent — the slow-fetch
stub didn't observe `init.signal`, so a regression that ignored
the `0` override would fire the AbortController at the 1ms client
default but the stub would keep the promise pending. The 50ms
`resolveResponse` would win, the test would still pass, and the
documented "0 disables timeout" contract would be unprotected.

Mirrored the listener pattern already used by the two sibling
tests in fold-in 2 — `init.signal.addEventListener('abort', () =>
reject(...))`. Now a regression that re-rejects `0` triggers the
abort, the stub rejects, the test fails.

8/8 restartMcpServer SDK tests pass; SDK typecheck clean.

* fix(serve): fold-in 5 — TOCTOU + setDisabledTools coverage

Two new critical reviews from wenshao on PR #4297:

C1 — TOCTOU between lstat and writeFile (#3260836305):
The `lstat(target)` symlink check and the subsequent `writeFile`
were two separate syscalls, leaving a race window where a local
attacker with workspace write access could substitute a symlink
between them. With `force: true`, `writeFile` would follow the
link and truncate an external target.

The `action === 'created'` path now uses `fs.open(target, 'wx')`
(O_WRONLY|O_CREAT|O_EXCL), which atomically refuses any
pre-existing inode (regular file, dir, OR symlink) at the target
path. EEXIST after the absence check most plausibly means a
race-created symlink, so we throw `WorkspaceInitSymlinkError(kind:
'target')` — same typed class the route maps to 400.

The `force: true` overwrite path retains the existing TOCTOU as a
documented limitation; closing it requires `O_NOFOLLOW`-aware open
which the post-PR18 `WorkspaceFileSystem` migration will provide.

C2 — P2-2 zero test coverage (#3260836302):
The `setDisabledTools` runtime sync was the only Wave-4 P2 fix
without a dedicated test. Added 5 Config-level tests:
- Initializes from `disabledTools` ConfigParameters
- Defaults to empty set when omitted
- `setDisabledTools` replaces the live snapshot
- Defensive copy: caller-set mutations don't leak into the live snapshot
- Accepts an empty set (clears live snapshot)

Plus a TOCTOU regression test in httpAcpBridge.test.ts that
spies fs.lstat / fs.readFile to simulate the race window:
pre-creates a symlink, makes lstat lie about it, asserts the
'wx' open catches the racing inode and throws the typed
`WorkspaceInitSymlinkError(kind: 'target')`.

1622/1622 unit tests pass; typecheck clean across cli /
sdk-typescript / core.

* fix(serve): fold-in 6 — count actual skips in broadcast alarm

DeepSeek review on #4297 (#3261079572):
`broadcastWorkspaceEvent` unconditionally subtracted 1 from the
`eligible` recipient count whenever `skipSessionId` was set, even
when the id matched zero live sessions (caller mistake, stale id,
or the matching session was just torn down between resolution and
broadcast). In a single-session workspace that's the difference
between `eligible = 0` (alarm suppressed) and `eligible = 1`
(alarm fires when the publish failed) — silently losing the
all-dropped breadcrumb the telemetry was meant to surface.

Today's call sites pass real session ids so the bug doesn't
manifest in practice, but the defensive shape is small: track
`skippedCount` inside the loop and subtract that, so the alarm
condition is self-consistent regardless of how the caller mis-uses
the param.

162/162 bridge tests pass; CLI typecheck clean.

* fix(serve): fold-in 7 — close overwrite TOCTOU, harden boot + diagnostics

Round-7 review on PR #4297. Three critical fixes + one suggestion
test, plus a regression test for the overwrite TOCTOU close.

C1 — force:true overwrite TOCTOU (#3262615446):
The fold-in 5 fix only closed the `'created'` action via 'wx';
the `'overwrote'` branch still used plain `fs.writeFile`, so a
local writer could swap the verified regular file to a symlink
between the lstat/readFile checks and the write and have the
forced overwrite truncate an external target. Switched to
`fs.open(target, O_WRONLY | O_TRUNC | O_NOFOLLOW)` — `O_NOFOLLOW`
makes open() fail with ELOOP on a symlink at the final component
even under race. ELOOP / ENOENT (race-deleted) translate to
`WorkspaceInitSymlinkError(kind: 'target')` so the route still
maps to a structured 400 instead of a generic 500.

C2 — settings.json corrupt blocks daemon boot (#3262625091):
`loadSettings(boundWorkspace)` at boot had no try/catch — a
corrupted, malformed, or temporarily unreadable settings file
threw synchronously and prevented daemon startup. Pre-PR this
never happened because settings were read lazily inside request
handlers. Wrapped in try/catch with stderr fallback so the daemon
keeps booting (with the bridge's default context filename) when
the file is broken.

C3 — malformed `tools.disabled` clears policy silently (#3262625101):
When `merged.tools?.disabled` is present but not an array
(boolean / string / object from a hand-edited settings.json), the
ternary `Array.isArray(...) ? ... : []` substituted an empty list
without firing the surrounding catch block. After an MCP restart
every disabled tool would silently re-register. Added an explicit
`!Array.isArray && !== undefined` check that stderr-logs the
malformed type before clearing — operators see the
misconfiguration instead of a stealth re-enable.

S1 — contextFilename extraction tested (#3262690842):
Lifted the inline `firstStringInArray` + branching into an
exported `extractContextFilename(value: unknown)` helper and
added `runQwenServe.test.ts` with 5 tests covering the four
branches the suggestion called out: non-empty string, array with
strings, array with no strings, non-string non-array.

Plus a TOCTOU regression test for the overwrite path that
verifies `O_NOFOLLOW` returns `WorkspaceInitSymlinkError(kind:
'target')` when the file is race-substituted with a symlink
behind the lstat/readFile mocks.

S2 (acpAgent restart-handler integration test #3262690845) is
deferred — Config-level coverage of `setDisabledTools` already
locks the load-bearing surface (5 tests in fold-in 5), and
adding a full acpAgent integration test requires heavy ext-method
plumbing. The new C3 stderr diagnostic plus existing tests give
us the regression signal we need without that scaffolding.

1627/1627 unit tests pass; typecheck clean across cli /
sdk-typescript / core / acp-bridge.

* fix(serve): fold-in 8 — split ELOOP / ENOENT diagnostic in overwrite path

qwen-latest review on PR #4297 (#3262861754):
The fold-in 7 ELOOP/ENOENT branch shared one error message that
said "swapped to a symlink." That's accurate for ELOOP (genuine
O_NOFOLLOW rejection — likely an attack race) but misleading for
ENOENT in the overwrite path: there `readFile` just succeeded
proving the file existed, so ENOENT means the file was DELETED
between the content check and the open — a benign race with a
concurrent writer (git checkout, editor save, lockfile rename),
NOT a symlink swap. An operator seeing the symlink language for
a benign delete would `ls -la`, see no symlink, and waste time
hunting an attack that didn't happen.

Split into two messages:
- ELOOP: "swapped to a symlink between the content check and the
  overwrite — refusing to follow it"
- ENOENT: "deleted between the content check and the overwrite
  (likely a concurrent writer) — refusing to recreate blindly"

Both still surface as `WorkspaceInitSymlinkError(kind: 'target')`
so the route maps to a structured 400; the class doubles as the
workspace-init race-condition bucket with kind='target' meaning
"target inode misbehaved at write time" generally.

Updated the existing fold-in 7 TOCTOU test to assert the ELOOP
message specifically, and added a new ENOENT race-delete test
that mocks lstat/readFile to land on the overwrote action against
a non-existent path — verifies the message says "deleted" and
NOT "swapped to a symlink."

170/170 bridge tests pass; CLI typecheck clean.

* fix(serve): fold-in 9 — route MCP restart through registry cleanup wrapper

gpt-5.5 critical review on PR #4297 (#3263088414):

The fold-in 5 P2-2 fix refreshed `Config.disabledTools` from merged
settings, but then called `manager.discoverMcpToolsForServer()`
directly — bypassing the `ToolRegistry.discoverToolsForServer`
wrapper that PURGES the server's existing `DiscoveredMCPTool`
entries (and `revealedDeferred` markers) plus its prompts before
rediscovery. Without the cleanup, `registerTool` only consulted
the refreshed `disabledTools` set for NEWLY-discovered tools —
entries already in the registry from the prior MCP boot kept
serving requests. Net effect: toggle-disable-then-restart
silently left the disabled tool live, breaking the documented
"toggle + restart" workflow that P2-2 was meant to fix.

Routed through `toolRegistry.discoverToolsForServer(serverName)`
which:
1. Removes existing `DiscoveredMCPTool` entries for this server
2. Drops their `revealedDeferred` reveal state
3. Removes the server's prompts via `removePromptsByServer`
4. THEN delegates to `manager.discoverMcpToolsForServer` for the
   actual reconnect + rediscover

The pre-discovery budget / in-flight checks still go through the
`manager` reference (which is the same object the registry
wrapper would forward to) — so soft-skip semantics for
`budget_would_exceed`, `in_flight`, `disabled` are preserved.

CLI typecheck clean; 403/403 server + bridge tests pass.

* fix(serve): fold-in 10 — qwen-latest 05:45-round review on #4297

5 review threads from qwen-latest's late round on PR #4297 (now closed
in favor of #4313 against `daemon_mode_b_main`). 1 critical + 4
suggestions, all adopted.

C1 — extractContextFilename / getCurrentGeminiMdFilename divergence
(#3263954685): with `context.fileName: ['  ', 'AGENTS.md']`, the
daemon parent's `extractContextFilename` (which skips empty entries)
wrote `AGENTS.md`, but the ACP child's `getCurrentGeminiMdFilename`
(which returned `arr[0]` unconditionally) read `''`. The init'd file
was orphaned. Aligned `getCurrentGeminiMdFilename` to skip empty
entries with the same semantics, falling back to
`DEFAULT_CONTEXT_FILENAME` when all entries are empty.

S2 — WorkspaceInitSymlinkError reused for non-symlink races
(#3263954690): the EEXIST race-create and ENOENT race-delete cases
were surfacing as `code: 'workspace_init_symlink'`, misleading
operators into hunting symlink attacks for benign concurrent-
modification windows. Split into a sibling `WorkspaceInitRaceError`
class (`kind: 'eexist' | 'enoent'`, HTTP code
`workspace_init_race`). The genuine symlink class stays for ELOOP,
lstat-detected target symlinks, and parent-realpath escapes.

S3 — fsConstants.O_NOFOLLOW defensive `?? 0` (#3263954697): matches
the existing codebase convention in
`core/src/utils/{sessionStorageUtils,gitDiff}.ts` and
`cli/src/ui/utils/customBanner.ts`. Functionally a no-op (JS
bitwise coerces undefined to 0) but consistent.

S5 — Parent-directory TOCTOU still open (#3263954707): O_NOFOLLOW
only protects the final path component; a local writer could swap
a real parent dir for a symlink between
`canonicalizeExistingAncestor` and `fs.open`. Added
`verifyParentWithinWorkspace` post-open helper that re-realpaths
`path.dirname(target)` and refuses with
`WorkspaceInitSymlinkError(kind: 'parent')` if the parent moved.
On the create path (where we just opened with `'wx'`), the failure
also unlinks the file we just made best-effort. Residual race
window narrowed from "between pre-check and open" to "between
post-open realpath and writeFile" — sub-millisecond, documented as
accepted Stage-1 trust posture.

S4 — broadcastWorkspaceEvent vs publishWorkspaceEvent stale comment
(#3263954688): the "now removed" comment was inaccurate (5 call
sites still use the closure). Replaced with an accurate
description of why both coexist (factory closure can't `this`-call
proxy member; closure also takes `skipSessionId` for persisted
approval-mode mirror) and a TODO marker for future helper extraction.

Two existing tests updated to assert the new `WorkspaceInitRaceError`
class for EEXIST / ENOENT scenarios (the symlink-class assertions
are preserved for ELOOP / lstat / parent cases).

1759/1759 unit tests pass; typecheck clean across all 4 packages.

* feat(acp-bridge): F1 — acp-bridge package self-sufficiency (#4175 mechanical lift + BridgeFileSystem seam) (#4319)

* refactor(acp-bridge): lift defaultSpawnChannelFactory to acp-bridge/spawnChannel (#4175 F1 step 1)

First mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves the production spawn factory + its `killChild` helper +
`SCRUBBED_CHILD_ENV_KEYS` denylist + `KILL_HARD_DEADLINE_MS` constant
from `cli/src/serve/httpAcpBridge.ts` (~283 lines) to
`@qwen-code/acp-bridge/spawnChannel`. This unblocks
`channels/base/AcpBridge.ts` and `vscode-ide-companion`'s
acpConnection from each reimplementing the child lifecycle — they can
now consume the same primitive.

Backward compatible: `cli/src/serve/httpAcpBridge.ts` imports the
lifted factory and re-exports it, so existing references in
`cli/src/serve/index.ts:90` and the factory's own internal usage
(`opts.channelFactory ?? defaultSpawnChannelFactory`) keep resolving.
Bridge tests that mock `defaultSpawnChannelFactory` via
`BridgeOptions.channelFactory` are unaffected.

Side cleanups: drops `spawn` / `ChildProcess` / `Readable` / `Writable`
/ `ndJsonStream` / `MissingCliEntryError` imports from
httpAcpBridge.ts (all only used by the lifted spawn factory).

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift BridgeClient + permission types to acp-bridge/bridgeClient (#4175 F1 step 2)

Second mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves `BridgeClient` class (~700 LOC) + `PendingPermission` interface +
`PermissionResolutionRecord` interface + `MAX_RESOLVED_PERMISSION_RECORDS`
constant + early-event capacity constants + `describeStatKind` and
`sliceLineRange` helpers from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridgeClient`.

Design choice for SessionEntry boundary: introduce a minimal
`BridgeClientSessionEntry` interface in bridgeClient.ts with only the
four fields BridgeClient actually reads from the factory's richer
`SessionEntry` (`sessionId`, `events`, `pendingPermissionIds`,
`activePromptOriginatorClientId`). The factory's `SessionEntry`
structurally satisfies it — TypeScript's structural typing enforces
the match at the `resolveEntry` callback signature, so no explicit
conversion is required and the bridge package stays free of daemon-host
session-bookkeeping types.

Cross-package writeStderrLine handling: inline the 3-line helper in
bridgeClient.ts (mirrors the spawnChannel.ts pattern from F1 step 1)
so acp-bridge has no reverse dependency on `cli/src/utils/stdioHelpers`.

httpAcpBridge.ts shrinks from 4406 LOC to 3647 LOC (-759 lines).
Removed ACP SDK imports that only BridgeClient consumed: `Client`,
`RequestPermissionRequest`, `WriteTextFileRequest`,
`WriteTextFileResponse`, `ReadTextFileRequest`, `ReadTextFileResponse`,
`SessionNotification`. Kept the ones the factory still uses
(`CancelNotification`, `PromptRequest`, `RequestPermissionResponse`,
`SetSessionModelRequest`, `SetSessionModelResponse`).

Backward compatible: httpAcpBridge.ts re-exports `BridgeClient`,
`BridgeClientSessionEntry`, `PendingPermission`,
`PermissionResolutionRecord`, and `MAX_RESOLVED_PERMISSION_RECORDS` so
the `ChannelInfo.client: BridgeClient` field declaration below + any
embedder reaching into these types keep resolving.

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- 229/229 cli server tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift createHttpAcpBridge factory to acp-bridge/bridge (#4175 F1 step 3)

Third + final mechanical lift of #4175 F1 (acp-bridge package
self-sufficiency). Moves the `createHttpAcpBridge` factory closure
(~3000 LOC) + `ChannelInfo` + `SessionEntry` interfaces + factory-only
helpers (`canonicalizeExistingAncestor`, `verifyParentWithinWorkspace`,
`withTimeout`, `isServeDebugLoggingEnabled`, `writeServeDebugLine`,
`hasControlCharacter`) + factory constants (`DEFAULT_INIT_TIMEOUT_MS`,
`MCP_RESTART_TIMEOUT_MS`, `DEFAULT_MAX_SESSIONS`, `MAX_EVENT_RING_SIZE`,
`DEFAULT_PERMISSION_TIMEOUT_MS`, `DEFAULT_MAX_PENDING_PER_SESSION`,
`MAX_DISPLAY_NAME_LENGTH`) from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridge`.

`cli/src/serve/httpAcpBridge.ts` shrinks from 3647 LOC to 97 LOC — a
pure re-export shim that preserves every existing relative import
path (`./httpAcpBridge.js`) so `server.ts`, `runQwenServe.ts`,
`workspaceAgents.ts`, `workspaceMemory.ts`, `index.ts`, plus the bridge
test suite, keep resolving without any call-site changes.

The new `bridge.ts` reuses what was already in acp-bridge (errors,
types, options, status helpers, channel types, event bus, workspace
paths) via local relative imports — no reverse dependency on `cli`.
`writeStderrLine` is inlined at the top of `bridge.ts` (same pattern as
`spawnChannel.ts` + `bridgeClient.ts` from F1 steps 1-2) so the
package self-contained promise holds.

Cumulative F1 impact across the 3 mechanical lift steps:
- httpAcpBridge.ts: 4682 LOC → 97 LOC (-4585 lines; the original file
  was 98% bridge core, 2% backward-compat re-exports)
- 3 new files in acp-bridge: spawnChannel.ts (~270 LOC), bridgeClient.ts
  (~745 LOC), bridge.ts (~3515 LOC)
- All daemon-host concerns (env snapshot, daemon preflight cells)
  remain in `cli/src/serve/daemonStatusProvider.ts` and reach the
  bridge through the `BridgeOptions.statusProvider` seam frozen by
  PR 22b/2.

- 735/735 cli serve tests pass across 17 files
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- typecheck clean across acp-bridge + cli

`packages/cli/src/serve/httpAcpBridge.test.ts` (~6600 LOC) is
intentionally NOT moved in this commit — it currently imports
`createHttpAcpBridge` / `defaultSpawnChannelFactory` / `BridgeClient`
via the cli shim and keeps passing without changes. Moving it to
`acp-bridge/src/bridge.test.ts` is a follow-up worth tracking
separately so the production-code lift can land + be reviewed cleanly.

The `BridgeFileSystem` injection seam (originally bundled into F1 as
the 22b' scope) is also deferred to a follow-up so the mechanical lift
stays mechanical — design + implementation of the fs injection is its
own discussion.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* feat(acp-bridge): add BridgeFileSystem injection seam (#4175 F1 step 5, 22b' scope)

Adds the `BridgeFileSystem` injection seam originally scoped as #4175
22b'. When a `BridgeFileSystem` is wired through
`BridgeOptions.fileSystem`, `BridgeClient.readTextFile` and
`BridgeClient.writeTextFile` delegate to it instead of running their
inline `fs.realpath` / `fs.writeFile` / `fs.readFile` proxy.

This unblocks production `qwen serve` plumbing PR 18's
`WorkspaceFileSystem` (TOCTOU guards, symlink-substitution checks,
trust gate, `.gitignore`, audit hooks) into the ACP fs methods —
closing the `ws.ts:613` follow-up thread that has been tracked since
PR 18 landed. The serve-side adapter that wraps `WorkspaceFileSystem`
+ the `runQwenServe` wiring are intentionally split into the
immediate-follow-up so this PR stays focused on the seam design.

Backward compatible: `fileSystem` is optional on `BridgeOptions`.
Tests, Mode A in-process consumers, channels (`packages/channels/base/
AcpBridge.ts`), and the VSCode IDE companion all keep working
unchanged — they omit the field and `BridgeClient` falls through to
the inline proxy that has been the Stage 1 default since #3889.

API:
- `BridgeFileSystem.readText(params: ReadTextFileRequest):
  Promise<ReadTextFileResponse>`
- `BridgeFileSystem.writeText(params: WriteTextFileRequest):
  Promise<WriteTextFileResponse>`

The interface mirrors ACP SDK request/response types directly so the
adapter does the minimum amount of translation (`{ path, content }`
↔ `WorkspaceFileSystem`'s `ResolvedPath` brand types + options bag).

- 735/735 cli serve tests pass (inline fallback path preserved)
- 44/44 acp-bridge tests pass
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): catch README + stale source comments up to F1 lift

Self-review fold-in: post-F1 the package README still said "PR 22a"
and listed `BridgeClient` / `createHttpAcpBridge` /
`defaultSpawnChannelFactory` under "What's not here yet" — both
contradicted by this PR. Updated:

- README lift-history table now shows PR 22a / 22b/1 / 22b/2 as
  merged and F1 (this PR) as the slice that closes the bridge core
  + adds `BridgeFileSystem`. F3 PR 24 row aligned to the
  feature-cohesive plan.
- "What's here today" now documents `spawnChannel`, `bridgeClient`,
  `bridge`, `bridgeFileSystem` modules.
- "What's not here yet" section removed (its 2 bullets are both
  resolved by F1).
- Subpath import list updated to enumerate all 14 subpaths.
- Backward-compat section updated to call out the 97-line shim and
  the 6 consuming files that still import via `./httpAcpBridge.js`.

Source-comment line-number drift:
- `channel.ts:12` no longer claims `defaultSpawnChannelFactory` is
  "still in cli/src/serve/httpAcpBridge.ts" — points to the lifted
  location.
- `permission.ts:33` + `permission.ts:45` no longer reference
  `httpAcpBridge.ts:1096-1106` / `httpAcpBridge.ts:1003` (file is
  now 97 lines after F1). Updated to point at the structurally-
  equivalent locations inside the lifted `bridgeClient.ts`.
- `permission.ts:7` no longer says first-responder still lives in
  `cli/src/serve/httpAcpBridge.ts` — points at the bridgeClient.ts
  location.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): adopt 3 Copilot review comments on F1 doc accuracy

Folds in 3 of 4 Copilot inline comments from #4319 review:

1. `bridgeClient.ts` writeTextFile preserveMode comment said "fall
   through to umask defaults" for new files, but the code passes
   `mode: preserveMode?.mode ?? 0o600` to `fs.writeFile`. Updated the
   "BkwQW" comment + the inner catch-block comment to clarify that
   new files actually get the `0o600` default applied at writeFile
   time (NOT umask defaults — the explicit `mode` arg bypasses umask
   for atomicity per the `Blehd` comment block).

2. `bridgeFileSystem.ts` JSDoc referenced
   `cli/src/serve/bridgeFileSystemAdapter.ts` as if the file exists,
   but it's deferred to the immediate F1 follow-up PR. Reworded as
   "the immediate follow-up PR will land a serve-side adapter" so
   reviewers don't grep for a non-existent file.

3. `bridgeOptions.ts` `fileSystem` field JSDoc had the same wording
   issue ("Production `qwen serve` wires this to..."). Same fix — now
   says "The immediate F1 follow-up will land a serve-side adapter"
   so the deferred state is obvious.

Declined from this review round:

- Copilot inline #1 (`spawnChannel.ts:155` stderr forwarder drops
  empty lines): pre-existing behavior since #3889. F1 lifted verbatim
  — not a regression introduced here. Out of scope for a lift PR.
- github-actions bot summary: most items are pre-existing notes
  (TOCTOU residual race, SCRUBBED_CHILD_ENV_KEYS allowlist concern,
  sliceLineRange benchmark threshold) on code the F1 lift moved
  verbatim. One ("httpAcpBridge.ts still has ~3700 LOC") is a false
  positive — the file is 97 LOC after F1. Others are cosmetic
  refactors (extract FIXME to tracking issue, ARCHITECTURE_DECISIONS
  doc system, deprecation timeline) that aren't worth churning the
  lift PR over.

- 44/44 acp-bridge tests pass
- typecheck clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): tighten BridgeFileSystem contract + re-export type from shim

Self-review + code-reviewer agent fold-in, two changes:

1. `cli/src/serve/httpAcpBridge.ts` shim now re-exports
   `BridgeFileSystem` from `@qwen-code/acp-bridge/bridgeFileSystem`
   so the immediate F1 follow-up adapter (in `cli/src/serve/`)
   can import it via the established `./httpAcpBridge.js` path
   like every other daemon-side bridge import does. Without this
   the adapter would need to deep-import from acp-bridge while
   every other serve file goes through the shim — inconsistent.

2. `BridgeFileSystem.readText` + `writeText` JSDoc now spells out
   the two defensive gates the inline proxy carried (non-regular-
   file rejection + 100 MiB buffered-size cap for reads;
   write-then-rename atomicity + dangling-symlink walk-through +
   mode preservation + `0o600` new-file default for writes). When
   a `BridgeFileSystem` is injected, the inline path is FULLY
   bypassed — without the contract spelled out, a future adapter
   author could silently drop the `/dev/zero` / 500 MB log RSS
   defenses the inline path established.

Note on F1 CI: this PR targets `daemon_mode_b_main` but the
`.github/workflows/ci.yml` `pull_request` trigger is scoped to
`branches: main / release/**`, so the main CI workflow (Lint /
Test on Linux/macOS/Windows / CodeQL) does NOT run on this PR.
This is a by-design side effect of the new feature-cohesive
branching strategy — `daemon_mode_b_main → main` periodic merges
will trigger the full CI matrix, providing safety net coverage
before any F-series work lands on `main`. Locally verified:
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- 735/735 cli serve tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover BridgeFileSystem injection seam + extract shared writeStderrLine (#4319 wenshao review)

Folds in wenshao review on #4319:

1. **[Critical]** zero test coverage for the F1 step 5 `BridgeFileSystem`
   delegation branches in `BridgeClient.writeTextFile` /
   `BridgeClient.readTextFile` and the factory's
   `opts.fileSystem` → constructor positional-arg forwarding.

   New `packages/acp-bridge/src/bridgeClient.test.ts` adds 6 tests
   covering:
   - writeTextFile delegates to injected fileSystem.writeText (inline
     proxy fully bypassed; `fakeFs.writeText` called with the original
     params; `readText` mock not invoked)
   - writeTextFile invalid-path call succeeds purely via the mock
     when fileSystem is injected (proof that the inline `fs.realpath`
     path doesn't run)
   - readTextFile delegates to injected fileSystem.readText
   - readTextFile propagates injection errors to the caller
   - inline-fallback regression guard: write actually hits disk via
     the inline proxy when fileSystem is omitted (real tmp file
     round-trip)
   - same for read

   Why these matter: the 7-arg `BridgeClient` constructor places
   `fileSystem` at the tail as optional. A reordering — or dropping
   the arg from `bridge.ts` factory's `new BridgeClient(..., opts.fileSystem)`
   call — would silently bypass the adapter in production and the
   inline `fs.writeFile` raw-path would run with no audit / trust /
   TOCTOU coverage. The delegation tests would catch that because
   the mock fileSystem would never be invoked.

2. **[Suggestion]** `writeStderrLine` was defined identically in
   `bridge.ts:117` and `bridgeClient.ts:30` (22 call sites across the
   two files). Both consumers live in the SAME `@qwen-code/acp-bridge`
   package, so the original "no reverse-dep on cli" justification
   doesn't apply within the package. Extracted to
   `packages/acp-bridge/src/internal/stderrLine.ts` — a single source
   of truth that future behavior changes (timestamp prefix, log
   level, structured field) can edit once. `internal/` subpath is
   intentionally not in `package.json`'s `exports`, keeping the
   helper package-private. `spawnChannel.ts` deliberately does NOT
   consume it (its stderr writes use `process.stderr.write(prefix +
   line + '\n')` directly because each line carries its own
   `[serve pid=… cwd=…]` line prefix).

- 6/6 new BridgeFileSystem-seam tests pass
- 50/50 acp-bridge total (44 existing + 6 new)
- 174/174 cli httpAcpBridge tests pass (no regression from refactor)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover defaultSpawnChannelFactory env scrubbing + fix bridge.ts comment refs (#4319 wenshao round 2)

Folds in wenshao review on #4319 round 2 — 1 Critical + 2 Suggestions:

1. **[Critical] spawnChannel.ts has 0 unit tests, security-critical
   paths untested.** Now that `defaultSpawnChannelFactory` is a public
   export of `@qwen-code/acp-bridge`, channels + IDE consumers can't
   rely on cli-package integration tests for env-scrubbing guarantees.

   Refactored the inline env-scrubbing logic into a pure exported
   helper `scrubChildEnv(source, scrubbed, overrides)`. Behavior is
   byte-identical to the pre-extraction inline implementation; the
   factory body now reads:

       const childEnv = scrubChildEnv(
         process.env, SCRUBBED_CHILD_ENV_KEYS, childEnvOverrides);

   Added `packages/acp-bridge/src/spawnChannel.test.ts` with 12 tests
   covering:
   - shallow-clone (no aliasing into live process.env)
   - QWEN_SERVER_TOKEN stripping
   - non-scrubbed vars pass through
   - override-add a new key
   - override-replace an existing key
   - override with undefined deletes the key (PR 14 fix #4247 wenshao R5)
   - override CANNOT re-introduce a scrubbed key (defense in depth)
   - override CANNOT undo the scrub by setting undefined for a scrubbed key
   - override-apply-after-scrub ordering invariant
   - empty overrides equals no overrides
   - multi-key scrub for forward-compat (the WARNING comment on
     SCRUBBED_CHILD_ENV_KEYS anticipates a future sandboxed-agent
     mode expanding the denylist; this verifies the loop already
     handles that)

   The killChild SIGTERM→SIGKILL escalation + STDERR_LINE_CAP_CHARS
   truncation are NOT covered yet — they require either real child
   processes or extensive node:child_process mocking; both are
   orthogonal to the env-scrubbing security guarantees wenshao
   explicitly called out, and can land as a follow-up if anyone
   wants the full surface tested.

2. **[Suggestion] bridge.ts comments referenced a "consolidated re-
   export block earlier in this file" that doesn't exist in acp-bridge
   (only in the cli shim).** Fixed both occurrences (~line 292, ~line
   310) to point at the actual local import + the package barrel
   re-export.

3. **[Suggestion] bridge.ts canonicalizeWorkspace re-export comment
   referenced `./fs/paths.ts`.** Updated to mention the full lift
   chain: extracted to `cli/src/serve/fs/paths.ts` in PR 18, then
   lifted here to `./workspacePaths.ts` in PR 22b/1.

- 12/12 new spawn env-scrub tests pass
- 62/62 acp-bridge total (50 existing + 12 new spawn)
- 174/174 cli httpAcpBridge tests still pass (the factory's inline
  env-scrubbing refactor preserves byte-identical behavior)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): fix 14-arg→7-arg typo in test docstring + simplify canonicalizeWorkspace re-export doc (#4319 wenshao round 3)

Folds in 2 of 3 wenshao Suggestions from #4319 round 3:

1. `bridgeClient.test.ts:20` JSDoc said "the 14-arg constructor's
   positional slot" — typo I introduced when writing the test in
   `fbc92bccf`. The same docstring correctly says "the constructor
   takes 7 positional args" at line 25. Updated to "7-arg".

2. `bridge.ts:3461` `canonicalizeWorkspace` re-export JSDoc no longer
   references the historical `cli/src/serve/fs/paths.ts` location.
   Reads cleaner as a present-tense pointer to `./workspacePaths.ts`
   (where the implementation actually lives now post-PR 22b/1).
   Git history covers the lift chain; the docstring should describe
   current state.

DECLINED + tracked separately:

- **[Critical]** `closeSession` + `killSession` use module-scoped
  `channelInfo` instead of `channelInfoForEntry(entry)` — channel-
  overlap edge case can kill the wrong channel. Wenshao explicitly
  notes "pre-existing bug preserved by the lift" — F1's mechanical-
  lift scope shouldn't carry behavior fixes, and the fix needs a
  channel-overlap regression test to land safely. Tracked as #4325.

- 62/62 acp-bridge tests pass (no regression from doc tweaks)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): polish from second-pass self-review (cross-platform test + package metadata + dead tombstones)

Five small adoptions from a second-pass code-reviewer agent review on
F1 (no new external comments — pre-emptive cleanup before reviewer
returns):

1. **`bridge.ts:290-313`** — deleted two standalone "InvalidPermission
   OptionError / WorkspaceInit* / McpServer* lifted to bridgeErrors"
   tombstone comments. Pre-22b they were load-bearing (explained why
   the class wasn't `class`-defined inline at that file location).
   Post-F1 the symbols are imported at the top of the file and the
   comments sit between unrelated code (`writeServeDebugLine` /
   `MAX_DISPLAY_NAME_LENGTH` / `DEFAULT_INIT_TIMEOUT_MS`) with no
   anchor. Dead doc — removed.

2. **`README.md`** — `spawnChannel` entry now lists `scrubChildEnv`
   alongside `defaultSpawnChannelFactory` + `killChild` +
   `SCRUBBED_CHILD_ENV_KEYS`. Channels / VSCode IDE consume the
   package barrel so the helper should be visible in the inventory.

3. **`package.json:description`** — refreshed from the PR 22a wording
   ("EventBus, AcpChannel, in-memory channel, PermissionMediator
   interface") to include F1 additions (`createHttpAcpBridge` /
   `BridgeClient` / `defaultSpawnChannelFactory` / `BridgeFileSystem`).
   Visible on `npm view`-style tooling + IDE hover so worth keeping
   current.

4. **`bridgeClient.test.ts:92-115`** — swapped `/proc/no-such-file`
   for `/this/dir/never/exists/file.txt` and reworded the comment.
   `/proc/` is Linux-only; on macOS / Windows the inline proxy's
   dangling-symlink fallback would write through to a path under
   root rather than failing. Test passed regardless (mock assertion,
   not real disk) but the comment overstated portability.

5. **`spawnChannel.test.ts:36`** — added a comment block explaining
   why the test deliberately hand-rolls the SCRUBBED set instead of
   importing the production `SCRUBBED_CHILD_ENV_KEYS`. The
   decoupling is intentional (pure-function parameterized test +
   forward-guard for future denylist expansion) but a naive reader
   would think it's an oversight.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint + pre-commit hooks clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(acp-bridge): bridge.ts security fold-in from #4297 review (3 issues)

Folds 3 unresolved review comments from the post-merge thread on #4297
(wenshao via qwen-latest agent) into F1 (#4319). All 3 touch
`acp-bridge/src/bridge.ts` — the same file F1 already moves the lifted
factory into — so consolidating here saves opening a separate
follow-up PR and keeps the security narrative in one reviewable
commit. The 2 cross-package fixes (`core/src/memory/const.ts` test
gap + `cli/src/serve/runQwenServe.ts` malformed-context fallback)
will land as their own small PRs after F1 merges.

#### Fix 1 (wenshao Critical, #4297 thread): `fs.unlink(target)`
arbitrary-file-deletion primitive in `verifyParentWithinWorkspace`
'create'-cleanup

After `fs.open(target, 'wx')` creates the empty file at the real
parent, an attacker with local workspace write access can swap the
parent directory for a symlink (`docs/` → `/etc`). The cleanup's
`fs.unlink(target)` re-resolves the TEXTUAL path through the
attacker's freshly-planted parent symlink, deleting whatever file
exists at the external location.

Fix: drop the `fs.unlink(target)` line. The 0-byte file at the
pre-race location is harmless (0 bytes, inside the workspace we'd
already verified) — leaving it over deleting an arbitrary external
file is the right safety trade. Comment block explains the
reasoning so future maintainers don't re-introduce the unlink.

#### Fix 2 (wenshao Critical): `O_TRUNC` arbitrary-file-truncation
primitive in workspace-init 'overwrite' branch

`O_TRUNC` causes the kernel to truncate the file to zero bytes AT
`open(2)` SYSCALL TIME — strictly before `verifyParentWithinWorkspace`
runs. A parent-symlink TOCTOU race between
`canonicalizeExistingAncestor` and this `open()` zeros the file at
the attacker-redirected location (arbitrary-file-truncation
primitive against any file the daemon UID can open). The pre-fix
code's own comment on `verifyParentWithinWorkspace` acknowledged
this as "Acceptable residual posture for the Stage-1 trust model";
wenshao pushed back that arbitrary-file-zeroing exceeds the
Stage-1 trust budget.

Fix: drop `O_TRUNC` from the open flags. Truncation moves to AFTER
`verifyParentWithinWorkspace` succeeds, via `fh.truncate(0)` on the
fd we already hold. fd-based truncate does NOT re-resolve the path
— an attacker swapping the parent symlink after we open can't
redirect the truncation.

#### Fix 3 (wenshao Suggestion): `canonicalizeExistingAncestor`
missing `ELOOP` catch

Circular symlinks in the parent path (`a -> b`, `b -> a`) cause
`fs.realpath` to fail with `ELOOP`. Without catching it, the error
propagates as an unstructured HTTP 500 instead of the typed
`WorkspaceInitSymlinkError` (HTTP 400) the route handler expects
from the workspace-init race-detection family.

Fix: add `'ELOOP'` to the caught error codes alongside `'ENOENT'`
and `'ENOTDIR'`. Walking up the parent chain when ELOOP hits at a
sub-component preserves the existing "walk to the deepest extant
ancestor" contract — the deepest realpath-able ancestor still
dictates the canonical prefix.

#### Why no new tests in this commit

- Fix 1 is a single-line removal: any regression that re-adds the
  unlink would be caught by reviewing the diff; existing 174-test
  `httpAcpBridge.test.ts` integration suite confirms the create-path
  still works (file is created + closed correctly; only the
  attacker-cleanup branch changes).
- Fix 2 is a structural move (truncate from open-time to post-verify);
  the existing overwrite-init integration tests confirm the
  end-to-end behavior is unchanged (file ends up empty after init).
  Adding a TOCTOU race regression test requires controlled
  filesystem-race simulation that exceeds reasonable test infra
  scope for this PR.
- Fix 3 is a one-word addition to an error code list; the
  `canonicalizeExistingAncestor` helper is module-private and the
  integration test for circular-symlink → typed 400 would require
  exporting it OR setting up a real circular-symlink workspace.
  Both routes widen scope beyond the security fix itself; the
  high-level behavior is verifiable by the existing route-error-
  mapping test pattern + diff review.

A follow-up PR can add the integration tests once the security fix
itself has shipped; the immediate priority is closing the
arbitrary-file-deletion + arbitrary-file-truncation primitives.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint clean

#### Refs

- Original review on #4297 (wenshao via qwen-latest agent), post-
  merge, currently unresolvable on #4297 itself because that PR is
  already MERGED.
- Other 2 #4297 review threads (`const.ts` test coverage,
  `runQwenServe.ts` malformed-context observability) target files
  outside F1's scope and will land as separate follow-up PRs.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix: post-merge Codex P2 fold-in — MCP restart disabled-tools normalization + SDK timeout headroom (#4319)

Folds in 2 P2 findings from a Codex review run on `git diff main...HEAD`
of F1 PR #4319. Both are pre-existing in code merged into
`daemon_mode_b_main` before F1 was created (#4282 PR 17), but they're
tiny tactical fixes (~25 LOC + 1 LOC) on the same integration branch
the same reviewer (wenshao) already engages with, so folding into F1
saves an extra follow-up PR cycle.

#### Fix 1: normalize disabled tool names during MCP restart refresh

`packages/cli/src/acp-integration/acpAgent.ts:1563-1566`

The bootstrap path in `cli/src/config/config.ts:1426-1434` applies a
4-step normalization to `tools.disabled`:
  1. typeof string filter
  2. .trim()
  3. drop empty after trim
  4. dedupe via Set

The MCP-restart refresh path only did step 1, then stored the raw
strings. `ToolRegistry` checks disabled tools with EXACT
`Set.has(tool.name)`, so a tool disabled at boot as `' Foo '` (or
`'Foo\n'`) is no longer matched after `restartMcpServer` and gets
silently re-registered. This contradicts the documented "toggle +
restart" workflow that #4282 PR 17 advertised.

Fix: mirror the bootstrap normalization verbatim before
`setDisabledTools`. Adds 6 lines + a 7-line comment pointing at the
bootstrap reference for future maintainers.

#### Fix 2: add headroom to MCP restart SDK timeout

`packages/sdk-typescript/src/daemon/DaemonClient.ts:102`

The SDK's `MCP_RESTART_DEFAULT_TIMEOUT_MS` was EXACTLY 300_000ms, the
same ceiling the daemon's own `MCP_RESTART_TIMEOUT_MS` uses for the
upper bound on a single MCP rediscovery. For restarts that finish
(or fail with a typed `McpServerRestartFailedError` JSON envelope)
near 300s, the client `AbortSignal` could fire BEFORE the daemon had
finished serializing + transmitting the response, yielding a client
`TimeoutError` even though the daemon was still within its own
budget.

Fix: bump to 330_000ms (10% / 30s headroom over the daemon ceiling).
Comment updated to call out the race + the rationale for the
specific headroom value. Callers needing tighter caps still pass
their own `timeoutMs` to `restartMcpServer`.

#### Why folded into F1 vs separate follow-up PRs

These are post-merge findings on `#4282 PR 17` code, not F1-introduced
regressions. Normally we'd track as separate follow-up issues (mirror
of the #4325 / `channelInfo` decline). But:

- Both fixes are TINY (~25 LOC + ~2 LOC including comment); the bridge
  security fold-in commit `7bd66c6e8` set the precedent of folding in
  small same-branch issues when the cost-benefit favors closing them
  immediately.
- Same reviewer (wenshao via qwen-latest agent) — won't be confused
  by the scope expansion; in fact the original PR 17 commenter is
  also the one who'd review the follow-up issue's fix.
- Both fixes target `daemon_mode_b_main`-only paths (MCP restart route
  added by PR 17 lives on the integration branch).
- Saves opening 2 trivial follow-up issues that would just sit until
  someone picks them up.

#### Verification

- sdk-typescript: 424/424 tests pass (no test hardcoded the old
  300_000 default — only the constant declaration itself referenced it)
- cli acp-integration: 282/282 tests pass (no test exercised the
  exact whitespace-bearing disabled-tools scenario, so no test
  changes were strictly required; a regression test would belong in
  a separate test-coverage PR alongside the const.ts test gap from
  the #4297 unresolved-comment thread)
- typecheck clean across cli + sdk-typescript

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): wenshao review round 4 — 3 Suggestion fold-ins (#4319)

1. **bridge.ts:2270 stale line refs in `publishWorkspaceEvent` JSDoc**
   — comment said `permission_resolved at line 1717` (actual: line 682)
   and `broadcastWorkspaceEvent closure at ~line 2127` (actual: line
   1281). Line numbers drifted across the lift commits. Replaced both
   with function-name refs (`in resolvePending`, `declared above in
   this factory body`) that survive future edits.

2. **`ws.ts:613` opaque references in bridgeFileSystem.ts:20 +
   bridgeOptions.ts:267** — no `ws.ts` file exists in the repo; the
   ref came from an internal review thread on PR 18 that future
   readers can't locate. Replaced with a self-contained description
   ("post-PR-18 follow-up thread about BridgeClient's inline fs proxy
   bypassing WorkspaceFileSystem (originally raised in…
chiga0 added a commit that referenced this pull request May 27, 2026
…BX9_p) (#4557)

* fix(serve): post-merge fixes for #4291 review (7 threads) (#4305)

* fix(serve): address qwen-latest review on merged #4291 (7 threads)

Seven post-merge findings from the qwen-latest review on #4291,
all real. Most are tightening fixes for issues introduced by the
earlier rounds of #4291 — the same security / DRY / observability
classes the original review surfaced, applied to surfaces that
weren't covered initially.

#1 (deviceFlow.ts:1179) — late-poll observer closure retained the
entire entry by reference (deviceCode/pkceVerifier BrandedSecrets +
cancelController) for the lifetime of the daemon if `provider.poll()`
never settled. Memory leak + indefinite secret retention. Destructure
the four fields the closure actually needs (deviceFlowId, providerId,
initiatorClientId, audit sink) so the entry is GC-eligible the
moment runPollTick returns.

#2 (server.ts) — `callerIsInitiator` was duplicated verbatim across
three locations: GET handler, toDeviceFlowStartResponseBody,
toDeviceFlowStateBody. The exact bug class #4291 was fixing was
"POST and GET diverged on the same redaction policy" — duplicating
the gate recreated the preconditions for divergence. Extracted to
shared `callerIsDeviceFlowInitiator(view, callerClientId)` helper
with the consolidated threat-model JSDoc. All three sites now call
the helper.

#3 (deviceFlow.ts:1110) — timeout callback constructed two separate
`DeviceFlowPollTimeoutError` instances (one for `signal.reason`, one
for the wrapper rejection). Each capture its own V8 stack trace,
and `signal.reason.stack` would diverge from the caught rejection's
stack — confusing for operators inspecting both. Build the sentinel
ONCE per timer fire and pass the same instance to both sites.

#4 (qwenDeviceFlowProvider.ts:273) — `Error.name` is a freely
assignable string property; a hostile fetch wrapper could set
`e.name = 'X\n[serve] FAKE LINE\x1b[31m'` to inject log lines or
ANSI sequences via the same vector we already closed for `oauthError`.
The non-OAuth catch path interpolated `${err.name}` raw. Apply the
same `sanitizeForStderr()` helper.

#5 (deviceFlow.ts:1551) — on the timeout path, `rawProviderError`
is undefined (deliberately, to skip the misleading
`provider.poll() threw (raw): ...` audit template), but that left
the audit hint field omitted entirely. Operators reading the
durable audit trail saw `errorKind: 'upstream_error'` with no signal
whether it was a hung IdP or a generic provider failure. Use
`result.hint` (which already carries the timeout-specific
`provider.poll() timed out after Nms; check IdP connectivity` text
built in the catch) so the audit matches the SSE event.

#6 (server.ts) — the `QWEN_SERVE_DEBUG` env-var check was inlined
in the GET route handler, duplicating the `isServeDebugMode()`
helper from `./debugMode.js` that workspaceAgents and
workspaceMemory already use. The inline copy also had a dead `?? ''`
fallback (the value is guaranteed truthy at that point per the
preceding check). Use the canonical helper.

#7 (deviceFlow.ts:1217) — late-rejection observer interpolated the
raw `lateErr.message` into the audit hint (truncated to 256 bytes,
but RFC 8628 `device_code` values fit comfortably in 256 bytes).
The provider's catch already uses the `name + length` redaction
pattern to prevent WAF-echoed `device_code`/PKCE leaks; the
registry layer was undoing that hardening because the same failure
settled late. Apply the same `name + length` pattern at the late-
rejection site.

Tests:
- Existing late-rejection test reseeded with a `device-code-secret-*`
  substring inside the long detail; hard-negative-asserts the seeded
  secret is absent from the audit + asserts the new
  `Error (message N bytes; raw suppressed)` shape.
- Existing poll-timeout test now also asserts: hint IS defined on
  the audit (not omitted), hint contains `'timed out after'` /
  `'check IdP connectivity'`, and `signal.reason instanceof
  DeviceFlowPollTimeoutError` (proves the single sentinel is
  shared between abort and reject).
- New `sanitizes control characters in attacker-controlled
  err.name` test in qwenDeviceFlowProvider.test.ts pins the round-4
  #4 fix with a hostile `e.name` containing `\n` + `\x1b[31m...`.

cli serve 702/702 (was 686, +16 — additional tests imported via
the acp-bridge package lift on main); sdk 421/421; typecheck clean
across all 4 workspaces; eslint --max-warnings 0 clean on touched
files.

Refs: #4175, #4255, #4291

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): address deepseek-v4-pro review on #4305 (4 threads)

Round-5 fold-in. Four findings from the deepseek-v4-pro review on
PR #4305 — all real, three are sister fixes for the same security
classes that #4305 already closed at adjacent surfaces.

#1 (deviceFlow.ts) — `pollTimedOut` race correctness. The flag was
set unconditionally inside the timer callback. If the provider
settled the wrapper at 29.9s, `finally` would call
`clearScheduled(pollTimer)` — but if the timer callback was already
queued for execution before the clear landed (a real possibility
in Node's event-loop ordering, even if not always observed in
practice), this branch could still run and incorrectly mark
`pollTimedOut`. Move the flag assignment to the catch block where
the settled cause is unambiguous via `instanceof
DeviceFlowPollTimeoutError`. New test pins the negative: provider
beats the timeout → no spurious `lost_late_poll_after_timeout`
audit even after ticking 2× the ceiling.

#2 (deviceFlow.ts) — late-rejection observer interpolated raw
`lateErr.name` into the audit hint without sanitization. Same
attacker-controlled vector closed at the provider layer for
`err.name` in round-4. Route through `sanitizeForStderr`.

#3 (deviceFlow.ts) — late-success observer interpolated
`latePollResult.kind` directly into the audit template. While the
typed shape is `'pending' | 'slow_down' | 'success' | 'error'`, a
non-conforming provider could return an arbitrary string. Same
log-injection vector. Route through `sanitizeForStderr`.

#4 (qwenDeviceFlowProvider.ts → deviceFlow.ts) —
`sanitizeForStderr` only stripped ASCII C0/C1 + DEL; bypass via
Unicode lookalikes:
  - U+2028/U+2029: LINE/PARAGRAPH SEPARATOR (newline-equivalent in
    most Unicode-aware terminals — most direct log-forging vector)
  - U+200B–U+200F: zero-width chars + LRM/RLM
  - U+202A–U+202E: bidirectional override controls
  - U+FEFF: BOM / ZWNBSP

A malicious IdP returning `slow_down
[serve] FAKE` in
`oauthError` would otherwise still forge log lines.

Architectural change: `sanitizeForStderr` was previously private to
`qwenDeviceFlowProvider.ts`. To address #2/#3, the registry layer
needs to call it too. Lifted into `deviceFlow.ts` (the foundation
module) and re-imported from the provider. Single source of truth;
the regex is now a module-level constant compiled once with explicit
`\uXXXX` escapes (via `String.raw` so the source is greppable, not
literal-Unicode-laden).

Tests:
- `does NOT attach late-poll observer when the provider beats the
  timeout` — N1 race regression
- `sanitizes hostile latePollResult.kind in late-observer audit` — N3
- `sanitizes hostile lateErr.name in late-rejection observer audit` — N2
- `sanitizes Unicode lookalike controls (U+2028 LINE SEPARATOR,
  bidi, ZWNBSP) in oauthError` — N4

cli serve 706/706 (was 702, +4 — all new round-5 tests); sdk
421/421; typecheck clean; eslint --max-warnings 0 clean on touched
files.

Refs: #4175, #4255, #4291, #4305

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): address gpt-5.5 + qwen-latest review on #4305 round-5 (5 threads)

Round-6 fold-in. Five findings split between maintainability,
security hardening, and a real defensive bug.

#1 (qwenDeviceFlowProvider.test.ts) — gpt-5.5: round-5 #4 test
embedded U+2028 / U+200E / U+FEFF as literal characters in source.
Invisible in GitHub diffs / most editors; the negative
`not.toContain('')` looked like an empty-string check. Rewrote
the payload + assertions to use named `\uXXXX`-bound constants.
Also added a companion test exercising U+2066–U+2069 (round-6 #5
below).

#2 (deviceFlow.ts) — qwen-latest: the late-poll observer's
`void tracked.then(...)` was missing a terminal `.catch(() => {})`.
A synchronous throw inside either handler (e.g., a misbehaving
`audit.record`: backpressure, malformed payload, sink out-of-disk)
would reject the derived promise unhandled. On Node 22's default
`--unhandled-rejections=throw`, that crashes the daemon. Added the
terminal `.catch(() => {})` matching the persist-tracker pattern.
New test injects a poison audit sink that throws specifically on
the `lost_late_poll_after_timeout` call; asserts `flushAsync()`
resolves cleanly.

#3 (deviceFlow.ts) — qwen-latest: the `case 'error'` audit-record
hint interpolated `rawProviderError` (raw `err.message`) without
`sanitizeForStderr`. Per ES2019+ `JSON.stringify` no longer escapes
U+2028/U+2029 — those would still forge log lines downstream
through file/stdout audit sinks. Apply the same sanitizer used on
every other provider-controlled audit path. New test pins a hostile
provider message containing U+2028 + ANSI escape and asserts
neither survives.

#4 (deviceFlow.ts) — qwen-latest: the round-5 #1 comment claimed
"`DeviceFlowPollTimeoutError` isn't exported as a public DeviceFlow
contract", but it IS `export class` (the test file constructs it
directly for fixtures). With `pollTimedOut = true` keyed solely on
`instanceof`, a future provider that imports + throws the class
would spoof the registry's "I caused the timeout" signal —
attaching a phantom late-poll observer.

Fix: introduce a runtime brand `_isRegistryTimeout: boolean` on the
class (default `false`) plus an internal-only
`makeRegistryPollTimeoutError(ms)` helper that sets the brand to
`true`. The brand is set ONLY at the registry's race-timer
construction site. Both gates updated:
  - `if (err instanceof X && err._isRegistryTimeout === true)` in
    the catch (for `pollTimedOut`)
  - `if (lateErr instanceof X && lateErr._isRegistryTimeout === true)`
    in the late-rejection self-filter

A provider-thrown brand-false instance now flows through the
generic provider-throw audit path — correctly auditing the misuse
rather than silently swallowing it. Repurposed the original "no
double-audit when registry's own DeviceFlowPollTimeoutError is
late-rejected" test (which was actually exercising the brand-false
path) into the inverted assertion: brand-false provider throw IS
audited as a real failure. Removed the orphaned old assertion; the
brand-true happy path is implicitly covered by the hanging-provider
test (which exercises the registry-built timeout end-to-end).

#5 (deviceFlow.ts) — qwen-latest: `sanitizeForStderr` regex covered
U+202A–U+202E (bidi embedding/override) but missed U+2066–U+2069
(LRI/RLI/FSI/PDI). These are the primary CVE-2021-42574
("Trojan Source") attack vectors — a hostile IdP swapping U+2066
for U+202D achieves the same visual reordering and would have
bypassed the round-5 filter entirely. Extended the regex range and
JSDoc; new test exercises U+2066/U+2068/U+2069 in `oauthError` and
asserts none survive while substantive ASCII parts remain.

cli serve 713/713 (was 710, +3 round-6 tests + the round-5 #4
rewrite + the round-6 #5 companion); typecheck clean across all 4
workspaces; eslint --max-warnings 0 clean on touched files.

Refs: #4175, #4255, #4291, #4305

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): replace literal U+2028 with explicit 
 escape in round-6 #3 test

PR #4312 review (Copilot): the round-6 #3 test (sanitizes
rawProviderError) regressed back to embedding a literal U+2028
character in source via `const U_2028 = ' '`. That's the same
maintainability anti-pattern round-6 #1 was fixing in the sister
test. Internal-consistency fix: switch to the explicit `
`
escape so the constant is greppable and reviewable in GitHub diffs.

Refs: #4291, #4305, #4312

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): post-merge P2 corrections from Codex review on #4282 (#4297)

* fix(serve): post-merge P2 corrections from Codex review on #4282

Follow-up to PR #4282 (Wave 4 PR 17) addressing four P2 issues
flagged by Codex's `/review` after the squash-merge to main:

P2-1 — Read the workspace context filename for init
  `qwen serve` parent never goes through `loadCliConfig`, so the
  process-global `getCurrentGeminiMdFilename()` stays on the default
  `QWEN.md` even when the workspace configures
  `context.fileName: 'AGENTS.md'`. `runQwenServe` now snapshots the
  workspace's merged setting at boot and forwards via
  `BridgeOptions.contextFilename`, so init writes the same file the
  ACP child reads.

P2-2 — Restart MCP servers with a fresh disabledTools snapshot
  `Config.disabledTools` was frozen at construction time;
  `setWorkspaceToolEnabled` only updated settings.json. The
  documented "toggle + restart" workflow re-registered just-disabled
  tools because rediscovery still saw the bootstrap snapshot. Added
  `Config.setDisabledTools()` plus a re-read at the ACP restart
  handler so `discoverMcpToolsForServer` honors the latest set.

P2-3 — Match the SDK timeout to the daemon's restart budget
  Bridge waits up to 300s for stdio MCP discovery; SDK helper used
  the client-wide 30s default and aborted valid slow restarts.
  Added a per-call `timeoutMs` plumbed through `fetchWithTimeout`,
  defaulting `restartMcpServer` to 5 minutes.

P2-4 — Reject symlinked parent directories before init writes
  `lstat(target)` only checked the final component; a symlinked
  parent (e.g. `docs -> /tmp` with `context.fileName:
  'docs/QWEN.md'`) would let `writeFile` follow the link and create
  / truncate outside `boundWorkspace`. Added
  `canonicalizeExistingAncestor` (walks up through ENOENT to the
  deepest extant ancestor, then `realpath`s) and verifies the
  canonical parent stays within the canonical workspace.

5 new tests (4 bridge / 2 SDK):
- contextFilename snapshot honored
- parent-symlink escape rejected
- nested real subdir accepted
- restartMcpServer survives 1.2s response with 1s default timeout
- restartMcpServer honors a 50ms caller override

Typecheck clean across cli / sdk-typescript / core.
1604/1604 unit tests pass.

* fix(serve): fold-in 1 — address 16:32:44-round review on #4282

Follow-up addressing the 8 unresolved review threads opened on PR
shipping in this same #4297; addresses correctness gaps + missing
test coverage that would otherwise let regressions ride into main.

Behavior fix:
- broadcastWorkspaceEvent gains a `skipSessionId` parameter; when
  `setSessionApprovalMode` runs with `persist:true`, the broadcast
  skips the requesting session so it doesn't receive the same
  `approval_mode_changed` event twice (once via session-scoped
  publish + once via broadcast). The SDK reducer's
  `approvalModeChangedCount` now increments by 1, not 2, on the
  requesting client (peers still see 1 via the broadcast).
  Addresses #3260501134.

Observability + posture:
- broadcastWorkspaceEvent now mirrors PR 16's publishWorkspaceEvent
  member: per-entry success/failure accounting + an "ALL buses
  dropped" stderr elevation. The previous local helper silently
  swallowed every publish failure. Addresses #3260501126.
- WorkspaceInitPathEscapeError + WorkspaceInitSymlinkError typed
  classes for the two boundary guards in initWorkspace, mapped to
  HTTP 400 by sendBridgeError. Previous generic `Error` fell
  through to the 500 handler, telling operators "daemon broken"
  when the actual fix was workspace-config correction. Addresses
  #3260501161.

Public surface symmetry:
- Re-export McpServerNotFoundError, McpServerRestartFailedError,
  WorkspaceInitPathEscapeError, WorkspaceInitSymlinkError from the
  serve barrel. External embeds matching these via `instanceof`
  no longer need deep imports. Addresses #3260501163.

Test coverage:
- restartMcpServer bridge tests (5): success + event broadcast,
  soft-skip + refused event, McpServerNotFoundError translation,
  McpServerRestartFailedError translation, originator clientId
  stamping. Addresses #3260501141.
- sendBridgeError mapping tests (4): McpServerNotFoundError → 404,
  McpServerRestartFailedError → 502, WorkspaceInitPathEscapeError
  → 400, WorkspaceInitSymlinkError → 400. Addresses #3260501148.
- initWorkspace boundary guard tests (2 added): symlink-at-target
  rejected, contextFilename '../outside.md' rejected. Addresses
  #3260501157.
- TrustGateError tests assert the typed class via `.toThrow(TrustGateError)`,
  not just message text. Addresses #3260501165.

Also updates the existing fold-in 4 S2 broadcast test to reflect
the new no-duplicate semantics on the requesting session.

Typecheck clean across cli / sdk-typescript / core.
1615/1615 unit tests pass.

* fix(serve): fold-in 2 — copilot + wenshao review on #4297

Round-2 reviewer adoption on the same PR:

Critical fixes:
- `restartMcpServer` JSDoc documents `timeoutMs: 0` as "disable the
  timeout entirely", but the `> 0` guard in `fetchWithTimeout`
  rejected `0` and silently fell back to the 30s client default.
  Loosened the guard to `>= 0` so `0` flows through to the
  no-timeout branch via the existing truthiness check; NaN /
  negative inputs still coerce to the client default. Addresses
  duplicate reports from copilot (#3260577538) and wenshao
  (#3260661833).
- TS2322 in the slow-fetch test stub: `resolveResponse` was typed
  against `import('undici-types').Response` but assigned a
  `(v: Response) => void`. Re-typed against the global `Response`
  throughout. Caught only by tsc runs that include the test
  files. Addresses #3260663072.

Test fidelity:
- Slow-fetch stub now observes `init.signal` and rejects on abort,
  so a regression that drops the per-call `timeoutMs` override
  will reliably fail the test instead of resolving after the
  timer fired (false-negative coverage). Addresses #3260577600.
- New test pinning the `timeoutMs: 0` semantics: 1ms client
  default + a stub that resolves after 50ms. Without the `>= 0`
  fix, the call would abort at 1ms; with it, the explicit
  `0` disables the timer and the call completes.

Bug fixes:
- `runQwenServe.contextFilenameForInit` previously called
  `String(arr[0])` on the array branch, producing a literal
  `"[object Object]"` filename for hand-edited bad data. Now
  validates each element with `typeof === 'string'` and falls
  back to `undefined` (so the bridge uses its
  `getCurrentGeminiMdFilename()` default) when no string is
  found. Addresses #3260577641.

Documentation drift:
- `Config.getDisabledTools()` JSDoc rewritten to describe the
  mutable-via-`setDisabledTools()` semantics introduced by P2-2,
  and the "registration-time only / no retroactive unregister"
  contract that pairs with it. Old comment claimed the set was
  frozen at construction. Addresses #3260577677.

Observability:
- `acpAgent` MCP-restart `loadSettings` failure now surfaces a
  stderr line naming the server + the underlying error, instead
  of silently swallowing it. The documented "toggle + restart"
  workflow used to break with zero diagnostic when settings.json
  was corrupted or unreadable. Addresses #3260663303.

Code organization:
- Moved `canonicalizeExistingAncestor` after `describeStatKind` so
  the latter's JSDoc is no longer orphaned (TypeScript only
  associates the last `/** ... */` block before a declaration).
  Addresses #3260668618.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.

* fix(serve): fold-in 3 — read merged scope on MCP restart refresh

Critical bug from wenshao review (#3260725526) on PR #4297:
the P2-2 acpAgent re-read narrowed `Config.disabledTools` to
`SettingScope.Workspace` alone, dropping User / System scope
entries. The bootstrap Config received `merged.tools?.disabled`
(union of all scopes), so user-level / system-level disables
worked at boot — but the first `mcp restart` would replace the
in-memory set with the workspace scope alone, silently re-enabling
any tool that was disabled at a higher scope but absent from the
workspace file.

The asymmetry vs. the persist-write path is deliberate and
documented:
- Reads (here): merged — match the bootstrap Config snapshot,
  preserve user/system policy.
- Writes (`runQwenServe.persistDisabledTools`): workspace scope —
  don't bake higher-scope entries into the workspace file
  (per-#4282 fold-in 1 H2 fix).

Two paths look alike but answer different questions.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.

* fix(test): fold-in 4 — wire timeoutMs:0 stub to init.signal

Critical follow-up from wenshao (#3260810242) on PR #4297:
the new `timeoutMs: 0` regression test (added in fold-in 2)
inherited the same flaw it was meant to prevent — the slow-fetch
stub didn't observe `init.signal`, so a regression that ignored
the `0` override would fire the AbortController at the 1ms client
default but the stub would keep the promise pending. The 50ms
`resolveResponse` would win, the test would still pass, and the
documented "0 disables timeout" contract would be unprotected.

Mirrored the listener pattern already used by the two sibling
tests in fold-in 2 — `init.signal.addEventListener('abort', () =>
reject(...))`. Now a regression that re-rejects `0` triggers the
abort, the stub rejects, the test fails.

8/8 restartMcpServer SDK tests pass; SDK typecheck clean.

* fix(serve): fold-in 5 — TOCTOU + setDisabledTools coverage

Two new critical reviews from wenshao on PR #4297:

C1 — TOCTOU between lstat and writeFile (#3260836305):
The `lstat(target)` symlink check and the subsequent `writeFile`
were two separate syscalls, leaving a race window where a local
attacker with workspace write access could substitute a symlink
between them. With `force: true`, `writeFile` would follow the
link and truncate an external target.

The `action === 'created'` path now uses `fs.open(target, 'wx')`
(O_WRONLY|O_CREAT|O_EXCL), which atomically refuses any
pre-existing inode (regular file, dir, OR symlink) at the target
path. EEXIST after the absence check most plausibly means a
race-created symlink, so we throw `WorkspaceInitSymlinkError(kind:
'target')` — same typed class the route maps to 400.

The `force: true` overwrite path retains the existing TOCTOU as a
documented limitation; closing it requires `O_NOFOLLOW`-aware open
which the post-PR18 `WorkspaceFileSystem` migration will provide.

C2 — P2-2 zero test coverage (#3260836302):
The `setDisabledTools` runtime sync was the only Wave-4 P2 fix
without a dedicated test. Added 5 Config-level tests:
- Initializes from `disabledTools` ConfigParameters
- Defaults to empty set when omitted
- `setDisabledTools` replaces the live snapshot
- Defensive copy: caller-set mutations don't leak into the live snapshot
- Accepts an empty set (clears live snapshot)

Plus a TOCTOU regression test in httpAcpBridge.test.ts that
spies fs.lstat / fs.readFile to simulate the race window:
pre-creates a symlink, makes lstat lie about it, asserts the
'wx' open catches the racing inode and throws the typed
`WorkspaceInitSymlinkError(kind: 'target')`.

1622/1622 unit tests pass; typecheck clean across cli /
sdk-typescript / core.

* fix(serve): fold-in 6 — count actual skips in broadcast alarm

DeepSeek review on #4297 (#3261079572):
`broadcastWorkspaceEvent` unconditionally subtracted 1 from the
`eligible` recipient count whenever `skipSessionId` was set, even
when the id matched zero live sessions (caller mistake, stale id,
or the matching session was just torn down between resolution and
broadcast). In a single-session workspace that's the difference
between `eligible = 0` (alarm suppressed) and `eligible = 1`
(alarm fires when the publish failed) — silently losing the
all-dropped breadcrumb the telemetry was meant to surface.

Today's call sites pass real session ids so the bug doesn't
manifest in practice, but the defensive shape is small: track
`skippedCount` inside the loop and subtract that, so the alarm
condition is self-consistent regardless of how the caller mis-uses
the param.

162/162 bridge tests pass; CLI typecheck clean.

* fix(serve): fold-in 7 — close overwrite TOCTOU, harden boot + diagnostics

Round-7 review on PR #4297. Three critical fixes + one suggestion
test, plus a regression test for the overwrite TOCTOU close.

C1 — force:true overwrite TOCTOU (#3262615446):
The fold-in 5 fix only closed the `'created'` action via 'wx';
the `'overwrote'` branch still used plain `fs.writeFile`, so a
local writer could swap the verified regular file to a symlink
between the lstat/readFile checks and the write and have the
forced overwrite truncate an external target. Switched to
`fs.open(target, O_WRONLY | O_TRUNC | O_NOFOLLOW)` — `O_NOFOLLOW`
makes open() fail with ELOOP on a symlink at the final component
even under race. ELOOP / ENOENT (race-deleted) translate to
`WorkspaceInitSymlinkError(kind: 'target')` so the route still
maps to a structured 400 instead of a generic 500.

C2 — settings.json corrupt blocks daemon boot (#3262625091):
`loadSettings(boundWorkspace)` at boot had no try/catch — a
corrupted, malformed, or temporarily unreadable settings file
threw synchronously and prevented daemon startup. Pre-PR this
never happened because settings were read lazily inside request
handlers. Wrapped in try/catch with stderr fallback so the daemon
keeps booting (with the bridge's default context filename) when
the file is broken.

C3 — malformed `tools.disabled` clears policy silently (#3262625101):
When `merged.tools?.disabled` is present but not an array
(boolean / string / object from a hand-edited settings.json), the
ternary `Array.isArray(...) ? ... : []` substituted an empty list
without firing the surrounding catch block. After an MCP restart
every disabled tool would silently re-register. Added an explicit
`!Array.isArray && !== undefined` check that stderr-logs the
malformed type before clearing — operators see the
misconfiguration instead of a stealth re-enable.

S1 — contextFilename extraction tested (#3262690842):
Lifted the inline `firstStringInArray` + branching into an
exported `extractContextFilename(value: unknown)` helper and
added `runQwenServe.test.ts` with 5 tests covering the four
branches the suggestion called out: non-empty string, array with
strings, array with no strings, non-string non-array.

Plus a TOCTOU regression test for the overwrite path that
verifies `O_NOFOLLOW` returns `WorkspaceInitSymlinkError(kind:
'target')` when the file is race-substituted with a symlink
behind the lstat/readFile mocks.

S2 (acpAgent restart-handler integration test #3262690845) is
deferred — Config-level coverage of `setDisabledTools` already
locks the load-bearing surface (5 tests in fold-in 5), and
adding a full acpAgent integration test requires heavy ext-method
plumbing. The new C3 stderr diagnostic plus existing tests give
us the regression signal we need without that scaffolding.

1627/1627 unit tests pass; typecheck clean across cli /
sdk-typescript / core / acp-bridge.

* fix(serve): fold-in 8 — split ELOOP / ENOENT diagnostic in overwrite path

qwen-latest review on PR #4297 (#3262861754):
The fold-in 7 ELOOP/ENOENT branch shared one error message that
said "swapped to a symlink." That's accurate for ELOOP (genuine
O_NOFOLLOW rejection — likely an attack race) but misleading for
ENOENT in the overwrite path: there `readFile` just succeeded
proving the file existed, so ENOENT means the file was DELETED
between the content check and the open — a benign race with a
concurrent writer (git checkout, editor save, lockfile rename),
NOT a symlink swap. An operator seeing the symlink language for
a benign delete would `ls -la`, see no symlink, and waste time
hunting an attack that didn't happen.

Split into two messages:
- ELOOP: "swapped to a symlink between the content check and the
  overwrite — refusing to follow it"
- ENOENT: "deleted between the content check and the overwrite
  (likely a concurrent writer) — refusing to recreate blindly"

Both still surface as `WorkspaceInitSymlinkError(kind: 'target')`
so the route maps to a structured 400; the class doubles as the
workspace-init race-condition bucket with kind='target' meaning
"target inode misbehaved at write time" generally.

Updated the existing fold-in 7 TOCTOU test to assert the ELOOP
message specifically, and added a new ENOENT race-delete test
that mocks lstat/readFile to land on the overwrote action against
a non-existent path — verifies the message says "deleted" and
NOT "swapped to a symlink."

170/170 bridge tests pass; CLI typecheck clean.

* fix(serve): fold-in 9 — route MCP restart through registry cleanup wrapper

gpt-5.5 critical review on PR #4297 (#3263088414):

The fold-in 5 P2-2 fix refreshed `Config.disabledTools` from merged
settings, but then called `manager.discoverMcpToolsForServer()`
directly — bypassing the `ToolRegistry.discoverToolsForServer`
wrapper that PURGES the server's existing `DiscoveredMCPTool`
entries (and `revealedDeferred` markers) plus its prompts before
rediscovery. Without the cleanup, `registerTool` only consulted
the refreshed `disabledTools` set for NEWLY-discovered tools —
entries already in the registry from the prior MCP boot kept
serving requests. Net effect: toggle-disable-then-restart
silently left the disabled tool live, breaking the documented
"toggle + restart" workflow that P2-2 was meant to fix.

Routed through `toolRegistry.discoverToolsForServer(serverName)`
which:
1. Removes existing `DiscoveredMCPTool` entries for this server
2. Drops their `revealedDeferred` reveal state
3. Removes the server's prompts via `removePromptsByServer`
4. THEN delegates to `manager.discoverMcpToolsForServer` for the
   actual reconnect + rediscover

The pre-discovery budget / in-flight checks still go through the
`manager` reference (which is the same object the registry
wrapper would forward to) — so soft-skip semantics for
`budget_would_exceed`, `in_flight`, `disabled` are preserved.

CLI typecheck clean; 403/403 server + bridge tests pass.

* fix(serve): fold-in 10 — qwen-latest 05:45-round review on #4297

5 review threads from qwen-latest's late round on PR #4297 (now closed
in favor of #4313 against `daemon_mode_b_main`). 1 critical + 4
suggestions, all adopted.

C1 — extractContextFilename / getCurrentGeminiMdFilename divergence
(#3263954685): with `context.fileName: ['  ', 'AGENTS.md']`, the
daemon parent's `extractContextFilename` (which skips empty entries)
wrote `AGENTS.md`, but the ACP child's `getCurrentGeminiMdFilename`
(which returned `arr[0]` unconditionally) read `''`. The init'd file
was orphaned. Aligned `getCurrentGeminiMdFilename` to skip empty
entries with the same semantics, falling back to
`DEFAULT_CONTEXT_FILENAME` when all entries are empty.

S2 — WorkspaceInitSymlinkError reused for non-symlink races
(#3263954690): the EEXIST race-create and ENOENT race-delete cases
were surfacing as `code: 'workspace_init_symlink'`, misleading
operators into hunting symlink attacks for benign concurrent-
modification windows. Split into a sibling `WorkspaceInitRaceError`
class (`kind: 'eexist' | 'enoent'`, HTTP code
`workspace_init_race`). The genuine symlink class stays for ELOOP,
lstat-detected target symlinks, and parent-realpath escapes.

S3 — fsConstants.O_NOFOLLOW defensive `?? 0` (#3263954697): matches
the existing codebase convention in
`core/src/utils/{sessionStorageUtils,gitDiff}.ts` and
`cli/src/ui/utils/customBanner.ts`. Functionally a no-op (JS
bitwise coerces undefined to 0) but consistent.

S5 — Parent-directory TOCTOU still open (#3263954707): O_NOFOLLOW
only protects the final path component; a local writer could swap
a real parent dir for a symlink between
`canonicalizeExistingAncestor` and `fs.open`. Added
`verifyParentWithinWorkspace` post-open helper that re-realpaths
`path.dirname(target)` and refuses with
`WorkspaceInitSymlinkError(kind: 'parent')` if the parent moved.
On the create path (where we just opened with `'wx'`), the failure
also unlinks the file we just made best-effort. Residual race
window narrowed from "between pre-check and open" to "between
post-open realpath and writeFile" — sub-millisecond, documented as
accepted Stage-1 trust posture.

S4 — broadcastWorkspaceEvent vs publishWorkspaceEvent stale comment
(#3263954688): the "now removed" comment was inaccurate (5 call
sites still use the closure). Replaced with an accurate
description of why both coexist (factory closure can't `this`-call
proxy member; closure also takes `skipSessionId` for persisted
approval-mode mirror) and a TODO marker for future helper extraction.

Two existing tests updated to assert the new `WorkspaceInitRaceError`
class for EEXIST / ENOENT scenarios (the symlink-class assertions
are preserved for ELOOP / lstat / parent cases).

1759/1759 unit tests pass; typecheck clean across all 4 packages.

* feat(acp-bridge): F1 — acp-bridge package self-sufficiency (#4175 mechanical lift + BridgeFileSystem seam) (#4319)

* refactor(acp-bridge): lift defaultSpawnChannelFactory to acp-bridge/spawnChannel (#4175 F1 step 1)

First mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves the production spawn factory + its `killChild` helper +
`SCRUBBED_CHILD_ENV_KEYS` denylist + `KILL_HARD_DEADLINE_MS` constant
from `cli/src/serve/httpAcpBridge.ts` (~283 lines) to
`@qwen-code/acp-bridge/spawnChannel`. This unblocks
`channels/base/AcpBridge.ts` and `vscode-ide-companion`'s
acpConnection from each reimplementing the child lifecycle — they can
now consume the same primitive.

Backward compatible: `cli/src/serve/httpAcpBridge.ts` imports the
lifted factory and re-exports it, so existing references in
`cli/src/serve/index.ts:90` and the factory's own internal usage
(`opts.channelFactory ?? defaultSpawnChannelFactory`) keep resolving.
Bridge tests that mock `defaultSpawnChannelFactory` via
`BridgeOptions.channelFactory` are unaffected.

Side cleanups: drops `spawn` / `ChildProcess` / `Readable` / `Writable`
/ `ndJsonStream` / `MissingCliEntryError` imports from
httpAcpBridge.ts (all only used by the lifted spawn factory).

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift BridgeClient + permission types to acp-bridge/bridgeClient (#4175 F1 step 2)

Second mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves `BridgeClient` class (~700 LOC) + `PendingPermission` interface +
`PermissionResolutionRecord` interface + `MAX_RESOLVED_PERMISSION_RECORDS`
constant + early-event capacity constants + `describeStatKind` and
`sliceLineRange` helpers from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridgeClient`.

Design choice for SessionEntry boundary: introduce a minimal
`BridgeClientSessionEntry` interface in bridgeClient.ts with only the
four fields BridgeClient actually reads from the factory's richer
`SessionEntry` (`sessionId`, `events`, `pendingPermissionIds`,
`activePromptOriginatorClientId`). The factory's `SessionEntry`
structurally satisfies it — TypeScript's structural typing enforces
the match at the `resolveEntry` callback signature, so no explicit
conversion is required and the bridge package stays free of daemon-host
session-bookkeeping types.

Cross-package writeStderrLine handling: inline the 3-line helper in
bridgeClient.ts (mirrors the spawnChannel.ts pattern from F1 step 1)
so acp-bridge has no reverse dependency on `cli/src/utils/stdioHelpers`.

httpAcpBridge.ts shrinks from 4406 LOC to 3647 LOC (-759 lines).
Removed ACP SDK imports that only BridgeClient consumed: `Client`,
`RequestPermissionRequest`, `WriteTextFileRequest`,
`WriteTextFileResponse`, `ReadTextFileRequest`, `ReadTextFileResponse`,
`SessionNotification`. Kept the ones the factory still uses
(`CancelNotification`, `PromptRequest`, `RequestPermissionResponse`,
`SetSessionModelRequest`, `SetSessionModelResponse`).

Backward compatible: httpAcpBridge.ts re-exports `BridgeClient`,
`BridgeClientSessionEntry`, `PendingPermission`,
`PermissionResolutionRecord`, and `MAX_RESOLVED_PERMISSION_RECORDS` so
the `ChannelInfo.client: BridgeClient` field declaration below + any
embedder reaching into these types keep resolving.

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- 229/229 cli server tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift createHttpAcpBridge factory to acp-bridge/bridge (#4175 F1 step 3)

Third + final mechanical lift of #4175 F1 (acp-bridge package
self-sufficiency). Moves the `createHttpAcpBridge` factory closure
(~3000 LOC) + `ChannelInfo` + `SessionEntry` interfaces + factory-only
helpers (`canonicalizeExistingAncestor`, `verifyParentWithinWorkspace`,
`withTimeout`, `isServeDebugLoggingEnabled`, `writeServeDebugLine`,
`hasControlCharacter`) + factory constants (`DEFAULT_INIT_TIMEOUT_MS`,
`MCP_RESTART_TIMEOUT_MS`, `DEFAULT_MAX_SESSIONS`, `MAX_EVENT_RING_SIZE`,
`DEFAULT_PERMISSION_TIMEOUT_MS`, `DEFAULT_MAX_PENDING_PER_SESSION`,
`MAX_DISPLAY_NAME_LENGTH`) from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridge`.

`cli/src/serve/httpAcpBridge.ts` shrinks from 3647 LOC to 97 LOC — a
pure re-export shim that preserves every existing relative import
path (`./httpAcpBridge.js`) so `server.ts`, `runQwenServe.ts`,
`workspaceAgents.ts`, `workspaceMemory.ts`, `index.ts`, plus the bridge
test suite, keep resolving without any call-site changes.

The new `bridge.ts` reuses what was already in acp-bridge (errors,
types, options, status helpers, channel types, event bus, workspace
paths) via local relative imports — no reverse dependency on `cli`.
`writeStderrLine` is inlined at the top of `bridge.ts` (same pattern as
`spawnChannel.ts` + `bridgeClient.ts` from F1 steps 1-2) so the
package self-contained promise holds.

Cumulative F1 impact across the 3 mechanical lift steps:
- httpAcpBridge.ts: 4682 LOC → 97 LOC (-4585 lines; the original file
  was 98% bridge core, 2% backward-compat re-exports)
- 3 new files in acp-bridge: spawnChannel.ts (~270 LOC), bridgeClient.ts
  (~745 LOC), bridge.ts (~3515 LOC)
- All daemon-host concerns (env snapshot, daemon preflight cells)
  remain in `cli/src/serve/daemonStatusProvider.ts` and reach the
  bridge through the `BridgeOptions.statusProvider` seam frozen by
  PR 22b/2.

- 735/735 cli serve tests pass across 17 files
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- typecheck clean across acp-bridge + cli

`packages/cli/src/serve/httpAcpBridge.test.ts` (~6600 LOC) is
intentionally NOT moved in this commit — it currently imports
`createHttpAcpBridge` / `defaultSpawnChannelFactory` / `BridgeClient`
via the cli shim and keeps passing without changes. Moving it to
`acp-bridge/src/bridge.test.ts` is a follow-up worth tracking
separately so the production-code lift can land + be reviewed cleanly.

The `BridgeFileSystem` injection seam (originally bundled into F1 as
the 22b' scope) is also deferred to a follow-up so the mechanical lift
stays mechanical — design + implementation of the fs injection is its
own discussion.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* feat(acp-bridge): add BridgeFileSystem injection seam (#4175 F1 step 5, 22b' scope)

Adds the `BridgeFileSystem` injection seam originally scoped as #4175
22b'. When a `BridgeFileSystem` is wired through
`BridgeOptions.fileSystem`, `BridgeClient.readTextFile` and
`BridgeClient.writeTextFile` delegate to it instead of running their
inline `fs.realpath` / `fs.writeFile` / `fs.readFile` proxy.

This unblocks production `qwen serve` plumbing PR 18's
`WorkspaceFileSystem` (TOCTOU guards, symlink-substitution checks,
trust gate, `.gitignore`, audit hooks) into the ACP fs methods —
closing the `ws.ts:613` follow-up thread that has been tracked since
PR 18 landed. The serve-side adapter that wraps `WorkspaceFileSystem`
+ the `runQwenServe` wiring are intentionally split into the
immediate-follow-up so this PR stays focused on the seam design.

Backward compatible: `fileSystem` is optional on `BridgeOptions`.
Tests, Mode A in-process consumers, channels (`packages/channels/base/
AcpBridge.ts`), and the VSCode IDE companion all keep working
unchanged — they omit the field and `BridgeClient` falls through to
the inline proxy that has been the Stage 1 default since #3889.

API:
- `BridgeFileSystem.readText(params: ReadTextFileRequest):
  Promise<ReadTextFileResponse>`
- `BridgeFileSystem.writeText(params: WriteTextFileRequest):
  Promise<WriteTextFileResponse>`

The interface mirrors ACP SDK request/response types directly so the
adapter does the minimum amount of translation (`{ path, content }`
↔ `WorkspaceFileSystem`'s `ResolvedPath` brand types + options bag).

- 735/735 cli serve tests pass (inline fallback path preserved)
- 44/44 acp-bridge tests pass
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): catch README + stale source comments up to F1 lift

Self-review fold-in: post-F1 the package README still said "PR 22a"
and listed `BridgeClient` / `createHttpAcpBridge` /
`defaultSpawnChannelFactory` under "What's not here yet" — both
contradicted by this PR. Updated:

- README lift-history table now shows PR 22a / 22b/1 / 22b/2 as
  merged and F1 (this PR) as the slice that closes the bridge core
  + adds `BridgeFileSystem`. F3 PR 24 row aligned to the
  feature-cohesive plan.
- "What's here today" now documents `spawnChannel`, `bridgeClient`,
  `bridge`, `bridgeFileSystem` modules.
- "What's not here yet" section removed (its 2 bullets are both
  resolved by F1).
- Subpath import list updated to enumerate all 14 subpaths.
- Backward-compat section updated to call out the 97-line shim and
  the 6 consuming files that still import via `./httpAcpBridge.js`.

Source-comment line-number drift:
- `channel.ts:12` no longer claims `defaultSpawnChannelFactory` is
  "still in cli/src/serve/httpAcpBridge.ts" — points to the lifted
  location.
- `permission.ts:33` + `permission.ts:45` no longer reference
  `httpAcpBridge.ts:1096-1106` / `httpAcpBridge.ts:1003` (file is
  now 97 lines after F1). Updated to point at the structurally-
  equivalent locations inside the lifted `bridgeClient.ts`.
- `permission.ts:7` no longer says first-responder still lives in
  `cli/src/serve/httpAcpBridge.ts` — points at the bridgeClient.ts
  location.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): adopt 3 Copilot review comments on F1 doc accuracy

Folds in 3 of 4 Copilot inline comments from #4319 review:

1. `bridgeClient.ts` writeTextFile preserveMode comment said "fall
   through to umask defaults" for new files, but the code passes
   `mode: preserveMode?.mode ?? 0o600` to `fs.writeFile`. Updated the
   "BkwQW" comment + the inner catch-block comment to clarify that
   new files actually get the `0o600` default applied at writeFile
   time (NOT umask defaults — the explicit `mode` arg bypasses umask
   for atomicity per the `Blehd` comment block).

2. `bridgeFileSystem.ts` JSDoc referenced
   `cli/src/serve/bridgeFileSystemAdapter.ts` as if the file exists,
   but it's deferred to the immediate F1 follow-up PR. Reworded as
   "the immediate follow-up PR will land a serve-side adapter" so
   reviewers don't grep for a non-existent file.

3. `bridgeOptions.ts` `fileSystem` field JSDoc had the same wording
   issue ("Production `qwen serve` wires this to..."). Same fix — now
   says "The immediate F1 follow-up will land a serve-side adapter"
   so the deferred state is obvious.

Declined from this review round:

- Copilot inline #1 (`spawnChannel.ts:155` stderr forwarder drops
  empty lines): pre-existing behavior since #3889. F1 lifted verbatim
  — not a regression introduced here. Out of scope for a lift PR.
- github-actions bot summary: most items are pre-existing notes
  (TOCTOU residual race, SCRUBBED_CHILD_ENV_KEYS allowlist concern,
  sliceLineRange benchmark threshold) on code the F1 lift moved
  verbatim. One ("httpAcpBridge.ts still has ~3700 LOC") is a false
  positive — the file is 97 LOC after F1. Others are cosmetic
  refactors (extract FIXME to tracking issue, ARCHITECTURE_DECISIONS
  doc system, deprecation timeline) that aren't worth churning the
  lift PR over.

- 44/44 acp-bridge tests pass
- typecheck clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): tighten BridgeFileSystem contract + re-export type from shim

Self-review + code-reviewer agent fold-in, two changes:

1. `cli/src/serve/httpAcpBridge.ts` shim now re-exports
   `BridgeFileSystem` from `@qwen-code/acp-bridge/bridgeFileSystem`
   so the immediate F1 follow-up adapter (in `cli/src/serve/`)
   can import it via the established `./httpAcpBridge.js` path
   like every other daemon-side bridge import does. Without this
   the adapter would need to deep-import from acp-bridge while
   every other serve file goes through the shim — inconsistent.

2. `BridgeFileSystem.readText` + `writeText` JSDoc now spells out
   the two defensive gates the inline proxy carried (non-regular-
   file rejection + 100 MiB buffered-size cap for reads;
   write-then-rename atomicity + dangling-symlink walk-through +
   mode preservation + `0o600` new-file default for writes). When
   a `BridgeFileSystem` is injected, the inline path is FULLY
   bypassed — without the contract spelled out, a future adapter
   author could silently drop the `/dev/zero` / 500 MB log RSS
   defenses the inline path established.

Note on F1 CI: this PR targets `daemon_mode_b_main` but the
`.github/workflows/ci.yml` `pull_request` trigger is scoped to
`branches: main / release/**`, so the main CI workflow (Lint /
Test on Linux/macOS/Windows / CodeQL) does NOT run on this PR.
This is a by-design side effect of the new feature-cohesive
branching strategy — `daemon_mode_b_main → main` periodic merges
will trigger the full CI matrix, providing safety net coverage
before any F-series work lands on `main`. Locally verified:
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- 735/735 cli serve tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover BridgeFileSystem injection seam + extract shared writeStderrLine (#4319 wenshao review)

Folds in wenshao review on #4319:

1. **[Critical]** zero test coverage for the F1 step 5 `BridgeFileSystem`
   delegation branches in `BridgeClient.writeTextFile` /
   `BridgeClient.readTextFile` and the factory's
   `opts.fileSystem` → constructor positional-arg forwarding.

   New `packages/acp-bridge/src/bridgeClient.test.ts` adds 6 tests
   covering:
   - writeTextFile delegates to injected fileSystem.writeText (inline
     proxy fully bypassed; `fakeFs.writeText` called with the original
     params; `readText` mock not invoked)
   - writeTextFile invalid-path call succeeds purely via the mock
     when fileSystem is injected (proof that the inline `fs.realpath`
     path doesn't run)
   - readTextFile delegates to injected fileSystem.readText
   - readTextFile propagates injection errors to the caller
   - inline-fallback regression guard: write actually hits disk via
     the inline proxy when fileSystem is omitted (real tmp file
     round-trip)
   - same for read

   Why these matter: the 7-arg `BridgeClient` constructor places
   `fileSystem` at the tail as optional. A reordering — or dropping
   the arg from `bridge.ts` factory's `new BridgeClient(..., opts.fileSystem)`
   call — would silently bypass the adapter in production and the
   inline `fs.writeFile` raw-path would run with no audit / trust /
   TOCTOU coverage. The delegation tests would catch that because
   the mock fileSystem would never be invoked.

2. **[Suggestion]** `writeStderrLine` was defined identically in
   `bridge.ts:117` and `bridgeClient.ts:30` (22 call sites across the
   two files). Both consumers live in the SAME `@qwen-code/acp-bridge`
   package, so the original "no reverse-dep on cli" justification
   doesn't apply within the package. Extracted to
   `packages/acp-bridge/src/internal/stderrLine.ts` — a single source
   of truth that future behavior changes (timestamp prefix, log
   level, structured field) can edit once. `internal/` subpath is
   intentionally not in `package.json`'s `exports`, keeping the
   helper package-private. `spawnChannel.ts` deliberately does NOT
   consume it (its stderr writes use `process.stderr.write(prefix +
   line + '\n')` directly because each line carries its own
   `[serve pid=… cwd=…]` line prefix).

- 6/6 new BridgeFileSystem-seam tests pass
- 50/50 acp-bridge total (44 existing + 6 new)
- 174/174 cli httpAcpBridge tests pass (no regression from refactor)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover defaultSpawnChannelFactory env scrubbing + fix bridge.ts comment refs (#4319 wenshao round 2)

Folds in wenshao review on #4319 round 2 — 1 Critical + 2 Suggestions:

1. **[Critical] spawnChannel.ts has 0 unit tests, security-critical
   paths untested.** Now that `defaultSpawnChannelFactory` is a public
   export of `@qwen-code/acp-bridge`, channels + IDE consumers can't
   rely on cli-package integration tests for env-scrubbing guarantees.

   Refactored the inline env-scrubbing logic into a pure exported
   helper `scrubChildEnv(source, scrubbed, overrides)`. Behavior is
   byte-identical to the pre-extraction inline implementation; the
   factory body now reads:

       const childEnv = scrubChildEnv(
         process.env, SCRUBBED_CHILD_ENV_KEYS, childEnvOverrides);

   Added `packages/acp-bridge/src/spawnChannel.test.ts` with 12 tests
   covering:
   - shallow-clone (no aliasing into live process.env)
   - QWEN_SERVER_TOKEN stripping
   - non-scrubbed vars pass through
   - override-add a new key
   - override-replace an existing key
   - override with undefined deletes the key (PR 14 fix #4247 wenshao R5)
   - override CANNOT re-introduce a scrubbed key (defense in depth)
   - override CANNOT undo the scrub by setting undefined for a scrubbed key
   - override-apply-after-scrub ordering invariant
   - empty overrides equals no overrides
   - multi-key scrub for forward-compat (the WARNING comment on
     SCRUBBED_CHILD_ENV_KEYS anticipates a future sandboxed-agent
     mode expanding the denylist; this verifies the loop already
     handles that)

   The killChild SIGTERM→SIGKILL escalation + STDERR_LINE_CAP_CHARS
   truncation are NOT covered yet — they require either real child
   processes or extensive node:child_process mocking; both are
   orthogonal to the env-scrubbing security guarantees wenshao
   explicitly called out, and can land as a follow-up if anyone
   wants the full surface tested.

2. **[Suggestion] bridge.ts comments referenced a "consolidated re-
   export block earlier in this file" that doesn't exist in acp-bridge
   (only in the cli shim).** Fixed both occurrences (~line 292, ~line
   310) to point at the actual local import + the package barrel
   re-export.

3. **[Suggestion] bridge.ts canonicalizeWorkspace re-export comment
   referenced `./fs/paths.ts`.** Updated to mention the full lift
   chain: extracted to `cli/src/serve/fs/paths.ts` in PR 18, then
   lifted here to `./workspacePaths.ts` in PR 22b/1.

- 12/12 new spawn env-scrub tests pass
- 62/62 acp-bridge total (50 existing + 12 new spawn)
- 174/174 cli httpAcpBridge tests still pass (the factory's inline
  env-scrubbing refactor preserves byte-identical behavior)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): fix 14-arg→7-arg typo in test docstring + simplify canonicalizeWorkspace re-export doc (#4319 wenshao round 3)

Folds in 2 of 3 wenshao Suggestions from #4319 round 3:

1. `bridgeClient.test.ts:20` JSDoc said "the 14-arg constructor's
   positional slot" — typo I introduced when writing the test in
   `fbc92bccf`. The same docstring correctly says "the constructor
   takes 7 positional args" at line 25. Updated to "7-arg".

2. `bridge.ts:3461` `canonicalizeWorkspace` re-export JSDoc no longer
   references the historical `cli/src/serve/fs/paths.ts` location.
   Reads cleaner as a present-tense pointer to `./workspacePaths.ts`
   (where the implementation actually lives now post-PR 22b/1).
   Git history covers the lift chain; the docstring should describe
   current state.

DECLINED + tracked separately:

- **[Critical]** `closeSession` + `killSession` use module-scoped
  `channelInfo` instead of `channelInfoForEntry(entry)` — channel-
  overlap edge case can kill the wrong channel. Wenshao explicitly
  notes "pre-existing bug preserved by the lift" — F1's mechanical-
  lift scope shouldn't carry behavior fixes, and the fix needs a
  channel-overlap regression test to land safely. Tracked as #4325.

- 62/62 acp-bridge tests pass (no regression from doc tweaks)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): polish from second-pass self-review (cross-platform test + package metadata + dead tombstones)

Five small adoptions from a second-pass code-reviewer agent review on
F1 (no new external comments — pre-emptive cleanup before reviewer
returns):

1. **`bridge.ts:290-313`** — deleted two standalone "InvalidPermission
   OptionError / WorkspaceInit* / McpServer* lifted to bridgeErrors"
   tombstone comments. Pre-22b they were load-bearing (explained why
   the class wasn't `class`-defined inline at that file location).
   Post-F1 the symbols are imported at the top of the file and the
   comments sit between unrelated code (`writeServeDebugLine` /
   `MAX_DISPLAY_NAME_LENGTH` / `DEFAULT_INIT_TIMEOUT_MS`) with no
   anchor. Dead doc — removed.

2. **`README.md`** — `spawnChannel` entry now lists `scrubChildEnv`
   alongside `defaultSpawnChannelFactory` + `killChild` +
   `SCRUBBED_CHILD_ENV_KEYS`. Channels / VSCode IDE consume the
   package barrel so the helper should be visible in the inventory.

3. **`package.json:description`** — refreshed from the PR 22a wording
   ("EventBus, AcpChannel, in-memory channel, PermissionMediator
   interface") to include F1 additions (`createHttpAcpBridge` /
   `BridgeClient` / `defaultSpawnChannelFactory` / `BridgeFileSystem`).
   Visible on `npm view`-style tooling + IDE hover so worth keeping
   current.

4. **`bridgeClient.test.ts:92-115`** — swapped `/proc/no-such-file`
   for `/this/dir/never/exists/file.txt` and reworded the comment.
   `/proc/` is Linux-only; on macOS / Windows the inline proxy's
   dangling-symlink fallback would write through to a path under
   root rather than failing. Test passed regardless (mock assertion,
   not real disk) but the comment overstated portability.

5. **`spawnChannel.test.ts:36`** — added a comment block explaining
   why the test deliberately hand-rolls the SCRUBBED set instead of
   importing the production `SCRUBBED_CHILD_ENV_KEYS`. The
   decoupling is intentional (pure-function parameterized test +
   forward-guard for future denylist expansion) but a naive reader
   would think it's an oversight.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint + pre-commit hooks clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(acp-bridge): bridge.ts security fold-in from #4297 review (3 issues)

Folds 3 unresolved review comments from the post-merge thread on #4297
(wenshao via qwen-latest agent) into F1 (#4319). All 3 touch
`acp-bridge/src/bridge.ts` — the same file F1 already moves the lifted
factory into — so consolidating here saves opening a separate
follow-up PR and keeps the security narrative in one reviewable
commit. The 2 cross-package fixes (`core/src/memory/const.ts` test
gap + `cli/src/serve/runQwenServe.ts` malformed-context fallback)
will land as their own small PRs after F1 merges.

#### Fix 1 (wenshao Critical, #4297 thread): `fs.unlink(target)`
arbitrary-file-deletion primitive in `verifyParentWithinWorkspace`
'create'-cleanup

After `fs.open(target, 'wx')` creates the empty file at the real
parent, an attacker with local workspace write access can swap the
parent directory for a symlink (`docs/` → `/etc`). The cleanup's
`fs.unlink(target)` re-resolves the TEXTUAL path through the
attacker's freshly-planted parent symlink, deleting whatever file
exists at the external location.

Fix: drop the `fs.unlink(target)` line. The 0-byte file at the
pre-race location is harmless (0 bytes, inside the workspace we'd
already verified) — leaving it over deleting an arbitrary external
file is the right safety trade. Comment block explains the
reasoning so future maintainers don't re-introduce the unlink.

#### Fix 2 (wenshao Critical): `O_TRUNC` arbitrary-file-truncation
primitive in workspace-init 'overwrite' branch

`O_TRUNC` causes the kernel to truncate the file to zero bytes AT
`open(2)` SYSCALL TIME — strictly before `verifyParentWithinWorkspace`
runs. A parent-symlink TOCTOU race between
`canonicalizeExistingAncestor` and this `open()` zeros the file at
the attacker-redirected location (arbitrary-file-truncation
primitive against any file the daemon UID can open). The pre-fix
code's own comment on `verifyParentWithinWorkspace` acknowledged
this as "Acceptable residual posture for the Stage-1 trust model";
wenshao pushed back that arbitrary-file-zeroing exceeds the
Stage-1 trust budget.

Fix: drop `O_TRUNC` from the open flags. Truncation moves to AFTER
`verifyParentWithinWorkspace` succeeds, via `fh.truncate(0)` on the
fd we already hold. fd-based truncate does NOT re-resolve the path
— an attacker swapping the parent symlink after we open can't
redirect the truncation.

#### Fix 3 (wenshao Suggestion): `canonicalizeExistingAncestor`
missing `ELOOP` catch

Circular symlinks in the parent path (`a -> b`, `b -> a`) cause
`fs.realpath` to fail with `ELOOP`. Without catching it, the error
propagates as an unstructured HTTP 500 instead of the typed
`WorkspaceInitSymlinkError` (HTTP 400) the route handler expects
from the workspace-init race-detection family.

Fix: add `'ELOOP'` to the caught error codes alongside `'ENOENT'`
and `'ENOTDIR'`. Walking up the parent chain when ELOOP hits at a
sub-component preserves the existing "walk to the deepest extant
ancestor" contract — the deepest realpath-able ancestor still
dictates the canonical prefix.

#### Why no new tests in this commit

- Fix 1 is a single-line removal: any regression that re-adds the
  unlink would be caught by reviewing the diff; existing 174-test
  `httpAcpBridge.test.ts` integration suite confirms the create-path
  still works (file is created + closed correctly; only the
  attacker-cleanup branch changes).
- Fix 2 is a structural move (truncate from open-time to post-verify);
  the existing overwrite-init integration tests confirm the
  end-to-end behavior is unchanged (file ends up empty after init).
  Adding a TOCTOU race regression test requires controlled
  filesystem-race simulation that exceeds reasonable test infra
  scope for this PR.
- Fix 3 is a one-word addition to an error code list; the
  `canonicalizeExistingAncestor` helper is module-private and the
  integration test for circular-symlink → typed 400 would require
  exporting it OR setting up a real circular-symlink workspace.
  Both routes widen scope beyond the security fix itself; the
  high-level behavior is verifiable by the existing route-error-
  mapping test pattern + diff review.

A follow-up PR can add the integration tests once the security fix
itself has shipped; the immediate priority is closing the
arbitrary-file-deletion + arbitrary-file-truncation primitives.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint clean

#### Refs

- Original review on #4297 (wenshao via qwen-latest agent), post-
  merge, currently unresolvable on #4297 itself because that PR is
  already MERGED.
- Other 2 #4297 review threads (`const.ts` test coverage,
  `runQwenServe.ts` malformed-context observability) target files
  outside F1's scope and will land as separate follow-up PRs.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix: post-merge Codex P2 fold-in — MCP restart disabled-tools normalization + SDK timeout headroom (#4319)

Folds in 2 P2 findings from a Codex review run on `git diff main...HEAD`
of F1 PR #4319. Both are pre-existing in code merged into
`daemon_mode_b_main` before F1 was created (#4282 PR 17), but they're
tiny tactical fixes (~25 LOC + 1 LOC) on the same integration branch
the same reviewer (wenshao) already engages with, so folding into F1
saves an extra follow-up PR cycle.

#### Fix 1: normalize disabled tool names during MCP restart refresh

`packages/cli/src/acp-integration/acpAgent.ts:1563-1566`

The bootstrap path in `cli/src/config/config.ts:1426-1434` applies a
4-step normalization to `tools.disabled`:
  1. typeof string filter
  2. .trim()
  3. drop empty after trim
  4. dedupe via Set

The MCP-restart refresh path only did step 1, then stored the raw
strings. `ToolRegistry` checks disabled tools with EXACT
`Set.has(tool.name)`, so a tool disabled at boot as `' Foo '` (or
`'Foo\n'`) is no longer matched after `restartMcpServer` and gets
silently re-registered. This contradicts the documented "toggle +
restart" workflow that #4282 PR 17 advertised.

Fix: mirror the bootstrap normalization verbatim before
`setDisabledTools`. Adds 6 lines + a 7-line comment pointing at the
bootstrap reference for future maintainers.

#### Fix 2: add headroom to MCP restart SDK timeout

`packages/sdk-typescript/src/daemon/DaemonClient.ts:102`

The SDK's `MCP_RESTART_DEFAULT_TIMEOUT_MS` was EXACTLY 300_000ms, the
same ceiling the daemon's own `MCP_RESTART_TIMEOUT_MS` uses for the
upper bound on a single MCP rediscovery. For restarts that finish
(or fail with a typed `McpServerRestartFailedError` JSON envelope)
near 300s, the client `AbortSignal` could fire BEFORE the daemon had
finished serializing + transmitting the response, yielding a client
`TimeoutError` even though the daemon was still within its own
budget.

Fix: bump to 330_000ms (10% / 30s headroom over the daemon ceiling).
Comment updated to call out the race + the rationale for the
specific headroom value. Callers needing tighter caps still pass
their own `timeoutMs` to `restartMcpServer`.

#### Why folded into F1 vs separate follow-up PRs

These are post-merge findings on `#4282 PR 17` code, not F1-introduced
regressions. Normally we'd track as separate follow-up issues (mirror
of the #4325 / `channelInfo` decline). But:

- Both fixes are TINY (~25 LOC + ~2 LOC including comment); the bridge
  security fold-in commit `7bd66c6e8` set the precedent of folding in
  small same-branch issues when the cost-benefit favors closing them
  immediately.
- Same reviewer (wenshao via qwen-latest agent) — won't be confused
  by the scope expansion; in fact the original PR 17 commenter is
  also the one who'd review the follow-up issue's fix.
- Both fixes target `daemon_mode_b_main`-only paths (MCP restart route
  added by PR 17 lives on the integration branch).
- Saves opening 2 trivial follow-up issues that would just sit until
  someone picks them up.

#### Verification

- sdk-typescript: 424/424 tests pass (no test hardcoded the old
  300_000 default — only the constant declaration itself referenced it)
- cli acp-integration: 282/282 tests pass (no test exercised the
  exact whitespace-bearing disabled-tools scenario, so no test
  changes were strictly required; a regression test would belong in
  a separate test-coverage PR alongside the const.ts test gap from
  the #4297 unresolved-comment thread)
- typecheck clean across cli + sdk-typescript

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): wenshao review round 4 — 3 Suggestion fold-ins (#4319)

1. **bridge.ts:2270 stale line refs in `publishWorkspaceEvent` JSDoc**
   — comment said `permission_resolved at line 1717` (actual: line 682)
   and `broadcastWorkspaceEvent closure at ~line 2127` (actual: line
   1281). Line numbers drifted across the lift commits. Replaced both
   with function-name refs (`in resolvePending`, `declared above in
   this factory body`) that survive future edits.

2. **`ws.ts:613` opaque references in bridgeFileSystem.ts:20 +
   bridgeOptions.ts:267** — no `ws.ts` file exists in the repo; the
   ref came from an internal review thread on PR 18 that future
   readers can't locate. Replaced with a self-contained description
   ("post-PR-18 follow-up thread about BridgeClient's inline fs proxy
   bypassing WorkspaceFileSystem (origina…
chiga0 added a commit that referenced this pull request May 28, 2026
… approval-mode serialization, catch-up indicator) (#4510)

* fix(serve): post-merge fixes for #4291 review (7 threads) (#4305)

* fix(serve): address qwen-latest review on merged #4291 (7 threads)

Seven post-merge findings from the qwen-latest review on #4291,
all real. Most are tightening fixes for issues introduced by the
earlier rounds of #4291 — the same security / DRY / observability
classes the original review surfaced, applied to surfaces that
weren't covered initially.

#1 (deviceFlow.ts:1179) — late-poll observer closure retained the
entire entry by reference (deviceCode/pkceVerifier BrandedSecrets +
cancelController) for the lifetime of the daemon if `provider.poll()`
never settled. Memory leak + indefinite secret retention. Destructure
the four fields the closure actually needs (deviceFlowId, providerId,
initiatorClientId, audit sink) so the entry is GC-eligible the
moment runPollTick returns.

#2 (server.ts) — `callerIsInitiator` was duplicated verbatim across
three locations: GET handler, toDeviceFlowStartResponseBody,
toDeviceFlowStateBody. The exact bug class #4291 was fixing was
"POST and GET diverged on the same redaction policy" — duplicating
the gate recreated the preconditions for divergence. Extracted to
shared `callerIsDeviceFlowInitiator(view, callerClientId)` helper
with the consolidated threat-model JSDoc. All three sites now call
the helper.

#3 (deviceFlow.ts:1110) — timeout callback constructed two separate
`DeviceFlowPollTimeoutError` instances (one for `signal.reason`, one
for the wrapper rejection). Each capture its own V8 stack trace,
and `signal.reason.stack` would diverge from the caught rejection's
stack — confusing for operators inspecting both. Build the sentinel
ONCE per timer fire and pass the same instance to both sites.

#4 (qwenDeviceFlowProvider.ts:273) — `Error.name` is a freely
assignable string property; a hostile fetch wrapper could set
`e.name = 'X\n[serve] FAKE LINE\x1b[31m'` to inject log lines or
ANSI sequences via the same vector we already closed for `oauthError`.
The non-OAuth catch path interpolated `${err.name}` raw. Apply the
same `sanitizeForStderr()` helper.

#5 (deviceFlow.ts:1551) — on the timeout path, `rawProviderError`
is undefined (deliberately, to skip the misleading
`provider.poll() threw (raw): ...` audit template), but that left
the audit hint field omitted entirely. Operators reading the
durable audit trail saw `errorKind: 'upstream_error'` with no signal
whether it was a hung IdP or a generic provider failure. Use
`result.hint` (which already carries the timeout-specific
`provider.poll() timed out after Nms; check IdP connectivity` text
built in the catch) so the audit matches the SSE event.

#6 (server.ts) — the `QWEN_SERVE_DEBUG` env-var check was inlined
in the GET route handler, duplicating the `isServeDebugMode()`
helper from `./debugMode.js` that workspaceAgents and
workspaceMemory already use. The inline copy also had a dead `?? ''`
fallback (the value is guaranteed truthy at that point per the
preceding check). Use the canonical helper.

#7 (deviceFlow.ts:1217) — late-rejection observer interpolated the
raw `lateErr.message` into the audit hint (truncated to 256 bytes,
but RFC 8628 `device_code` values fit comfortably in 256 bytes).
The provider's catch already uses the `name + length` redaction
pattern to prevent WAF-echoed `device_code`/PKCE leaks; the
registry layer was undoing that hardening because the same failure
settled late. Apply the same `name + length` pattern at the late-
rejection site.

Tests:
- Existing late-rejection test reseeded with a `device-code-secret-*`
  substring inside the long detail; hard-negative-asserts the seeded
  secret is absent from the audit + asserts the new
  `Error (message N bytes; raw suppressed)` shape.
- Existing poll-timeout test now also asserts: hint IS defined on
  the audit (not omitted), hint contains `'timed out after'` /
  `'check IdP connectivity'`, and `signal.reason instanceof
  DeviceFlowPollTimeoutError` (proves the single sentinel is
  shared between abort and reject).
- New `sanitizes control characters in attacker-controlled
  err.name` test in qwenDeviceFlowProvider.test.ts pins the round-4
  #4 fix with a hostile `e.name` containing `\n` + `\x1b[31m...`.

cli serve 702/702 (was 686, +16 — additional tests imported via
the acp-bridge package lift on main); sdk 421/421; typecheck clean
across all 4 workspaces; eslint --max-warnings 0 clean on touched
files.

Refs: #4175, #4255, #4291

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): address deepseek-v4-pro review on #4305 (4 threads)

Round-5 fold-in. Four findings from the deepseek-v4-pro review on
PR #4305 — all real, three are sister fixes for the same security
classes that #4305 already closed at adjacent surfaces.

#1 (deviceFlow.ts) — `pollTimedOut` race correctness. The flag was
set unconditionally inside the timer callback. If the provider
settled the wrapper at 29.9s, `finally` would call
`clearScheduled(pollTimer)` — but if the timer callback was already
queued for execution before the clear landed (a real possibility
in Node's event-loop ordering, even if not always observed in
practice), this branch could still run and incorrectly mark
`pollTimedOut`. Move the flag assignment to the catch block where
the settled cause is unambiguous via `instanceof
DeviceFlowPollTimeoutError`. New test pins the negative: provider
beats the timeout → no spurious `lost_late_poll_after_timeout`
audit even after ticking 2× the ceiling.

#2 (deviceFlow.ts) — late-rejection observer interpolated raw
`lateErr.name` into the audit hint without sanitization. Same
attacker-controlled vector closed at the provider layer for
`err.name` in round-4. Route through `sanitizeForStderr`.

#3 (deviceFlow.ts) — late-success observer interpolated
`latePollResult.kind` directly into the audit template. While the
typed shape is `'pending' | 'slow_down' | 'success' | 'error'`, a
non-conforming provider could return an arbitrary string. Same
log-injection vector. Route through `sanitizeForStderr`.

#4 (qwenDeviceFlowProvider.ts → deviceFlow.ts) —
`sanitizeForStderr` only stripped ASCII C0/C1 + DEL; bypass via
Unicode lookalikes:
  - U+2028/U+2029: LINE/PARAGRAPH SEPARATOR (newline-equivalent in
    most Unicode-aware terminals — most direct log-forging vector)
  - U+200B–U+200F: zero-width chars + LRM/RLM
  - U+202A–U+202E: bidirectional override controls
  - U+FEFF: BOM / ZWNBSP

A malicious IdP returning `slow_down
[serve] FAKE` in
`oauthError` would otherwise still forge log lines.

Architectural change: `sanitizeForStderr` was previously private to
`qwenDeviceFlowProvider.ts`. To address #2/#3, the registry layer
needs to call it too. Lifted into `deviceFlow.ts` (the foundation
module) and re-imported from the provider. Single source of truth;
the regex is now a module-level constant compiled once with explicit
`\uXXXX` escapes (via `String.raw` so the source is greppable, not
literal-Unicode-laden).

Tests:
- `does NOT attach late-poll observer when the provider beats the
  timeout` — N1 race regression
- `sanitizes hostile latePollResult.kind in late-observer audit` — N3
- `sanitizes hostile lateErr.name in late-rejection observer audit` — N2
- `sanitizes Unicode lookalike controls (U+2028 LINE SEPARATOR,
  bidi, ZWNBSP) in oauthError` — N4

cli serve 706/706 (was 702, +4 — all new round-5 tests); sdk
421/421; typecheck clean; eslint --max-warnings 0 clean on touched
files.

Refs: #4175, #4255, #4291, #4305

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): address gpt-5.5 + qwen-latest review on #4305 round-5 (5 threads)

Round-6 fold-in. Five findings split between maintainability,
security hardening, and a real defensive bug.

#1 (qwenDeviceFlowProvider.test.ts) — gpt-5.5: round-5 #4 test
embedded U+2028 / U+200E / U+FEFF as literal characters in source.
Invisible in GitHub diffs / most editors; the negative
`not.toContain('')` looked like an empty-string check. Rewrote
the payload + assertions to use named `\uXXXX`-bound constants.
Also added a companion test exercising U+2066–U+2069 (round-6 #5
below).

#2 (deviceFlow.ts) — qwen-latest: the late-poll observer's
`void tracked.then(...)` was missing a terminal `.catch(() => {})`.
A synchronous throw inside either handler (e.g., a misbehaving
`audit.record`: backpressure, malformed payload, sink out-of-disk)
would reject the derived promise unhandled. On Node 22's default
`--unhandled-rejections=throw`, that crashes the daemon. Added the
terminal `.catch(() => {})` matching the persist-tracker pattern.
New test injects a poison audit sink that throws specifically on
the `lost_late_poll_after_timeout` call; asserts `flushAsync()`
resolves cleanly.

#3 (deviceFlow.ts) — qwen-latest: the `case 'error'` audit-record
hint interpolated `rawProviderError` (raw `err.message`) without
`sanitizeForStderr`. Per ES2019+ `JSON.stringify` no longer escapes
U+2028/U+2029 — those would still forge log lines downstream
through file/stdout audit sinks. Apply the same sanitizer used on
every other provider-controlled audit path. New test pins a hostile
provider message containing U+2028 + ANSI escape and asserts
neither survives.

#4 (deviceFlow.ts) — qwen-latest: the round-5 #1 comment claimed
"`DeviceFlowPollTimeoutError` isn't exported as a public DeviceFlow
contract", but it IS `export class` (the test file constructs it
directly for fixtures). With `pollTimedOut = true` keyed solely on
`instanceof`, a future provider that imports + throws the class
would spoof the registry's "I caused the timeout" signal —
attaching a phantom late-poll observer.

Fix: introduce a runtime brand `_isRegistryTimeout: boolean` on the
class (default `false`) plus an internal-only
`makeRegistryPollTimeoutError(ms)` helper that sets the brand to
`true`. The brand is set ONLY at the registry's race-timer
construction site. Both gates updated:
  - `if (err instanceof X && err._isRegistryTimeout === true)` in
    the catch (for `pollTimedOut`)
  - `if (lateErr instanceof X && lateErr._isRegistryTimeout === true)`
    in the late-rejection self-filter

A provider-thrown brand-false instance now flows through the
generic provider-throw audit path — correctly auditing the misuse
rather than silently swallowing it. Repurposed the original "no
double-audit when registry's own DeviceFlowPollTimeoutError is
late-rejected" test (which was actually exercising the brand-false
path) into the inverted assertion: brand-false provider throw IS
audited as a real failure. Removed the orphaned old assertion; the
brand-true happy path is implicitly covered by the hanging-provider
test (which exercises the registry-built timeout end-to-end).

#5 (deviceFlow.ts) — qwen-latest: `sanitizeForStderr` regex covered
U+202A–U+202E (bidi embedding/override) but missed U+2066–U+2069
(LRI/RLI/FSI/PDI). These are the primary CVE-2021-42574
("Trojan Source") attack vectors — a hostile IdP swapping U+2066
for U+202D achieves the same visual reordering and would have
bypassed the round-5 filter entirely. Extended the regex range and
JSDoc; new test exercises U+2066/U+2068/U+2069 in `oauthError` and
asserts none survive while substantive ASCII parts remain.

cli serve 713/713 (was 710, +3 round-6 tests + the round-5 #4
rewrite + the round-6 #5 companion); typecheck clean across all 4
workspaces; eslint --max-warnings 0 clean on touched files.

Refs: #4175, #4255, #4291, #4305

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): replace literal U+2028 with explicit 
 escape in round-6 #3 test

PR #4312 review (Copilot): the round-6 #3 test (sanitizes
rawProviderError) regressed back to embedding a literal U+2028
character in source via `const U_2028 = ' '`. That's the same
maintainability anti-pattern round-6 #1 was fixing in the sister
test. Internal-consistency fix: switch to the explicit `
`
escape so the constant is greppable and reviewable in GitHub diffs.

Refs: #4291, #4305, #4312

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(serve): post-merge P2 corrections from Codex review on #4282 (#4297)

* fix(serve): post-merge P2 corrections from Codex review on #4282

Follow-up to PR #4282 (Wave 4 PR 17) addressing four P2 issues
flagged by Codex's `/review` after the squash-merge to main:

P2-1 — Read the workspace context filename for init
  `qwen serve` parent never goes through `loadCliConfig`, so the
  process-global `getCurrentGeminiMdFilename()` stays on the default
  `QWEN.md` even when the workspace configures
  `context.fileName: 'AGENTS.md'`. `runQwenServe` now snapshots the
  workspace's merged setting at boot and forwards via
  `BridgeOptions.contextFilename`, so init writes the same file the
  ACP child reads.

P2-2 — Restart MCP servers with a fresh disabledTools snapshot
  `Config.disabledTools` was frozen at construction time;
  `setWorkspaceToolEnabled` only updated settings.json. The
  documented "toggle + restart" workflow re-registered just-disabled
  tools because rediscovery still saw the bootstrap snapshot. Added
  `Config.setDisabledTools()` plus a re-read at the ACP restart
  handler so `discoverMcpToolsForServer` honors the latest set.

P2-3 — Match the SDK timeout to the daemon's restart budget
  Bridge waits up to 300s for stdio MCP discovery; SDK helper used
  the client-wide 30s default and aborted valid slow restarts.
  Added a per-call `timeoutMs` plumbed through `fetchWithTimeout`,
  defaulting `restartMcpServer` to 5 minutes.

P2-4 — Reject symlinked parent directories before init writes
  `lstat(target)` only checked the final component; a symlinked
  parent (e.g. `docs -> /tmp` with `context.fileName:
  'docs/QWEN.md'`) would let `writeFile` follow the link and create
  / truncate outside `boundWorkspace`. Added
  `canonicalizeExistingAncestor` (walks up through ENOENT to the
  deepest extant ancestor, then `realpath`s) and verifies the
  canonical parent stays within the canonical workspace.

5 new tests (4 bridge / 2 SDK):
- contextFilename snapshot honored
- parent-symlink escape rejected
- nested real subdir accepted
- restartMcpServer survives 1.2s response with 1s default timeout
- restartMcpServer honors a 50ms caller override

Typecheck clean across cli / sdk-typescript / core.
1604/1604 unit tests pass.

* fix(serve): fold-in 1 — address 16:32:44-round review on #4282

Follow-up addressing the 8 unresolved review threads opened on PR
shipping in this same #4297; addresses correctness gaps + missing
test coverage that would otherwise let regressions ride into main.

Behavior fix:
- broadcastWorkspaceEvent gains a `skipSessionId` parameter; when
  `setSessionApprovalMode` runs with `persist:true`, the broadcast
  skips the requesting session so it doesn't receive the same
  `approval_mode_changed` event twice (once via session-scoped
  publish + once via broadcast). The SDK reducer's
  `approvalModeChangedCount` now increments by 1, not 2, on the
  requesting client (peers still see 1 via the broadcast).
  Addresses #3260501134.

Observability + posture:
- broadcastWorkspaceEvent now mirrors PR 16's publishWorkspaceEvent
  member: per-entry success/failure accounting + an "ALL buses
  dropped" stderr elevation. The previous local helper silently
  swallowed every publish failure. Addresses #3260501126.
- WorkspaceInitPathEscapeError + WorkspaceInitSymlinkError typed
  classes for the two boundary guards in initWorkspace, mapped to
  HTTP 400 by sendBridgeError. Previous generic `Error` fell
  through to the 500 handler, telling operators "daemon broken"
  when the actual fix was workspace-config correction. Addresses
  #3260501161.

Public surface symmetry:
- Re-export McpServerNotFoundError, McpServerRestartFailedError,
  WorkspaceInitPathEscapeError, WorkspaceInitSymlinkError from the
  serve barrel. External embeds matching these via `instanceof`
  no longer need deep imports. Addresses #3260501163.

Test coverage:
- restartMcpServer bridge tests (5): success + event broadcast,
  soft-skip + refused event, McpServerNotFoundError translation,
  McpServerRestartFailedError translation, originator clientId
  stamping. Addresses #3260501141.
- sendBridgeError mapping tests (4): McpServerNotFoundError → 404,
  McpServerRestartFailedError → 502, WorkspaceInitPathEscapeError
  → 400, WorkspaceInitSymlinkError → 400. Addresses #3260501148.
- initWorkspace boundary guard tests (2 added): symlink-at-target
  rejected, contextFilename '../outside.md' rejected. Addresses
  #3260501157.
- TrustGateError tests assert the typed class via `.toThrow(TrustGateError)`,
  not just message text. Addresses #3260501165.

Also updates the existing fold-in 4 S2 broadcast test to reflect
the new no-duplicate semantics on the requesting session.

Typecheck clean across cli / sdk-typescript / core.
1615/1615 unit tests pass.

* fix(serve): fold-in 2 — copilot + wenshao review on #4297

Round-2 reviewer adoption on the same PR:

Critical fixes:
- `restartMcpServer` JSDoc documents `timeoutMs: 0` as "disable the
  timeout entirely", but the `> 0` guard in `fetchWithTimeout`
  rejected `0` and silently fell back to the 30s client default.
  Loosened the guard to `>= 0` so `0` flows through to the
  no-timeout branch via the existing truthiness check; NaN /
  negative inputs still coerce to the client default. Addresses
  duplicate reports from copilot (#3260577538) and wenshao
  (#3260661833).
- TS2322 in the slow-fetch test stub: `resolveResponse` was typed
  against `import('undici-types').Response` but assigned a
  `(v: Response) => void`. Re-typed against the global `Response`
  throughout. Caught only by tsc runs that include the test
  files. Addresses #3260663072.

Test fidelity:
- Slow-fetch stub now observes `init.signal` and rejects on abort,
  so a regression that drops the per-call `timeoutMs` override
  will reliably fail the test instead of resolving after the
  timer fired (false-negative coverage). Addresses #3260577600.
- New test pinning the `timeoutMs: 0` semantics: 1ms client
  default + a stub that resolves after 50ms. Without the `>= 0`
  fix, the call would abort at 1ms; with it, the explicit
  `0` disables the timer and the call completes.

Bug fixes:
- `runQwenServe.contextFilenameForInit` previously called
  `String(arr[0])` on the array branch, producing a literal
  `"[object Object]"` filename for hand-edited bad data. Now
  validates each element with `typeof === 'string'` and falls
  back to `undefined` (so the bridge uses its
  `getCurrentGeminiMdFilename()` default) when no string is
  found. Addresses #3260577641.

Documentation drift:
- `Config.getDisabledTools()` JSDoc rewritten to describe the
  mutable-via-`setDisabledTools()` semantics introduced by P2-2,
  and the "registration-time only / no retroactive unregister"
  contract that pairs with it. Old comment claimed the set was
  frozen at construction. Addresses #3260577677.

Observability:
- `acpAgent` MCP-restart `loadSettings` failure now surfaces a
  stderr line naming the server + the underlying error, instead
  of silently swallowing it. The documented "toggle + restart"
  workflow used to break with zero diagnostic when settings.json
  was corrupted or unreadable. Addresses #3260663303.

Code organization:
- Moved `canonicalizeExistingAncestor` after `describeStatKind` so
  the latter's JSDoc is no longer orphaned (TypeScript only
  associates the last `/** ... */` block before a declaration).
  Addresses #3260668618.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.

* fix(serve): fold-in 3 — read merged scope on MCP restart refresh

Critical bug from wenshao review (#3260725526) on PR #4297:
the P2-2 acpAgent re-read narrowed `Config.disabledTools` to
`SettingScope.Workspace` alone, dropping User / System scope
entries. The bootstrap Config received `merged.tools?.disabled`
(union of all scopes), so user-level / system-level disables
worked at boot — but the first `mcp restart` would replace the
in-memory set with the workspace scope alone, silently re-enabling
any tool that was disabled at a higher scope but absent from the
workspace file.

The asymmetry vs. the persist-write path is deliberate and
documented:
- Reads (here): merged — match the bootstrap Config snapshot,
  preserve user/system policy.
- Writes (`runQwenServe.persistDisabledTools`): workspace scope —
  don't bake higher-scope entries into the workspace file
  (per-#4282 fold-in 1 H2 fix).

Two paths look alike but answer different questions.

Typecheck clean across cli / sdk-typescript / core.
1616/1616 unit tests pass.

* fix(test): fold-in 4 — wire timeoutMs:0 stub to init.signal

Critical follow-up from wenshao (#3260810242) on PR #4297:
the new `timeoutMs: 0` regression test (added in fold-in 2)
inherited the same flaw it was meant to prevent — the slow-fetch
stub didn't observe `init.signal`, so a regression that ignored
the `0` override would fire the AbortController at the 1ms client
default but the stub would keep the promise pending. The 50ms
`resolveResponse` would win, the test would still pass, and the
documented "0 disables timeout" contract would be unprotected.

Mirrored the listener pattern already used by the two sibling
tests in fold-in 2 — `init.signal.addEventListener('abort', () =>
reject(...))`. Now a regression that re-rejects `0` triggers the
abort, the stub rejects, the test fails.

8/8 restartMcpServer SDK tests pass; SDK typecheck clean.

* fix(serve): fold-in 5 — TOCTOU + setDisabledTools coverage

Two new critical reviews from wenshao on PR #4297:

C1 — TOCTOU between lstat and writeFile (#3260836305):
The `lstat(target)` symlink check and the subsequent `writeFile`
were two separate syscalls, leaving a race window where a local
attacker with workspace write access could substitute a symlink
between them. With `force: true`, `writeFile` would follow the
link and truncate an external target.

The `action === 'created'` path now uses `fs.open(target, 'wx')`
(O_WRONLY|O_CREAT|O_EXCL), which atomically refuses any
pre-existing inode (regular file, dir, OR symlink) at the target
path. EEXIST after the absence check most plausibly means a
race-created symlink, so we throw `WorkspaceInitSymlinkError(kind:
'target')` — same typed class the route maps to 400.

The `force: true` overwrite path retains the existing TOCTOU as a
documented limitation; closing it requires `O_NOFOLLOW`-aware open
which the post-PR18 `WorkspaceFileSystem` migration will provide.

C2 — P2-2 zero test coverage (#3260836302):
The `setDisabledTools` runtime sync was the only Wave-4 P2 fix
without a dedicated test. Added 5 Config-level tests:
- Initializes from `disabledTools` ConfigParameters
- Defaults to empty set when omitted
- `setDisabledTools` replaces the live snapshot
- Defensive copy: caller-set mutations don't leak into the live snapshot
- Accepts an empty set (clears live snapshot)

Plus a TOCTOU regression test in httpAcpBridge.test.ts that
spies fs.lstat / fs.readFile to simulate the race window:
pre-creates a symlink, makes lstat lie about it, asserts the
'wx' open catches the racing inode and throws the typed
`WorkspaceInitSymlinkError(kind: 'target')`.

1622/1622 unit tests pass; typecheck clean across cli /
sdk-typescript / core.

* fix(serve): fold-in 6 — count actual skips in broadcast alarm

DeepSeek review on #4297 (#3261079572):
`broadcastWorkspaceEvent` unconditionally subtracted 1 from the
`eligible` recipient count whenever `skipSessionId` was set, even
when the id matched zero live sessions (caller mistake, stale id,
or the matching session was just torn down between resolution and
broadcast). In a single-session workspace that's the difference
between `eligible = 0` (alarm suppressed) and `eligible = 1`
(alarm fires when the publish failed) — silently losing the
all-dropped breadcrumb the telemetry was meant to surface.

Today's call sites pass real session ids so the bug doesn't
manifest in practice, but the defensive shape is small: track
`skippedCount` inside the loop and subtract that, so the alarm
condition is self-consistent regardless of how the caller mis-uses
the param.

162/162 bridge tests pass; CLI typecheck clean.

* fix(serve): fold-in 7 — close overwrite TOCTOU, harden boot + diagnostics

Round-7 review on PR #4297. Three critical fixes + one suggestion
test, plus a regression test for the overwrite TOCTOU close.

C1 — force:true overwrite TOCTOU (#3262615446):
The fold-in 5 fix only closed the `'created'` action via 'wx';
the `'overwrote'` branch still used plain `fs.writeFile`, so a
local writer could swap the verified regular file to a symlink
between the lstat/readFile checks and the write and have the
forced overwrite truncate an external target. Switched to
`fs.open(target, O_WRONLY | O_TRUNC | O_NOFOLLOW)` — `O_NOFOLLOW`
makes open() fail with ELOOP on a symlink at the final component
even under race. ELOOP / ENOENT (race-deleted) translate to
`WorkspaceInitSymlinkError(kind: 'target')` so the route still
maps to a structured 400 instead of a generic 500.

C2 — settings.json corrupt blocks daemon boot (#3262625091):
`loadSettings(boundWorkspace)` at boot had no try/catch — a
corrupted, malformed, or temporarily unreadable settings file
threw synchronously and prevented daemon startup. Pre-PR this
never happened because settings were read lazily inside request
handlers. Wrapped in try/catch with stderr fallback so the daemon
keeps booting (with the bridge's default context filename) when
the file is broken.

C3 — malformed `tools.disabled` clears policy silently (#3262625101):
When `merged.tools?.disabled` is present but not an array
(boolean / string / object from a hand-edited settings.json), the
ternary `Array.isArray(...) ? ... : []` substituted an empty list
without firing the surrounding catch block. After an MCP restart
every disabled tool would silently re-register. Added an explicit
`!Array.isArray && !== undefined` check that stderr-logs the
malformed type before clearing — operators see the
misconfiguration instead of a stealth re-enable.

S1 — contextFilename extraction tested (#3262690842):
Lifted the inline `firstStringInArray` + branching into an
exported `extractContextFilename(value: unknown)` helper and
added `runQwenServe.test.ts` with 5 tests covering the four
branches the suggestion called out: non-empty string, array with
strings, array with no strings, non-string non-array.

Plus a TOCTOU regression test for the overwrite path that
verifies `O_NOFOLLOW` returns `WorkspaceInitSymlinkError(kind:
'target')` when the file is race-substituted with a symlink
behind the lstat/readFile mocks.

S2 (acpAgent restart-handler integration test #3262690845) is
deferred — Config-level coverage of `setDisabledTools` already
locks the load-bearing surface (5 tests in fold-in 5), and
adding a full acpAgent integration test requires heavy ext-method
plumbing. The new C3 stderr diagnostic plus existing tests give
us the regression signal we need without that scaffolding.

1627/1627 unit tests pass; typecheck clean across cli /
sdk-typescript / core / acp-bridge.

* fix(serve): fold-in 8 — split ELOOP / ENOENT diagnostic in overwrite path

qwen-latest review on PR #4297 (#3262861754):
The fold-in 7 ELOOP/ENOENT branch shared one error message that
said "swapped to a symlink." That's accurate for ELOOP (genuine
O_NOFOLLOW rejection — likely an attack race) but misleading for
ENOENT in the overwrite path: there `readFile` just succeeded
proving the file existed, so ENOENT means the file was DELETED
between the content check and the open — a benign race with a
concurrent writer (git checkout, editor save, lockfile rename),
NOT a symlink swap. An operator seeing the symlink language for
a benign delete would `ls -la`, see no symlink, and waste time
hunting an attack that didn't happen.

Split into two messages:
- ELOOP: "swapped to a symlink between the content check and the
  overwrite — refusing to follow it"
- ENOENT: "deleted between the content check and the overwrite
  (likely a concurrent writer) — refusing to recreate blindly"

Both still surface as `WorkspaceInitSymlinkError(kind: 'target')`
so the route maps to a structured 400; the class doubles as the
workspace-init race-condition bucket with kind='target' meaning
"target inode misbehaved at write time" generally.

Updated the existing fold-in 7 TOCTOU test to assert the ELOOP
message specifically, and added a new ENOENT race-delete test
that mocks lstat/readFile to land on the overwrote action against
a non-existent path — verifies the message says "deleted" and
NOT "swapped to a symlink."

170/170 bridge tests pass; CLI typecheck clean.

* fix(serve): fold-in 9 — route MCP restart through registry cleanup wrapper

gpt-5.5 critical review on PR #4297 (#3263088414):

The fold-in 5 P2-2 fix refreshed `Config.disabledTools` from merged
settings, but then called `manager.discoverMcpToolsForServer()`
directly — bypassing the `ToolRegistry.discoverToolsForServer`
wrapper that PURGES the server's existing `DiscoveredMCPTool`
entries (and `revealedDeferred` markers) plus its prompts before
rediscovery. Without the cleanup, `registerTool` only consulted
the refreshed `disabledTools` set for NEWLY-discovered tools —
entries already in the registry from the prior MCP boot kept
serving requests. Net effect: toggle-disable-then-restart
silently left the disabled tool live, breaking the documented
"toggle + restart" workflow that P2-2 was meant to fix.

Routed through `toolRegistry.discoverToolsForServer(serverName)`
which:
1. Removes existing `DiscoveredMCPTool` entries for this server
2. Drops their `revealedDeferred` reveal state
3. Removes the server's prompts via `removePromptsByServer`
4. THEN delegates to `manager.discoverMcpToolsForServer` for the
   actual reconnect + rediscover

The pre-discovery budget / in-flight checks still go through the
`manager` reference (which is the same object the registry
wrapper would forward to) — so soft-skip semantics for
`budget_would_exceed`, `in_flight`, `disabled` are preserved.

CLI typecheck clean; 403/403 server + bridge tests pass.

* fix(serve): fold-in 10 — qwen-latest 05:45-round review on #4297

5 review threads from qwen-latest's late round on PR #4297 (now closed
in favor of #4313 against `daemon_mode_b_main`). 1 critical + 4
suggestions, all adopted.

C1 — extractContextFilename / getCurrentGeminiMdFilename divergence
(#3263954685): with `context.fileName: ['  ', 'AGENTS.md']`, the
daemon parent's `extractContextFilename` (which skips empty entries)
wrote `AGENTS.md`, but the ACP child's `getCurrentGeminiMdFilename`
(which returned `arr[0]` unconditionally) read `''`. The init'd file
was orphaned. Aligned `getCurrentGeminiMdFilename` to skip empty
entries with the same semantics, falling back to
`DEFAULT_CONTEXT_FILENAME` when all entries are empty.

S2 — WorkspaceInitSymlinkError reused for non-symlink races
(#3263954690): the EEXIST race-create and ENOENT race-delete cases
were surfacing as `code: 'workspace_init_symlink'`, misleading
operators into hunting symlink attacks for benign concurrent-
modification windows. Split into a sibling `WorkspaceInitRaceError`
class (`kind: 'eexist' | 'enoent'`, HTTP code
`workspace_init_race`). The genuine symlink class stays for ELOOP,
lstat-detected target symlinks, and parent-realpath escapes.

S3 — fsConstants.O_NOFOLLOW defensive `?? 0` (#3263954697): matches
the existing codebase convention in
`core/src/utils/{sessionStorageUtils,gitDiff}.ts` and
`cli/src/ui/utils/customBanner.ts`. Functionally a no-op (JS
bitwise coerces undefined to 0) but consistent.

S5 — Parent-directory TOCTOU still open (#3263954707): O_NOFOLLOW
only protects the final path component; a local writer could swap
a real parent dir for a symlink between
`canonicalizeExistingAncestor` and `fs.open`. Added
`verifyParentWithinWorkspace` post-open helper that re-realpaths
`path.dirname(target)` and refuses with
`WorkspaceInitSymlinkError(kind: 'parent')` if the parent moved.
On the create path (where we just opened with `'wx'`), the failure
also unlinks the file we just made best-effort. Residual race
window narrowed from "between pre-check and open" to "between
post-open realpath and writeFile" — sub-millisecond, documented as
accepted Stage-1 trust posture.

S4 — broadcastWorkspaceEvent vs publishWorkspaceEvent stale comment
(#3263954688): the "now removed" comment was inaccurate (5 call
sites still use the closure). Replaced with an accurate
description of why both coexist (factory closure can't `this`-call
proxy member; closure also takes `skipSessionId` for persisted
approval-mode mirror) and a TODO marker for future helper extraction.

Two existing tests updated to assert the new `WorkspaceInitRaceError`
class for EEXIST / ENOENT scenarios (the symlink-class assertions
are preserved for ELOOP / lstat / parent cases).

1759/1759 unit tests pass; typecheck clean across all 4 packages.

* feat(acp-bridge): F1 — acp-bridge package self-sufficiency (#4175 mechanical lift + BridgeFileSystem seam) (#4319)

* refactor(acp-bridge): lift defaultSpawnChannelFactory to acp-bridge/spawnChannel (#4175 F1 step 1)

First mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves the production spawn factory + its `killChild` helper +
`SCRUBBED_CHILD_ENV_KEYS` denylist + `KILL_HARD_DEADLINE_MS` constant
from `cli/src/serve/httpAcpBridge.ts` (~283 lines) to
`@qwen-code/acp-bridge/spawnChannel`. This unblocks
`channels/base/AcpBridge.ts` and `vscode-ide-companion`'s
acpConnection from each reimplementing the child lifecycle — they can
now consume the same primitive.

Backward compatible: `cli/src/serve/httpAcpBridge.ts` imports the
lifted factory and re-exports it, so existing references in
`cli/src/serve/index.ts:90` and the factory's own internal usage
(`opts.channelFactory ?? defaultSpawnChannelFactory`) keep resolving.
Bridge tests that mock `defaultSpawnChannelFactory` via
`BridgeOptions.channelFactory` are unaffected.

Side cleanups: drops `spawn` / `ChildProcess` / `Readable` / `Writable`
/ `ndJsonStream` / `MissingCliEntryError` imports from
httpAcpBridge.ts (all only used by the lifted spawn factory).

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift BridgeClient + permission types to acp-bridge/bridgeClient (#4175 F1 step 2)

Second mechanical lift of #4175 F1 (acp-bridge package self-sufficiency).
Moves `BridgeClient` class (~700 LOC) + `PendingPermission` interface +
`PermissionResolutionRecord` interface + `MAX_RESOLVED_PERMISSION_RECORDS`
constant + early-event capacity constants + `describeStatKind` and
`sliceLineRange` helpers from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridgeClient`.

Design choice for SessionEntry boundary: introduce a minimal
`BridgeClientSessionEntry` interface in bridgeClient.ts with only the
four fields BridgeClient actually reads from the factory's richer
`SessionEntry` (`sessionId`, `events`, `pendingPermissionIds`,
`activePromptOriginatorClientId`). The factory's `SessionEntry`
structurally satisfies it — TypeScript's structural typing enforces
the match at the `resolveEntry` callback signature, so no explicit
conversion is required and the bridge package stays free of daemon-host
session-bookkeeping types.

Cross-package writeStderrLine handling: inline the 3-line helper in
bridgeClient.ts (mirrors the spawnChannel.ts pattern from F1 step 1)
so acp-bridge has no reverse dependency on `cli/src/utils/stdioHelpers`.

httpAcpBridge.ts shrinks from 4406 LOC to 3647 LOC (-759 lines).
Removed ACP SDK imports that only BridgeClient consumed: `Client`,
`RequestPermissionRequest`, `WriteTextFileRequest`,
`WriteTextFileResponse`, `ReadTextFileRequest`, `ReadTextFileResponse`,
`SessionNotification`. Kept the ones the factory still uses
(`CancelNotification`, `PromptRequest`, `RequestPermissionResponse`,
`SetSessionModelRequest`, `SetSessionModelResponse`).

Backward compatible: httpAcpBridge.ts re-exports `BridgeClient`,
`BridgeClientSessionEntry`, `PendingPermission`,
`PermissionResolutionRecord`, and `MAX_RESOLVED_PERMISSION_RECORDS` so
the `ChannelInfo.client: BridgeClient` field declaration below + any
embedder reaching into these types keep resolving.

- 44/44 acp-bridge tests pass
- 174/174 cli httpAcpBridge tests pass
- 229/229 cli server tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* refactor(acp-bridge): lift createHttpAcpBridge factory to acp-bridge/bridge (#4175 F1 step 3)

Third + final mechanical lift of #4175 F1 (acp-bridge package
self-sufficiency). Moves the `createHttpAcpBridge` factory closure
(~3000 LOC) + `ChannelInfo` + `SessionEntry` interfaces + factory-only
helpers (`canonicalizeExistingAncestor`, `verifyParentWithinWorkspace`,
`withTimeout`, `isServeDebugLoggingEnabled`, `writeServeDebugLine`,
`hasControlCharacter`) + factory constants (`DEFAULT_INIT_TIMEOUT_MS`,
`MCP_RESTART_TIMEOUT_MS`, `DEFAULT_MAX_SESSIONS`, `MAX_EVENT_RING_SIZE`,
`DEFAULT_PERMISSION_TIMEOUT_MS`, `DEFAULT_MAX_PENDING_PER_SESSION`,
`MAX_DISPLAY_NAME_LENGTH`) from `cli/src/serve/httpAcpBridge.ts` to
`@qwen-code/acp-bridge/bridge`.

`cli/src/serve/httpAcpBridge.ts` shrinks from 3647 LOC to 97 LOC — a
pure re-export shim that preserves every existing relative import
path (`./httpAcpBridge.js`) so `server.ts`, `runQwenServe.ts`,
`workspaceAgents.ts`, `workspaceMemory.ts`, `index.ts`, plus the bridge
test suite, keep resolving without any call-site changes.

The new `bridge.ts` reuses what was already in acp-bridge (errors,
types, options, status helpers, channel types, event bus, workspace
paths) via local relative imports — no reverse dependency on `cli`.
`writeStderrLine` is inlined at the top of `bridge.ts` (same pattern as
`spawnChannel.ts` + `bridgeClient.ts` from F1 steps 1-2) so the
package self-contained promise holds.

Cumulative F1 impact across the 3 mechanical lift steps:
- httpAcpBridge.ts: 4682 LOC → 97 LOC (-4585 lines; the original file
  was 98% bridge core, 2% backward-compat re-exports)
- 3 new files in acp-bridge: spawnChannel.ts (~270 LOC), bridgeClient.ts
  (~745 LOC), bridge.ts (~3515 LOC)
- All daemon-host concerns (env snapshot, daemon preflight cells)
  remain in `cli/src/serve/daemonStatusProvider.ts` and reach the
  bridge through the `BridgeOptions.statusProvider` seam frozen by
  PR 22b/2.

- 735/735 cli serve tests pass across 17 files
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- typecheck clean across acp-bridge + cli

`packages/cli/src/serve/httpAcpBridge.test.ts` (~6600 LOC) is
intentionally NOT moved in this commit — it currently imports
`createHttpAcpBridge` / `defaultSpawnChannelFactory` / `BridgeClient`
via the cli shim and keeps passing without changes. Moving it to
`acp-bridge/src/bridge.test.ts` is a follow-up worth tracking
separately so the production-code lift can land + be reviewed cleanly.

The `BridgeFileSystem` injection seam (originally bundled into F1 as
the 22b' scope) is also deferred to a follow-up so the mechanical lift
stays mechanical — design + implementation of the fs injection is its
own discussion.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* feat(acp-bridge): add BridgeFileSystem injection seam (#4175 F1 step 5, 22b' scope)

Adds the `BridgeFileSystem` injection seam originally scoped as #4175
22b'. When a `BridgeFileSystem` is wired through
`BridgeOptions.fileSystem`, `BridgeClient.readTextFile` and
`BridgeClient.writeTextFile` delegate to it instead of running their
inline `fs.realpath` / `fs.writeFile` / `fs.readFile` proxy.

This unblocks production `qwen serve` plumbing PR 18's
`WorkspaceFileSystem` (TOCTOU guards, symlink-substitution checks,
trust gate, `.gitignore`, audit hooks) into the ACP fs methods —
closing the `ws.ts:613` follow-up thread that has been tracked since
PR 18 landed. The serve-side adapter that wraps `WorkspaceFileSystem`
+ the `runQwenServe` wiring are intentionally split into the
immediate-follow-up so this PR stays focused on the seam design.

Backward compatible: `fileSystem` is optional on `BridgeOptions`.
Tests, Mode A in-process consumers, channels (`packages/channels/base/
AcpBridge.ts`), and the VSCode IDE companion all keep working
unchanged — they omit the field and `BridgeClient` falls through to
the inline proxy that has been the Stage 1 default since #3889.

API:
- `BridgeFileSystem.readText(params: ReadTextFileRequest):
  Promise<ReadTextFileResponse>`
- `BridgeFileSystem.writeText(params: WriteTextFileRequest):
  Promise<WriteTextFileResponse>`

The interface mirrors ACP SDK request/response types directly so the
adapter does the minimum amount of translation (`{ path, content }`
↔ `WorkspaceFileSystem`'s `ResolvedPath` brand types + options bag).

- 735/735 cli serve tests pass (inline fallback path preserved)
- 44/44 acp-bridge tests pass
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): catch README + stale source comments up to F1 lift

Self-review fold-in: post-F1 the package README still said "PR 22a"
and listed `BridgeClient` / `createHttpAcpBridge` /
`defaultSpawnChannelFactory` under "What's not here yet" — both
contradicted by this PR. Updated:

- README lift-history table now shows PR 22a / 22b/1 / 22b/2 as
  merged and F1 (this PR) as the slice that closes the bridge core
  + adds `BridgeFileSystem`. F3 PR 24 row aligned to the
  feature-cohesive plan.
- "What's here today" now documents `spawnChannel`, `bridgeClient`,
  `bridge`, `bridgeFileSystem` modules.
- "What's not here yet" section removed (its 2 bullets are both
  resolved by F1).
- Subpath import list updated to enumerate all 14 subpaths.
- Backward-compat section updated to call out the 97-line shim and
  the 6 consuming files that still import via `./httpAcpBridge.js`.

Source-comment line-number drift:
- `channel.ts:12` no longer claims `defaultSpawnChannelFactory` is
  "still in cli/src/serve/httpAcpBridge.ts" — points to the lifted
  location.
- `permission.ts:33` + `permission.ts:45` no longer reference
  `httpAcpBridge.ts:1096-1106` / `httpAcpBridge.ts:1003` (file is
  now 97 lines after F1). Updated to point at the structurally-
  equivalent locations inside the lifted `bridgeClient.ts`.
- `permission.ts:7` no longer says first-responder still lives in
  `cli/src/serve/httpAcpBridge.ts` — points at the bridgeClient.ts
  location.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): adopt 3 Copilot review comments on F1 doc accuracy

Folds in 3 of 4 Copilot inline comments from #4319 review:

1. `bridgeClient.ts` writeTextFile preserveMode comment said "fall
   through to umask defaults" for new files, but the code passes
   `mode: preserveMode?.mode ?? 0o600` to `fs.writeFile`. Updated the
   "BkwQW" comment + the inner catch-block comment to clarify that
   new files actually get the `0o600` default applied at writeFile
   time (NOT umask defaults — the explicit `mode` arg bypasses umask
   for atomicity per the `Blehd` comment block).

2. `bridgeFileSystem.ts` JSDoc referenced
   `cli/src/serve/bridgeFileSystemAdapter.ts` as if the file exists,
   but it's deferred to the immediate F1 follow-up PR. Reworded as
   "the immediate follow-up PR will land a serve-side adapter" so
   reviewers don't grep for a non-existent file.

3. `bridgeOptions.ts` `fileSystem` field JSDoc had the same wording
   issue ("Production `qwen serve` wires this to..."). Same fix — now
   says "The immediate F1 follow-up will land a serve-side adapter"
   so the deferred state is obvious.

Declined from this review round:

- Copilot inline #1 (`spawnChannel.ts:155` stderr forwarder drops
  empty lines): pre-existing behavior since #3889. F1 lifted verbatim
  — not a regression introduced here. Out of scope for a lift PR.
- github-actions bot summary: most items are pre-existing notes
  (TOCTOU residual race, SCRUBBED_CHILD_ENV_KEYS allowlist concern,
  sliceLineRange benchmark threshold) on code the F1 lift moved
  verbatim. One ("httpAcpBridge.ts still has ~3700 LOC") is a false
  positive — the file is 97 LOC after F1. Others are cosmetic
  refactors (extract FIXME to tracking issue, ARCHITECTURE_DECISIONS
  doc system, deprecation timeline) that aren't worth churning the
  lift PR over.

- 44/44 acp-bridge tests pass
- typecheck clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): tighten BridgeFileSystem contract + re-export type from shim

Self-review + code-reviewer agent fold-in, two changes:

1. `cli/src/serve/httpAcpBridge.ts` shim now re-exports
   `BridgeFileSystem` from `@qwen-code/acp-bridge/bridgeFileSystem`
   so the immediate F1 follow-up adapter (in `cli/src/serve/`)
   can import it via the established `./httpAcpBridge.js` path
   like every other daemon-side bridge import does. Without this
   the adapter would need to deep-import from acp-bridge while
   every other serve file goes through the shim — inconsistent.

2. `BridgeFileSystem.readText` + `writeText` JSDoc now spells out
   the two defensive gates the inline proxy carried (non-regular-
   file rejection + 100 MiB buffered-size cap for reads;
   write-then-rename atomicity + dangling-symlink walk-through +
   mode preservation + `0o600` new-file default for writes). When
   a `BridgeFileSystem` is injected, the inline path is FULLY
   bypassed — without the contract spelled out, a future adapter
   author could silently drop the `/dev/zero` / 500 MB log RSS
   defenses the inline path established.

Note on F1 CI: this PR targets `daemon_mode_b_main` but the
`.github/workflows/ci.yml` `pull_request` trigger is scoped to
`branches: main / release/**`, so the main CI workflow (Lint /
Test on Linux/macOS/Windows / CodeQL) does NOT run on this PR.
This is a by-design side effect of the new feature-cohesive
branching strategy — `daemon_mode_b_main → main` periodic merges
will trigger the full CI matrix, providing safety net coverage
before any F-series work lands on `main`. Locally verified:
- 174/174 cli httpAcpBridge tests pass
- 44/44 acp-bridge tests pass
- 735/735 cli serve tests pass
- typecheck clean across acp-bridge + cli

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover BridgeFileSystem injection seam + extract shared writeStderrLine (#4319 wenshao review)

Folds in wenshao review on #4319:

1. **[Critical]** zero test coverage for the F1 step 5 `BridgeFileSystem`
   delegation branches in `BridgeClient.writeTextFile` /
   `BridgeClient.readTextFile` and the factory's
   `opts.fileSystem` → constructor positional-arg forwarding.

   New `packages/acp-bridge/src/bridgeClient.test.ts` adds 6 tests
   covering:
   - writeTextFile delegates to injected fileSystem.writeText (inline
     proxy fully bypassed; `fakeFs.writeText` called with the original
     params; `readText` mock not invoked)
   - writeTextFile invalid-path call succeeds purely via the mock
     when fileSystem is injected (proof that the inline `fs.realpath`
     path doesn't run)
   - readTextFile delegates to injected fileSystem.readText
   - readTextFile propagates injection errors to the caller
   - inline-fallback regression guard: write actually hits disk via
     the inline proxy when fileSystem is omitted (real tmp file
     round-trip)
   - same for read

   Why these matter: the 7-arg `BridgeClient` constructor places
   `fileSystem` at the tail as optional. A reordering — or dropping
   the arg from `bridge.ts` factory's `new BridgeClient(..., opts.fileSystem)`
   call — would silently bypass the adapter in production and the
   inline `fs.writeFile` raw-path would run with no audit / trust /
   TOCTOU coverage. The delegation tests would catch that because
   the mock fileSystem would never be invoked.

2. **[Suggestion]** `writeStderrLine` was defined identically in
   `bridge.ts:117` and `bridgeClient.ts:30` (22 call sites across the
   two files). Both consumers live in the SAME `@qwen-code/acp-bridge`
   package, so the original "no reverse-dep on cli" justification
   doesn't apply within the package. Extracted to
   `packages/acp-bridge/src/internal/stderrLine.ts` — a single source
   of truth that future behavior changes (timestamp prefix, log
   level, structured field) can edit once. `internal/` subpath is
   intentionally not in `package.json`'s `exports`, keeping the
   helper package-private. `spawnChannel.ts` deliberately does NOT
   consume it (its stderr writes use `process.stderr.write(prefix +
   line + '\n')` directly because each line carries its own
   `[serve pid=… cwd=…]` line prefix).

- 6/6 new BridgeFileSystem-seam tests pass
- 50/50 acp-bridge total (44 existing + 6 new)
- 174/174 cli httpAcpBridge tests pass (no regression from refactor)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* test(acp-bridge): cover defaultSpawnChannelFactory env scrubbing + fix bridge.ts comment refs (#4319 wenshao round 2)

Folds in wenshao review on #4319 round 2 — 1 Critical + 2 Suggestions:

1. **[Critical] spawnChannel.ts has 0 unit tests, security-critical
   paths untested.** Now that `defaultSpawnChannelFactory` is a public
   export of `@qwen-code/acp-bridge`, channels + IDE consumers can't
   rely on cli-package integration tests for env-scrubbing guarantees.

   Refactored the inline env-scrubbing logic into a pure exported
   helper `scrubChildEnv(source, scrubbed, overrides)`. Behavior is
   byte-identical to the pre-extraction inline implementation; the
   factory body now reads:

       const childEnv = scrubChildEnv(
         process.env, SCRUBBED_CHILD_ENV_KEYS, childEnvOverrides);

   Added `packages/acp-bridge/src/spawnChannel.test.ts` with 12 tests
   covering:
   - shallow-clone (no aliasing into live process.env)
   - QWEN_SERVER_TOKEN stripping
   - non-scrubbed vars pass through
   - override-add a new key
   - override-replace an existing key
   - override with undefined deletes the key (PR 14 fix #4247 wenshao R5)
   - override CANNOT re-introduce a scrubbed key (defense in depth)
   - override CANNOT undo the scrub by setting undefined for a scrubbed key
   - override-apply-after-scrub ordering invariant
   - empty overrides equals no overrides
   - multi-key scrub for forward-compat (the WARNING comment on
     SCRUBBED_CHILD_ENV_KEYS anticipates a future sandboxed-agent
     mode expanding the denylist; this verifies the loop already
     handles that)

   The killChild SIGTERM→SIGKILL escalation + STDERR_LINE_CAP_CHARS
   truncation are NOT covered yet — they require either real child
   processes or extensive node:child_process mocking; both are
   orthogonal to the env-scrubbing security guarantees wenshao
   explicitly called out, and can land as a follow-up if anyone
   wants the full surface tested.

2. **[Suggestion] bridge.ts comments referenced a "consolidated re-
   export block earlier in this file" that doesn't exist in acp-bridge
   (only in the cli shim).** Fixed both occurrences (~line 292, ~line
   310) to point at the actual local import + the package barrel
   re-export.

3. **[Suggestion] bridge.ts canonicalizeWorkspace re-export comment
   referenced `./fs/paths.ts`.** Updated to mention the full lift
   chain: extracted to `cli/src/serve/fs/paths.ts` in PR 18, then
   lifted here to `./workspacePaths.ts` in PR 22b/1.

- 12/12 new spawn env-scrub tests pass
- 62/62 acp-bridge total (50 existing + 12 new spawn)
- 174/174 cli httpAcpBridge tests still pass (the factory's inline
  env-scrubbing refactor preserves byte-identical behavior)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): fix 14-arg→7-arg typo in test docstring + simplify canonicalizeWorkspace re-export doc (#4319 wenshao round 3)

Folds in 2 of 3 wenshao Suggestions from #4319 round 3:

1. `bridgeClient.test.ts:20` JSDoc said "the 14-arg constructor's
   positional slot" — typo I introduced when writing the test in
   `fbc92bccf`. The same docstring correctly says "the constructor
   takes 7 positional args" at line 25. Updated to "7-arg".

2. `bridge.ts:3461` `canonicalizeWorkspace` re-export JSDoc no longer
   references the historical `cli/src/serve/fs/paths.ts` location.
   Reads cleaner as a present-tense pointer to `./workspacePaths.ts`
   (where the implementation actually lives now post-PR 22b/1).
   Git history covers the lift chain; the docstring should describe
   current state.

DECLINED + tracked separately:

- **[Critical]** `closeSession` + `killSession` use module-scoped
  `channelInfo` instead of `channelInfoForEntry(entry)` — channel-
  overlap edge case can kill the wrong channel. Wenshao explicitly
  notes "pre-existing bug preserved by the lift" — F1's mechanical-
  lift scope shouldn't carry behavior fixes, and the fix needs a
  channel-overlap regression test to land safely. Tracked as #4325.

- 62/62 acp-bridge tests pass (no regression from doc tweaks)
- typecheck + eslint clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): polish from second-pass self-review (cross-platform test + package metadata + dead tombstones)

Five small adoptions from a second-pass code-reviewer agent review on
F1 (no new external comments — pre-emptive cleanup before reviewer
returns):

1. **`bridge.ts:290-313`** — deleted two standalone "InvalidPermission
   OptionError / WorkspaceInit* / McpServer* lifted to bridgeErrors"
   tombstone comments. Pre-22b they were load-bearing (explained why
   the class wasn't `class`-defined inline at that file location).
   Post-F1 the symbols are imported at the top of the file and the
   comments sit between unrelated code (`writeServeDebugLine` /
   `MAX_DISPLAY_NAME_LENGTH` / `DEFAULT_INIT_TIMEOUT_MS`) with no
   anchor. Dead doc — removed.

2. **`README.md`** — `spawnChannel` entry now lists `scrubChildEnv`
   alongside `defaultSpawnChannelFactory` + `killChild` +
   `SCRUBBED_CHILD_ENV_KEYS`. Channels / VSCode IDE consume the
   package barrel so the helper should be visible in the inventory.

3. **`package.json:description`** — refreshed from the PR 22a wording
   ("EventBus, AcpChannel, in-memory channel, PermissionMediator
   interface") to include F1 additions (`createHttpAcpBridge` /
   `BridgeClient` / `defaultSpawnChannelFactory` / `BridgeFileSystem`).
   Visible on `npm view`-style tooling + IDE hover so worth keeping
   current.

4. **`bridgeClient.test.ts:92-115`** — swapped `/proc/no-such-file`
   for `/this/dir/never/exists/file.txt` and reworded the comment.
   `/proc/` is Linux-only; on macOS / Windows the inline proxy's
   dangling-symlink fallback would write through to a path under
   root rather than failing. Test passed regardless (mock assertion,
   not real disk) but the comment overstated portability.

5. **`spawnChannel.test.ts:36`** — added a comment block explaining
   why the test deliberately hand-rolls the SCRUBBED set instead of
   importing the production `SCRUBBED_CHILD_ENV_KEYS`. The
   decoupling is intentional (pure-function parameterized test +
   forward-guard for future denylist expansion) but a naive reader
   would think it's an oversight.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint + pre-commit hooks clean

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix(acp-bridge): bridge.ts security fold-in from #4297 review (3 issues)

Folds 3 unresolved review comments from the post-merge thread on #4297
(wenshao via qwen-latest agent) into F1 (#4319). All 3 touch
`acp-bridge/src/bridge.ts` — the same file F1 already moves the lifted
factory into — so consolidating here saves opening a separate
follow-up PR and keeps the security narrative in one reviewable
commit. The 2 cross-package fixes (`core/src/memory/const.ts` test
gap + `cli/src/serve/runQwenServe.ts` malformed-context fallback)
will land as their own small PRs after F1 merges.

#### Fix 1 (wenshao Critical, #4297 thread): `fs.unlink(target)`
arbitrary-file-deletion primitive in `verifyParentWithinWorkspace`
'create'-cleanup

After `fs.open(target, 'wx')` creates the empty file at the real
parent, an attacker with local workspace write access can swap the
parent directory for a symlink (`docs/` → `/etc`). The cleanup's
`fs.unlink(target)` re-resolves the TEXTUAL path through the
attacker's freshly-planted parent symlink, deleting whatever file
exists at the external location.

Fix: drop the `fs.unlink(target)` line. The 0-byte file at the
pre-race location is harmless (0 bytes, inside the workspace we'd
already verified) — leaving it over deleting an arbitrary external
file is the right safety trade. Comment block explains the
reasoning so future maintainers don't re-introduce the unlink.

#### Fix 2 (wenshao Critical): `O_TRUNC` arbitrary-file-truncation
primitive in workspace-init 'overwrite' branch

`O_TRUNC` causes the kernel to truncate the file to zero bytes AT
`open(2)` SYSCALL TIME — strictly before `verifyParentWithinWorkspace`
runs. A parent-symlink TOCTOU race between
`canonicalizeExistingAncestor` and this `open()` zeros the file at
the attacker-redirected location (arbitrary-file-truncation
primitive against any file the daemon UID can open). The pre-fix
code's own comment on `verifyParentWithinWorkspace` acknowledged
this as "Acceptable residual posture for the Stage-1 trust model";
wenshao pushed back that arbitrary-file-zeroing exceeds the
Stage-1 trust budget.

Fix: drop `O_TRUNC` from the open flags. Truncation moves to AFTER
`verifyParentWithinWorkspace` succeeds, via `fh.truncate(0)` on the
fd we already hold. fd-based truncate does NOT re-resolve the path
— an attacker swapping the parent symlink after we open can't
redirect the truncation.

#### Fix 3 (wenshao Suggestion): `canonicalizeExistingAncestor`
missing `ELOOP` catch

Circular symlinks in the parent path (`a -> b`, `b -> a`) cause
`fs.realpath` to fail with `ELOOP`. Without catching it, the error
propagates as an unstructured HTTP 500 instead of the typed
`WorkspaceInitSymlinkError` (HTTP 400) the route handler expects
from the workspace-init race-detection family.

Fix: add `'ELOOP'` to the caught error codes alongside `'ENOENT'`
and `'ENOTDIR'`. Walking up the parent chain when ELOOP hits at a
sub-component preserves the existing "walk to the deepest extant
ancestor" contract — the deepest realpath-able ancestor still
dictates the canonical prefix.

#### Why no new tests in this commit

- Fix 1 is a single-line removal: any regression that re-adds the
  unlink would be caught by reviewing the diff; existing 174-test
  `httpAcpBridge.test.ts` integration suite confirms the create-path
  still works (file is created + closed correctly; only the
  attacker-cleanup branch changes).
- Fix 2 is a structural move (truncate from open-time to post-verify);
  the existing overwrite-init integration tests confirm the
  end-to-end behavior is unchanged (file ends up empty after init).
  Adding a TOCTOU race regression test requires controlled
  filesystem-race simulation that exceeds reasonable test infra
  scope for this PR.
- Fix 3 is a one-word addition to an error code list; the
  `canonicalizeExistingAncestor` helper is module-private and the
  integration test for circular-symlink → typed 400 would require
  exporting it OR setting up a real circular-symlink workspace.
  Both routes widen scope beyond the security fix itself; the
  high-level behavior is verifiable by the existing route-error-
  mapping test pattern + diff review.

A follow-up PR can add the integration tests once the security fix
itself has shipped; the immediate priority is closing the
arbitrary-file-deletion + arbitrary-file-truncation primitives.

- 62/62 acp-bridge tests pass
- 174/174 cli httpAcpBridge.test.ts pass
- typecheck + eslint clean

#### Refs

- Original review on #4297 (wenshao via qwen-latest agent), post-
  merge, currently unresolvable on #4297 itself because that PR is
  already MERGED.
- Other 2 #4297 review threads (`const.ts` test coverage,
  `runQwenServe.ts` malformed-context observability) target files
  outside F1's scope and will land as separate follow-up PRs.

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* fix: post-merge Codex P2 fold-in — MCP restart disabled-tools normalization + SDK timeout headroom (#4319)

Folds in 2 P2 findings from a Codex review run on `git diff main...HEAD`
of F1 PR #4319. Both are pre-existing in code merged into
`daemon_mode_b_main` before F1 was created (#4282 PR 17), but they're
tiny tactical fixes (~25 LOC + 1 LOC) on the same integration branch
the same reviewer (wenshao) already engages with, so folding into F1
saves an extra follow-up PR cycle.

#### Fix 1: normalize disabled tool names during MCP restart refresh

`packages/cli/src/acp-integration/acpAgent.ts:1563-1566`

The bootstrap path in `cli/src/config/config.ts:1426-1434` applies a
4-step normalization to `tools.disabled`:
  1. typeof string filter
  2. .trim()
  3. drop empty after trim
  4. dedupe via Set

The MCP-restart refresh path only did step 1, then stored the raw
strings. `ToolRegistry` checks disabled tools with EXACT
`Set.has(tool.name)`, so a tool disabled at boot as `' Foo '` (or
`'Foo\n'`) is no longer matched after `restartMcpServer` and gets
silently re-registered. This contradicts the documented "toggle +
restart" workflow that #4282 PR 17 advertised.

Fix: mirror the bootstrap normalization verbatim before
`setDisabledTools`. Adds 6 lines + a 7-line comment pointing at the
bootstrap reference for future maintainers.

#### Fix 2: add headroom to MCP restart SDK timeout

`packages/sdk-typescript/src/daemon/DaemonClient.ts:102`

The SDK's `MCP_RESTART_DEFAULT_TIMEOUT_MS` was EXACTLY 300_000ms, the
same ceiling the daemon's own `MCP_RESTART_TIMEOUT_MS` uses for the
upper bound on a single MCP rediscovery. For restarts that finish
(or fail with a typed `McpServerRestartFailedError` JSON envelope)
near 300s, the client `AbortSignal` could fire BEFORE the daemon had
finished serializing + transmitting the response, yielding a client
`TimeoutError` even though the daemon was still within its own
budget.

Fix: bump to 330_000ms (10% / 30s headroom over the daemon ceiling).
Comment updated to call out the race + the rationale for the
specific headroom value. Callers needing tighter caps still pass
their own `timeoutMs` to `restartMcpServer`.

#### Why folded into F1 vs separate follow-up PRs

These are post-merge findings on `#4282 PR 17` code, not F1-introduced
regressions. Normally we'd track as separate follow-up issues (mirror
of the #4325 / `channelInfo` decline). But:

- Both fixes are TINY (~25 LOC + ~2 LOC including comment); the bridge
  security fold-in commit `7bd66c6e8` set the precedent of folding in
  small same-branch issues when the cost-benefit favors closing them
  immediately.
- Same reviewer (wenshao via qwen-latest agent) — won't be confused
  by the scope expansion; in fact the original PR 17 commenter is
  also the one who'd review the follow-up issue's fix.
- Both fixes target `daemon_mode_b_main`-only paths (MCP restart route
  added by PR 17 lives on the integration branch).
- Saves opening 2 trivial follow-up issues that would just sit until
  someone picks them up.

#### Verification

- sdk-typescript: 424/424 tests pass (no test hardcoded the old
  300_000 default — only the constant declaration itself referenced it)
- cli acp-integration: 282/282 tests pass (no test exercised the
  exact whitespace-bearing disabled-tools scenario, so no test
  changes were strictly required; a regression test would belong in
  a separate test-coverage PR alongside the const.ts test gap from
  the #4297 unresolved-comment thread)
- typecheck clean across cli + sdk-typescript

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)

* docs(acp-bridge): wenshao review round 4 — 3 Suggestion fold-ins (#4319)

1. **bridge.ts:2270 stale line refs in `publishWorkspaceEvent` JSDoc**
   — comment said `permission_resolved at line 1717` (actual: line 682)
   and `broadcastWorkspaceEvent closure at ~line 2127` (actual: line
   1281). Line numbers drifted across the lift commits. Replaced both
   with function-name refs (`in resolvePending`, `declared above in
   this factory body`) that survive future edits.

2. **`ws.ts:613` opaque references in bridgeFileSystem.ts:20 +
   bridgeOptions.ts:267** — no `ws.ts` file exists in the repo; the
   ref came from an internal review thread on PR 18 that future
   readers can't locate. Replaced with a self-contained description
   ("post-PR-18 follow-up thread about BridgeClient's inline fs prox…
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants