Thanks for the PR, @doudouOUC!

Template looks good ✓ — all required sections present, bilingual, N/A appropriately used for the evidence section on this non-UI change.

On direction: This directly addresses one of the five tracked ACP gaps in issue #5677 (/lsp). Adding a structured, read-only LSP status endpoint for daemon/ACP clients is clearly within scope — remote clients need typed status data, not Markdown from a slash command. The approach of keeping it separate from the existing /lsp interactive command is the right call.

On approach: The scope feels right. The change follows the established session-status pattern (REST route → ACP method → capability tag → SDK helper), mirrors existing routes like /session/:id/tasks and /session/:id/supported-commands, and the sanitization in buildSessionLspStatus correctly strips debug internals (pid, args, stderr, rootUri, workspaceFolder). The --experimental-lsp opt-in for spawned ACP children keeps LSP startup gated. The extraArgs mechanism on createSpawnChannelFactory is minimal and extensible without being speculative.

One thing worth noting: ServeLspServerStatus / ServeSessionLspStatus in packages/acp-bridge/src/status.ts and DaemonLspServerStatus / DaemonSessionLspStatus in packages/sdk-typescript/src/daemon/types.ts are near-identical type definitions. This mirrors the existing pattern for other status types (tasks, context, etc.) across the bridge/SDK boundary, so it's consistent — but if there's ever a consolidation effort for these duplicated shapes, this would be one more entry.

Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code Review

The implementation follows established patterns well — REST route, ACP method, capability tag, SDK helper, sanitization. The diff is clean and focused. One critical bug found:

🐛 --experimental-lsp flag is not registered in the yargs builder. The ServeArgs interface declares experimentalLsp?: boolean and the handler reads argv.experimentalLsp, but no .option('experimental-lsp', {...}) call exists in the builder chain (serve.ts:116-316). The production CLI uses .strict() (via config.ts:1057), so passing --experimental-lsp at runtime produces Unknown arguments: experimental-lsp, experimentalLsp and the daemon refuses to start. The unit test in serve.test.ts passes because its buildParser() uses yargs([]).exitProcess(false).fail(false) without .strict(), so the test never catches this gap. Fix: add .option('experimental-lsp', { type: 'boolean', default: false, description: '...' }) to the builder.

Everything else looks correct: sanitization strips pid/args/stderr/rootUri/workspaceFolder, session ownership is enforced, disabled/unavailable states return HTTP 200 with proper payload shape.

Real-Scenario Testing

Attempt 1: --experimental-lsp flag (BROKEN)

$ QWEN_SERVER_TOKEN=testtoken npm run dev -- serve --port 18899 --experimental-lsp
...
Unknown arguments: experimental-lsp, experimentalLsp

The daemon refuses to start with --experimental-lsp because the flag is not registered in the yargs builder (see code review above).

Attempt 2: Default (no flag) — LSP status route works

$ QWEN_SERVER_TOKEN=testtoken npm run dev -- serve --port 18899
...
qwen serve listening on http://127.0.0.1:18899 (mode=http-bridge, workspace=...)
qwen serve: bound to workspace "..."
qwen serve: /acp WebSocket transport enabled on /acp

Capability check confirms session_lsp_status is advertised:

$ curl -s http://127.0.0.1:18899/capabilities -H "Authorization: Bearer testtoken" | jq '.features[] | select(contains("lsp"))'
"session_lsp_status"

Non-existent session returns proper 404:

$ curl -s http://127.0.0.1:18899/session/fake-session-id/lsp -H "Authorization: Bearer testtoken"
{"error":"No session with id \"fake-session-id\"","sessionId":"fake-session-id"}

Real session returns valid disabled-LSP payload:

$ curl -s http://127.0.0.1:18899/session/fc7ed8f4.../lsp -H "Authorization: Bearer testtoken" -H "X-Qwen-Client-Id: client_..."
{
  "v": 1,
  "sessionId": "fc7ed8f4-291b-47e2-b1ae-4679ebf00a10",
  "workspaceCwd": "/home/runner/work/qwen-code/qwen-code/.qwen/worktrees/triage",
  "enabled": false,
  "configuredServers": 0,
  "readyServers": 0,
  "failedServers": 0,
  "inProgressServers": 0,
  "notStartedServers": 0,
  "servers": []
}

Unit Tests

All focused tests pass:

• packages/acp-bridge: 320 passed (bridge.test.ts, spawnChannel.test.ts)
• packages/cli: 828 passed (acpAgent.test.ts, server.test.ts, transport.test.ts, serve.test.ts, run-qwen-serve.test.ts)
• packages/sdk-typescript: 273 passed (DaemonClient.test.ts, DaemonSessionClient.test.ts, acpRouteTable.test.ts, daemon-public-surface.test.ts)
• npm run typecheck: ✅ passed
• npm run build: ✅ passed

— Qwen Code · qwen3.7-max

This is a well-structured PR that follows the project's established patterns for session-status endpoints. The REST route, ACP methods, capability tag, SDK helpers, and sanitization are all implemented consistently with existing routes like /session/:id/tasks. The documentation updates are thorough.

The one issue is real though: --experimental-lsp doesn't work at runtime because it's missing from the yargs builder. The unit test masks the problem by using a non-strict parser. This means the LSP opt-in for spawned ACP children — a key part of the feature — is non-functional. The fix is trivial (one .option() call), but it needs to be there before this ships.

Requesting changes for that one fix. Everything else looks ready.

— Qwen Code · qwen3.7-max

@qwen-code /triage

Thanks for the PR, @doudouOUC!

Template looks good ✓ — all required sections present, bilingual, N/A correctly used for the evidence section since this is a non-UI API change.

On direction: well-aligned. Issue #5677 tracks the ACP gap for remote status commands, and /lsp already has local interactive behavior. Daemon/ACP clients need structured data, not Markdown — this PR fills that gap cleanly by extending the existing session-status surface pattern (context, tasks, stats). No direct CHANGELOG reference, but session-status endpoints are a well-established area.

On approach: scope feels right. REST route, ACP HTTP/WS methods, capability tag, SDK helpers, sanitization boundary, docs — each file in the diff serves the stated goal. The --experimental-lsp flag for child opt-in is appropriate since LSP is still experimental. The minor whitespace normalization in 00-index.md is cosmetic noise but not worth splitting out.

Moving on to code review. 🔍

— Qwen Code · qwen3.7-max

Code Review

The implementation is clean and consistent across all surfaces. The buildSessionLspStatus sanitization in acpAgent.ts is the critical piece — it uses an explicit allowlist (name, status, languages, transport, command, error) that strips debug internals (args, pid, stderrTail, rootUri, workspaceFolder, exitCode). This is correctly tested with assertions like expect(JSON.stringify(lsp)).not.toContain('pid') etc.

The new types (ServeSessionLspStatus in status.ts, DaemonSessionLspStatus in SDK types.ts) mirror each other and match the core LspStatusSnapshot shape. The REST route, ACP dispatch, WS method registration, capability tag, and SDK route-table entry all follow the established patterns of sibling routes (/tasks, /stats, /context).

No correctness bugs, security holes, or structural violations found. The --experimental-lsp flag is properly threaded through ServeArgs → ServeOptions → createSpawnChannelFactory → child args after --acp, with a test verifying it's absent by default.

Test Results

All focused test suites pass:

Build: ✅ 0 errors (15 pre-existing warnings). Typecheck: ✅ clean. CI: ✅ all green (macOS, Linux, Windows, lint, integration tests).

Real-Scenario Testing (tmux)

Booted the daemon from PR code via npm run dev -- serve --no-web --port 19876:

$ npm run dev -- serve --no-web --port 19876

> @qwen-code/[email protected] dev
> node scripts/dev.js serve --no-web --port 19876

qwen serve: daemon log → /home/runner/.qwen/debug/daemon/serve-5135-918fec44.log
qwen serve: session reaper started (interval 60000ms, idle threshold 1800000ms)
qwen serve listening on http://127.0.0.1:19876 (mode=http-bridge, workspace=...)
qwen serve: bound to workspace "..."
qwen serve: bearer auth disabled (loopback default). Set QWEN_SERVER_TOKEN to enable.
qwen serve: /acp WebSocket transport enabled on /acp

Capabilities endpoint confirms session_lsp is advertised (verified via curl /capabilities).

LSP endpoint returns correct 404 for non-existent sessions:

$ curl -s http://127.0.0.1:19876/session/nonexistent/lsp
{"error":"No session with id \"nonexistent\"","sessionId":"nonexistent"}
HTTP_STATUS:404

Daemon log confirms the route is handled:

2026-06-23T10:11:15.714Z [WARN] [DAEMON] route=GET /session/nonexistent/lsp sessionId=nonexistent durationMs=4 status=404 request completed

(Note: a full session-attached LSP status test requires an active ACP session with model configuration, which is not feasible in a sandboxed CI runner without API keys. The unit tests cover the enabled/disabled/unavailable/sanitization paths comprehensively.)

— Qwen Code · qwen3.7-max

This is a clean, well-tested PR that fills a real gap (issue #5677) — daemon/ACP clients can now get structured LSP status instead of relying on Markdown from the local /lsp command.

The implementation follows the established session-status pattern exactly: REST route, ACP methods (HTTP + WS), capability tag, SDK types + helpers, sanitization boundary. The buildSessionLspStatus allowlist correctly strips debug internals. All 1422 focused tests pass, build and typecheck are clean, CI is green across all platforms, and the daemon boots and serves the new endpoint correctly in real-scenario testing.

The scope is proportional to the goal — no drive-by refactors, no speculative features. The --experimental-lsp child opt-in is appropriately scoped.

Approval guardrail check: this is a feat PR (not refactor), so the cross-repository guardrail does not block. All stages are clean.

Approving. ✅

— Qwen Code · qwen3.7-max

Maintainer verification — local real-binary + tmux E2E ✅

I built this PR from a clean worktree at the PR head (f6453e4a9), ran the full focused test plan, and exercised the new route end-to-end against a real qwen serve daemon running in tmux with a real typescript-language-server. The feature works as designed. One docs-only inconsistency is worth fixing before merge.

Environment

• macOS (darwin), Node v22.22.2, npm 10.9.7
• Worktree at PR head f6453e4a9, fresh npm ci + npm run build
• Real LSP server: [email protected] (--stdio), in a throwaway TS workspace with a .lsp.json

1. Build / typecheck / tests — all green

*The single failure was server.test.ts › bearer auth › is open by default with Error: socket hang up — a transient supertest socket flake unrelated to this PR (it touches no auth code). It passes in isolation on re-run. All LSP-specific cases pass, verified by name:

• acpAgent.test.ts: disabled / unavailable / READY-with-sanitization / FAILED server while stripping debug internals ✅
• transport.test.ts: initialize advertises _qwen/session/lsp, _qwen/session/lsp returns status ✅
• serve.test.ts / run-qwen-serve.test.ts: --experimental-lsp parse + spawn opt-in ✅

2. Real tmux E2E

Daemon A — qwen serve --experimental-lsp + real typescript-language-server:

// GET /session/:id/lsp  → HTTP 200
{"v":1,"enabled":true,"configuredServers":1,"readyServers":1,
 "failedServers":0,"inProgressServers":0,"notStartedServers":0,
 "servers":[{"name":"typescript-language-server","status":"READY",
   "languages":["typescript"],"transport":"stdio",
   "command":"typescript-language-server"}]}

Sanitization proven against a live server: the actual process exists with a real PID and --stdio args —

52826 node .../typescript-language-server --stdio

— yet the response leaks none of pid / args / stderrTail / rootUri / workspaceFolder / exitCode / exitSignal / warmedUp / restartAttempts. Server entry keys are exactly name, status, languages, transport, command. The whitelist mapping in buildSessionLspStatus makes this structural (future core debug fields can't leak).

Daemon B — qwen serve without --experimental-lsp:

// GET /session/:id/lsp  → HTTP 200  (NOT an error)
{"v":1,"enabled":false,"configuredServers":0,"readyServers":0,"servers":[]}

Unknown session → HTTP 404 {"error":"No session with id ...","sessionId":"..."}. ✅

End-to-end opt-in chain confirmed working: serve --experimental-lsp → extraArgs:['--experimental-lsp'] → child spawned as qwen --acp --experimental-lsp → main CLI config.ts (lspEnabled = !bareMode && argv.experimentalLsp) → getLspStatusSnapshot() returns the real snapshot. getLspStatusSnapshot() already exists in core on main, so the PR correctly leaves packages/core untouched.

3. ⚠️ Finding (docs only): capability tag name mismatch — session_lsp_status vs session_lsp

Code, tests, and the running daemon all use the tag session_lsp (the last commit f6453e4a9 deliberately renamed the test baseline to session_lsp). But the docs still say session_lsp_status in 5 places. Runtime proof from GET /capabilities:

has session_lsp        : true
has session_lsp_status : false

A client that follows the docs and pre-flights session_lsp_status (as the protocol doc explicitly instructs: "pre-flight this tag before exposing remote LSP status") will never detect the capability, because the daemon advertises session_lsp. Stale locations:

• docs/developers/daemon/08-session-lifecycle.md:227 (heading) and :259 (capability-tags list)
• docs/developers/daemon/11-capabilities-versioning.md:92 (the "67 tags" Sessions list)
• docs/developers/qwen-serve-protocol.md:132 (the features array literal) and :162 (prose)

Recommendation: rename those 5 session_lsp_status → session_lsp to match the registry/route convention (/tasks→session_tasks, /stats→session_stats, so /lsp→session_lsp). Docs-only, non-blocking for runtime, but it breaks the documented capability-discovery contract for SDK consumers, so worth folding into this PR.

Verdict

Functionally correct, well-tested, and the sanitization holds against a real language server. The only action item is the 5-line docs tag-name fix above. LGTM once that's addressed. 👍

// GET /session/:id/lsp  → HTTP 200
{"v":1,"enabled":true,"configuredServers":1,"readyServers":1,
 "failedServers":0,"inProgressServers":0,"notStartedServers":0,
 "servers":[{"name":"typescript-language-server","status":"READY",
   "languages":["typescript"],"transport":"stdio",
   "command":"typescript-language-server"}]}

52826 node .../typescript-language-server --stdio

// GET /session/:id/lsp  → HTTP 200(不是 error)
{"v":1,"enabled":false,"configuredServers":0,"readyServers":0,"servers":[]}

has session_lsp        : true
has session_lsp_status : false

[qwen] Fixed in 5cb3a9d: renamed all 5 session_lsp_status references to session_lsp across the three doc files (08-session-lifecycle.md, 11-capabilities-versioning.md, qwen-serve-protocol.md). Capability tag name now matches code/tests/runtime consistently.

@qwen-code /triage

@qwen-code /triage