Skip to content

fix(serve): auth device-flow follow-up for #4255 review threads#4291

Merged
doudouOUC merged 5 commits into
mainfrom
fix/serve-auth-device-flow-followup
May 18, 2026
Merged

fix(serve): auth device-flow follow-up for #4255 review threads#4291
doudouOUC merged 5 commits into
mainfrom
fix/serve-auth-device-flow-followup

Conversation

@doudouOUC

@doudouOUC doudouOUC commented May 18, 2026

Copy link
Copy Markdown
Collaborator

Summary

Fold-in for the 5 review comments posted ~20 min after #4255 merged (deepseek-v4-pro / DeepSeek). All 5 are real, observable gaps; this PR addresses them in a single follow-up.

# Severity File What
1 Critical qwenDeviceFlowProvider.ts poll() catch now writes raw err.message to stderr (mirrors start()). Without it, on-call sees only the static upstream_error hint at 3 AM and can't distinguish WAF block / proxy 503 / JSON parse
2 Critical deviceFlow.ts runPollTick races provider.poll() against new DEVICE_FLOW_POLL_TIMEOUT_MS = 30_000. Same shape as doStart (#1) and persist (#2). A non-abortable provider could pin the per-providerId singleton until sweeper-level expiry (10 min default)
3 Suggestion server.ts GET /workspace/auth/device-flow/:id only echoes userCode / verificationUri / verificationUriComplete / initiatorClientId to caller matching the original initiator (via X-Qwen-Client-Id). Symmetric with the POST take-over response (round-12 #6)
4 Suggestion deviceFlow.ts cancellerClientId is now first-writer-wins. Two SDK clients racing cancel() on the same persist-in-flight entry can no longer overwrite SSE event attribution
5 Suggestion events.ts 'not_found_or_evicted' added to DaemonAuthDeviceFlowErrorKind typed union. SDK consumers' exhaustive switches now narrow it as a known literal instead of falling into the (string & {}) fallback arm

Test plan

  • npx vitest run packages/cli/src/serve/ — 668 passed (was 665; +3 tests)
  • npx vitest run packages/sdk-typescript/test/unit/ — 389 passed
  • npm run typecheck — clean across cli + core + sdk + webui
  • npx eslint --max-warnings 0 <touched surface> — clean
  • New tests:
    • deviceFlow.test.ts: poll timeout race + cancellerClientId first-writer-wins
    • server.test.ts: GET clientId gating (matching / anonymous / different)

Refs: #4175, #4255

🤖 Generated with Qwen Code


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

更正:表 #1 称 writes raw err.message to stderr,实际相反——sanitizeForStderr 仅输出结构化 oauthError,刻意不打印 raw(防 device_code 泄漏)。

Fold-in for the 5 review comments posted ~20 min after #4255 merged
(deepseek-v4-pro / DeepSeek). All 5 are real, observable gaps; this
commit addresses them in a single follow-up:

1. **stderr audit for raw poll() errors** (Critical) — `qwenDeviceFlowProvider.poll()`'s
   catch block previously dropped raw `err.message` on the floor; only
   the static `upstream_error` hint reached SSE/HTTP. `start()` already
   used `writeStderrLine(...)` for this; symmetrize so on-call has a
   breadcrumb at 3 AM (WAF block vs. proxy 503 vs. JSON parse).

2. **runPollTick poll() Promise.race timeout** (Critical) — `provider.poll()`
   only had `entry.cancelController.signal` for cooperative cancellation;
   a non-abortable provider could pin the per-providerId singleton until
   the sweeper expired the entry (10 min default). Add
   `DEVICE_FLOW_POLL_TIMEOUT_MS = 30_000` and race the same shape used
   by `doStart` (#1) and persist (#2).

3. **GET clientId-gated userCode/verificationUri/initiatorClientId** —
   `GET /workspace/auth/device-flow/:id` previously echoed all fields
   to any bearer holder; the POST take-over response (round-12 #6)
   already gated `initiatorClientId` on caller-clientId match. Symmetrize:
   only the original starter (matched by `X-Qwen-Client-Id`) sees
   `userCode` / `verificationUri` / `verificationUriComplete` /
   `initiatorClientId`. Anonymous and different-clientId callers see
   only the public envelope.

4. **cancellerClientId first-writer-wins** — two SDK clients racing
   `cancel()` on the same persist-in-flight entry would overwrite
   attribution; the second cancel is functionally a no-op on the
   entry (already marked `cancelRequestedDuringPersist`) but its id
   silently took over the SSE event's `originatorClientId`. Guard
   with `if (entry.cancellerClientId === undefined)`.

5. **`not_found_or_evicted` into `DaemonAuthDeviceFlowErrorKind`** —
   SDK synthesizes this errorKind from a daemon 404, but the typed
   union didn't list it; SDK consumers' exhaustive switches couldn't
   narrow it as a known literal (fell into the `(string & {})` fallback
   arm). Add the literal so it's compile-time recognized.

Tests:
- `deviceFlow.test.ts` +2 (poll timeout race; cancellerClientId
  first-writer-wins)
- `server.test.ts` +1 (GET clientId gating: matching / anonymous /
  different)
- existing 665 cli serve + 384 sdk tests still green
- typecheck clean across cli + core + sdk + webui
- eslint --max-warnings 0 clean on touched files

Refs: #4175, #4255

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
Copilot AI review requested due to automatic review settings May 18, 2026 15:26
@github-actions

Copy link
Copy Markdown
Contributor

📋 Review Summary

This PR addresses 5 review comments from #4255 (deepseek-v4-pro review) with focused, well-targeted fixes. The changes improve error handling, timeout enforcement, and security gating in the device-flow authentication system. All modifications are conservative and follow established patterns from the earlier PR.

🔍 General Feedback

  • Strong defensive programming: The timeout race patterns (Promise.race with authoritative timers) are now consistently applied across start(), poll(), and persist() phases
  • Good test coverage: New tests directly exercise the specific failure modes identified in review (hanging poll, concurrent cancel, clientId gating)
  • Consistent error handling: Stderr audit logging follows the same truncation pattern as existing code
  • Type safety: Adding 'not_found_or_evicted' to the typed union is the right approach for SDK consumer exhaustiveness checks

🎯 Specific Feedback

🟡 High

  • File: deviceFlow.ts:1047-1083 - The poll timeout implementation introduces a new pollTimer variable that must be tracked and cleared. The finally block correctly clears it, but there's a subtle race: if provider.poll() throws synchronously before the timer fires, the timer is still scheduled and will fire later. This is harmless (the reject on an already-resolved promise is a no-op), but consider calling clearScheduled in the catch block immediately when an error is caught to avoid the unnecessary timer callback execution.

  • File: deviceFlow.ts:944 - The first-writer-wins check entry.cancellerClientId === undefined is correct, but the comment mentions "subsequent callers stay in the audit trail through their own audit.record(...) path". Verify that the audit trail actually records the second caller's clientId - the code at line 944 shows the assignment is skipped, but the audit record should still be written. A test asserting the second caller appears in audit logs would strengthen this.

🟢 Medium

  • File: qwenDeviceFlowProvider.ts:209-213 - The new stderr logging for poll() failures mirrors the start() path well. However, the errorKind determination at line 199 happens before the stderr write, meaning the errorKind value is available. Consider including the mapped errorKind in the stderr message itself (you already do this - good!), but also consider adding the upstream error code when available (similar to how start() logs the error envelope). This would help on-call distinguish between authorization_pending noise and genuine failures at a glance.

  • File: server.ts:1776-1796 - The toDeviceFlowStateBody function now conditionally includes sensitive fields based on callerIsInitiator. The logic is correct, but the function signature change (adding optional callerClientId) means all existing call sites need to be audited. The diff shows only one call site (line 739), which is correctly updated. Consider making callerClientId required and passing undefined explicitly from call sites that don't have a clientId, to make the security boundary more explicit in the type system.

🔵 Low

  • File: deviceFlow.ts:54-67 - The JSDoc for DEVICE_FLOW_POLL_TIMEOUT_MS is comprehensive but quite verbose. Consider trimming the explanation of "why" (the hung IdP scenario) since this is already documented in the design docs referenced by feat(serve): auth device-flow route (#4175 Wave 4 PR 21) #4255. The key information (30s timeout, symmetric with other phases, aborts signal first) is present and valuable.

  • File: events.ts:207-214 - The JSDoc comment for 'not_found_or_evicted' is excellent and provides clear guidance on the three reachable causes. Consider adding a fourth scenario: "the daemon's sweeper evicted the entry after the terminal grace period expired" - this is implied by (a) but worth calling out explicitly since the SDK consumer will encounter this most frequently.

  • File: deviceFlow.test.ts:740-745 - The test for hanging poll uses expect(provider.lastPollSignal?.aborted).toBe(true). Consider also asserting that provider.pollCount remains at 1 (no retry after timeout) to verify the registry doesn't reschedule a poll after a timeout rejection.

✅ Highlights

  • Excellent test design: The FakeProvider.pollHangs test hook is a clean way to model misbehaving providers without complex mocking infrastructure
  • Security-conscious: The GET endpoint clientId gating correctly prevents cross-client enumeration of verification codes while maintaining the bearer-token security boundary
  • Consistent patterns: All timeout implementations now follow the same Promise.race pattern with signal abort + timer reject, making the codebase more maintainable
  • Good observability: Stderr audit logging provides on-call operators with actionable detail without leaking sensitive data to SSE subscribers

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 follows up on device-flow auth review feedback for qwen serve, tightening polling behavior, client-scoped GET responses, SDK error typing, and related tests.

Changes:

  • Adds a bounded poll timeout and first-writer-wins cancellation attribution in the device-flow registry.
  • Restricts GET device-flow detail fields based on X-Qwen-Client-Id.
  • Extends SDK error typing for synthetic 404/eviction states and adds route/registry tests.

Reviewed changes

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

Show a summary per file
File Description
packages/sdk-typescript/src/daemon/events.ts Adds not_found_or_evicted to the typed device-flow error kind union.
packages/cli/src/serve/server.ts Gates sensitive GET device-flow fields on matching caller client id.
packages/cli/src/serve/server.test.ts Adds coverage for GET client-id gating behavior.
packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts Adds stderr logging for poll failures.
packages/cli/src/serve/auth/deviceFlow.ts Adds poll timeout handling and first-writer-wins canceller attribution.
packages/cli/src/serve/auth/deviceFlow.test.ts Adds tests for poll timeout and concurrent cancel attribution.

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

Comment thread packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts Outdated
Comment thread packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts Outdated
Comment thread packages/cli/src/serve/server.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts Outdated
@github-actions

github-actions Bot commented May 18, 2026

Copy link
Copy Markdown
Contributor

Code Coverage Summary

Package Lines Statements Functions Branches
CLI 77.36% 77.36% 79.92% 79.99%
Core 79.38% 79.38% 82% 82.77%
CLI Package - Full Text Report
-------------------|---------|----------|---------|---------|-------------------
File               | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s 
-------------------|---------|----------|---------|---------|-------------------
All files          |   77.36 |    79.99 |   79.92 |   77.36 |                   
 src               |   75.73 |    69.15 |   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 |     72.5 |     100 |   74.51 | ...41-265,290,391 
  ...ActiveAuth.ts |     100 |     87.5 |     100 |     100 | 66-80             
 ...cp-integration |   61.49 |    64.49 |   77.77 |   61.49 |                   
  acpAgent.ts      |   62.85 |    64.59 |   82.75 |   62.85 | ...2076,2090-2098 
  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         |   79.57 |    79.37 |    92.3 |   79.57 |                   
  auth.ts          |   88.49 |    88.63 |     100 |   88.49 | ...49-150,153-155 
  capabilities.ts  |     100 |     90.9 |     100 |     100 | 264               
  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 |   78.38 |    77.75 |   95.49 |   78.38 | ...5223,5254-5295 
  ...oryChannel.ts |     100 |      100 |     100 |     100 |                   
  index.ts         |       0 |        0 |       0 |       0 | 1-106             
  loopbackBinds.ts |     100 |      100 |     100 |     100 |                   
  runQwenServe.ts  |   73.81 |    87.83 |   55.55 |   73.81 | ...87-703,728-730 
  server.ts        |   86.16 |    82.94 |   90.62 |   86.16 | ...2469,2534-2543 
  status.ts        |    93.5 |    96.96 |   88.88 |    93.5 | 369-376,574-575   
  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.86 |    79.67 |     100 |   84.86 |                   
  audit.ts         |     100 |    96.15 |     100 |     100 | 201               
  errors.ts        |     100 |      100 |     100 |     100 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  paths.ts         |   78.26 |    76.76 |     100 |   78.26 | ...38,567-571,584 
  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.44 |    82.53 |   86.66 |   82.44 |                   
  ...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.38 |    74.63 |   91.66 |   77.38 | ...2465,2478-2486 
  ...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.69 |     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 |    7.14 |     100 |                   
  ...eractiveUi.ts |     100 |      100 |    7.14 |     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.51 |   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 |     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.38 |    82.77 |      82 |   79.38 |                   
 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.32 |    81.27 |   65.39 |   78.32 |                   
  config.ts        |   76.12 |    79.96 |   60.63 |   76.12 | ...3659,3670-3682 
  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.74 |    82.29 |   89.86 |   86.74 |                   
  baseLlmClient.ts |   92.35 |    80.85 |   86.66 |   92.35 | ...34,342-356,495 
  client.ts        |    85.8 |    77.77 |   84.84 |    85.8 | ...1769,1808-1811 
  ...tGenerator.ts |    72.1 |    61.11 |     100 |    72.1 | ...63,365,372-375 
  ...lScheduler.ts |   82.97 |    81.44 |   93.47 |   82.97 | ...2431,2483-2487 
  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.42 |    88.88 |     100 |   96.42 | ...00,413-414,462 
 ...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 |    92.1 |    80.38 |   90.32 |    92.1 |                   
  index.ts         |     100 |      100 |     100 |     100 |                   
  ...tGenerator.ts |   92.08 |    80.38 |   90.32 |   92.08 | ...85,895-896,924 
 ...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.23 |    82.44 |   94.11 |   89.23 |                   
  ...eGoalStore.ts |   81.57 |    92.85 |   81.81 |   81.57 | ...43-146,154-162 
  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.59 |     85.9 |   78.77 |   74.59 |                   
  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 |   90.69 |    87.87 |     100 |   90.69 | ...67-471,482-485 
  ...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,104            
  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.55 |   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 |    79.59 |   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.

Three real findings from the Copilot review on the follow-up PR
(#4291), plus a documentation-level clarification:

C1+C2 (Critical, qwenDeviceFlowProvider.ts) — the new poll() catch
stderr line had two issues that the original implementation glossed
over:
  - It treated `AbortError` (the normal cancel/dispose lifecycle event)
    as a "poll failed" operator audit line, polluting stderr with
    every user cancellation and shutdown.
  - It echoed raw `err.message` into stderr. `pollDeviceToken` POSTs
    `device_code` + PKCE verifier per RFC 8628 §3.4; a WAF / reverse
    proxy that echoes the request body in its error response would
    leak bearer-equivalent secret material into daemon logs,
    violating the BrandedSecret-style "secrets never appear in logs"
    contract. Restructure: skip on aborted signal / `AbortError`;
    log STRUCTURED diagnostics only — `QwenOAuthPollError.oauthError`
    on the OAuth path, `err.name + message length` on non-OAuth.

C4 (Bug, deviceFlow.ts) — the first-writer-wins guard from the
original follow-up PR used `entry.cancellerClientId === undefined`
as the gate, which silently broke when the first canceller was
anonymous: their `cancel(id, undefined)` left the field undefined,
and a later identified `cancel(id, 'sdk-B')` saw the gate as still
open and overwrote attribution. Decouple "have we recorded a
canceller" from "do we have a clientId" via a new
`cancellerRecorded` boolean flag. Anonymous first cancellers now
correctly block any later writer.

C3 (Doc, server.ts) — the GET clientId gate from the original
follow-up was correctly flagged by Copilot as syntactic-only, NOT a
real authentication boundary (anyone holding the bearer token can
spoof `X-Qwen-Client-Id`). Behavior unchanged — bearer remains the
auth boundary, this gate prevents accidental cross-client reads in
well-behaved multi-SDK setups (mirrors POST take-over round-12 #6).
Add a "Threat model" paragraph to the JSDoc making this explicit so
future readers don't mistake it for a security boundary.

Tests:
  - `cancellerClientId is first-writer-wins even when the first
     canceller is anonymous` — covers the C4 regression with
     anonymous-first + identified-second cancel.
  - `poll() that hangs past POLL_TIMEOUT_MS` — additionally pins
     `pollCount === 1` to assert the registry doesn't reschedule
     after a timeout-driven `upstream_error` (Qwen Code review
     summary, low priority).

cli serve 669/669; sdk 389/389; 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)
Comment thread packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts Outdated
Comment thread packages/cli/src/serve/auth/deviceFlow.ts Outdated
Comment thread packages/cli/src/serve/server.ts
Comment thread packages/cli/src/serve/server.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts Outdated
Five new findings from the qwen-latest review on the follow-up PR
(#4291), all real:

#1 Critical (qwenDeviceFlowProvider.test.ts NEW) — the four poll()
catch branches added in the previous round (AbortError skip,
QwenOAuthPollError structured detail, generic Error name+length
redaction, non-Error throw placeholder) had ZERO unit-test coverage.
The security-critical secret-suppression path (preventing
device_code + PKCE leakage via WAF-echoed request bodies) was
unverified. Added a dedicated test file with 7 tests pinning each
branch — including hard negative assertions that the raw `err.message`
never appears in stderr when the message contains seeded device-flow
secrets.

#2 Critical (deviceFlow.ts) — runPollTick's race-timer rejection was
routed through the same `provider.poll() threw (raw): ...` audit
template as a real provider throw. At 3 AM, on-call grepping the
provider source for that throw would waste time on the wrong layer
when the actual issue is a hung IdP. Introduced a sentinel
`DeviceFlowPollTimeoutError` class; the catch branches on it to use
a dedicated hint (`provider.poll() timed out after Nms; check IdP
connectivity`) and skip the misleading raw audit template.

#3 (server.ts) — the GET clientId gate from the previous round used
`initiatorClientId !== undefined && callerClientId !== undefined`
as the equality precondition, which silently locked anonymous-
started flows out of their own data: a flow started without
X-Qwen-Client-Id has `initiatorClientId === undefined`, so even the
same anonymous caller could no longer retrieve `userCode` /
`verificationUri` via GET (HTTP 200, redacted body, no error). Fix:
also accept the both-undefined case so the gate's purpose ("prevent
cross-client reads") is preserved without locking anonymous flows
out of themselves.

#4 (server.ts JSDoc) — the GET handler now calls parseClientIdHeader
to drive the gate, which means a malformed X-Qwen-Client-Id (>128
chars or invalid characters) returns 400 instead of the previous
200. Behavior unchanged — strict matches POST/DELETE — but the JSDoc
is updated to document the contract change explicitly so future
readers / SDK upgrades aren't surprised. Anonymous callers (header
absent) are unaffected.

#5 (deviceFlow.ts) — when our race-timer fires first, the original
`provider.poll()` promise keeps running in the background. If it
later resolves (flaky-but-responsive IdP), the second `.then(...)`
on the already-settled outer promise was a silent no-op. Added a
passive observer on the original promise that records a
`lost_late_poll_after_timeout` audit line — symmetric with the
`lost_success_after_timeout` pattern on the persist path. Operators
can now distinguish "IdP fully unresponsive" from "IdP responsive
but slow past the 30s ceiling" — the alerting / triage signal that
was missing.

Tests:
- NEW packages/cli/src/serve/auth/qwenDeviceFlowProvider.test.ts (7
  tests pinning the four stderr branches; uses brandSecret-shaped
  fixtures so a future regression that re-introduces device_code
  in stderr fails CI)
- deviceFlow.test.ts: poll-timeout test now asserts the timeout
  hint (timed out after / check IdP connectivity), the absence of
  the misleading "see daemon audit log for details" line, and that
  the audit hint never carries the "provider.poll() threw (raw)"
  template
- deviceFlow.test.ts: new test covering the lost_late_poll_after_timeout
  observer (provider.poll() resolves AFTER the registry race fires)
- server.test.ts: new test for the anonymous-started-flow case in #3

cli serve 678/678 (+9 from previous push); sdk 389/389; 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)
@doudouOUC doudouOUC requested a review from wenshao May 18, 2026 16:53
Comment thread packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts
Comment thread packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts Outdated
Comment thread packages/cli/src/serve/server.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts Outdated
Comment thread packages/cli/src/serve/auth/deviceFlow.test.ts
Comment thread packages/cli/src/serve/server.ts
Comment thread packages/cli/src/serve/server.ts
doudouOUC added 2 commits May 19, 2026 01:13
Three findings from the gpt-5.5 review on the follow-up PR (#4291),
all real:

#1 (qwenDeviceFlowProvider.ts) — the previous abort-skip gate was
`opts.signal.aborted || err.name === 'AbortError'`, which silently
dropped stderr breadcrumbs for `AbortError`s coming from sources we
did NOT initiate: upstream IdP TCP RST, proxy timeout, undici/
node-fetch wrapping unrelated transport failures as AbortError.
Those are real failures the operator needs visibility into. The
gate is now `opts.signal.aborted` only — unexpected `AbortError`s
fall through to the sanitized non-OAuth path with a `name + length`
breadcrumb. New test pins the regression: signal NOT aborted +
provider throws AbortError → stderr DOES record a line.

#2 (qwenDeviceFlowProvider.ts) — `QwenOAuthPollError.oauthError`
comes directly from the upstream JSON `error` field; it's
attacker-controlled if the IdP / WAF / proxy is hostile or
compromised. A value like `slow_down\n[serve] FORGED LOG ENTRY ...`
would otherwise forge additional log lines; a value containing
`\x1b[31m` could inject ANSI control sequences into operator
terminals. New `sanitizeForStderr(value)` helper replaces C0/C1
controls and DEL with `?` (length-preserving) before interpolation.
New test uses a malicious `oauthError` containing both `\n` and
`\x1b` and asserts the forged second log line never materializes
and the ANSI escapes are gone.

#3 (server.ts) — `toDeviceFlowStartResponseBody` previously echoed
`userCode` / `verificationUri` / `verificationUriComplete`
unconditionally on EVERY POST response, including the take-over
case (`attached: true`). That made the carefully-closed GET
redaction a paper tiger: any bearer-token holder POSTing the same
`providerId` got the verification material another client started.
Apply the SAME `callerIsInitiator` gate (with both-undefined branch
for anonymous-start → anonymous-reattach) to the take-over
response. Fresh starts naturally pass the gate (caller IS the
initiator on the same request); take-over callers with a different
clientId — or anonymous take-overs against an identified start —
see only the public envelope.

Tests:
- `qwenDeviceFlowProvider.test.ts`: reworked `signal.aborted +
  AbortError → no stderr` test (the legitimate cancel path); NEW
  test for `signal NOT aborted + AbortError → stderr DOES record`
  (the regression #1 closes); NEW test for control-char
  sanitization (#2). Total 9 tests (was 7).
- `server.test.ts`: NEW test for cross-client take-over (sdk-A
  starts, sdk-B / anonymous take-over → no userCode); NEW test
  preserving the anonymous-start → anonymous-reattach use case
  via the both-undefined branch.

cli serve 682/682; sdk 389/389; 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)
Four findings from the qwen-latest review on the follow-up PR
(#4291), all real:

N1 (deviceFlow.ts) — `lost_late_poll_after_timeout` success handler
unconditionally wrote "IdP is responsive but slow", but for a
cooperative provider whose abort path RESOLVES to
`{kind: 'error', errorKind: 'upstream_error'}` (the Qwen impl does
this in response to AbortError), the late observer's success
handler fires with `latePollResult.kind === 'error'`. The "response"
is just the abort-cooperation path — IdP could be totally down.
At 3 AM, on-call would conclude the IdP is reachable, the exact
opposite of correct triage. Branch the hint on
`latePollResult.kind === 'error'` to use "abort-driven cooperation;
IdP responsiveness unknown" instead.

N2 (deviceFlow.test.ts) — the `onRejected` branch of the late-poll
observer was zero-tested, leaving three sub-paths uncovered: the
`DeviceFlowPollTimeoutError` self-filter guard, the >256-byte
truncation tail, and the audit record itself. Added two tests:
late-rejection with a connection-reset-shaped error (covers the
truncation + audit shape), and a guard test rejecting with the
registry's own DeviceFlowPollTimeoutError sentinel that asserts NO
late audit line is emitted (no double-counting).

N3 (server.test.ts) — the GET strict-clientId behavior change
introduced in #4291 (now 400s on malformed `X-Qwen-Client-Id`) was
documented in JSDoc but not pinned in CI. A future refactor that
removed or reordered `parseClientIdHeader` would silently revert
the contract. Added a test pinning both the over-length (>128
chars) and invalid-charset paths.

N4 (server.ts) — when the `callerIsInitiator` gate redacts the GET
response, operators triaging "SDK got HTTP 200 but no userCode" had
zero signal in daemon stderr / audit. Added a `QWEN_SERVE_DEBUG`-
gated stderr breadcrumb in the GET handler — cheap, doesn't pollute
production logs (multi-SDK setups would otherwise flood the audit
with legitimate cross-client traffic), and operators who hit the
symptom can flip the env var and get the breadcrumb on the next
reproduction.

Tests:
- N1 paired tests: existing `kind=pending` resolve path now also
  asserts the "responsive but slow" hint AND negative assertion
  on "abort-driven"; new test exercises kind=error resolve and
  asserts the "abort-driven cooperation" hint with negative
  assertion on "responsive but slow"
- N2: late-rejection observer test (with truncation tail
  assertion) + DeviceFlowPollTimeoutError self-filter guard test
- N3: GET 400 invalid_client_id pinned for over-length and
  invalid-charset paths

cli serve 686/686 (was 682, +4); sdk 389/389; typecheck clean;
eslint --max-warnings 0 clean on touched files.

Refs: #4175, #4255, #4291

🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
@doudouOUC doudouOUC self-assigned this May 18, 2026
@doudouOUC doudouOUC requested a review from wenshao May 18, 2026 17:37
Comment thread packages/cli/src/serve/auth/deviceFlow.ts
Comment thread packages/cli/src/serve/server.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts
Comment thread packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts

@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.

No additional issues found. LGTM! ✅ — gpt-5.5 via Qwen Code /review

Comment thread packages/cli/src/serve/server.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts
@doudouOUC doudouOUC merged commit 93ad0ff into main May 18, 2026
26 checks passed
Comment thread packages/cli/src/serve/auth/deviceFlow.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts
Comment thread packages/cli/src/serve/auth/deviceFlow.ts
Comment thread packages/cli/src/serve/auth/qwenDeviceFlowProvider.ts
doudouOUC added a commit that referenced this pull request May 19, 2026
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)
doudouOUC added a commit that referenced this pull request May 19, 2026
…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)
doudouOUC added a commit that referenced this pull request May 19, 2026
… 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)
doudouOUC added a commit that referenced this pull request May 19, 2026
* 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)
@yiliang114 yiliang114 added the skip-changelog Exclude from release notes label May 20, 2026
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

skip-changelog Exclude from release notes

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants