342 commits

Author	SHA1	Message	Date
jinye	9505246886	fix(serve): align integration test + user doc with merged sessionScope override (#4214) ... PR #4209 (Wave 2 PR 5) shipped per-request `sessionScope` override and added a `session_scope_override` capability tag to the registry. Two follow-ups from wenshao's review landed unaddressed: 1. `integration-tests/cli/qwen-serve-routes.test.ts` still asserted the pre-PR 9-element `caps.features` list and was named "all 9 Stage 1 features". Running the suite against a real daemon would fail — the daemon now advertises 10 features, with `session_scope_override` between `session_create` and `session_list` per the registry order. PR CI didn't catch this because integration tests need a real `qwen serve` spawn and run only in the release pipeline; the unit-level `EXPECTED_STAGE1_FEATURES` constant in `server.test.ts` was updated, but its integration sibling was missed. 2. `docs/users/qwen-serve.md` "Stage 1.5+ runtime guarantees" still listed per-request `sessionScope` override as item 1 of "Blockers for serious downstream use", saying "today the daemon-wide default is the only setting." Directly contradicts the merged behavior and the protocol doc, so downstream integrators reading the user guide get inverse guidance. Fixes: - Update the integration test name to "all 10 Stage 1 features" and insert `session_scope_override` in the asserted array (matching registry order); add a comment noting the unit/integration/registry triple must stay in lockstep. - Remove the obsolete blocker bullet from the user doc and renumber the remaining items (2/3 → 1/2 in Blockers, 4-7 → 3-6 in Reliability, 8-10 → 7-9 in Integration ergonomics). No production code changes. 🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)	2026-05-17 01:51:25 +08:00
易良	ba77ddd81b	fix(lsp): expose status and startup diagnostics (#3649) ... * feat(lsp): add /lsp slash command to show server status Implements the /lsp command that displays the status of all configured LSP servers. Previously this was documented in the FAQ but never implemented, leaving users with no way to check if their language servers started successfully. Changes: - Add LspServerStatusInfo interface to lsp/types.ts - Add getServerStatus() to LspClient and NativeLspClient - Expose getServerHandles() from NativeLspService - Create lspCommand.ts with status table output - Register /lsp in BuiltinCommandLoader (only when LSP is enabled) The command shows: server name, command, languages, and status (NOT_STARTED / IN_PROGRESS / READY / FAILED + error message). * fix(lsp): expose status and startup diagnostics * fix(lsp): harden status command diagnostics * fix(lsp): add stderr error listener and harden initialization error handling - Add stderr 'error' event listener in LspConnectionFactory to prevent unhandled stream errors from crashing the process - Wrap setLspInitializationError calls in try-catch in config.ts to guard against post-initialization state changes that would throw	2026-05-17 01:42:28 +08:00
jinye	54fd5c50f0	feat(telemetry): add detailed sensitive span attributes (#4097) ... Layer detailed content attributes onto the existing hierarchical spans (qwen-code.interaction / qwen-code.llm_request / qwen-code.tool) gated by includeSensitiveSpanAttributes: - Interaction span: user prompt (new_context) - LLM request span: system prompt + hash + preview + length (full text deduped per session via SHA-256), tool schemas (per-tool tool_schema events, also hash-deduped), model output - Tool span: tool input, tool result on every exit path (success + pre-hook block + post-hook stop + tool error + try-block cancel + catch-block cancel + execution exception) All large content truncated at 60KB with *_truncated and *_original_length metadata. Heavy serialization (safeJsonStringify on tool I/O, partToString on user prompt) is guarded by the sensitive flag at the call site so it doesn't run when telemetry is off. Also adds: - getActiveInteractionSpan() helper for client.ts to attach prompt attributes to the interaction span. - Updated config schema description and docs (telemetry.md + settings.md) to reflect expanded scope and add security/cost notes. - 28 unit tests for detailed-span-attributes, 4 tests for getActiveInteractionSpan, integration mocks updated.	2026-05-17 00:36:48 +08:00
dreamWB	966b040359	feat(cli): readline Ctrl+P/N for history and selection navigation (#4082) ... * feat(cli): readline Ctrl+P/N for history and selection navigation Adds GNU-readline-style Ctrl+P (previous) and Ctrl+N (next) shortcuts to the qwen-code TUI so users coming from bash/zsh, Emacs, or Claude Code feel at home. The change has three orthogonal behavior groups: 1. Input prompt, history-versus-line-motion two-step edge Ctrl+P / Ctrl+N and the arrow keys behave identically and apply a two-step edge transition that matches GNU readline and Claude Code: inside a multi-line buffer they move the cursor between visual rows; on the top row with the cursor away from column 0 the first Up press snaps the cursor to column 0 without changing history, and only the second press walks one entry back. The mirror rule holds for Down at the last row (snap to end of line, then advance). After navigateUp the buffer is parked at offset 0 (the "start of older entry" landing position); after navigateDown setText's default end-of-text positioning keeps the cursor at the end. The same two-step rule applies to single-line buffers so the reverse-direction case the issue called out works: pressing Ctrl+N immediately after Ctrl+P loaded a single-line older entry (cursor at col 0) first snaps the cursor to end-of-line, and only the next Ctrl+N moves forward through the history. Bare k/j inside the input prompt remain ordinary typed letters — the vim aliases are selection-list shortcuts, not text-editing ones. 2. Selection lists: arrows, k/j, and Ctrl+P/N are interchangeable A new pair of Command bindings, SELECTION_UP and SELECTION_DOWN, is wired into the shared useSelectionList hook and every dialog that used to hand-roll an "up/down arrow only" or "up/k arrow + vim only" navigation check. Covered surfaces: the main selection-list hook itself, the MCP / extensions / agents / hooks / background- tasks / rewind / plugin-choice / ask-user-question dialogs, the memory dialog (both its file list and the auto-memory and auto-cleanup toggle panel above the list), the settings dialog list (with the in-place value editor's "block other keys while editing" guard preserved), and the manage-models dialog's top tabs row. The auth-provider wizard's Advanced Config focus rows and the resume-session picker's cross-mode arrows are extended with the readline Ctrl+P / Ctrl+N synonyms while keeping their existing arrow-key and (for the session picker) vim k/j semantics intact. 3. Selection surfaces that wrap an active text input AskUserQuestionDialog's "Other / type a custom answer" field, manage-models' search input, the resume-session picker's search field, and the auth-wizard's Context-window number input all coexist with the selection list on the same screen. In those surfaces typing k or j has to land in the text buffer, not scroll the surrounding list. The fix is to scope the input-aware handler to unambiguous non-letter shortcuts only — arrow keys plus readline-style Ctrl+P / Ctrl+N escape the text field, while bare letters (including k / j / p / n) are delivered to the active input. The keyBinding-level fix that backs this is the `{ key: 'k', ctrl: false }` / `{ key: 'j', ctrl: false }` clauses on SELECTION_UP / SELECTION_DOWN, which prevent Ctrl+K from accidentally matching SELECTION_UP and thereby firing both the list-up handler and the KILL_LINE_RIGHT handler in the same keystroke (the P0 finding the quality-gate review surfaced). Focus-traversal tokens (the agent tab bar and the background-task pill) and chord shortcuts (Ctrl+Shift+Up/Down for embedded-shell history) are deliberately left untouched because their existing "any printable letter yields focus back to the composer" UX would break under the new vim-style letter bindings, and the Help viewer's scroll is a viewer rather than a selection list and is out of this PR's scope. Documentation: docs/users/reference/keyboard-shortcuts.md is updated so the Ctrl+P / Ctrl+N entries describe the two-step edge rule and the radio-button-select table mentions the new k/j and Ctrl+P/N aliases. Per-dialog on-screen hints (which still read "↑↓ to navigate") are intentionally not touched so the i18n string surface stays unchanged; the global reference doc is the authoritative source for the new shortcuts. Tests: - packages/cli/src/ui/keyMatchers.test.ts adds positive cases covering ↑ / ↓ / bare k / bare j / Ctrl+P / Ctrl+N matching SELECTION_UP / SELECTION_DOWN and negative cases asserting that Ctrl+K and Ctrl+J do NOT match (the conflict guard). - packages/cli/src/ui/components/InputPrompt.test.tsx adds a "two-step edge transition for history navigation" describe block with four cases: a mid-line Ctrl+P snaps to col 0 without invoking navigateUp; an at-col-0 Ctrl+P does invoke navigateUp and then parks the cursor via moveToOffset(0); a not-at-end Ctrl+N snaps to end-of-line without invoking navigateDown; and arrow Up obeys the same rule as Ctrl+P for keyboard-parity. The test file's mock buffer's setText was also corrected to mirror the real buffer's "cursor lands at the end of the new text" semantic so the cursor field is internally consistent during keypress assertions; the small InputPrompt render-frame snapshot in the same file's __snapshots__/ directory was regenerated to reflect the now- accurate cursor render position. Three pre-existing arrow-key navigation tests were updated to pre-position the mock cursor at the relevant edge before pressing the arrow, because the new two-step rule means the first arrow press at a non-edge position is a cursor snap, not a history step. Multi-line cursor-between- rows movement is covered indirectly by the keyBinding-level matcher tests plus the end-to-end manual demo plan. The work landed in three rounds against the planner's gate: round 1 added the unified SELECTION_UP / SELECTION_DOWN Command binding and the cursor-first dispatch in the input prompt; round 2 picked up the quality-gate review's P0 (the Ctrl+K double-fire in the "Other" custom-input field) and the user's hand-test feedback on the missing two-step edge in the reverse direction plus the MemoryDialog top-panel sections that weren't wired through SELECTION_*; round 3 swept the remaining adjacent dialogs (SettingsDialog list, ManageModelsDialog tabs and search transitions, ProviderSetupSteps advancedConfig, useSessionPicker's cross-mode arrows) so the keyboard model is uniform across the TUI. The original issue also asks for Meta+B / Meta+F word motion and smarter Ctrl+H token-aware backspace among other readline conveniences. The user explicitly scoped this PR down to Ctrl+P / Ctrl+N at the planner approval gate; the remaining wish-list items are deferred to follow-up issues. Closes #3821 * docs(cli): refine Ctrl+P/N input-history rows; fix Ctrl+J in selection-list comment Both items came from a non-blocking COMMENTED review on PR #4082 (https://github.com/QwenLM/qwen-code/pull/4082#pullrequestreview-4271527787), flagging two polish points in the readline Ctrl+P/Ctrl+N feature the parent commit `feat(cli): readline Ctrl+P/N for history and selection navigation` (f66427b) introduced. The `Up Arrow`, `Down Arrow`, `Ctrl+P`, and `Ctrl+N` rows of the Input Prompt table in `docs/users/reference/keyboard-shortcuts.md` are reworded to describe the three-phase keystroke sequence the implementation walks through — an intra-buffer visual-row step (a no-op in a single-line buffer, where there's exactly one visual row), a column-edge snap when the cursor reaches the buffer's first or last visual row with the cursor not already at column 0 (for the up-direction pair) or end-of-line (for the down-direction pair), and the readline-style previous-history or next-history walk on the press after the snap. The reviewer specifically pointed out that the prior wording described single-line input as "navigates the input history directly", which no longer matches the post-PR-#4082 behavior: single-line input also goes through the snap-then-walk two-press rule (the snap is a no-op when the cursor is already at the line's edge column, in which case the keystroke does the history walk on its first press). The new sentence covers the single-line and multi-line cases in one shape — single-line is the degenerate zero-row-walk-prefix instance of the same rule. The up-direction text is shared verbatim between the `Up Arrow` row (L31) and the `Ctrl+P` row (L43), and the down-direction text between the `Down Arrow` row (L27) and the `Ctrl+N` row (L42), so the keyboard- parity alias relationship is signaled by source-side text duplication rather than a prose cross-reference. The Input Prompt table's 234-byte canonical row width (the separator row's `| <50-dash> | <177-dash> |` template, which sets the column-1 and column-2 source-side widths the file's existing untouched rows already align to) is preserved by trailing-ASCII-space padding inside the description column. The comment above `[Command.SELECTION_UP]` and `[Command.SELECTION_DOWN]` in `packages/cli/src/config/keyBindings.ts` previously read // Selection list navigation — up/k/Ctrl+P move selection up; down/j/Ctrl+N move selection down // ctrl: false on k/j ensures Ctrl+K (kill-line) and Ctrl+N (history-down) are not captured here The `Ctrl+N` half of the second line is wrong: `Ctrl+N` is intentionally matched here as the selection-down readline alias — the `{ key: 'n', ctrl: true }` entry in the `SELECTION_DOWN` array literal directly below the comment, mirroring the input-prompt-side `[Command.HISTORY_DOWN]: [{ key: 'n', ctrl: true }]` binding at L134 of the same file. The Ctrl-modified key the bare-letter `k` and `j` matchers actually guard against — the one already bound elsewhere whose double-match with the bare-letter selection-key the `ctrl: false` opt-out is preventing — is `Ctrl+J`, the ASCII line-feed (0x0A) encoding of the Enter family that appears as `{ key: 'j', ctrl: true }` inside the four-alternative `[Command.NEWLINE]` array a few lines below. The corrected one-liner is // Selection-list nav: arrows + k/j + Ctrl+P/Ctrl+N // ctrl: false on bare k/j skips Ctrl+K and Ctrl+J in the same terse no-trailing-period section-label style as the file's adjacent `// Screen control` (L129), `// History navigation` (L132), `// Auto-completion` (L213, post-edit numbering), and `// Text input` (L219) header comments. A 64-line block-comment that earlier in the review-fix cycle wrapped this same correct fact in dispatch-broadcast- model prose plus `keyMatchers.test.ts` backreferences was condensed to those two lines for cell-budget consistency with the rest of the file. No code behavior change. The local verification surface the reviewer named at the bottom of the review summary stays green: from `packages/cli`, npx vitest run \ src/ui/keyMatchers.test.ts \ src/config/keyBindings.test.ts \ src/ui/components/InputPrompt.test.tsx runs 178 cases with 177 passed and one unrelated skip (the implementation file `InputPrompt.tsx`'s feature flag for the keyboard- queue-input-editing case that was already skipped on the parent commit), including all four cases inside the `InputPrompt > two-step edge transition for history navigation` describe-block — `Ctrl+P with cursor mid-line snaps to col 0 without touching history`, `Ctrl+N with cursor not at end-of-line snaps to end without touching history`, `Ctrl+P at col 0 walks history and parks the cursor at offset 0`, and `arrow Up applies the same two-step rule as Ctrl+P (snap before navigate)`. Those four test-case names are the implementation-side anchors the new docs wording verbally mirrors. `npx tsc --noEmit -p .` in the same package directory reports zero diagnostics. * fix(cli): align readline history shortcuts with dialogs * test(cli): cover readline navigation aliases * fix(cli): guard readline shortcuts in dialog inputs * test(cli): cover readline aliases in more dialogs	2026-05-16 23:07:25 +08:00
DennisYu07	57282ebb7d	feat(hooks): add prompt hook type with LLM evaluation support (#3388) ... * implement prompt hook * resolve comment * resolve comment * resolve comment * resolve comment * fix unit test	2026-05-15 17:13:05 +08:00
tanzhenxin	f6315b378d	refactor(cli): revert dynamic slash command LLM translation (#4145) ... * refactor(cli): revert dynamic slash command LLM translation (#4137) Removes the runtime LLM-translation path for dynamic slash command descriptions added in #3871, along with its `general.dynamicCommandTranslation` setting and the `/language translate` subcommand tree. Keeps the built-in locale coverage from the same PR untouched. Localization of dynamic command descriptions should be solved at the source (manifest fields, not runtime model calls); see #4137 for the proposed alternative. * refactor(cli): drop translate prompts from mustTranslateKeys Follow-up to the dynamic command translation revert: the 7 prompt keys were stripped from every locale file in the previous commit, but the allow-list in mustTranslateKeys still demanded them. * refactor(cli): drop dead CommandService.fromCommands and vacuous tests Follow-up cleanup after the dynamic command translation revert. CommandService.fromCommands was introduced by #3871 solely to wrap the LLM-translated command list. With the LLM-translation path gone, it has no remaining non-test callers — remove it and the matching test mock. Also drop two assertions in languageCommand.test.ts that checked for the absence of a top-level /language cache command. They tested a migration state that never existed in this branch and now pass vacuously. * docs: drop /language translate references after revert Two user-facing docs documented the /language translate subcommands (status/on/off/cache refresh/clear) that were removed in the dynamic command translation revert. Strip them so users following the docs don't hit "Invalid command" errors. * refactor(cli): drop unused localizeDescription field The DynamicCommandLocalizationService that read this flag was removed in the revert, leaving the field with five setters and zero readers. Drop the field, its JSDoc, and the five `localizeDescription: true` assignments. Also tidy the now-misleading `modelDescription` JSDoc and the stale `reloadCommands` comment that referenced the removed feature. * refactor(cli): drop unused getLanguageNameForTranslationTarget The only caller was the removed DynamicCommandLocalizationService. Remove the function from `i18n/languages.ts` and the matching import + re-export from `i18n/index.ts`.	2026-05-15 16:01:16 +08:00
DennisYu07	1c529e4f0a	feat(hooks): Add TodoCreated and TodoCompleted hooks for todo lifecycle events (#3378) ... * add TaskCreated and TaskCompleted * resolve comment * resolve lint * change merge logic from simple to or * resolve lint error * reslove commnent * fix i18n key mismatch and malformed imports * resolve comment	2026-05-15 15:51:01 +08:00
MikeWang0316tw	02a65f90c4	fix(i18n): Correct zh-TW translations to match Traditional Chinese conventions (#4129) ... * fix(i18n): Correct zh-TW translations to match Traditional Chinese conventions Fix ~131 lines of Traditional Chinese (zh-TW) translations that used Simplified Chinese character forms instead of standard Traditional Chinese usage. Changes: - 文件 → 檔案 (47 occurrences) - 爲 → 為 (45 occurrences) - 啓 → 啟 (44 occurrences) - 曆史 → 歷史 (6 occurrences) - 鏈接 → 連結 (4 occurrences) - 菜單 → 選單 (3 occurrences) * fix(i18n): Replace 服務器 with 伺服器 (15 occurrences) Align with Traditional Chinese convention where 伺服器 is the standard term for 'server' in computing contexts. * fix(i18n): Update zh-TW.js header comment to prevent accidental overwrite Clarify that the file is the authoritative source and should not be overwritten with auto-generated output, to prevent future maintainers from regenerating with raw OpenCC and losing manual corrections. * fix(i18n): Add zh-TW regression check and maintenance docs Addresses reviewer feedback on PR #4129 (points 2 and 3): - scripts/check-i18n.ts: Iterate over parsed zh-TW translation values (not raw file content) and report the offending key. Replace the earlier substring list with ZH_TW_FORBIDDEN_PATTERNS, which targets the three real regression categories: variant Traditional characters produced by OpenCC s2t (爲, 啓), Mainland-Chinese vocabulary (服務器, 菜單, 鏈接), and pure Simplified characters. Excludes 禁用 / 配置 / 文件 / 打開 to avoid false positives on Taiwan-valid usage. - scripts/tests/check-i18n.test.ts: Cover the new check, including negative cases for Taiwan-valid vocabulary. - docs/users/features/language.md: Document zh-TW maintenance — the vocabulary table, why raw OpenCC s2t output is not acceptable, and where the CI-enforced list lives. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(i18n): Address review feedback on zh-TW check (#4129) - check-i18n.ts: Sort ZH_TW_FORBIDDEN_PATTERNS longest-first and break on first match so e.g. `历史` reports the specific bigram instead of also firing the bare `历` rule (no duplicate CI errors). - check-i18n.ts: Add ZH_TW_ALLOWED_EXCEPTIONS escape hatch so a future legitimate translation (e.g. 區塊鏈 in a UI string) can opt out by key without weakening the global pattern list. - docs/users/features/language.md: Add a "CI enforced?" column so contributors can tell which rows block CI vs. which are review-only style guidance. Replace bare `曆` in the table with the `曆史` bigram and note that `曆` is correct in calendar terms (日曆, 農曆, 西曆) — prevents a future maintainer from globally replacing 曆→歷. - Tests: Cover the dedup behavior on overlapping patterns. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * docs(i18n): Note word-boundary limitation of zh-TW substring check Document the known limitation that `includes()`-based pattern matching does not respect Chinese word boundaries — a bigram like `鏈接` will false-positive on `區塊鏈接口` (區塊鏈 + 接口). Direct contributors to `ZH_TW_ALLOWED_EXCEPTIONS` when this happens instead of weakening the pattern list. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>	2026-05-15 15:26:12 +08:00
Shaojin Wen	790f2d0485	refactor(serve): 1 daemon = 1 workspace (#3803 §02) (#4113) ... * refactor(serve): 1 daemon = 1 workspace (#3803 §02) Stage 1 shipped with M-workspaces-per-daemon routing (`byWorkspaceChannel` Map keyed by request `cwd`). The §02 architectural revision in `docs/comparison/qwen-code-daemon-design/02-architectural-decisions.md` narrows the bridge to 1 daemon = 1 workspace × N sessions: each daemon binds to one canonical workspace path at boot; `POST /session` with a mismatched `cwd` returns 400 `workspace_mismatch`. Multi-workspace deployments run multiple daemon processes (one per workspace, supervised externally — systemd / docker-compose / k8s / `qwen-coordinator`). Bridge state collapses from maps to single optional slots: - `byWorkspaceChannel: Map<string, ChannelInfo>` → `channelInfo?: ChannelInfo` - `inFlightChannelSpawns: Map<string, Promise>` → `inFlightChannelSpawn?: Promise` - `byWorkspace: Map<string, SessionEntry>` → `defaultEntry?: SessionEntry` - `liveChannels: Set<ChannelInfo>` → not needed; `channelInfo` is the live reference, cleared only by `channel.exited` (preserves the tanzhenxin BkUyD invariant that `killAllSync` finds a target mid-SIGTERM-grace) `BridgeOptions.boundWorkspace` becomes required. `WorkspaceMismatchError` is thrown from `spawnOrAttach` when the request's canonical cwd doesn't match the bound path, translated to 400 `workspace_mismatch` (with both paths in the body) by the route layer. `CapabilitiesEnvelope.workspaceCwd` surfaces the bound path so clients pre-flight check + omit `cwd` from `POST /session` (it falls back to the bound workspace). A new `--workspace <path>` CLI flag lets operators override `process.cwd()` at boot. The previous `--http-bridge` / `--multi-workspace` opt-in was never shipped; nothing changes for default users running `qwen serve` in their project directory. Removed code path: ~150 LOC of multi-workspace map machinery in `httpAcpBridge.ts` plus the test cases that exercised it. Test surgery: - New `makeBridge()` helper in `httpAcpBridge.test.ts` injects `boundWorkspace: WS_A` by default; tests that need a different bind (the mismatch test) pass it explicitly. - `does NOT reuse across workspaces` → `rejects cross-workspace requests with WorkspaceMismatchError` (the new semantics under §02). - `shutdown kills every live channel` retargeted to single-channel multi-session shutdown. - `killAllSync force-kills channels even after shutdown cleared byWorkspaceChannel (BkUyD)` retargeted to single-channel: the invariant is the same (channel reference must outlive eager shutdown clearing), the surface is just smaller. - `listWorkspaceSessions` cross-workspace assertion now expects empty for the un-bound path. - `--max-sessions` cap test uses two thread-scope sessions on `WS_A` instead of WS_A + WS_B. Closes #3803 §02. * fix(serve): address review findings on the §02 refactor Two correctness fixes + four doc/test polish items surfaced by the multi-agent review of #4113: 1. `killSession` → `spawnOrAttach` race (Critical). After killing the last session, `channel.kill()` runs through a 5s SIGTERM grace before SIGKILL. During that window a concurrent `spawnOrAttach` used to hit `ensureChannel`, find `channelInfo` still set, and reuse the dying transport — either landing the caller with a sessionId that 404s on every follow-up once `channel.exited` fires, or hanging until the newSession timeout. Fix: add an `isDying: boolean` flag on `ChannelInfo`, set synchronously by `killSession` / `doSpawn`-newSession-failure / `shutdown` BEFORE awaiting `channel.kill()`. `ensureChannel` treats a dying channel as absent and spawns a fresh one. The tanzhenxin BkUyD invariant ("`channelInfo` reference must outlive the kill-await for `killAllSync` mid-grace") is preserved — we set `isDying` but don't clear `channelInfo` until the OS reaps the child via `channel.exited`. A regression test in `httpAcpBridge.test.ts` pins the invariant: a never-resolving `kill()` keeps the SIGTERM grace open while a concurrent spawn verifies the factory was called twice (two distinct handles). 2. `boundWorkspace` canonicalization divergence (Critical). `server.ts` and `runQwenServe.ts` each computed `opts.workspace ?? process.cwd()` independently. The bridge canonicalized that string via `realpathSync.native` (resolving symlinks, case-folding on case-insensitive filesystems); the callers retained the raw form. On macOS HFS+ / APFS or any symlinked path, `/capabilities.workspaceCwd` advertised one spelling while the bridge enforced against another — clients echoing the advertised path back saw `POST /session` succeed but the response carry a different `workspaceCwd`. Fix: export `canonicalizeWorkspace` from `httpAcpBridge.ts` and call it once in `runQwenServe` (after the existence check) and once in `createServeApp`. Both paths land on the same canonical form; the bridge's own re-canonicalize is now a no-op (idempotent). 3. Reject `--workspace` pointing at non-existent directories at boot (Suggestion). `canonicalizeWorkspace`'s ENOENT fallback to `path.resolve` previously let the daemon boot pointed at a path that didn't exist; every `POST /session` then spawned a `qwen --acp` child with that cwd and the agent failed with an opaque ENOENT. Now `runQwenServe` `statSync`s the bound path at boot and rejects "directory does not exist" / "not a directory" with a clear message. 4. Stale docstrings (Nice to have). `types.ts` `ServeMode` JSDoc said "one `qwen --acp` child PER WORKSPACE" — directly contradicted the new `workspace` field's doc in the same file. `commands/serve.ts` `--http-bridge` description said "per workspace" — directly contradicted the `--workspace` flag's help in the same yargs builder. Both updated to "per daemon (the daemon binds to ONE workspace at boot)". 5. Stale `byWorkspace` comment references (Nice to have). `server.ts:188` ("orphaned in byId / byWorkspace") and `httpAcpBridge.test.ts:1210` ("still in byId/byWorkspace at the moment of crash") referenced the removed Map. Updated to `defaultEntry`. 6. `/capabilities` curl example in the Authentication section of `docs/users/qwen-serve.md` was missing the new `workspaceCwd` field — the Quickstart's curl example was updated but the parallel one in the auth section was not. Synced. Tests added: - `killSession marks the channel dying so concurrent spawnOrAttach gets a fresh channel` — pins fix (1). - `--workspace flows end-to-end and surfaces on /capabilities` — exercises the runQwenServe → server.ts → bridge plumbing that no prior test covered. - `rejects --workspace pointing at a non-existent directory` and `rejects --workspace pointing at a regular file` — pin fix (3). - `rejects relative --workspace at boot` — covers the absoluteness check that exists but was untested. Net: +238 / -24 across 8 files. All 149 serve tests pass. * fix(serve): BkUyD overwrite race + Windows-fragile test + doSpawn-failure coverage Round-2 review of #4113 caught three follow-up issues introduced by or left open after round-1's fixes: 1. **BkUyD invariant overwrite race (Critical).** Round-1's `isDying` flag lets `ensureChannel` skip a dying channel and spawn a fresh one. When the fresh spawn completes, `channelInfo = info` overwrote the dying channel's reference — leaving NO global pointer to it. `killAllSync()` then iterated only `channelInfo` (the fresh one) and missed the dying child entirely. A double-Ctrl+C arriving mid-SIGTERM-grace would call `process.exit(1)` before the dying child's per-channel SIGKILL escalation timer fired, orphaning the child. Restore a `aliveChannels: Set<ChannelInfo>` (parallel to the original Stage 1 design, but justified by single-workspace too). Entries added in `ensureChannel`, removed by each channel's `channel.exited` handler. `killAllSync` iterates the SET, not the single attach-target slot. `shutdown` does the same — snapshots every alive channel and kills each, not just the current `channelInfo`. New regression test pins the invariant: spawn → killSession (channel marked dying, kill hangs) → spawnOrAttach (fresh channel overwrites `channelInfo`) → `killAllSync` — expect BOTH channels' `killSync` to fire. Pre-fix only the fresh one would have fired. 2. **Windows-fragile test path.** The new `rejects --workspace pointing at a regular file` test used `new URL(import.meta.url).pathname` to get a path to the test file. On Windows that returns `/C:/path/...` (leading slash); `fs.statSync` then resolves it as path-from-current-drive-root, fails with ENOENT, and the test sees the "does not exist" error message instead of the expected "not a directory" branch. CI runs `windows-latest`. Fix: `fileURLToPath(import.meta.url)` from `node:url`. 3. **doSpawn newSession-failure isDying path was untested.** The round-1 fix added `ci.isDying = true` to both `killSession` AND `doSpawn`'s newSession-failure catch, but only the killSession path had a regression test. Added a parallel one for the doSpawn path: thread-scope bridge with a `newSessionImpl` that throws on the first call → captures the rejection without awaiting it (the bridge's `await ci.channel.kill()` hangs in the test), yields enough cycles for the `isDying = true` sync prefix to settle, then confirms (a) the next `spawnOrAttach` produces a fresh channel and (b) `killAllSync` finds both channels in `aliveChannels`. Also added a `newSessionImpl` option to the test FakeAgent — the existing `initializeThrows` hook covered handshake-time failures, but post-init `newSession` rejections (auth, bad config, mid-init crashes) had no test affordance. All 151 serve tests pass. * docs(serve): update daemon-client-quickstart for §02 single-workspace Round-3 review caught that the SDK example doc was the only one of the three serve-related docs that the §02 refactor didn't touch. Updated: - Boot log example now shows the `, workspace=/path/to/your-project` suffix that `runQwenServe` emits after the §02 changes. - The "Hello daemon" example now reads `caps.workspaceCwd` off `/capabilities` and passes it back as `workspaceCwd` on session creation — illustrating the documented pre-flight pattern, not a hand-written literal that may not match the daemon's actual bind. - Shared-session example makes the prerequisite explicit: the daemon must be bound to `/work/repo` (via `--workspace` or `cd`); under §02 two clients can only share a session if they're both hitting a daemon already bound to that workspace. - New "Workspace mismatch" section shows how to handle the `400 workspace_mismatch` error class: catching `DaemonHttpError`, branching on `body.code`, surfacing `boundWorkspace` / `requestedWorkspace` for the operator. This is a new error class SDK consumers' error handlers should branch on. No code changes; docs only. * feat(sdk,test): align SDK types + integration tests with §02 single-workspace Round-4 review caught one type-drift gap + a set of integration-test assumptions that the §02 refactor invalidated. **SDK type drift.** `DaemonCapabilities` in `packages/sdk-typescript/src/daemon/types.ts` was the SDK-side mirror of `CapabilitiesEnvelope` on the daemon side. The §02 PR added `workspaceCwd: string` to the daemon envelope (and the round-3 doc example reads `caps.workspaceCwd` off the SDK client) but the SDK type wasn't updated. A TypeScript consumer copying the doc snippet verbatim would hit `TS2339 'workspaceCwd' does not exist on type 'DaemonCapabilities'`. The wire field is present so JS consumers wouldn't notice — but the SDK is marketed as a TypeScript quickstart, so this is a real onboarding break. Fix: add `workspaceCwd: string` to `DaemonCapabilities` (parallel to `DaemonSession.workspaceCwd` which is already there). The SDK unit test for `client.capabilities()` was updated to put the new field in the mocked response. **Integration tests.** `qwen-serve-routes.test.ts` spawns a real `qwen serve` daemon in `beforeAll`. Three breakages exposed: 1. The daemon was launched without `--workspace`, so it inherited the test runner's `cwd`. Tests then POST `workspaceCwd: REPO_ROOT` assuming the daemon is bound to the repo root — true when run via `npm test` from the repo, brittle from IDEs / launchers that have a different `cwd`. Added `'--workspace', REPO_ROOT` to the spawn args so the bound workspace is deterministic regardless of where the test runner is launched. 2. The `bad modelServiceId` test used `cwd: '/tmp'`. Under §02 this would now return 400 workspace_mismatch before the session was spawned. Switched to `REPO_ROOT` and softened the `attached` assertion (REPO_ROOT may already have a session from earlier tests in the suite under sessionScope:single). 3. Added three new integration tests pinning the §02 surface end-to-end through a real daemon process: - `rejects cross-workspace cwd with 400 workspace_mismatch` — posts `/tmp` and asserts the full structured error body (`code`, `boundWorkspace`, `requestedWorkspace`). - `omits cwd → falls back to bound workspace` — posts an empty body and asserts the response's `workspaceCwd` matches REPO_ROOT (verifies the runQwenServe → createServeApp → bridge fallback plumbing). - `GET /capabilities surfaces workspaceCwd` — asserts the new SDK type field is populated correctly off the wire. All 422 unit tests pass (cli serve + sdk). Integration tests typecheck clean. * fix(serve): address /review feedback from gpt-5.5 + deepseek-v4-pro Process the 7 inline /review comments on PR #4113: - C1+C3 (SDK): make `DaemonCapabilities.workspaceCwd` and `CreateSessionRequest.workspaceCwd` optional in the SDK types. `workspaceCwd` is an additive field on the v=1 envelope per #3803 §02; the protocol's "bump v only on incompatible changes" stance is honored by leaving the field optional at the type level. `DaemonClient.createOrAttachSession` now omits `cwd` from the body when `workspaceCwd` isn't passed, matching the PR description's "SDK accepts bound path or none". Adds a unit test pinning the empty-body shape. - C2 (docs/users/qwen-serve.md): the `--http-bridge` row described the pre-§02 per-session model; updated to reflect one child per daemon with N sessions multiplexed via ACP `newSession()`. - C4 (server.ts): `WorkspaceMismatchError` was silently 400'ing without a stderr breadcrumb, leaving operators blind to cross-workspace routing drift. Mirrors the SessionLimitExceeded /InvalidPermissionOption observability pattern. - C5 (server.test.ts): the `/capabilities` fallback test compared `res.body.workspaceCwd` against raw `process.cwd()`; on macOS default tmpdir flows (`/var/folders/...` → `/private/var/...`) the canonicalize-once route value diverges. Use `realpathSync.native(process.cwd())` to match the route's canonicalization. - C6 (server.ts): the cwd-not-absolute error said "cwd is required and must be an absolute path" but cwd is now optional under §02. Tightened wording to "must be an absolute path when provided". - C7 (runQwenServe.ts): the `statSync` catch only wrapped ENOENT with a friendly diagnostic; EACCES / EPERM (typical for SIP-protected dirs on macOS or root-owned paths the daemon's UID can't traverse) re-threw as raw `SystemError`. Wrap both codes with a `--workspace`-context message so the boot failure points at the flag the operator set. Docs: quickstart shows the explicit-pass-or-omit options side by side; protocol reference notes `workspaceCwd` is additive to v=1. * fix(serve/test): make /work/bound literals Windows-portable Windows CI failed on this PR's two new tests because returns (drive-relative absolute), so the route's canonicalize step diverged from the hardcoded literal. Mirror the WS_A/WS_B pattern already used in httpAcpBridge.test.ts: define WS_BOUND / WS_DIFFERENT via `path.resolve(path.sep, …)` and use the constants everywhere. The 400 workspace_mismatch test would still have passed (mock controls both throw + assertion) but I aligned it for consistency. Failures from CI run 25806528710: expected 'D:\work\bound' to be '/work/bound' (Object.is) Affected tests: - createServeApp > GET /capabilities > reports the bound workspace - createServeApp > POST /session > 200 when cwd is omitted * fix(serve): address second /review round (gpt-5.5 + deepseek-v4-pro) Four new inline findings from the latest /review pass: - N1 (integration-tests/cli/qwen-serve-routes.test.ts) — Critical: the `workspace_mismatch` assertion compared `requestedWorkspace` against the literal `'/tmp'`, but the bridge canonicalizes via `realpathSync.native` and on macOS `/tmp` is a symlink to `/private/tmp`. Compare against `realpathSync.native('/tmp')` so the assertion is portable. - N2 (packages/cli/src/serve/types.ts): `CapabilitiesEnvelope.workspaceCwd: string` (server side) diverged from the SDK's `DaemonCapabilities.workspaceCwd?: string`. Made the server type optional too — matches the SDK, matches the protocol doc's "additive to v=1" framing, doesn't change runtime emission (the post-§02 server still always populates the field). - N3 + N4 (packages/cli/src/serve/server.ts + sdk-typescript/.../DaemonClient.ts): the route's `cwd` validation treated every non-string body value (`null`, `123`, `{}`, `[]`) the same as omitted, silently falling back to `boundWorkspace`. That hid client/orchestrator serialization bugs as "session attached to wrong workspace". Now the route uses `'cwd' in body` to detect presence and rejects presence-but-not-a-string with `400 'cwd must be a string absolute path when provided'`. Empty string still hits the existing `path.isAbsolute` branch ("must be an absolute path when provided"), so an SDK caller passing `workspaceCwd: ''` no longer silently lands in the daemon's bound workspace. SDK side: reverted my conditional spread to `cwd: req.workspaceCwd` unconditional. `JSON.stringify` strips `undefined` automatically (so omitted `workspaceCwd` becomes "no `cwd` key" on the wire, as before), but empty-string is now forwarded verbatim and the server's 400 surfaces the bug instead of the SDK swallowing it. Added a unit test pinning the empty-string-forwarded shape. Server tests: - `400 when cwd is present but not a string` covers null / number / object / array via a sub-loop. - `400 when cwd is the empty string` pins the isAbsolute path. bridge: 73/73; server: 80/80 (was 78, +2 new); SDK: 40/40 (was 39, +1 empty-string test). tsc clean for SDK and PR-touched CLI files. * fix(serve): use const cwd in POST /session (prefer-const lint) CI lint failed with packages/cli/src/serve/server.ts:199:9 prefer-const: 'cwd' is never reassigned. The wave-4 rewrite split the original 'let cwd; if (!cwd) cwd = boundWorkspace' into a single ternary, which removes the only mutation path; the variable should be const accordingly. * fix(serve): address third /review round (gpt-5.5 + glm-5.1 + deepseek-v4-pro) Five new inline findings; M1 was already resolved in 1c7f5f069. - M2 (httpAcpBridge.ts): drop the dead `ChannelInfo.workspaceCwd` field. Pre-§02 it was the routing key for `byWorkspaceChannel.get`; after the §02 collapse all reads target `SessionEntry.workspaceCwd` and `ChannelInfo.workspaceCwd` was only written, never read. Per- channel storage also suggests variance the "1 daemon = 1 workspace" model forbids. Removing the field encodes the single-workspace invariant in the type itself; left a stub comment so future readers don't reintroduce it. - M3 (httpAcpBridge.ts): fast-path `canonicalizeWorkspace` when `req.workspaceCwd === boundWorkspace`. The §02 recommended client flow is `caps.workspaceCwd` → POST `cwd: caps.workspaceCwd`, and the omit-cwd route in server.ts synthesizes the same equality. Both hit the equality check and skip the sync `realpathSync.native` syscall. Non-equal inputs fall through to the full canonicalize (clients sending `/work/./bound`, mixed casing on case-insensitive FS, symlink aliases) so correctness is unchanged. - M4 (httpAcpBridge.ts): operator stderr breadcrumb in the `channel.exited` handler. An agent crash (OOM / segfault) used to be silent on the daemon side — the child-stderr forwarder caught whatever the child wrote before dying (often nothing on SIGKILL/segfault), and SSE subscribers saw `session_died` frames but operators reading `qwen serve`'s own output had no signal that the agent process was gone. Log code+signal+affected-session-count so the line is the canonical "agent disappeared" indicator. - M5 (server.ts): documentation-only. The reviewer wanted `createServeApp` to validate `opts.workspace` exists + is a directory (currently only `runQwenServe` does). Trade-off: doing that breaks 4 existing tests which pass synthetic `/work/bound` on purpose to exercise route-layer behavior without a real directory. Deferred the helper extraction; added a JSDoc note pinning the contract so future entry points binding `createServeApp` to user input know to replicate the validation. - M6 (runQwenServe.ts): pass the already-canonical `boundWorkspace` into `createServeApp` via `opts.workspace`. `canonicalizeWorkspace` is idempotent so the server-side recanonicalize is a no-op today, but if a future refactor ever makes it non-idempotent the values the route advertises on `/capabilities` and the bridge enforces would diverge — landing clients in a "/capabilities says X, POST /session/X returns workspace_mismatch" contradiction. Removes the drift risk. bridge: 73/73; server: 80/80; tsc clean for PR-touched files. * fix(serve,sdk): address fourth /review round (deepseek-v4-pro x2) Two new inline findings: - O1 (server.ts): the POST /session route uses `'cwd' in body` against `safeBody`'s `Object.create(null)` output to distinguish "client omitted cwd" from "client sent cwd". The semantics quietly couple to `safeBody`'s literal strip list (`__proto__/constructor/prototype`). If a future maintainer adds a user-facing key (e.g. `cwd`) to that strip list, the route's presence-check would silently flip to "absent → fallback", masking the bug as "wrong workspace bound." Extracted `PROTOTYPE_POLLUTION_KEYS: ReadonlySet<string>` as a named module-scope constant; safeBody uses `.has()` on it (behavior unchanged); the route's comment now cross-references the const so the coupling is documented at both ends. The const's JSDoc spells out what to do if the strip set ever has to grow into user-key territory. - O2 (sdk-typescript): `DaemonCapabilities.workspaceCwd` is `string | undefined` (additive to v=1; pre-§02 daemons omit). SDK consumers that pass it into a `string` context get a TS strict error or, against an old daemon, a runtime `Cannot read properties of undefined`. Added a `requireWorkspaceCwd` helper + `DaemonCapabilityMissingError` so consumers can opt into an actionable `DaemonCapabilities.workspaceCwd is missing — introduced in #3803 §02 …` error instead. Exported both from `@qwen-code/sdk`'s top-level module + the `daemon/` sub-module. Unit tests cover populated, missing, and empty-string inputs. bridge: 73/73; server: 80/80; SDK DaemonClient: 43/43 (was 40, +3 new requireWorkspaceCwd cases). tsc clean for SDK and PR-touched CLI files. * fix(serve): address tanzhenxin REQUEST_CHANGES (cold-spawn + streaming-test bind) Two findings from the CHANGES_REQUESTED review on PR #4113. - T1 (integration-tests/cli/qwen-serve-streaming.test.ts) — high severity: the daemon spawn in `beforeAll` did not pass `--workspace REPO_ROOT`, so under §02 the daemon bound to whatever cwd the test runner was invoked from. Every later `createOrAttachSession({ workspaceCwd: REPO_ROOT })` then 400'd with `workspace_mismatch`, and the entire file — child-crash recovery, multi-client first-responder permission, Last-Event-ID resume — silently no-op'd once `SKIP_LLM_TESTS` was unset. The sibling `qwen-serve-routes.test.ts` got the same fix earlier in this PR; this file was missed in that pass. Added the flag with a comment pointing at the rationale so the omission can't recur. - T2 (packages/cli/src/serve/httpAcpBridge.ts) — medium severity: cold-spawn window orphans the agent child on double-Ctrl+C. The `qwen --acp` child exists from the moment `channelFactory` spawns it, but pre-fix the bridge only added the channel to `aliveChannels` AFTER `connection.initialize()` returned. During the up-to-`initTimeoutMs` (default 10s) handshake window `aliveChannels` was empty, and a double-Ctrl+C in that window played out as: first SIGINT entered `shutdown()` and awaited the in-flight spawn; second SIGINT called `killAllSync()` against an empty set; `process.exit(1)` orphaned the child. Same class of bug the BkUyD invariant set out to close — the post-init overwrite race was covered, the pre-init handshake window wasn't. Fix: move `info` creation + `aliveChannels.add(info)` + the `channel.exited` handler registration BEFORE the `initialize` await. Init-failure / late-shutdown / child-crash-during-handshake all converge on the same cleanup path: mark `isDying = true`, `await channel.kill()`, let the exited handler `aliveChannels .delete(info)` once the OS reaps the process. `channelInfo` (the attach target) is still assigned LAST so `ensureChannel`'s fast-path never returns a still-handshaking channel. Regression test: `killAllSync force-kills the channel during the initialize handshake` uses a bespoke factory whose agent's `initialize` never resolves and asserts `killAllSync` fires killSync against the channel during the handshake window. Pre-fix the test would observe an empty `killSyncCalls` array. bridge: 74/74 (was 73, +1 cold-spawn test); server: 80/80; tsc clean for PR-touched files. * fix(serve): address third /review round (gpt-5.5 + glm-5.1 + deepseek-v4-pro) Eight new inline findings; six applied, two deferred-with-reply. - P1 (httpAcpBridge.ts init-failure isDying comment): my comment overstated what `info.isDying` accomplishes on the init-failure path — concurrent `ensureChannel()` callers don't bypass via `isDying`, they coalesce on `inFlightChannelSpawn` and observe the same rejection. Reworded to describe the actual cross-path invariant marker. - P2 (server.ts workspace_mismatch log injection): doudouOUC flagged log injection via `err.requested` (user-controlled). `path.resolve` + `realpathSync.native` preserve control chars in path segments, so a body `{"cwd": "/legit/path\nqwen serve: FAKE LOG"}` would emit two valid-looking daemon log lines on stderr — weaponizing line-based log shippers (Splunk / Loki / journald → SIEM). `JSON.stringify` both `err.bound` and `err.requested` in the log line escapes control chars + quotes the values, making any injection attempt visible-as-quoted-noise rather than forged-line. Bound is operator-controlled and inherently safe but quoted symmetrically for readability. The defense-in-depth alternative (reject control chars in canonicalizeWorkspace) is deferred — this single log site was the actionable interpolation; future workspace-path-into-stderr / -JSON / -templated-SQL flows can pick up the rejection if they ship. - P3 (httpAcpBridge.test.ts): refactor the cross-workspace WorkspaceMismatchError test to a single `.catch((e) => e)` capture rather than firing the rejection twice (once for the `rejects .toBeInstanceOf` matcher, once for the field assertions). Logic unchanged. - P4 (httpAcpBridge.ts channel.exited log): the `qwen serve: channel exited (...)` line fired on every channel exit including planned shutdown — alarming for operators who Ctrl+C'd a healthy daemon. Guarded with `if (!shuttingDown)` so the planned-shutdown case (operator already saw `received SIGINT, draining...`) stays silent. The killSession path (last session leaves, daemon stays up — no top-level context line) still logs, since the line is the only signal that the cleanup actually ran. - P5 (httpAcpBridge.ts): light trim of the "pre-fix" narrative voice in two comment blocks (cold-spawn ensureChannel layout + BkUyD killAllSync aliveChannels iteration). Kept the invariant explanations — those carry maintenance value — dropped the "pre-fix the code did X" framing that's review-context not future-reader context. - P6 (server.ts + runQwenServe.ts): `createServeApp` now accepts a pre-canonicalized `deps.boundWorkspace` to skip its own `canonicalizeWorkspace` syscall when the caller (runQwenServe) already did the work. Replaces my earlier `{...opts, workspace: boundWorkspace}` opts-mutation hack — cleaner separation of concerns + drops one `realpathSync.native` per boot. Direct callers (tests, embeds) that omit `deps.boundWorkspace` still get the in-body canonicalize path. - P8 (httpAcpBridge.ts): defensive `aliveChannels.size > 2` warning. The set is intentionally multi-entry to cover the killSession-then-spawnOrAttach overlap window (size 2 is legitimate). Anything higher implies a `channel.exited` handler never fired for a prior channel — a real leak we'd otherwise catch only as gradually-growing RSS. The warning surfaces it the moment it happens. - P7 (CreateSessionRequest.workspaceCwd optional): deferred with reply rationale. Making the field optional is the §02 design ("SDK accepts bound path or none"); the JSDoc already explains the omit-vs-explicit choice; Stage 1 has no shipping SDK consumers so there's no breakage to call out in a changelog file. No code change. bridge: 74/74 (cross-workspace test refactor + behavioral assertions unchanged); server: 80/80; SDK 43/43. tsc clean for PR-touched files. * fix(serve): apply auto-fixes from /review (#4113) - canonicalizeWorkspace: narrow catch to ENOENT only, propagate other filesystem errors - listWorkspaceSessions: add fast-path string equality to avoid realpathSync on every poll - GET /workspace/:id/sessions: return 400 workspace_mismatch for cross-workspace queries - SessionNotFoundError: accept optional extra message; clarify agent-crash-on-spawn case - requireWorkspaceCwd: distinguish empty-string (post-§02 bug) from absent (pre-§02 daemon) * fix(serve/test): bind workspace explicitly in GET /workspace tests Wave-5 commit 0c6e963cd ("apply auto-fixes from /review (#4113)") added a 400 workspace_mismatch reject path to GET /workspace/:id/sessions for cross-workspace queries, but the existing two happy-path tests queried `/work/a` / `/work/idle` against an unbound daemon (which falls back to `process.cwd()`). Both turned to 400 in CI. Bind the daemon to WS_BOUND in both happy-path tests and query the same path. Add a third regression test that pins the §02 cross-workspace rejection contract — `code: workspace_mismatch`, both paths in the body, bridge.listCalls untouched (no silent fallback regression). Brings server.test.ts from 80 → 82 tests, all passing. * fix(serve,sdk): address fourth /review round (deepseek-v4-pro x2) Six new inline findings; five applied, one defer-with-reply. - Q1 (httpAcpBridge.ts + server.ts + tests): cwd length amplification through WorkspaceMismatchError. The error constructor interpolates `requested` into `.message` TWICE; `sendBridgeError` echoes it on stderr (now JSON.stringify-wrapped); `res.json` echoes it again — a ~10 MB `cwd` body (right under express.json's 10 MB cap) would amplify to ~60 MB per request × maxConnections (default 256). On loopback-default-no-token deployments this is pre-auth. Added `MAX_WORKSPACE_PATH_LENGTH = 4096` (Linux PATH_MAX); route rejects oversized `cwd` with a 400 BEFORE the bridge is touched, and the `WorkspaceMismatchError` constructor truncates `requested` as defense-in-depth for non-route callers (tests, embeds, future entry points that throw the error directly). Three new tests pin the route 400, the constructor truncation, and the normal-path passthrough. - Q2 + Q5 (httpAcpBridge.ts docs): the `channelInfo` declaration comment + `ChannelInfo.sessionIds` JSDoc + `ChannelInfo.isDying` JSDoc all overstated when `channelInfo` is cleared. Post-§02 the BkUyD invariant is "ONLY `channel.exited` clears `channelInfo`" — teardown initiators (killSession last-session-leaving, doSpawn-newSession-failure, ensureChannel init-failure/late- shutdown, shutdown) set `isDying = true` but LEAVE `channelInfo` pointing at the dying channel until OS reap, so `killAllSync` can still reach it through `aliveChannels`. A future maintainer reading the old phrasing might "fix" killSession to also clear `channelInfo` and silently break the double-Ctrl+C force-kill path. Rewrote all three sites to describe the actual invariant + enumerate the 5 isDying set-sites + spell out the BkUyD rationale in one place (the `isDying` JSDoc) that other comments point at. - Q3 (runQwenServe.ts): the "listening on …" boot summary goes to stdout but every other operational diagnostic (bearer auth, the workspace_mismatch breadcrumb, channel-exited, bridge errors) goes to stderr. Operators capturing only stderr (systemd / docker / k8s default) miss the `workspace=` indicator, which is the single piece of information they need most when triaging §02 migration issues. Added a `qwen serve: bound to workspace "X"` stderr line alongside the stdout one — keeps stdout untouched (integration tests + scripts parse it) while making the breadcrumb visible to stderr-only log shippers. `JSON.stringify` the boundWorkspace value (operator-controlled but cheap defense-in-depth against any future flow that lands a control char in the path). - Q4 (integration-tests/tsconfig.json): the `paths` entry resolved `@qwen-code/sdk` to the SDK's built `dist/` directory; `dist/` is gitignored and stale dist (no `npm run build` first) yields TS2339 errors on the integration tests' imports of new SDK fields. Pointed `paths` at SDK source instead — `tsc -p integration-tests/tsconfig.json` no longer requires a prior rebuild. The vitest config's runtime alias still resolves to `dist/index.mjs` so the actual test execution exercises the published-bundle shape; this paths entry only affects type resolution. - Q6 (httpAcpBridge.ts): `createHttpAcpBridge` constructor called `canonicalizeWorkspace(opts.boundWorkspace)` even when the caller (`runQwenServe`) had already canonicalized and threaded the same value through `deps.boundWorkspace` into `createServeApp`. Two independent `realpathSync.native` calls can theoretically diverge on NFS-transient / mid-rename filesystems, landing the bridge with a canonical form different from what `/capabilities` advertises and from `createServeApp`'s view. Dropped the bridge's re-canonicalize; kept `path.isAbsolute` (structural, not a syscall); documented the caller contract on `BridgeOptions .boundWorkspace` ("MUST be pre-canonicalized; tests/embeds call `canonicalizeWorkspace` first"). Tests use `path.resolve(path.sep, ...)` which is already canonical-or- fallback for non-existent paths, so no test changes needed. bridge: 76/76 (was 74, +2 WorkspaceMismatchError truncation tests); server: 82/82 (was 80, +2 length cap + the auto-applied helper). tsc clean for SDK, CLI PR-touched files, and integration-tests' qwen-serve-*.	2026-05-15 12:44:36 +08:00
ChiGao	d343e2c15e	feat(perf): progressive MCP availability — MCP no longer blocks first input (#3994) ... * feat(perf): progressive MCP availability — MCP no longer blocks first input Today `Config.initialize()` runs MCP discovery synchronously and the cli can't accept input until every configured MCP server finishes its discover handshake. One slow or hung server bottlenecks every user with MCP configured. Validated by the profiler instrumentation added in this PR (set `QWEN_CODE_PROFILE_STARTUP=1` to reproduce): | User scenario | Time to first prompt input | | ------------------------- | -------------------------- | | No MCP | ~480 ms | | 1 fast MCP | ~875 ms | | 2 fast + 1 slow MCP | **~7.1 s** | | 1 hung MCP server | **~10.5 s** | (Measured on macOS arm64 / Node 24.15, n=30/fixture, p50.) `Config.initialize()` now passes `{ skipDiscovery: true }` to `createToolRegistry` by default and kicks off MCP discovery in a fire-and-forget background path. As each server completes discover, the cli's `AppContainer` debounces `setTools()` calls into one-frame (16 ms) batches so the model sees the consolidated tool list shortly after each server settles. Rollback: `QWEN_CODE_LEGACY_MCP_BLOCKING=1`. - `packages/core/src/config/config.ts` — `Config.initialize` switches to `skipDiscovery: true` + new `startMcpDiscoveryInBackground()` (defensive against partially-stubbed `ToolRegistry` in tests). Adds `MCPServerConfig.discoveryTimeoutMs` (last positional ctor param — doesn't shift existing call sites). Tool-call timeout is untouched. - `packages/core/src/tools/tool-registry.ts` — new `getMcpClientManager()` getter so the background path can call the incremental discover directly without going through `discoverMcpTools` (which would wipe already-registered tools). - `packages/core/src/tools/mcp-client-manager.ts` — `discoverAllMcpToolsIncremental` now: emits `mcp-client-update` after IN_PROGRESS transition, wraps each per-server discover in a discovery-only timeout (stdio 30s, remote 5s), emits trailing `mcp-client-update` after COMPLETED so UI subscribers see the terminal state. - `packages/cli/src/ui/AppContainer.tsx` — new `useEffect` (gated on `isConfigInitialized`) subscribes to `mcp-client-update` and 16ms-batches `setTools()` calls. Same effect also defers `finalizeStartupProfile` until MCP settles (or 35s hard cap), so startup-perf profiles capture the full MCP timeline. Activated only by `QWEN_CODE_PROFILE_STARTUP=1`; when unset every profiler entry point short-circuits in a single null/flag check and returns. Heisenberg overhead measured at -1.12% Δp50 between profile-on vs profile-off (Welch p=0.092, n=30/config × 3 configs) — within statistical noise. - `packages/cli/src/utils/startupProfiler.ts` — extended with `events` array (multi-fire), `recordStartupEvent`, `setInteractiveMode`, `derivedPhases`, per-checkpoint heap snapshots, `MAX_EVENTS` cap, and `QWEN_CODE_PROFILE_STARTUP_OUTER` / NO_HEAP env opt-ins. + 7 new tests. - `packages/core/src/utils/startupEventSink.ts` (new) — minimal cross-package sink so `core` can emit profiler events without reverse-depending on `cli`. No-op when no sink registered. + 4 tests. - `packages/core/src/index.ts` — export `setStartupEventSink` / `recordStartupEvent` / type aliases. - `packages/cli/src/gemini.tsx` — registers the sink at `main()` entry, adds `first_paint` checkpoint after Ink render, calls `setInteractiveMode(true)` in the interactive branch. - `packages/core/src/config/config.ts` — emits `tool_registry_created`. - `packages/core/src/core/client.ts` — emits `gemini_tools_updated` at the end of `setTools()`. - `packages/core/src/tools/mcp-client-manager.ts` — emits `mcp_discovery_start`, `mcp_server_ready:<name>`, `mcp_first_tool_registered`, `mcp_all_servers_settled`. - `packages/cli/src/ui/AppContainer.tsx` — emits `config_initialize_start`, `config_initialize_end`, `input_enabled`. `Config.initialize()` now returns BEFORE MCP discovery completes. Things to check: - Any code path that assumed "after `config.initialize()`, all MCP tools exist in the registry" — these will see only built-in tools initially; new tools appear via `mcp-client-update` events. - `MCPDiscoveryState.COMPLETED` is now set asynchronously instead of synchronously after `initialize()` resolves. - Model requests issued before MCP settles see only built-in tools; subsequent requests see the full set as servers come online. - Tests that assert MCP tool count immediately after `config.initialize()` should wait for the `mcp-client-update` with COMPLETED discoveryState instead. - 313 impacted-area tests green (config / mcp-client-manager / client / startupProfiler 18 / startupEventSink 4). - `tsc --noEmit` clean for `packages/core` and `packages/cli`. - `eslint` clean on touched files. - Manual: `QWEN_CODE_PROFILE_STARTUP=1 SANDBOX=1` interactive run produces a JSON profile in `~/.qwen/startup-perf/` containing `first_paint`, `config_initialize_start/end`, `input_enabled`, MCP per-server events, and `gemini_tools_updated`. See PR description's "How to validate" section. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(core): harden progressive MCP discovery against silent regressions Addresses review feedback on PR #3994: - Skip user-disabled servers in discoverAllMcpToolsIncremental. The new incremental path used to iterate Object.entries(servers) without consulting isMcpServerDisabled, so a server the user had explicitly turned off would still get connected and its tools registered. Mirrors the existing protection in discoverAllMcpTools. - Disconnect the underlying client when runWithDiscoveryTimeout fires. Without this, the inner discoverMcpToolsForServer kept running after the timeout rejected the outer promise — if discover() eventually succeeded it would register the late server's tools into the live toolRegistry (a silent registration vector, especially exploitable with a 0/negative discoveryTimeoutMs override). - Clamp discoveryTimeoutMs to [100ms, 300_000ms]. 0/negative/Infinity values previously passed through to setTimeout unvalidated and made the silent-registration bug above trivially reachable. - Classify the `tcp` (WebSocket) transport field as remote so hung WS handshakes use the 5s default instead of the 30s stdio default. - Defensive delete of serverDiscoveryPromises[name] in the per-server catch so a doomed/orphan entry can't briefly short-circuit a subsequent discoverMcpToolsForServer call. Adds focused tests for each fix. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): restore runtime.json sidecar and harden non-interactive MCP visibility Addresses review feedback on PR #3994: - Restore writeRuntimeStatus + markRuntimeStatusEnabled in startInteractiveUI. The progressive-MCP diff inadvertently dropped the runtime.json sidecar write from the interactive entry point, leaving Config.refreshSessionId()'s session-swap refresh as dead code and silently breaking external integrations (terminal multiplexers, IDE integrations, status daemons) that map PID → sessionId via runtime.json. - Add Config.getFailedMcpServerNames() and surface a stderr warning in --prompt / stream-json / ACP entry points when one or more MCP servers failed during background discovery. Per-server errors are caught inside discoverAllMcpToolsIncremental and never reached a TTY otherwise, so a script using non-interactive mode with broken MCP config would silently run with only built-in tools — a regression vs the legacy synchronous path. - Pass the parsed `settings` object through to runNonInteractiveStreamJson. The new call site dropped the argument, falling back to createMinimalSettings() and losing any user-configured permission / approval / hook setup for stream-json sessions. Added regression assertion to gemini.test.tsx. - Move finalizeStartupProfile out of gemini.tsx's stream-json branch and into Session.ensureConfigInitialized so it runs AFTER config.initialize() / waitForMcpReady() in stream-json. Previously the profile was finalized before any MCP / config_initialize_* events were emitted, producing empty stream-json profiles. - Gate setStartupEventSink registration on isStartupProfilerEnabled() so core-side recordStartupEvent calls short-circuit at the first null-check when profiling is disabled, instead of going through an arrow wrapper and the profiler's own enabled gate. - Tighten the type-unsafe ToolRegistry cast in startMcpDiscoveryInBackground to preserve the typed return signature so a rename of getMcpClientManager would be flagged at this call site (kept the optional-chain guard for tests that stub ToolRegistry as a plain object). - Re-document first_paint as "render call returned" so consumers don't confuse Ink's synchronous render() return with literal pixel paint. Kept the checkpoint name for backward compatibility with collected profiles. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): restore resize repaint and pin gemini_tools_lag capture in AppContainer Addresses review feedback on PR #3994: - Restore the terminal-resize useEffect that calls repaintStaticViewport() when terminalWidth changes. The progressive- MCP diff removed previousTerminalWidthRef + the repaint useCallback + the resize useEffect, so tmux pane resizes and fullscreen toggles leave the static region rendered at the old width — header content visibly tears until something else triggers refreshStatic. - Pin the gemini_tools_lag startup metric. The previous onMcpUpdate handler called finalizeOnce() synchronously when discovery reached COMPLETED, but the pending setTools() batch was still 16ms away. setTools() emits `gemini_tools_updated` — when finalize ran first the profile's `finalized` guard suppressed that event, so gemini_tools_lag came out undefined in interactive mode. New onMcpUpdate flushes setTools() NOW on COMPLETED and only finalizes after the flush resolves, guaranteeing the event lands. - Log setTools() batch-flush errors via debugLogger instead of silently swallowing them. GeminiClient.setTools() has no try/catch around warmAll() / getFunctionDeclarations() / getChat().setTools(); the previous `.catch(() => {})` would have hidden production tool-registration regressions completely. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(core): correct MCP failure visibility and incremental cleanup Addresses three review findings on PR #3994: - McpClient.discover() now flips the client status to DISCONNECTED before re-throwing. Previously, a server that connected successfully but whose discoverPrompts / discoverTools then rejected (or that returned no prompts and no tools) would remain CONNECTED in the global status registry. Config.getFailedMcpServerNames() filters by `status !== CONNECTED`, so such servers were silently omitted from the non-interactive failure banner and the Footer's MCP health pill kept counting them as healthy. - discoverAllMcpToolsIncremental no longer records `outcome: 'ready'` for servers whose connect/discover threw. The inner discoverMcpToolsForServerInternal catches errors without re-throwing (best-effort discovery semantics), so the try block resolved even for failures — only the runWithDiscoveryTimeout path reached the catch. Auth errors, server crashes, and missing-tools responses were therefore recorded as success in the startup profile. We now consult the actual server status (now correctly DISCONNECTED after the first fix) before emitting `ready`, and emit `outcome: 'failed'` otherwise. `mcp_first_tool_registered` is gated on the same check so a failed server can't pollute that user-facing metric. - discoverAllMcpToolsIncremental tears down enabled→disabled mid-session transitions. When a previously-connected server is disabled (e.g. via `/mcp disable foo` or by editing settings), the incremental path used to just `continue` past it, leaving its client, tools, health check, and global status entry in place. Now calls removeServer() for any already-known client we encounter in the disabled branch. Adds focused tests for each fix. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * docs(core): clarify ToolRegistry cast comment in startMcpDiscoveryInBackground Addresses review feedback on PR #3994. The previous comment claimed the call site uses "no defensive cast" but the code still casts via `as ToolRegistry & { getMcpClientManager?: ... }`. Reword to explain the cast's actual purpose: it exists only because some tests stub ToolRegistry as a plain object, so we use optional chaining to avoid crashing the init path when those tests run. Also note that the inner shape now uses `ReturnType<ToolRegistry['getMcpClientManager']>` — a future rename of the production method still surfaces as a type error at this call site rather than silently falling through to the `if (!manager)` branch. Comment-only change; no behavior diff. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(core): close MCP timeout TOCTOU race and propagate disconnect status Addresses two critical findings on PR #3994 round 6: - runWithDiscoveryTimeout no longer uses fire-and-forget disconnect. The prior `void client.disconnect()` returned before `transport.close()` landed, leaving a window where an in-flight `discover()` could pump `tools/list` through the transport and synchronously register tools into the live registry BEFORE the close took effect. The earlier fix comment described this as a "remote-exploitable silent-tool-registration vector"; the await closes the timing window but doesn't help if tools already landed, so we also drop them with `removeMcpToolsByServer()` after the disconnect resolves. No-op when discover hadn't reached registration yet. - McpClient.disconnect() now writes DISCONNECTED to the global registry directly. Previously, `isDisconnecting = true` was set BEFORE the internal `updateStatus(DISCONNECTED)` call, and `updateStatus`'s guard (designed to suppress LATE writes from a stale `connect()` catch) silently swallowed the write. The global stayed CONNECTED forever for timeout-disconnected servers, so `Config.getFailedMcpServerNames()` (which filters `status !== CONNECTED`) omitted them from the non-interactive failure banner and the Footer's MCP health pill kept counting them as healthy. This invalidated the round-5 `getMCPServerStatus === CONNECTED` gate, which would always pass the "ready" check for timed-out servers. The guard stays in place for its original purpose; the legitimate disconnect→DISCONNECTED notification now bypasses it by writing the registry directly. Also adds the `config_initialize_start` / `_end` profiler checkpoints to `Session.ensureConfigInitialized()` so stream-json startup profiles include the same derived `config_initialize_dur` phase as the non-stream-json branch in gemini.tsx (round 6 [Suggestion]). Tests cover (a) the disconnect-and-cleanup path on timeout and (b) the intentional-disconnect global registry propagation regression. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(mcp): surface failures + prevent health-check resurrection of timed-out servers Round-7 review follow-ups: - AppContainer (interactive): MCP startup failures now route through debugLogger.warn on COMPLETED. Was silent — only debug logs / profile events surfaced failures, so regular interactive users got no indication their MCP servers failed. Mirrors the non-interactive stderr warning, adjusted to debugLogger so it doesn't collide with Ink's rendered output. - acpAgent per-session: `QwenAgent.initializeConfig()` now emits the same `Warning: MCP server(s) failed to start` stderr line as the top-level `runAcpAgent` path. Previously per-session ACP configs with failed MCP servers silently fell back to built-in tools. - mcp-client-manager timeout handler: after disconnecting an intentionally timed-out server, also drop it from `this.clients` and stop any pending health-check timer. Without this the discovery `finally` block would arm a health-check that detected DISCONNECTED status and called `reconnectServer()` → `discoverMcpToolsForServer()` directly — bypassing `runWithDiscoveryTimeout` entirely and silently resurrecting the slow server. `startHealthCheck` also early-returns for unknown servers so the trailing finally-block call is a no-op. - startupEventSink: silent `catch {}` now logs via `debugLogger.error` so a corrupted sink doesn't silently drop every subsequent event. Quiet by default; visible under `QWEN_CODE_DEBUG=1`. Tests: - mcp-client-manager.test.ts: regression for the timeout → no-reconnect invariant (clients map purged + health-check timer absent). - acpAgent.test.ts: per-session newSession surfaces failures to stderr, and stays safe when Config lacks `getFailedMcpServerNames`. Declines (with reasoning in PR reply): - [Critical] AppContainer batch-flush useEffect untested → re-flag of the round-5 deferral that wenshao acknowledged at the time. Lower- layer invariants (this PR's mcp-client-manager + mcp-client tests) pin the dependent contracts. The component-test harness for timers + event emitters in this file is non-trivial and out of scope; tracked for a follow-up. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> --------- Co-authored-by: 秦奇 <gary.gq@alibaba-inc.com> Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-05-13 22:17:16 +08:00
Shaojin Wen	870bdf2a9d	feat(cli,sdk): qwen serve daemon (Stage 1) (#3889) ... * feat(cli): scaffold `qwen serve` HTTP daemon (Stage 1, #3803) Adds a `serve` subcommand that boots an Express 5 listener with bearer auth, host allowlist, and CORS modeled on `vscode-ide-companion/src/ ide-server.ts`. Ships only `/health` and `/capabilities` to begin with; session/prompt/event routes will land in follow-up PRs once the per- session ACP child-process bridge in `httpAcpBridge.ts` is wired. Defaults to 127.0.0.1 with auth disabled so local development needs no configuration. Binding beyond loopback (e.g. `--hostname 0.0.0.0`) refuses to start without a token (`--token` or `QWEN_SERVER_TOKEN`). Capabilities envelope versioned at v=1 with a `features` array — clients should gate UI off `features`, never off `mode`, so subsequent PRs can add capability tags without breaking older clients. Per design issue's Stage 1 scope (~700-1000 LOC). Adds ~430 LOC of implementation + tests in this scaffold; the remaining budget belongs to the route wiring + bridge implementation in follow-ups. * feat(cli): wire HttpAcpBridge + POST /session for `qwen serve` (#3803) Stage 1 follow-up to the scaffold. Implements the bridge between the HTTP daemon and the existing ACP child agent, plus the first session endpoint. `HttpAcpBridge.spawnOrAttach`: - Spawns `node $cliEntry --acp` per workspace via an injectable `ChannelFactory` (default uses `process.argv[1]`; tests use an in-memory `TransformStream` pair so they don't fork real processes). - Drives the ACP `initialize` + `newSession` handshake via the SDK's `ClientSideConnection`, with a 10s timeout that kills the channel. - Under `sessionScope: 'single'` (default), reuses the live session when the same canonical workspace cwd is requested again — backs the `attached: true` flag. - The `Client` impl on the bridge side proxies file reads/writes to local fs (daemon and agent share the host) and buffers `sessionUpdate` notifications for the SSE wiring in the next PR. `requestPermission` returns `cancelled` until the `/permission/:requestId` route lands. `POST /session`: - 400 on missing or relative `cwd`. - 200 with `{sessionId, workspaceCwd, attached}` on success. - 500 on bridge failure (the failing channel is killed, not leaked). `runQwenServe` constructs the bridge and ties `bridge.shutdown()` into the listener-close path so SIGINT/SIGTERM drain children before the socket closes. Tests (14 new, 0 regressions in the 4967-test baseline): - 9 bridge cases over an in-memory channel — fresh spawn, single-scope reuse, cross-workspace isolation, thread-scope independence, path canonicalization, relative-path rejection, init failure cleanup, init timeout, multi-channel shutdown. - 4 route cases for /session (missing/relative/200/500). - 1 lifecycle case asserting `runQwenServe.close()` calls `bridge.shutdown()` before closing the listener. Verified end-to-end: `qwen serve` boots, `POST /session` spawns a real `qwen --acp` child and returns the SDK-assigned `sessionId`, repeat calls under the same cwd return `attached: true`, `SIGTERM` reaps the child along with the listener. * feat(cli): wire POST /session/:id/prompt + /cancel for `qwen serve` (#3803) Stage 1 follow-up after the bridge scaffold. Adds the two routes a client needs to actually run a turn against the daemon. Bridge: - `sendPrompt(sessionId, req)` looks up the session, FIFO-queues the call against the per-session prompt queue, and forwards through the SDK `ClientSideConnection.prompt`. Concurrent calls observe ACP's "one active prompt per session" invariant — second waits for first. - A failed prompt does NOT poison the queue; the tail catches and keeps draining so the next caller still runs (the original caller still sees its own rejection). - `cancelSession(sessionId, req?)` bypasses the queue and forwards the ACP notification immediately. ACP semantics: the agent winds down the *currently active* prompt; queued work is unaffected. - Both methods throw `SessionNotFoundError` (a typed Error subclass) when the id is unknown so route handlers can map cleanly to 404 without brittle message matching. - Both methods overwrite the `sessionId` field in the request body with the routing id — a stale or spoofed body would otherwise be dispatched to the wrong agent process. Routes: - `POST /session/:id/prompt` → 200 with PromptResponse, 400 on missing/non-array prompt, 404 on unknown session, 500 on agent error. - `POST /session/:id/cancel` → 204 always (cancel is a notification), 404 on unknown session. Tests (14 new — 7 bridge + 7 route, 0 regressions in the 4981 baseline): - sendPrompt: success forwards & returns response · routing-id overrides body sessionId · concurrent prompts FIFO-serialize (verified via per-prompt start/end ordering with a release latch) · failed prompt doesn't block subsequent prompts · 404 for unknown id. - cancelSession: forwards with routing id · 404 for unknown id. - Routes: 200/400/404/500 paths for prompt; 204 with body or empty + 404 for cancel. Verified end-to-end against a real `qwen --acp` child: - POST /session/:id/prompt with `[{type:'text',text:'hi'}]` → 200 `{"stopReason":"end_turn"}` in ~3.4s. - POST /session/:id/cancel → 204. - POST /session/does-not-exist/prompt → 404 with the unknown id surfaced in the body. * feat(cli): wire SSE streaming for `qwen serve` events (#3803) Stage 1 follow-up that turns prompt into a real streaming experience. Replaces the in-memory `notifications: SessionNotification[]` buffer on each session with a per-session EventBus and exposes it through `GET /session/:id/events` as an `text/event-stream` SSE feed. EventBus (`packages/cli/src/serve/eventBus.ts`): - Monotonic per-session ids (`v: 1` schema). Each `publish` chains an id, returning the materialized BridgeEvent. - Bounded ring (default 1000) backs `Last-Event-ID` reconnect — a consumer that drops can resume from `lastEventId` and replay any still-buffered events before live events flow. - Per-subscriber bounded queue (default 256). When a slow consumer overruns its queue, the bus appends a synthetic `client_evicted` terminal frame and closes that subscription so it can't hold the daemon hostage. Other subscribers are unaffected. - `subscribe()` returns an AsyncIterable — registration is synchronous so events `publish`ed immediately after the subscribe land in the queue (a generator-style implementation deferred registration to first `next()` and raced with publishes). - AbortSignal-aware: aborting the signal closes the iterator promptly. Bridge (`httpAcpBridge.ts`): - `BridgeClient.sessionUpdate` now publishes onto the session's EventBus instead of pushing to a plain array — every ACP notification the agent emits becomes a stream event automatically. - New `subscribeEvents(sessionId, opts?)` returns the bus's AsyncIterable; throws `SessionNotFoundError` for unknown ids. - Shutdown closes every live event bus before killing channels so pending consumers unwind cleanly. Route (`server.ts`): - `GET /session/:id/events` sets the SSE content type, advertises a 3s reconnect hint, and writes a 15s heartbeat comment frame to keep proxy/NAT connections alive. - Forwards the `Last-Event-ID` header to the bus. - `req.on('close')` triggers an AbortController that propagates into the bridge subscription so disconnects don't leak subscribers. - 404 when the bridge can't find the session. Capabilities envelope: `STAGE1_FEATURES` now advertises `session_create`, `session_prompt`, `session_cancel`, `session_events` in addition to `health`/`capabilities` so clients can light up UI for the routes that have actually shipped. Tests (16 new, 0 regressions in the 4995 baseline): - 9 EventBus unit cases — id sequencing, live delivery, replay, replay+live splice, fan-out to N subscribers, eviction on overflow, abort-signal unsubscribe, bus.close() drains subscribers, ring-size eviction. - 4 bridge subscribe cases — 404, sessionUpdate→event publishing via real ACP fake-agent, shutdown closes live subscriptions. - 4 SSE route cases against a live HTTP listener — frame format, Last-Event-ID forwarding, 404, abort propagation on disconnect. Verified end-to-end against a real `qwen --acp` child: - Subscribed to `/session/$SID/events`, fired `POST /session/$SID/prompt` with text content. Captured 13 distinct `event: session_update` SSE frames in real time during the model's response — `available_ commands_update` metadata, 9 `agent_thought_chunk` frames carrying the model's chain-of-thought, 3 `agent_message_chunk` frames with the actual reply, and a final usage frame with token totals. - Frames carry monotonic ids 1..13, the daemon-side counter, and are valid SSE per the EventSource spec. * feat(cli): wire POST /permission/:requestId for `qwen serve` (#3803) Stage 1 follow-up that turns `BridgeClient.requestPermission` from a hardcoded `cancelled` placeholder into a real first-responder vote loop, and ships the HTTP route any attached client uses to cast the deciding vote. Bridge: - `requestPermission` generates a UUID requestId, registers a pending entry on a daemon-wide map (and the owning session's `pendingPermissionIds` set), publishes a `permission_request` event onto the session's EventBus (so SSE subscribers see it), and awaits the resolution. - New `respondToPermission(requestId, response)` resolves the pending promise with the supplied outcome. First call wins — subsequent calls return false. On success the bridge publishes a `permission_resolved` event so other attached clients can update their UI when the race is decided. - `cancelSession` and `shutdown` both resolve every still-pending permission for the affected session(s) as `{ outcome: { outcome: 'cancelled' } }` per the ACP spec requirement that a cancelled prompt MUST resolve outstanding requestPermission calls with cancelled. - New `pendingPermissionCount` getter exposes inflight count for inspection / tests. Route (`server.ts`): - `POST /permission/:requestId` validates the body's `outcome` is either `{ outcome: 'cancelled' }` or `{ outcome: 'selected', optionId: string }`, then forwards to `bridge.respondToPermission`. - 200 on accepted vote, 404 when the requestId is unknown or already resolved (Stage 1 doesn't differentiate), 400 on a malformed outcome. Capabilities envelope: STAGE1_FEATURES gains `permission_vote`. Tests (14 new — 9 bridge + 5 route, 0 regressions in the 5011 baseline): - Bridge: publishes permission_request with a generated requestId and waits; respondToPermission first-responder wins; publishes permission_resolved on vote; respondToPermission false for unknown requestId; cancelSession resolves outstanding as cancelled; shutdown resolves outstanding as cancelled. - Route: 200 on selected outcome; 200 on cancelled outcome; 404 on unknown requestId; 400 on malformed outcome; 400 on missing outcome. Verified end-to-end against a real `qwen --acp` child: - Subscribed to /session/$SID/events, sent a prompt asking the agent to write a file at /tmp/qwen-serve-permission-e2e-test.txt. - The agent triggered a permission_request via the bus, surfacing the three options Qwen Code presents (Allow Always / Allow / Reject) with their option ids. - POSTed `{outcome:{outcome:"selected",optionId:"proceed_once"}}` to /permission/$requestId — got HTTP 200. - Bus published the matching permission_resolved event. - Agent proceeded with the writeTextFile tool call; file was actually created on disk with the expected content. * feat(sdk): add DaemonClient for the qwen serve HTTP API (#3803) Stage 1 follow-up that proves the cross-mode protocol-isomorphism design assumption: an SDK client can drive the daemon's HTTP routes end-to-end without going through ProcessTransport's stdio + stream-json path. DaemonClient is a sibling of ProcessTransport, not a replacement. The two speak different protocols (ACP NDJSON over HTTP vs stream-json over stdio). Existing `query()` users keep getting subprocess-mode unchanged; applications that want daemon-mode (cross-client attach, shared MCP pool, network reachability, first-responder permissions) opt in by constructing a DaemonClient against a running `qwen serve`. API surface (`packages/sdk-typescript/src/daemon/`): - `new DaemonClient({ baseUrl, token?, fetch? })`. The `fetch` override is for tests; defaults to `globalThis.fetch`. Trailing slashes on `baseUrl` are stripped. - `health()`, `capabilities()` — discovery. - `createOrAttachSession({ workspaceCwd, modelServiceId? })` — `attached: true` on the response indicates a session was reused under sessionScope:single. - `prompt(sessionId, { prompt: ContentBlock[] })` — returns PromptResult with stopReason. - `cancel(sessionId)` — tolerates 204; throws on 404. - `subscribeEvents(sessionId, { lastEventId?, signal? })` — async iterator over parsed SSE frames; AbortSignal-aware. Native Node AbortController only — jsdom polyfills are incompatible with undici. - `respondToPermission(requestId, response)` — first-responder vote; returns true on 200, false on 404 (lost the race or unknown id), throws on 400/500. `DaemonHttpError` is thrown for any non-2xx (besides the 404 "already-resolved" case on permission votes); carries `status` and `body` so callers can branch on standard daemon HTTP semantics. `parseSseStream(body)` is the underlying SSE parser; exported separately so applications can consume daemon SSE outside the DaemonClient surface. Handles split-chunk frames, comment/retry directives, malformed JSON (skip), trailing frame without final newline. Wire types live SDK-side (no SDK→CLI dep); the capabilities envelope's `v` field signals breaking changes. Tests (26 new, 0 regressions in the 201 baseline): - 7 SSE parser cases — single frame, multiple frames, comments, chunked-split frame, malformed JSON skip, trailing frame on close, empty stream. - 19 DaemonClient cases — health success/error, capabilities, bearer auth presence/absence, createOrAttachSession success/400, prompt body shape + sessionId url-encoding, cancel 204/404, permission 200/400/404, subscribeEvents header forwarding + 404, baseUrl normalization. Verified end-to-end against a real `qwen serve` daemon driving a real `qwen --acp` child: - `client.capabilities()` returned `{v:1, mode:"http-bridge", features: [...7 tags]}`. - First `createOrAttachSession` returned `attached:false`; second returned `attached:true` with the same sessionId. - `client.prompt(...)` with text content yielded `{stopReason: "end_turn"}` while the parallel `subscribeEvents` iterator streamed 10 distinct frames during the same turn. - AbortController on the events iterator cleanly severed the SSE connection. * feat(cli,sdk): list workspace sessions + set session model (#3803) Closes the §04 Stage-1 routes table for `qwen serve` with the two remaining endpoints, plus matching SDK methods. `GET /workspace/:id/sessions` - `:id` is the URL-encoded canonical absolute workspace path (Express decodes path params automatically; clients pass `encodeURIComponent(cwd)`). - Returns `{ sessions: [{ sessionId, workspaceCwd }, ...] }` for live sessions whose canonical workspace matches. - Empty array (not 404) when the workspace is idle so picker UIs don't have to special-case "no sessions yet". - 400 when the decoded path isn't absolute. `POST /session/:id/model` - Body: `{ modelId: string, ... }`. The route's `:id` overrides any spoofed sessionId in the body. - Forwards to ACP's `unstable_setSessionModel` and publishes a `model_switched` event onto the session bus so cross-client UIs update. - 200 with the agent's response on success, 400 on missing/empty modelId, 404 on unknown session. - The SDK method is currently unstable; documented in the bridge comment in case the spec renames the method when it stabilizes. Bridge: - New `listWorkspaceSessions(workspaceCwd)` iterates `byId.values()` and filters by canonical workspace path; works for both `single` and `thread` session scopes. - New `setSessionModel(sessionId, req)` forwards through `connection.unstable_setSessionModel`, normalizes sessionId, publishes `model_switched`, throws SessionNotFoundError on unknown ids. `STAGE1_FEATURES` capabilities envelope grows to 9 tags, adding `session_list` and `session_set_model`. SDK (`DaemonClient`): - `listWorkspaceSessions(workspaceCwd)` URL-encodes the cwd and returns the parsed `sessions` array directly. - `setSessionModel(sessionId, modelId)` POSTs the body and returns the agent response (currently opaque per ACP unstable spec). - Wire types `DaemonSessionSummary` and `SetModelResult` exported from the SDK barrel. Tangential cleanup: `sendBridgeError` now extracts a useful message from non-Error values via a small `errorMessage` helper. JSON-RPC errors from the agent (`{code, message, data}`) used to surface as `"[object Object]"` in the 500 response body; they now show the inner `message` field. Caught while running the model-set e2e. Tests (17 new — 9 bridge + 7 route + 4 SDK, 0 regressions in the 5022 + 227 baselines): - Bridge listWorkspaceSessions: matching cwd returns the live sessions; canonicalizes the lookup; empty for relative paths. - Bridge setSessionModel: forwards modelId + overrides body sessionId; publishes model_switched event; 404 unknown session. - Route /workspace/:id/sessions: returns the bridge list; empty for idle workspace; 400 for relative path. - Route /session/:id/model: 200 success; 400 missing modelId; 400 empty modelId; 404 unknown session. - SDK listWorkspaceSessions: URL-encodes the cwd; throws on 400. - SDK setSessionModel: posts body; throws on 404. Verified end-to-end against a real `qwen serve`: - SDK reports 9 capability features, list returns the existing session, attached:true on repeat create, and `setSessionModel` rejects with HTTP 500 when the modelId isn't registered (with the daemon now surfacing "Internal error" instead of "[object Object]"). - 404 path through SDK on unknown sessionId works. * fix(cli,sdk): audit round 1 follow-ups for `qwen serve` (#3803) Self-review pass on PR #3889. Two real correctness bugs and an ergonomics gap, plus the test-coverage holes the audit surfaced. The loudest finding ("host allowlist no-op when bind=localhost") was a false positive — the conditional was misread; existing tests already prove the validator is active on `localhost` binds. Real fixes: - Bearer-auth timing-attack: `parts[1] !== token` short-circuits per byte, leaking which prefix is correct via response latency. Replace with SHA-256 of both sides + `crypto.timingSafeEqual` so comparison is constant-time regardless of token length. - Concurrent `spawnOrAttach` race in single-scope: two parallel callers for the same workspace both passed the `byWorkspace.get` check, both spawned, and one entry ended up orphaned in `byId` while the other won `byWorkspace`. Violates the "at most one session per workspace" invariant. Coalesce via an `inFlightSpawns` map: parallel callers attach to the in-flight promise and report `attached: true`. The slot is cleared on both success and rejection so a failed spawn doesn't poison the workspace forever. New test asserts ONE channel spawns under parallel calls and that retry works after rejection. - `Number.parseInt('1.5e10z', 10)` returns 1, so a malformed `Last-Event-ID` header silently passes through. Tighten `parseLastEventId` to `^\d+$` so anything not a pure decimal integer is dropped. New test exercises 'abc', '-1', '1.5e10z'. Ergonomics: - `LOOPBACK_BINDS` and `LOOPBACK_HOST_BINDS` now include `::1` and `[::1]`. IPv6 loopback users no longer have to set a token. Host-allowlist allows `[::1]:port` Host headers. Documentation: - `BridgeClient` doc-comment now states the Stage 1 trust model explicitly: agent runs as the same UID, the file-proxy methods are NOT a workspace-cwd sandbox, restricting them would be theatre. The audit flagged this as a "design gap" but the daemon-and-agent-on-same-host posture makes a sandbox here redundant — Stage 4+ remote-sandbox swaps the Client for a sandbox-aware variant. SDK fix: - `DaemonClient.failOnError` previously called `res.json()`, which consumes the body even on parse-failure; the subsequent `res.text()` returned empty. New impl reads once as text and attempts JSON-parse; raw text is the fallback. New test asserts a `text/plain` 502 surfaces the body verbatim. Test gap fills (audit-flagged): - Bridge: in-memory file-proxy tests for `BridgeClient.{read,write} TextFile` including line/limit slicing. - SSE route: `stream_error` synthetic frame on iterator throw mid-stream; numeric Last-Event-ID forwarded; malformed Last-Event-ID dropped. - DaemonClient: text/plain error body coerced to `body` field; `respondToPermission` 5xx throws; `subscribeEvents` null-body throws; `cancel`/`respondToPermission` URL-encode session/request ids that contain slashes. Verified end-to-end with a token-required daemon: right token → 200, wrong/missing/malformed → 401. All paths return uniform 401 messages so a side-channel can't distinguish between "no header", "bad scheme", and "wrong token". Test counts: cli serve **89** (was 81, +8), sdk daemon **35** (was 30, +5). Full suites still green. * fix(cli): audit round 2 follow-ups for `qwen serve` (#3803) Second self-review pass on PR #3889. Three real bugs (one correctness, one resource-cleanup, one cosmetic) plus consolidation of the loopback bindings into a single source of truth. Real fixes: - Shutdown could hang forever on a long-lived SSE consumer: `server.close` waits for every in-flight connection to drain, and a paused EventSource client never disconnects. Added a `SHUTDOWN_FORCE_CLOSE_MS` (5s) timer that calls `server.closeAllConnections()` to force-destroy stuck sockets, then resolves so `process.exit(0)` can run. New test asserts close completes well under 5.5s even when an SSE GET is in flight. - Signal-handler race during shutdown: round 1 detached the SIGINT/SIGTERM listeners *up front* in `handle.close()`. If a second SIGTERM arrived during the drain, no handler existed and Node's default termination ran, orphaning agent children. Switch to detaching at the *end* of the close path (in `finish()`): during the drain window the handler is still attached and the `if (shuttingDown) return` guard makes a second signal a no-op; after drain completes we can safely remove the listeners (this also fixes a test-suite MaxListenersExceededWarning that fired once we ran the runQwenServe tests >10 times in a single process). - SSE response had no `error` listener. When the underlying TCP socket died (RST, kill -9 on the client), the next `res.write` threw EPIPE and Express forwarded it to the default error handler, logging noisily. Added `res.on('error', cleanup)` so the failure is absorbed and triggers the same teardown path the `req.on('close')` handler uses. Validation: - `createHttpAcpBridge` now throws on invalid `sessionScope` (anything other than `'single'` or `'thread'`) and on `initializeTimeoutMs <= 0`. Misconfigured callers used to silently degrade to thread behavior; now they fail loudly. Cleanup: - The `LOOPBACK_BINDS` set was duplicated between `auth.ts` and `runQwenServe.ts` (round 1 missed this). Extracted into `packages/cli/src/serve/loopbackBinds.ts` with a single `isLoopbackBind(hostname)` helper. Both files now import; drift is impossible. - `res.flushHeaders?.()` lost the optional chaining. The method is on `http.ServerResponse` since Node 1.6; our `engines` floor is 20. Tests added: - bridge: `sessionScope` validation, `initializeTimeoutMs` validation. - server: shutdown force-close timeout, SIGINT/SIGTERM listener detach-after-drain. False positives from the round 2 audit (verified and dismissed): - "EventBus nextId overflow at 2^53" — theoretical only (would require ~9 quadrillion publishes per session). No code change. - "Subscribe-during-close race" — JS is single-threaded; the close() flag is set synchronously before the loop touches state. - "Queued prompts on shutdown" — by design; documented via the promptQueue tail comment. - "10MB body parser limit" — design choice for Stage 1's in-memory buffering model; revisit if ACP streaming lands in Stage 2. - "Unbounded body read in DaemonClient.failOnError" — daemon is local in Stage 1; the threat surface for adversarial-large error bodies is the same as the daemon's other unbounded buffers. Test counts: cli serve **93** (was 89, +4), full cli **5047** (no regressions), sdk **236** (no regressions). * docs(cli): audit rounds 3 + 4 follow-ups for `qwen serve` (#3803) Two more self-review passes on PR #3889. No correctness bugs surfaced this time — round 3 found a HIGH-severity Windows-path claim that turned out to be a false positive (`path.win32.isAbsolute('/foo/bar')` returns true; verified against Node 20). Round 4 confirmed every prior decision and surfaced one latent-but-not-currently-triggered concurrency note. Changes are pure documentation + a tiny optional-chain cleanup: - Drop `?.` on `server.closeAllConnections()` in runQwenServe.ts — the method exists since Node 18.2 and our `engines` floor is 20. The optional chain dated from before round 2's force-close timer landed; clean it up. - Help text for `qwen serve --port` now documents that port 0 means "OS-assigned ephemeral port" (which the implementation has always supported but never advertised). - `defaultSpawnChannelFactory` gains a comment near the spawn site documenting the FD-budget implication (~3 FDs per session, bump `ulimit -n` for many concurrent sessions) and the `stdio: ['pipe', 'pipe', 'inherit']` choice (child stderr lands in the daemon's stderr, interleaved across sessions). Both are Stage-1-accepted; Stage 2/4+ revisit each. - Comment on the bridge's `byWorkspace`/`byId` Maps documenting the known gap that a child crashing between requests leaves a garbage SessionEntry until daemon shutdown — surfaced as a per-prompt failure when the dead session is touched, not a hang. Stage 2's in-process bridge eliminates the spawned-child failure mode entirely so this gap goes away naturally. - `EventBus.subscribe` doc-comment now states explicitly that the returned iterator is NOT safe to drive from concurrent `.next()` callers — the underlying queue isn't atomic. Daemon usage is the sequential `for await ... of` inside the SSE route, so this is safe in production. Documented so a future fan-out consumer doesn't accidentally rely on undefined behavior. False positives verified and dismissed (round 3 + 4 combined): - `path.isAbsolute('/foo/bar')` Windows breakage — `path.win32. isAbsolute('/foo/bar')` is true; verified empirically. - "Windows drive divergence" causing duplicate sessions — different drives are different on-disk paths; sessions intentionally differ. - "parseSseStream early-break leaks reader" — `for await ... break` triggers `iterator.return()` which runs the generator's `finally` that calls `releaseLock`. Standard JS semantics. - "Promise executor sync-throw fragility in requestPermission" — sync throws inside `new Promise(executor)` reject the outer promise; functionally correct, just stylistic. - "Force-close timeout test elapsed assertion flakiness" — assertion is `< 5500ms` but the natural happy-path is sub-100ms. Generous headroom; not flake-prone in practice. - "fetch reference stale after polyfill" — `globalThis.fetch.bind` captures at construction; tests inject `opts.fetch` instead of polyfilling, which is the correct pattern. Test counts unchanged (cli serve **93**, sdk **236**); typecheck + lint clean. STAGE1_FEATURES still matches every implemented route 1:1, fakeBridge in tests implements every HttpAcpBridge method. * fix(cli): PR #3889 review round 1 — critical correctness (#3803) Addresses the four critical findings from the PR #3889 reviewer pass: 1. ACP `ReadTextFileRequest.line` is 1-based per spec, but the bridge's `BridgeClient.readTextFile` was treating it as a 0-based slice index. A client asking for `{line:1, limit:2}` ("first two lines") was getting lines 2-3 — a sign-off-by-one bug that breaks every editor / SDK client following the ACP schema. Convert to 0-based via `Math.max(0, line - 1)`. The existing slice test was asserting the wrong behavior; updated to expect the spec-correct result and added a second `line:3, limit:2` case to lock in the offset. 2. `modelServiceId` was accepted by the SDK + server `POST /session` path, forwarded into `bridge.spawnOrAttach`, and then silently dropped: `doSpawn` never wired it into the agent. Callers requesting a specific model got the agent's default and no indication anything was wrong. Now `doSpawn` issues `unstable_setSessionModel` immediately after `newSession`. If the agent rejects the model id, the half-initialized session is torn down and the spawn rejects so the caller can retry cleanly instead of inheriting silent drift. Three new bridge tests: happy path, omit-when-undefined, agent-rejection cleanup. 3. The CORS middleware used `cors({ origin: (o, cb) => cb(new CORSError(...), false) })` for browser-Origin requests. `cors` flows the Error into Express's error chain; without an explicit error handler that produces a 500 + HTML body, which is misleading for what is really a deterministic 403 denial. Replace with a tiny `RequestHandler` that checks `req.headers.origin` directly and returns `403 { error: 'Request denied by CORS policy' }` JSON. Drops the `cors` and `@types/cors` dependencies — there's no other consumer in the cli package. 4. The SSE `stream_error` synthetic frame hard-coded `id: 0`, which would regress the client's `Last-Event-ID` tracker and trigger duplicate replays on reconnect. The frame is terminal and daemon-emitted — it has no place in the per-session monotonic sequence. Refactor `formatSseFrame` to omit the `id:` line when the input event has no id field, and emit `stream_error` without one. Test updated to assert `frames[1].id === undefined` while the preceding `session_update` still carries its monotonic id. Tangential cleanup: `errorMessage` now formats the SSE error body (was `err.message` only — would have shown `[object Object]` for JSON-RPC errors mid-stream, mirroring the round-1 SDK fix). Test counts: cli serve **96** (was 93, +3 modelServiceId cases); existing readTextFile slice test rewritten in place. Full typecheck + lint + suite green. * fix(cli,sdk): PR #3889 review round 2 — SSE robustness + EventBus polish (#3803) Second batch of reviewer-flagged fixes for PR #3889. Addresses 7 robustness issues across the daemon's SSE pipeline + the bus + the SDK's stream parser. Daemon SSE (`server.ts`): - SSE writes now respect backpressure. `res.write` returns false when the kernel send buffer is full; the previous code ignored that and Node accumulated payloads in user-space memory unboundedly. A slow consumer on a chatty session could balloon daemon RSS. New `writeWithBackpressure` helper awaits `drain` (or `close`/`error`) before scheduling the next write — for both per-frame writes and heartbeats. - `parseLastEventId` rejects values > `Number.MAX_SAFE_INTEGER`. With the prior `^\d+$` regex a malicious 25-digit value would parse to a number that loses precision and confuses replay comparisons. EventBus (`eventBus.ts`): - `Last-Event-ID` replay events now `forcePush` past `maxQueued`. A client reconnecting with a 1000-event gap on a subscriber whose cap is 256 was silently losing entries 257-1000 — a sign-off-by- nothing breakage of the resume contract. Live publishes still go through the normal cap (slow live consumer must be evictable); historical replay is bypassed. - `onAbort` now disposes the subscription immediately instead of only closing the queue. An aborted-but-never-iterated subscriber used to linger in `bus.subs` until the consumer drove `next()` / `return()`. New tests cover both abort-after-subscribe and already-aborted-at-subscribe paths. - `BoundedAsyncQueue.next` now checks `buf.length > 0` before shifting instead of `buf.shift() !== undefined`. The bus never pushes `undefined` today but the queue is generic — the prior pattern would mis-handle a queue whose element type legitimately includes undefined. SDK SSE parser (`sse.ts`): - Now flushes the TextDecoder on stream close. Without the final `decoder.decode()`, an incomplete multi-byte UTF-8 sequence at the tail of the last chunk was silently dropped — corrupting any frame whose JSON ended mid-character. New test feeds a stream split mid-byte through "中" (3-byte UTF-8) and asserts the character round-trips. - Frame separators now accept both `\n\n` and `\r\n\r\n`. SSE spec allows CRLF, and intermediaries (corporate proxies, some Node http servers) sometimes normalize. Frame field splitter also accepts `\r?\n`. Two new tests cover pure CRLF + mixed-LF/CRLF. Test counts: cli serve **99** (was 96, +3 EventBus); sdk daemon-sse **10** (was 7, +3). Full typecheck + lint + suite green. * docs(cli,sdk): PR #3889 review round 3 — minor + docs (#3803) Last batch from the PR #3889 reviewer pass: mostly docs + a ReDoS-tooling-silencing rewrite + a yargs-key cleanup. - `commands/serve.ts` ServeArgs interface dropped the camelCase `httpBridge` mirror; the handler now reads `argv['http-bridge']` matching the declared option name. The dual surface relied on yargs's camelCase expansion behavior — fragile if yargs config ever changes. - `DaemonClient` constructor's `baseUrl.replace(/\/+$/, '')` (which is end-anchored and linear, but CodeQL's polynomial-regex detector flags any `\/+$` pattern on attacker-controlled input) swapped for a hand-rolled `stripTrailingSlashes` loop. Same behavior, no rule trigger. - `defaultSpawnChannelFactory`'s `cwd: workspaceCwd` flow into `spawn` is the second CodeQL finding ("uncontrolled data used in path expression"). It IS user-controlled, by design — that's the Stage 1 trust model. Added a `// lgtm[js/shell-command- constructed-from-input]` suppression with a comment explaining the model and pointing at issue #3803 §11 for the Stage 4+ remote- sandbox replacement. - Stale doc comment on `createServeApp` that still listed only `/health`, `/capabilities`, `POST /session` as shipped — now enumerates all 9 routes that match §04 of the design. - Stale doc comment on `HttpAcpBridge` saying "Stage 1 buffers them in-memory; SSE wiring lands in the next PR" — SSE wiring landed in commit 41aa95094. Replaced with a description of the actual flow through EventBus + SSE. No behavior change; tests + lint + typecheck still green. cli serve still **99**, sdk **38** (was 30 before this batch — daemon-sse +3, DaemonClient +5 from rounds 1+2). Full e2e against built daemon re-verified: CORS denial returns 403 JSON (was 500 HTML), bad `modelServiceId` now causes spawn to fail with HTTP 500 (was: silent default-model substitution), `POST /session` without modelServiceId unaffected. * fix(cli,sdk): self-audit round 5+ — close orphaned EventBus + DaemonEvent.id optional (#3803) Two more fixes from a final post-review-comment audit pass on PR #3889. Both are subtle correctness gaps that fell out of the round-1 critical fixes (modelServiceId apply + SSE id-less stream_error). - In `httpAcpBridge.ts:doSpawn`, when `unstable_setSessionModel` rejects after `newSession` succeeded, we tear down the entry from `byWorkspace` + `byId` (round 1 fix) but did NOT close the EventBus we'd just constructed for that entry. The agent could have published a session_update notification during init that queued in the (now unreachable) bus's ring buffer; without an explicit close the bus + buffer linger until the next GC cycle. Bounded leak (1 bus per failed spawn × 1000-event ring) but cleaner to close it. New regression test exercises the retry path after a model-rejection failure to lock in that we don't reuse the orphan and that subscribers on the fresh session see an empty iterator on immediate abort. - SDK `DaemonEvent.id` is now `id?: number` instead of `id: number`. The round-1 SSE fix made the daemon emit `stream_error` frames *without* an `id:` line so they don't pollute the per-session monotonic sequence. The SDK parser correctly returns `undefined` for the missing field, but the type still advertised `id: number` — TypeScript consumers persisting `lastSeenId = event.id` would accidentally store `undefined`. Made the field optional and added a doc comment instructing consumers to skip frames without an id. Plus one more false-positive verified and dismissed: - "writeWithBackpressure Promise double-settle race": the auditor flagged that `res.write(chunk, callback)` could fire its callback after the synchronous `ok=true` resolve. Verified harmless — Promise double-settle is a no-op, the callback only rejects on error (caught separately by `res.on('error', cleanup)`), and multiple parallel writes register independent listener sets that each remove their own pair after firing. Test counts: cli serve **100** (was 99, +1 retry-after-model-rejection regression). SDK unchanged at 239. Full typecheck + lint + suites green; flow re-verified end-to-end. * fix(cli,sdk): PR #3889 review round 4 — child-crash recovery + SSE/permission/SSE polish (#3803) Fourth and final batch of reviewer-flagged fixes for PR #3889. 14 inline threads addressed, plus 8 spam threads up for resolution. Critical correctness: - `eventBus.test.ts`'s ring-eviction test wrapped its assertion in a `void (async () => { … })()` IIFE that returned synchronously to vitest — the inner `expect` could fail without ever surfacing. Hoisted to a top-level `await` so the harness actually waits and a broken eviction would now fail loudly. - `runQwenServe.ts handle.close()` is now idempotent. Concurrent callers (test harness + signal handler firing simultaneously, explicit caller + finally-block fallback) used to each construct a new shutdown promise, arm a fresh force-close timer, and call `bridge.shutdown` redundantly. Cache a single `closePromise`; repeat calls return it. New test exercises 3 overlapping callers + a post-settle call → exactly one bridge.shutdown. - `POST /permission/:requestId` now rejects `outcome.selected` with an empty `optionId`. The string-typeof check passed `""` through; bridge would forward an opaque "unknown option" error from the agent. Tighten the validator + add a 400 test. - `denyBrowserOriginCors` now has explicit unit tests (3 cases: Origin-bearing GET → 403 JSON, no-Origin GET → 200, Origin-bearing POST → 403 + bridge untouched). The CSRF defense was previously implicit-only. Channel-exit recovery: - `AcpChannel` interface gains an `exited: Promise<void>` that resolves on either planned `kill()` or unexpected child crash. Bridge subscribes via `channel.exited.then(...)`: if the entry is still in `byId` when exit fires (i.e. unexpected crash), it cancels pending permissions, publishes a `session_died` event so SSE subscribers get notified, closes the bus, and removes the entry from `byWorkspace`/`byId`. Without this, a crashed child used to leave its `SessionEntry` stuck — under `sessionScope:'single'` (default) the whole workspace was unreachable until daemon restart. - `defaultSpawnChannelFactory` now wires `child.once('error', …)` in addition to `'exit'`. Without an `error` listener Node treats an async spawn failure (ENOMEM, EACCES, …) as an unhandled error and crashes the daemon. - Two new bridge tests: `crash()` simulates an unexpected exit → asserts `session_died` event + entry removed + retry spawns a fresh child; planned shutdown asserts the cleanup handler no-ops when the entry is already gone (no double-publish). SSE robustness: - SDK `parseSseStream` now calls `reader.cancel()` (not just `releaseLock`) in its `finally`. Early-break consumers were leaving the underlying HTTP body stream open; cancel propagates upstream so the connection drops promptly. New test asserts the underlying ReadableStream's `cancel()` runs. - SDK `parseSseStream` accepts `data:` (no space after colon) AND multiple `data:` lines per frame (joined by `\n` per spec). Two new tests cover both cases. - SDK `DaemonClient.subscribeEvents` now validates response Content-Type before delegating to the parser. A misconfigured proxy returning 200 + JSON was silently producing zero events; now throws `DaemonHttpError` with the actual mime type. - Daemon SSE route's initial `retry: 3000` write now `.catch(()=>{})`s. A socket that errors before the first write would have surfaced as an unhandled rejection. Documentation (deferred items now noted in code): - `EventBus.publish` ring shift is O(n) when full. Comment notes the deferral; circular-buffer refactor only if profiling flags it. - SSE heartbeat doesn't detect dead connections without TCP RST. Comment notes Stage 2 may add an explicit idle timeout. - `defaultSpawnChannelFactory` won't run a `.ts` entry directly — `npm run dev` users must build first. Comment in the spawn site. Test counts: cli serve **107** (was 100, +7), SDK daemon **42** (was 38, +4). Full typecheck + lint + suite green. * test(integration): qwen serve daemon — routes + streaming + recovery (#3803) Persists the e2e validation of every PR #3889 fix as vitest integration tests under `integration-tests/cli/`. Two files split by auth requirement: `qwen-serve-routes.test.ts` (18 cases, no LLM credential needed) - Bearer auth timing-safe compare: right token / wrong-same-length / wrong-shorter / missing / Basic-scheme. - CORS browser-Origin denial: GET-with-Origin → 403 JSON; no-Origin → 200. - Capabilities envelope: all 9 Stage 1 features advertised in order. - POST /session validation: relative cwd → 400; two parallel POSTs same workspace coalesce; bad modelServiceId tears down half-init. - POST /permission/:requestId validation: empty optionId → 400; missing optionId → 400; valid vote on unknown id → 404. - SDK SSE Content-Type guard: throws DaemonHttpError when upstream returns 200 + JSON. - Last-Event-ID strict parsing: malformed value accepted but ignored (`'1abc'` doesn't get parsed as 1). - Cancel idempotent + listWorkspaceSessions returns the live session. `qwen-serve-streaming.test.ts` (3 cases, gated by SKIP_LLM_TESTS) - Real `qwen --acp` child SIGKILL → daemon publishes `session_died`, removes the entry from `byWorkspace`/`byId`, next createOrAttachSession spawns fresh. Uses `pgrep -P` to locate the daemon's direct child by PID. - Two SSE subscribers + a tool requiring permission: both observe the same `permission_request` requestId; two concurrent POST votes resolve as exactly one 200 + one 404 (first-responder wins). - SSE reconnect with `Last-Event-ID: N` after consuming N frames yields events with `id > N` from the bus's replay ring. Both files spawn `node packages/cli/dist/index.js serve --port 0 --token …` per `beforeAll` and clean up in `afterAll`. Use the existing `@qwen-code/sdk` alias the integration-tests vitest config already wires to the built SDK bundle. Run with the existing `npm run test:integration:cli:sandbox:none` (or any of the integration-tests target). The streaming file is skip-able via `SKIP_LLM_TESTS=1` for environments without auth. Verified locally: 18/18 routes pass in ~6.8s; 3/3 streaming pass in ~23s against a real model. * fix(cli): PR #3889 review round 5 — claude-opus-4-7 audit (#3803) Seven new substantive findings from a `/qreview` pass on PR #3889. Six real bugs + one type-safety gap; all addressed. Critical correctness: - **EventBus replay overflow + eviction race**. Round 4's `forcePush` for `Last-Event-ID` replay bypassed the per-subscriber cap, but `BoundedAsyncQueue.push`'s cap check was `buf.length >= maxSize` — so the very next live publish saw the inflated buf, rejected, and triggered the `client_evicted` terminal frame. Concrete sequence the audit walked through: client reconnects after 300+ events, replay force-pushes 300 entries, next live event evicts them. Defeats the resume contract. Fix: track force-pushed items separately (`forcedInBuf` counter). `push()` cap is now on `(buf.length - forcedInBuf)`. `next()` decrements `forcedInBuf` as the consumer drains (force-pushed entries are FIFO at the front of `buf` since `forcePush` only runs at subscribe time, before any live `push`). Two new regression tests: (1) live publish after a >cap replay does NOT evict; (2) eviction triggers only after the LIVE backlog (excluding replay) hits the cap. Performance + UX: - **Eager express import on every `qwen` invocation**. The `serve` subcommand statically imported `../serve/index.js`, which transitively pulled express + body-parser + qs into cold-start path of every CLI invocation (interactive, mcp, channel, etc). ~50ms tax on the 99% of invocations that never run `serve`. Defer to dynamic `import()` inside the handler; types are still imported for the builder shape. - **Middleware order**: `express.json({limit:'10mb'})` ran BEFORE `bearerAuth`. Unauth POST got full JSON.parse before 401. Trivial DoS amp on non-loopback deployments. Reorder so auth + Host allowlist + CORS run first; body parser runs only for requests that pass the gate. - **`sendPrompt` no AbortSignal**. A stuck/dead child poisons the per-session FIFO; HTTP client disconnect didn't propagate so daemon CPU stayed tied up. `HttpAcpBridge.sendPrompt` now accepts `signal?: AbortSignal`. Route handler creates an AbortController and wires `req.on('close')` to abort it. On abort, bridge sends an ACP `cancel` notification; the agent winds down → prompt resolves with `stopReason: 'cancelled'` → next queued prompt can run. New test exercises real socket disconnect via `node:http` (jsdom AbortSignal isn't compatible with undici). Security: - **`--token` on argv leaks via `/proc/<pid>/cmdline`**. Default Linux permissions allow any local user to `ps auxww | grep 'qwen serve'` and read the bearer token. Daemon now warns to stderr when `--token` is used and recommends `QWEN_SERVER_TOKEN` (which uses `/proc/<pid>/environ`, owner-only). - **Token inherited by spawned `qwen --acp` child**. `env: process.env` in `defaultSpawnChannelFactory` passed `QWEN_SERVER_TOKEN` into the child. The agent runs user-supplied prompts with shell-tool access — leaving the token in env enables prompt-injection-into-self-call attacks. Strip `QWEN_SERVER_TOKEN` from the child's env before spawn. Robustness: - **`BridgeClient` publishes lacked try/catch on closed bus**. `BridgeClient.requestPermission` and `sessionUpdate` called `entry.events.publish(...)` directly. Shutdown closes the bus *before* killing the channel, so a late `sessionUpdate` from a not-yet-dead agent throws. For `requestPermission` the throw was particularly bad: `registerPending` had already mutated the daemon-wide map, so the throw left the registry inconsistent. Cleaner fix: make `EventBus.publish` a no-op on closed bus (returns undefined) instead of throwing. Removes the need for try/catch at every call site and keeps state consistent. Type safety: - **`STAGE1_FEATURES: readonly string[]`** widened the inferred tuple-of-literals back to `string[]`. A typo'd feature (`'sesion_set_model'`) compiled silent. Drop the annotation + add `as const`; export `Stage1Feature` literal-union for SDK-side `features.includes(...)` checks to narrow against. Test counts: cli serve **112** (was 105, +7); SDK unchanged at 243. Full typecheck + lint + suite green. * fix(cli): PR #3889 review round 6 — gpt-5.5 audit (#3803) Four new findings from a `/review` pass on PR #3889. Three real correctness bugs + one Stage 1 design-gap documentation. Critical: - **`[::1]` bind ENOTFOUND**. `LOOPBACK_BINDS` accepts `[::1]` for the auth gate, but `app.listen()` wants the unbracketed `::1`; `qwen serve --hostname [::1]` passed the gate and then crashed with ENOTFOUND. Strip brackets at bind-time, keep them for the printed URL. New test asserts the listener actually binds when the operator types `[::1]`. - **`sendPrompt` no transport-close detection**. The chained `entry.connection.prompt()` could hang indefinitely if the `qwen --acp` child wedged or the underlying stream broke mid-flight (the SDK's pending JSON-RPC promise never delivers a response). Because the per-session FIFO tail derives from that promise, a single stuck prompt poisoned every subsequent caller for the same session. Round 4's `channel.exited` is already wired to remove the entry, but the in-flight prompt itself wasn't racing it. Fix: race `entry.connection.prompt(...)` against `entry.channel.exited` inside `sendPrompt`; when the transport closes mid-flight, the prompt fast-fails with a descriptive error rather than hanging the queue. New test exercises this via a stuck fake agent + manual `crash()`. Real correctness: - **`spawnOrAttach` attach-path ignored modelServiceId**. Under `sessionScope:'single'` (default) a client requesting a specific model on attach got `attached:true` while continuing to use whatever model the shared session already had — a silent contract drift. Refactor the per-session `unstable_setSessionModel` call into a shared `applyModelServiceId(entry, modelId)` helper that runs both at create-time (existing path) AND on attach-with-model. Same helper publishes the `model_switched` event so cross-client UIs see the change. New tests cover apply-on-attach and the omit-modelServiceId-on-attach no-op case. Stage 1 design: - **`BridgeClient.{readTextFile, writeTextFile}` raw fs proxy**. The audit flagged that the bridge reimplements file I/O with `fs.{read,write}File` instead of delegating to core's filesystem service — divergence on BOM handling, non-UTF-8 encodings, original line endings. Wiring core's FileSystemService through the bridge is invasive (constructor dep, reaches into core's runtime), and Stage 2's in-process bridge eliminates the proxy entirely. Documented as a known gap with the exact user-visible scenarios; no behavior change in this PR. Test counts: cli serve **116** (was 112, +4); full cli **5070** (was 5066, +4); SDK unchanged at 243. Lint + typecheck green. * fix(cli): PR #3889 review round 7 — match CodeQL suppression to fired query (#3803) Single new CodeQL alert (#201) on `workspaceCwd → spawn({cwd})`. The round-3 suppression I added (`lgtm[js/shell-command-constructed-from- input]`) referenced the WRONG query id — the alert fires the `js/path-injection` query, not the shell-command one. The misnamed suppression also lived 30+ lines above the actual flagged spawn call, out of CodeQL's annotation scope. Move the suppression onto the line immediately preceding the spawn call and use the matching query id `js/path-injection`. The function-level comment block above still documents the Stage 1 trust model rationale (operator-controlled cwd is intentional; agent runs as same UID with shell-tool access; Stage 4+ remote sandbox replaces this factory entirely). Defense-in-depth note added: `workspaceCwd` is canonicalized via `path.resolve()` in `spawnOrAttach` before reaching this factory, and spawn's `cwd` doesn't pass through any shell. No behavior change. Test counts unchanged (cli serve 116, full cli 5070). * fix(cli): self-audit round 8 — concurrency + listener leak + IPv6 + CodeQL honesty (#3803) Multi-round audit pass on PR #3889 commits 5/6/7. Four findings, one real high-severity. High: - Attach-with-modelServiceId had no error recovery and no FIFO. If the agent rejected the new model on attach, `applyModelServiceId` threw, the route 500'd, and the existing session kept running the OLD model — caller sees a 500 with no easy way to detect the state. Worse, two simultaneous attaches with different modelServiceIds would race the `unstable_setSessionModel` calls with no serialization. Add a per-session `modelChangeQueue` (parallel to `promptQueue`); `applyModelServiceId` now chains through it. On failure publishes a `model_switch_failed` event to the bus so OTHER attached clients can see what happened (the failed-caller still gets the 500). Two new bridge tests cover rejection observability + concurrent FIFO. Medium: - `sendPrompt` was adding a `.then` listener to `entry.channel.exited` PER CALL, accumulating linearly with prompt count over a session's lifetime. ~hundreds of bytes per prompt; trivially observable on chatty long-running sessions. Cache a single `transportClosedReject` lazy-init promise on SessionEntry; every subsequent prompt's race uses the same promise. Low: - `[host]:port` IPv6 syntax in `--hostname` was being naively bracket-stripped to `host]:port`, which Node rejects with a cryptic ENOTFOUND at startup. Tighten the strip to only accept pure `[addr]` forms; reject the URL-with-port form upfront with a useful error pointing at `--port`. - `BoundedAsyncQueue.forcedInBuf` invariant comment was wrong: it claimed force-pushed items were always at the front of `buf`, but the eviction-frame path force-pushes at the BACK. The miscount that follows is functionally inert (`close()` blocks the next cap check), but the comment was actively misleading. Rewrote it to honestly describe both call paths and explain why the eviction-case miscount is harmless. CodeQL honesty: - Round 7's `// lgtm [js/path-injection]` comment doesn't actually suppress alerts — GitHub Code Scanning ignores inline `lgtm` annotations (LGTM.com retired 2021). Replaced the misleading `// lgtm` line with a NOTE block stating the constraint explicitly: suppression requires UI dismissal or `.github/codeql/codeql-config.yml`, both out of scope for a code-only PR. The function-level comment that explains the Stage 1 trust model rationale stays. Test counts: cli serve **119** (was 116, +3); full cli **5073** (was 5070, +3, no regressions). * fix(cli): self-audit round 9-10 — reject empty-bracket --hostname (#3803) Final fix from rounds 9-10 of the audit chain. One real concern + three nice-to-have test gaps that the code already handles correctly. - `--hostname '[]'` (empty brackets) used to slip past the bracket validator: `slice(1, -1)` produced `''`, which Node interprets as "bind to all interfaces". An operator typing `[]` clearly meant something specific, not wildcard. Reject the empty-inner case upfront with the same useful error as the `[host]:port` case. New test asserts the rejection. Round 10 ran a clean convergence pass and signed off: - Cross-cutting state invariants (byWorkspace, byId, inFlightSpawns, pendingPermissions, plus all per-entry queues and caches) — all mutations paired and async holes safe. - All test names match assertions. - Public type surface clean (DaemonEvent.id?, Stage1Feature CLI-only, DaemonClientOptions.fetch shape correct). - Production paths verified: non-executable child times out at 10s init, multiple-daemon EADDRINUSE rejects cleanly via `server.once('error', reject)`. - Three "missing test" notes (transportClosedReject cache sharing, full subscribe-publish-evict sequence, modelChangeQueue failure isolation) are diagnostic gaps — the code paths are correct and covered by adjacent tests. Test counts: cli serve **120** (was 119, +1 empty-bracket); SDK unchanged at 243. * docs(cli): note SSE single-line data emit vs multi-line parser (#3803) formatSseFrame emits the payload as a single `data:` line. The EventSource spec also allows a frame to span multiple `data:` lines (joined by `\n` on parse), and the SDK receive-side parser handles that variant — but we never emit it because the JSON payload has no embedded newlines after JSON.stringify. Document the in/out asymmetry so future readers don't mistake the absence of newline splitting for a bug. Closes review thread AMgP0. * fix(cli,sdk): close 11 #3889 review threads — race + leak + IPv6 + SSE Critical correctness: - setSessionModel now serializes through `entry.modelChangeQueue` so POST /session/:id/model can't race with the attach-with-different- modelServiceId path that already chains on the same queue. Without this two concurrent model changes interleave and the published `model_switched` event may not match the agent's actual model. - POST /session reaps the spawned child when the client disconnected during the 1-3s spawn window (`req.aborted && !session.attached`). Without this, every aborted request leaks one orphan child the daemon can't address by sessionId. Attached sessions skip the kill — another client legitimately owns them. - spawnOrAttach refuses dispatch once shutdown has started (`shuttingDown` flag set at the top of `shutdown()`). Late-arrivers on already-established HTTP connections that pass `server.close`'s rejection of NEW connections would otherwise spawn children the shutdown snapshot already missed. Late re-check inside `doSpawn` (after `connection.newSession` resolves) catches the in-flight case and tears down the half-built channel. - sendPrompt early-aborts pre-aborted callers before queuing — saves a queue trip and gives a clean trace for retry-after-abort flows. Defensive: - parseSseStream caps the unread buffer at 16 MiB. Without this, an upstream that returns non-SSE (misconfigured proxy, long-lived non-streaming body) feeds `buf` until the consumer OOMs. - parseSseStream now accepts an optional AbortSignal that is checked at each iteration, and DaemonClient.subscribeEvents forwards `opts.signal` into it. Post-200 aborts now actually stop iteration instead of buffering frames until the upstream closes. - DaemonClient.fetchTimeoutMs (30s default) wraps every short-poll method (health/capabilities/createOrAttachSession/listWorkspaceSessions/ setSessionModel/cancel/respondToPermission) with `AbortSignal.timeout`. Composes with caller-provided signals via `AbortSignal.any`. `prompt` is intentionally exempt (long-lived: model + tool turns can take minutes); `subscribeEvents` is exempt (long-lived SSE). - New `bridge.killSession(sessionId)` API mirrors the shutdown teardown for a single session — used by POST /session orphan-reap above and exposed for future routes that need targeted cleanup. Stale + cosmetic: - Bridge map header comment said "no path that removes a session... when its child process crashes between requests" — out of date since the `channel.exited` cleanup landed in an earlier audit round. Rewritten to describe the actual cleanup chain. - runQwenServe now wraps IPv6 hostname literals in brackets when building the URL (`http://[::1]:4170` not `http://::1:4170`). The bracket-stripping logic on `listenHostname` already handled `app.listen()` correctly; this fixes the printed/copy-paste URL. - Dead `mode: ServeMode` variable in serve.ts removed (the runQwenServe call hardcodes `mode: 'http-bridge'`); the warning condition is now inlined. Test plan: - `vitest run` cli/serve: 120/120 + 49/49 (httpAcpBridge) pass - `vitest run` sdk-typescript daemon: 42/42 pass - tsc --build packages/cli packages/sdk-typescript: clean - ESLint: clean * chore(lint): allow mime/lite in import/no-internal-modules (#3803) `packages/core/src/utils/fileUtils.ts` and its test import `mime/lite`, which is mime@4's documented public sub-export (a smaller bundle that omits the legacy mime DB) — not an internal module. The rule has been flagging these on PR CI runs even though main's CI happens to pass (likely stale-cache vs fresh-install timing). Add `mime/lite` to the allowlist so lint is consistent across main and PR runs. * fix(cli,sdk): close 14 review threads — env whitelist + races + Windows tests + structured errors (#3803) Critical correctness: - registerPending now resolves orphaned permissions as cancelled when the entry has been torn down between the agent's `requestPermission` decision and the bridge handler firing. Previously the permission would hang the agent forever (killSession's pendingPermissionIds iteration didn't include the just-orphaned id, shutdown's clear() dropped it without resolving). - Workspace key now goes through `realpathSync.native` (with a resolved-but-uncanonicalized fallback for non-existent paths) so case-insensitive filesystems (macOS APFS, Windows NTFS) don't silently degrade `sessionScope: 'single'` into "one session per spelling". Matches how `config.ts` / `settings.ts` / `sandbox.ts` resolve workspace paths. - killChild gets a hard 10s deadline after SIGKILL so a child stuck in uninterruptible sleep (D-state, e.g. NFS read on a dead server) can't block `bridge.shutdown()`'s `Promise.all` forever. `SHUTDOWN_FORCE_CLOSE_MS` in `runQwenServe` only covers `server.close()` — without this hard kill, daemon shutdown hangs. - setSessionModel now races the agent call against `transportClosedReject` and wraps in `withTimeout`, matching what `sendPrompt` and `applyModelServiceId` already do. Without the race, a wedged child blocks `POST /session/:id/model` forever. Also publishes a `model_switch_failed` SSE event on rejection so passive subscribers see the failure (matches `applyModelServiceId`). - shutdown() now awaits `inFlightSpawns` so the late-shutdown re-check inside `doSpawn` finishes its half-built channel teardown before `bridge.shutdown()` resolves. Without the await, `runQwenServe.close()` returns and `process.exit(0)` is queued before the orphan tears itself down, surfacing a stderr error AFTER the daemon claimed graceful shutdown. - sendPrompt re-checks `signal.aborted` immediately after `addEventListener` so a microsecond-window synchronous abort that fires between the early-exit check and listener registration still triggers the agent `cancel` notification. Security: - `defaultSpawnChannelFactory` now passes an *allowlisted* environment to the spawned `qwen --acp` child instead of `{ ...process.env }` with `QWEN_SERVER_TOKEN` deleted. The agent runs user-supplied prompts with shell-tool access; anything in its env (OPENAI/ ANTHROPIC/DASHSCOPE keys, AWS/GCP credentials, DB passwords, OAuth tokens) is reachable by prompt injection. Allowlist covers HOME/PATH/USER/LOGNAME/LANG/LC_*/TMPDIR/TEMP/TMP/NODE_PATH plus Windows essentials (SYSTEMROOT/USERPROFILE/APPDATA/...). The explicit `delete childEnv['QWEN_SERVER_TOKEN']` stays as defense-in-depth — anyone grepping for the token name finds the scrub explicitly named. Observability: - 5xx responses now carry structured `code` and `data` fields when the underlying error has them (JSON-RPC errors from the ACP SDK forward as `{code, message, data}`). Without this, every distinct failure (quota / rate-limit / auth / crash) collapses to the same opaque "Internal error" string at the client. - 5xx errors log to stderr (via `writeStderrLine`, not `console.error`, to keep the no-console lint rule happy). Stop-gap until structured access/error logging lands. - Eviction frame on EventBus subscriber overflow no longer consumes a `nextId` slot. The synthetic frame burning a sequence id meant healthy subscribers saw gaps (3 → 5) that the resume ring couldn't back-fill — silently broke the `BridgeEvent.id` "monotonic per- session" contract. `BridgeEvent.id` is now optional on the type to make the absence honest. Same pattern as `stream_error`. Cross-platform: - httpAcpBridge.test.ts now derives expected paths via `path.resolve(path.sep, 'work', 'a')` (factored out as `WS_A`/ `WS_B`/`SESS_A` constants) instead of hardcoded POSIX literals like `/work/a`. On Windows `path.resolve('/work/a')` returns `D:\work\a` so the literal expectation drifted; the bridge's internal canonicalization to that form was correct, the tests were wrong. Fixes 3 Windows CI matrices that have been red since the PR opened. Compatibility: - `DaemonClient.fetchWithTimeout` now feature-detects `AbortSignal.timeout` and `AbortSignal.any` with polyfills, so the SDK actually works on its declared minimum runtime (Node >=18.0.0). `AbortSignal.any` was added in Node 20.3 — without the fallback every non-streaming call throws on Node 18.0–20.2. Documentation: - `cancelSession` now explicitly documents that cancel only affects the currently active prompt; previously POST'd queued prompts continue to execute. Multi-prompt queueing is a daemon-introduced behavior (not in ACP spec), so the contract for queued prompts is ours to define and was previously implicit. - Removed misleading "still reliable on Node 20" comment around `req.aborted` and switched the orphan-cleanup signal to `res.writable` — the right "can we still send a response to this client?" check (`req.destroyed` is too eager: clients close their writable end after sending the body even though they're still listening for the response). * fix(cli): close 3 more review threads — case-insensitive Host, trim token, sliceLineRange (#3803) - hostAllowlist now lowercases the Host header before comparison. Per RFC 7230 §5.4 Host is case-insensitive; Express normalizes header *names* but not values, so a Docker proxy that capitalizes the hostname (`Host: Localhost:4170`) or a platform with case-preserving DNS (`HOST.docker.internal`) was getting 403 with an exact-match compare. - `runQwenServe` now `.trim()`s the token from both `--token` and `QWEN_SERVER_TOKEN`. Common gotcha: `export QWEN_SERVER_TOKEN=$(cat token.txt)` keeps the file's trailing `\n`, so the hashed-then- compared token never matches what well-behaved clients send. Every request returns the generic 401, no breadcrumb pointing at the whitespace, operators chase ghosts. - `BridgeClient.readTextFile` partial-read path no longer `content.split('\n')`s the entire file. New `sliceLineRange` walks `indexOf('\n', …)` forward only to the end-of-range boundary and returns a single substring. For a 100 MB file with `{line: 1, limit: 2}` this avoids a ~100 MB `String[]` allocation. * fix(sdk): close 2 #3889 polyfill leaks — abortTimeout + composeAbortSignals Two copilot review threads on commit 11567a43c's AbortSignal polyfill code: - `abortTimeout` polyfill scheduled `setTimeout` but never cleared it. Even after the awaited fetch resolved, the pending timer kept the event loop alive until it fired; on a heavily-used client the per-call timers accumulated. Fix: `.unref()` the handle (so a fast-resolving fetch doesn't pin the loop) AND clear it on the controller's `abort` event (so the composed-signal-aborted-first path also drops the timer). Defensive `typeof handle.unref` so the polyfill works in any runtime that returns a non-NodeJS Timeout shape. - `composeAbortSignals` polyfill added an `abort` listener to every input signal but never removed them. Long-lived caller signals (e.g. a session-scope cancel signal that lives for the whole SDK client) accumulated one listener per SDK call — slow leak that retained the closure + controller of every prior call. Fix: track per-input cleanups in an array, detach all on the first abort (whichever input fires) AND on the composed controller's own abort path (defense-in-depth for callers that abort the composed signal independently). Both leaks only fire on the polyfill path — runtimes with native `AbortSignal.timeout` / `AbortSignal.any` (Node 20.3+) take the early-return path and bypass the leak surface entirely. 29/29 DaemonClient.test.ts pass; tsc + ESLint clean. * fix(cli,sdk): close 13 deepseek review threads — error handling + race + log noise (#3803) Correctness: - `applyModelServiceId` now races against `transportClosedReject` like `setSessionModel` and `sendPrompt` already do, so a child crash during attach-with-different-model fails fast instead of waiting the full 10s `withTimeout`. - `POST /session` disconnect guard now handles the `attached` case: previously `!res.writable && session.attached` fell through to `res.json` and threw EPIPE through Express's default handler. - `POST /session/:id/prompt` now drops `AbortError` silently. When the HTTP client closes mid-prompt the bridge re-throws as `AbortError`; routing it through `sendBridgeError` produced a noisy 500 + stderr stack trace that under active use generated dozens of misleading log lines per second. - `POST /session/:id/prompt` now rejects empty arrays (`[]`) and non-object elements with a 400 instead of letting the ACP SDK surface 500s on degenerate input. - `readTextFile` rejects `limit <= 0` up front (previously `sliceLineRange` hit the `end < start` path with surprising results). - `inFlightSpawns` tracks ALL `doSpawn` promises now, not just single-scope ones. Under `thread` scope, `shutdown()` previously resolved before in-flight spawns finished their child cleanup, surfacing stderr noise after the daemon claimed graceful shutdown. Use a unique `${workspaceKey}#${randomUUID()}` key per thread-scope spawn so simultaneous spawns don't collide. Shutdown ordering: - The 5s force timer is now armed AFTER `bridge.shutdown()` resolves, so it only races `server.close()` (the listener drain) — not the bridge's own 10s `KILL_HARD_DEADLINE_MS` child cleanup. The earlier arrangement could resolve this promise while the bridge was still killing children, orphaning anything not yet at the deadline. Express error handling: - Final 4-arg error middleware catches `express.json()`'s `SyntaxError` on malformed bodies and returns JSON `400` instead of Express's default HTML page (which trips SDK clients that expect a JSON body on every response). - SSE `res.on('error')` handler now logs the error before cleanup, so operators get a breadcrumb for flaky-network triage instead of silent disconnect. Performance: - `ALLOWED_CHILD_ENV_KEYS` moved to module scope so the 22-element Set is allocated once at load instead of rebuilt on every `defaultSpawnChannelFactory` call. (Renamed from `ALLOWED_ENV_KEYS` for clarity.) Documentation: - `canonicalizeWorkspace` now explicitly notes the cross-module contract with `config.ts`/`settings.ts`/`sandbox.ts`. A shared utility was considered but deferred — the call sites use slightly different fallback policies and Stage 2 in-process collapses the bridge into core, removing the bridge-side path resolution entirely. Tests: - Two new DaemonClient tests exercise `fetchWithTimeout`'s AbortSignal.timeout / composeAbortSignals polyfill paths against a never-resolving fetch promise. Previously every test used `recordingFetch` with synchronous resolution, so those polyfills shipped untested — a logic error there would only surface when a real daemon became unresponsive. * docs(serve): close §08 Stage 1 doc gap — user guide + protocol reference + DaemonClient example (#3803) Stage 1 of issue #3803 §08 budgeted "Documentation + examples + e2e tests" as the closing 1d task. The e2e tests landed (22 cases under integration-tests/cli/), the docs did not. After merge, anyone who discovers `qwen serve` via `qwen --help` had nowhere in-repo to read about it — the only complete description lived on the PR page itself. This commit fills that gap with three complementary docs and a README mention: - `docs/users/qwen-serve.md` — operator-facing quickstart: 5-step curl walkthrough (start → /health → /capabilities → /session → /prompt → /events), CLI flag table, default-deployment threat model summary, and a pointer to the orchestrator-shaped multi-session future. - `docs/developers/qwen-serve-protocol.md` — full HTTP protocol reference: per-route request/response shapes, auth contract, error envelope, SSE frame format and event-type table, Last-Event-ID reconnect semantics, environment variables, source layout. - `docs/developers/examples/daemon-client-quickstart.md` — TypeScript end-to-end snippet with the SDK's DaemonClient: capabilities probe, spawn-or-attach, subscribe-before-prompt event handling, reconnect via Last-Event-ID, first-responder permission voting, shared-session collaboration between two clients, auth, cancel. - README.md — "Daemon mode" added to the 5-way usage list + a short section under Usage with three doc links. - `docs/users/_meta.ts` and `docs/developers/_meta.ts` — sidebar entries for the new pages. No code changes; no test changes. * docs(serve): close 8 deepseek doc-review findings (#3803) Inline doc review on the Stage 1 doc set caught real issues: - `qwen-serve-protocol.md`: `session_died` (and `client_evicted`, `stream_error`) now explicitly marked as terminal — SSE stream closes after the frame; subscribers should reconnect via POST /session for `session_died`. - `qwen-serve-protocol.md`: documented coalesced spawn failure path — when the underlying spawn fails, all coalesced callers receive the same error and the in-flight slot is cleared so a follow-up call can retry. - `qwen-serve-protocol.md`: clarified the `modelServiceId` (back-end provider, picked at session create) vs `modelId` (model within an already-bound service, picked via POST /session/:id/model) distinction, and explained why `/capabilities`'s `modelServices` array is always `[]` in Stage 1. - `qwen-serve-protocol.md`: typo "Re-races" → "Races" on the model switch description. - `qwen-serve.md`: reordered quickstart so SSE subscribe (now step 4) comes before the prompt POST (now step 5). Previously, step 4's blocking prompt resolved before step 5's `curl -N` was open, so readers following the steps verbatim never saw a streaming event. Also expanded the event-types paragraph to call out which frames are terminal. - `daemon-client-quickstart.md`: closed a TOCTOU race in the example — `sendPrompt` fired before the SSE handshake completed, so fast-starting agents could emit events into the ring before the iterator was actually pulling. Pass `lastEventId: 0` so the daemon's replay buffer covers the gap; comment in the example explains the rationale. - README.md: "Loopback bind has no auth" → "no auth by default" (since the user can opt into bearer auth on loopback by setting `QWEN_SERVER_TOKEN`). * fix(cli,sdk,docs): close 21 review threads — env regression + races + doc accuracy (#3803) CRITICAL regression fix: - Child env scrub flipped from allowlist back to denylist (just QWEN_SERVER_TOKEN). The earlier allowlist was overzealous: it dropped OPENAI_API_KEY / ANTHROPIC_API_KEY / GEMINI_API_KEY / QWEN_* / DASHSCOPE_API_KEY / custom modelProviders[].envKey, all of which the agent legitimately needs to authenticate to the LLM. Daemon-mode users with env-only auth would start the daemon, attach a session, then watch every prompt fail with auth errors. Threat- model rationale documented at the call site: prompt-injected shell tools can already read ~/.bashrc, ~/.aws/credentials, etc., so env passthrough isn't the security boundary; the user-as-trust-root is. QWEN_SERVER_TOKEN stays scrubbed to prevent agent → its own daemon escalation. Other code fixes: - doSpawn no longer tears down the session when create-time model switch fails. The session is still operational on the agent's default model; tearing it down left the caller with a 500 and no sessionId to retry against. The model_switch_failed SSE event is the visible signal; caller can retry via POST /session/:id/model once they have the sessionId. - doSpawn now uses applyModelServiceId for the create-time model switch (was raw conn.unstable_setSessionModel + withTimeout). The helper races against transportClosedReject too, so a child crash during model switch fails fast instead of consuming the full init timeout. - sendPrompt's abort handler now calls cancelPendingForSession before the ACP cancel notification (matching cancelSession). A client disconnecting mid-permission was leaving the agent stuck waiting on a vote that no SSE subscriber would ever cast. - shutdown() and killSession() now publish a terminal `session_died` SSE event before closing the bus. Previously the channel.exited handler's "byId.get(...) !== entry" guard short-circuited (entry already removed), so SSE subscribers couldn't tell daemon shutdown from a transient network error. - Express error middleware now special-cases `status: 413` (EntityTooLargeError from body-parser when a request exceeds the 10 MB JSON limit) and returns a JSON 413 instead of a misleading 500. - /health is now registered BEFORE bearerAuth middleware, so liveness probes work without credentials when the daemon was started with --token. CORS deny + Host allowlist still apply. - SSE writes serialize through a per-connection chain so the heartbeat interval can no longer interleave with the main event- write loop. Two concurrent res.write calls would otherwise bypass the backpressure guard and could interleave bytes between SSE frames on the wire. SDK: - abortTimeout / composeAbortSignals exported for direct unit testing. The existing test claimed to cover the polyfill paths via subscribeEvents, but subscribeEvents calls _fetch directly (not fetchWithTimeout), so composeAbortSignals never ran in the test. New tests exercise the helpers directly across native + polyfill runtimes. Doc accuracy fixes: - daemon-client-quickstart.md: createOrAttachSession({ cwd: ... }) → ({ workspaceCwd: ... }) (SDK type), client.sendPrompt → prompt, client.cancelSession → cancel. The example wouldn't typecheck. - qwen-serve.md: "binds one workspace" claim removed — a single daemon hosts sessions for any cwd the caller passes; the per-instance constraint is per-user / scale, not per-workspace. Auth verification example switched from /health to /capabilities (since /health is now exempt from bearer auth). - qwen-serve-protocol.md: env var was QWEN_E2E_LLM, real var is SKIP_LLM_TESTS (inverted polarity). Streaming test count was 4, actually 3. Added Stage 1 limitation notes for "no DELETE /session" and "no permission timeout". Added client-side ring-buffer gap detection guidance for Last-Event-ID reconnect. Test updates: - httpAcpBridge.test.ts: rewrote two tests for the new doSpawn-on-model-switch-fail contract (publish event, keep session). Updated shutdown-closes-subscriptions test to expect the new terminal `session_died` frame. - server.test.ts: switched bearer-auth rejection probes from /health to /capabilities (since /health is now exempt). Added a test that locks /health's exemption. * docs(serve): close 2 last review threads — prompt timeout limitation note (#3803) A05Yk (deepseek): document that `POST /session/:id/prompt` has no server-side timeout. The bridge only races against the agent child exiting + the caller's HTTP-disconnect AbortSignal; a wedged-but-alive agent blocks the per-session FIFO. Long-running prompts are legitimate (deep research / large-codebase analysis) so a default deadline is deliberately not set; Stage 2 will expose a configurable opt-in. Callers should set their own client-side timeout and disconnect / POST /session/:id/cancel on expiry. AyoUy (copilot): same env-allowlist concern as A09HB — already addressed by the allowlist→denylist revert in the previous commit (e74aa9919). No additional code change needed; the resolve here just acks that the upstream fix covers it. * fix(serve): close 3 copilot review threads — SSE envelope shape + integration test ordering (#3803) A8uSe / A8uSt — the SSE frame examples in qwen-serve.md and qwen-serve-protocol.md showed `data:` containing only the inner ACP payload (e.g. `{"sessionUpdate": ...}`). The daemon actually emits the full event envelope — `{id?, v, type, data, originatorClientId?}` — JSON-stringified on a single line. Readers copying the curl output and writing parsers against the documented shape would extract garbage or fail JSON-shape validation. Both docs now show the real envelope and call out the SSE-level `id:` / `event:` lines as EventSource convenience that duplicates fields already inside the JSON envelope. A8uSz — integration `qwen serve — bearer auth` tests probed `/health` for 401 assertions, but `/health` is now intentionally registered BEFORE the bearer middleware (per the A8dZT fix in the previous commit) so liveness probes work without credentials. Switched probes to `/capabilities`, plus added a `/health exempt` test that locks the exemption so a future middleware ordering change can't silently break liveness probes. Also: integration `bad modelServiceId tears down half-init session` asserted the OLD doSpawn-on-model-switch-fail behavior (throw + clear maps). Per #3889 review A05Ym the new behavior keeps the session operational on the agent's default model and surfaces the failure via the `model_switch_failed` SSE event. Test renamed to `bad modelServiceId keeps the session alive on the default model` and rewritten to assert the new contract. * fix(serve): close 3 copilot review threads — sync write throw, polyfill name, blockquote (#3803) A800o (server.ts:360): `res.write(chunk, cb)` callback isn't documented to receive an error argument in Node — errors come on the `'error'` event, which the surrounding code already wires up. The dead `(err) => if (err) reject(err)` branch was misleading. The real concern was that `res.write()` can throw synchronously when the socket is already destroyed (typical EPIPE shape), and the throw escaped the promise executor. Wrapped the `res.write` call in try/catch so that surfaces as a rejection on the returned promise instead of an unhandled exception. A8008 (DaemonClient.ts:375): `abortTimeout` polyfill called `new DOMException('TimeoutError')`, which sets the *message* to "TimeoutError" and leaves `name` at its default ("Error"). Native `AbortSignal.timeout()` aborts with `name === 'TimeoutError'` (per WHATWG), so callers doing `if (err.name === 'TimeoutError')` to distinguish timeout from user-abort would see the polyfill behave differently from the native runtime. Constructor signature is `new DOMException(message, name)` — fixed both args. A801J (qwen-serve-protocol.md:254): blockquote was broken — one line in the middle of the multi-line `>` block was missing the `>` prefix, which dropped the rest of the list out of the quote and rendered awkwardly. Added the missing `>`. * fix(cli,sdk): close 8 review threads — DoS cap + SDK plumbing + cleanup (#3803) Critical: - A9UEi — `EventBus` had no subscriber cap and evicted subscribers lingered in the `subs` Set until the consumer drove `next()`. An attacker opening thousands of SSE connections to one session would amplify each `publish()` (O(N) over subs) into a CPU/memory DoS, with each evicted-but-stalled connection's `BoundedAsyncQueue` pinned in memory forever. Two fixes: per-bus subscriber cap of 64 (refuses new subs at the limit by returning an empty iterable), AND `subs.delete(sub)` immediately when a subscriber is evicted so subsequent publishes don't pay the dead-sub iteration cost. Also set `server.maxConnections = 256` on the listener to bound socket descriptors against connections that never finish their headers. SDK: - A9UEv — `prompt()` now accepts an optional `AbortSignal`. Caller cancellation forwards through the underlying TCP close, which the daemon already translates into an ACP `cancel` notification. The bridge's `sendPrompt(sessionId, req, signal)` always supported it; only the SDK surface was missing the parameter. - A9UEn — `subscribeEvents` now applies `fetchTimeoutMs` to the CONNECT phase only (request → headers received). The SSE body itself stays uncapped (it's long-lived by design), but a daemon that's TCP-open but never returns headers no longer blocks callers indefinitely. Implementation: a setTimeout-driven AbortController composed with the caller's signal, cleared in `finally` once `_fetch` returns. - A9UEr — `respondToPermission` now drains the response body via `res.body?.cancel()` on both 200 and 404. undici keeps the underlying socket pinned waiting for an unconsumed body; long- running clients with frequent permission votes would exhaust the connection pool. Cleanup: - A9UNF — `MAX_BUF_BYTES` renamed to `MAX_BUF_CHARS` (the guard checks `buf.length`, which is UTF-16 code units, not bytes). The cap's job is "stop runaway non-SSE bodies", not exact accounting, so the proxy is intentional — but the name now matches the unit. Error message updated. - A9UNb / A9UNp — both integration tests' boot-timeout `setTimeout` is now stored and `clearTimeout`'d on success and on early exit. Without the clear the un-cancelled 10s timer outlived the spawn promise and could keep the vitest event loop alive past the test, manifesting as intermittent timeouts on slow CI. A9UEy was already addressed by the prior commit's `status === 413` branch in the Express error middleware (body-parser sets both `status: 413` and `type: 'entity.too.large'` on body-too-large errors); resolve only. * fix(cli,test): close 2 copilot review threads — case-insensitive bearer + Windows skip (#3803) A9sCe (auth.ts:88): bearer scheme parsing was case-sensitive (`parts[0] !== 'Bearer'`). Per RFC 7235 §2.1 / RFC 7230 §3.2.6 the auth scheme token is case-insensitive — `Bearer` / `bearer` / `BEARER` are all valid, and conformant clients may send any. The old code returned 401 on those. Switched to a regex-based split that also tolerates runs of whitespace between scheme and credentials, then `.toLowerCase()`s the scheme before comparing. The token value itself stays case-sensitive (it's user-defined opaque material). A9sCw (qwen-serve-streaming.test.ts): the streaming integration suite shells out to `pgrep` / `kill -KILL` to simulate child-process crashes for the `SIGKILL → session_died` test. Those binaries are POSIX-only — on Windows runners the suite would fail even when `SKIP_LLM_TESTS` is unset. Added `process.platform === 'win32'` to the SKIP gate. A Windows-equivalent (`taskkill /F /PID …`) needs different scaffolding; deferred. * fix(cli,sdk,docs): close 6 review threads — CodeQL regex, body cancel, env doc (#3803) A90nk (auth.ts:93): CodeQL flagged the new bearer-scheme regex `^(\S+)\s+(.+)$` as a polynomial-regex risk on user-controlled input — `\s+` and `.+` overlap on whitespace-heavy adversarial headers (the alert example: `'!\t' + '\t'.repeat(N)`). Replaced with a hand-rolled split (`indexOf(' ')` + manual whitespace skip) so there's no backtracking. Behavior unchanged: scheme is still case-insensitive, runs of whitespace between scheme and credentials still tolerated, scrubs `header.charCodeAt() === 0x20` explicitly so we don't accidentally consume tab/newline as scheme separator. A90oi / A96Q8 (qwen-serve.md:117): the threat-model bullet still claimed the spawned child runs with an "allowlisted environment" (HOME / PATH / USER / LOGNAME / LANG / etc), but the prior commit flipped the implementation to a denylist (only `QWEN_SERVER_TOKEN` scrubbed) so the agent could authenticate to LLM providers. Doc now matches code: explicit pass-through with a one-key scrub, plus the threat-model rationale (user-as-trust-root, env passthrough is not the boundary). A90ou (qwen-serve-protocol.md:300): `stream_error` example showed the inner ACP-style payload `{"error":"<message>"}` instead of the full envelope `{v, type, data:{error}}` that other SSE-frame examples in the same doc already use. Updated to match. A96RL (DaemonClient.ts:352): `subscribeEvents` threw on a 200 with the wrong content-type without consuming the response body first. On undici-backed `fetch` an unconsumed body keeps the underlying socket pinned waiting for the consumer; long-running clients hitting this path repeatedly would exhaust the connection pool. Same `await res.body?.cancel()` pattern as `respondToPermission`. A96RR (server.ts:167): prompt-element validation accepted any non-null object, but `typeof [] === 'object'`, so `prompt: [[]]` slipped past with a confusing 500 from the ACP SDK layer downstream. Added `!Array.isArray(item)` so the 400 actually catches array elements. * fix(cli,sdk,docs): close 10 review threads — DoS observability + race + tests (#3803) Code: - A-Ur8 (httpAcpBridge.ts:1319): SCRUBBED_CHILD_ENV_KEYS gets a prominent WARNING that the denylist-only design is correct ONLY because the agent has unrestricted shell-tool access. Any future sandbox-locked variant MUST switch back to allowlist or expand the denylist to cover provider/CI/cloud secret prefixes. - A-XfH (auth.ts:60): Host allowlist now accepts the no-port form (`localhost`, `127.0.0.1`, `[::1]`, `host.docker.internal`) when the bind port is 80. Per RFC 7230 §5.4 clients may legitimately omit the port suffix when it matches the URI scheme default. - A-UsJ (httpAcpBridge.ts:564): unify model-switch failure handling. The create-session path swallows the error to keep the session alive on its default model; the attach path now does the same (was: throwing a 500 with no sessionId, denying the caller any way to recover). Both paths surface failure via the `model_switch_failed` SSE event. - A-UsN (httpAcpBridge.ts:621): extracted the lazy-init `transportClosedReject` pattern into `getTransportClosedReject` helper. Three call sites (`applyModelServiceId`, `sendPrompt`, `setSessionModel`) collapsed to one, single-listener invariant documented at one place. - A-UsH (eventBus.ts:194): subscriber-cap rejection is now observable. EventBus.subscribe throws a typed `SubscriberLimitExceededError` (was: silent empty iterable). SSE route catches it, logs to stderr, and emits an SSE-shaped `stream_error` terminal frame so the rejected client sees a readable failure rather than a closed-with-no-frames stream. - A-UsO (server.ts:72): `/health` is now exempted from bearerAuth ONLY on loopback binds. On non-loopback the route is registered AFTER bearerAuth so probes must carry the token — otherwise an unauthenticated caller could probe arbitrary IP:port to confirm a `qwen serve` exists. Doc updated. Tests added: - A-UsP: new test sends an 11 MB body to verify the 413 path in the Express error middleware returns the actionable "Request body too large" JSON instead of a generic 500. - A-UsQ: new test for `DaemonClient.prompt(sessionId, req, signal)` AbortSignal forwarding through to fetch. - A-UsS: two new tests for `subscribeEvents` connect-timeout (never-resolving fetch aborts; fast-resolving fetch clears the timer so it doesn't leak as a dangling handle). - A-UsU: new test for `sendPrompt` abort path resolving pending permissions as cancelled — the bug being regressed: an HTTP client disconnecting mid-permission would leave the agent stuck waiting on a vote that no SSE subscriber would ever cast. Test contract updates: - `publishes model_switch_failed and surfaces the error when the agent rejects` rewritten for the new attach-path swallow contract: attach now returns the existing session with `attached: true` and the `model_switch_failed` event is the visible failure signal instead of a thrown error. * fix(serve): add missing v field on subscriber-limit stream_error frame (#3803) `tsc --build` (which CI runs as part of the lint job) caught what `tsc --noEmit` (the local typecheck script) missed: the new `stream_error` frame in `server.ts:344` was constructed without the `v` field, but `OmitId<BridgeEvent>` requires it. Local typecheck in the previous commit was clean; the build's stricter project graph reported `error TS2345` and broke both Lint and Test (Ubuntu) jobs. Set `v: 1` to match the existing `stream_error` construction in the SSE iterator-throw path in the same file. * docs(users): close 1 copilot review thread — GitHub canonical casing in nav (#3803) A_U2e: nav label "Github Actions" was inconsistent with the canonical "GitHub" casing used elsewhere in the repo (skills, README, etc.). Rename to "GitHub Actions" for consistent branding. Pre-existing entry in `docs/users/_meta.ts` adjacent to the `'qwen-serve'` line this PR added — flagged in the diff context. * fix(serve): close 4 deepseek review threads — closed-bus race + per-session stderr + entry override (#3803) BBb9H (correctness): `BridgeClient.requestPermission` could orphan a pending permission if the bus closed between `registerPending` and `entry.events.publish` (the shutdown path closes per-session buses BEFORE awaiting `channel.kill()`, so the agent can still issue `requestPermission` in that window). Pending was registered in the daemon-wide map but `publish()` returned `undefined` (closed bus) → no SSE subscriber ever saw the request → no client voted → agent's `requestPermission` hung forever, blocking the daemon's `Promise.all` over child kills. Now: check publish's return; if `undefined`, roll back the pending via a new `rollbackPending` callback that resolves it as `cancelled`. BBb8e (Critical observability): child stderr was `'inherit'` — all sessions' stderr interleaved on the daemon's stderr stream unattributed. Switched to `'pipe'` and forward each line with a `[serve pid=<n> cwd=<dir>]` prefix; operators can now `grep pid=12345` to pull one session's trace cleanly. Updated the now-stale doc comment that claimed inherit was current. BBb8- (deployability): `process.argv[1]` is brittle — fails on non-`qwen` launchers (bundled binaries, npx wrappers, `node -e`, `tsx`, container images that relocate the script). Added `QWEN_CLI_ENTRY` env override as the higher-priority resolution path. Improved the failure message to suggest the env var as the actionable fix. BBb82 (documented limitation): `withTimeout` REJECTS but doesn't ABORT the underlying ACP op. For `unstable_setSessionModel` this means a timed-out caller perceives failure while the agent may eventually complete the switch — drift between caller's perceived model and agent's actual model + contradictory SSE events. Documented as a Stage 1 limitation in the `withTimeout` JSDoc; acceptable because (1) ACP doesn't expose a cancel signal for `unstable_setSessionModel` yet so we couldn't abort even if we wanted to, (2) model switches complete in milliseconds in practice — a timeout means genuinely wedged, not just slow. Stage 2 will add abort plumbing once ACP exposes the hook. * ci(noop): re-trigger workflow for f8509dde5 (#3803) * fix(cli,sdk): close 8 review threads — sse abort + queue drain mode + perf + doc engine drift (#3803) Correctness: - BCcd6 (sse.ts:80): trailing flush at EOF used `splitFrames(buf)` which returned `[buf]` — a multi-byte split that completed multiple frame separators in the final `decoder.decode()` would merge the frames into one parse and silently drop events. Switched the EOF flush to `consumeFrames()` (same walker the main loop uses), then attempt one more `parseFrame` on any trailing fragment. Removed the now-unused `splitFrames` helper. - BCybH (sse.ts:67): `parseSseStream` only checked `signal.aborted` before each `reader.read()`, leaving the generator parked inside a pending `read()` if the upstream went idle right when the caller aborted — contradicting the docstring's "AbortSignal cleanup is prompt" claim. Added a one-shot abort listener that calls `reader.cancel()` (cleared in `finally`), so abort reliably terminates even on a stalled stream. - BCce_ / BCycT (eventBus.ts:391/253): subscribe documented "abort closes the iterator promptly" but `BoundedAsyncQueue.next()` drained any items already in `buf` before honoring `closed`. Aborted SSE subscribers could keep yielding hundreds of queued events to a closed socket. Added a `close({drain: false})` mode that truncates `buf` immediately, used by the abort path; the default drain-on-close behavior is preserved for the eviction path (which needs the synthetic `client_evicted` terminal frame to reach the consumer before the iterator unwinds). Performance: - BCcfe (auth.ts:72): `hostAllowlist` was allocating a fresh `Set` + 4 interpolated strings on every request. Cache once per resolved port (relevant because tests bind to ephemeral 0 and the port is only known after `listen()`); SSE heartbeats and high-frequency probes now skip the allocation. - BCcgJ (DaemonClient.ts:137): `fetchWithTimeout` used `AbortSignal.timeout()` — the timer fires regardless of whether the fetch resolved early. On a fast-resolving request with the default 30s timeout, the pending timer hangs around. Switched to `AbortController` + `setTimeout` + explicit `clearTimeout` in `finally`, so each timer is released the moment its fetch settles. Also `.unref()`s the timer so it doesn't pin the event loop on its own. Doc accuracy: - BCyc0 (DaemonClient.ts:468): the `abortTimeout` / `composeAbortSignals` JSDoc claimed Node 18-20.2 polyfill compatibility, but `engines.node` is `>=22.0.0` now. Reframed as a generic feature-detect for non-Node runtimes (browsers / edge workers) so future maintainers don't reason about the wrong floor. - BCydi (server.ts:368): "Always present in Node >= 20" → "on the supported Node versions (engines.node >=22)". CodeQL alert #207 (httpAcpBridge.ts:1342, `js/path-injection` on `cwd: workspaceCwd`) is the renumbered version of the already-accepted #201 — same trust-model rationale documented at the call site, same need for maintainer UI dismiss / config exclusion. * feat(serve): close 3 chiga0 audit items — ringSize 4000, --max-sessions, /health?deep=1 (#3803) Three "30-minute" items from chiga0's external architecture audit (2026-05-11). All actionable within Stage 1 scope; remaining items in chiga0's review (SaaS positioning, multi-token to Stage 1.5, acp-bridge package extraction, reference orchestrator) are larger scoping decisions deferred to Stage 1.5/2. DEFAULT_RING_SIZE 1000 → 4000 (Risk 4): - A single long turn can emit hundreds of frames (test plan reports 13 for a SHORT turn, real workloads can be 10× that). 1000 was exhausted by a moderate turn before a 5s reconnect window finished. 4000 gives ~30× headroom over a typical busy turn at the cost of a few hundred KB RAM/session. Updated user + protocol docs and the daemon-client-quickstart example. --max-sessions <n> (default 20) (Rec 3): - New `ServeOptions.maxSessions` + matching `BridgeOptions`. Bridge throws `SessionLimitExceededError` when `byId.size + inFlightSpawns.size >= max` BEFORE issuing a fresh spawn. Attaches to existing sessions (single scope) bypass the cap so an idle daemon's reconnects keep working at-capacity. `0` disables. Default of 20 sized below the design's N≈50 cliff (per-session ~30–50 MB RSS + FD pressure). HTTP route maps to 503 with `Retry-After: 5` and `code: session_limit_exceeded`. Tests cover: cap rejection under thread scope, attach-not-counted under single scope, `0` disables. Documented in CLI flags table + protocol Common-error section. /health?deep=1 (Risk 3): - Default `/health` stays cheap (no bridge access). With `?deep=1` the response includes `sessions` and `pendingPermissions` from the bridge — touches state so a wedged bridge surfaces as 503 `{status: "degraded"}` instead of "200 ok" on a zombie daemon (the `k8s rolling deploy will see healthy` failure mode chiga0 flagged). Loopback-vs-non-loopback bearer-exempt logic from the earlier A8dZT fix is preserved via a shared handler. Tests cover: cheap default, deep response shape, throwing-getter → 503. * fix(serve,sdk,docs): close 9 review threads — req.on('close') prompt-cancel bug + doc + types (#3803) Critical correctness: - BQAnZ (server.ts:225): `POST /session/:id/prompt` wired cancellation to `req.on('close')` — but Node's `IncomingMessage` fires that event when the request body has been fully consumed, even when the client is still listening for the response. Result: ordinary prompt calls were getting cancelled the moment their upload finished, returning `{stopReason: "cancelled"}` instead of completing. Switched to `res.on('close')` guarded by `!res.writableEnded` (the documented "client gave up before we could send the response" pattern, same as the POST /session disconnect-detection from earlier in the PR). Already addressed earlier — resolve as ack: - BQAna (httpAcpBridge.ts:767): no global session cap. Already shipped in commit 66ffd7cc6 — `--max-sessions` flag + bridge enforces with `SessionLimitExceededError` mapped to 503; both in-flight spawns and live sessions count against the cap. Doc fixes: - BDAOf (DaemonClient.ts:49): `fetchTimeoutMs` JSDoc said it applies to "every non-streaming method including prompt", but `prompt()` actually bypasses fetchWithTimeout (model+tool turns are minutes-scale, can't be 30s-capped). Doc now lists the short-lived methods explicitly and notes prompt's exemption. - BDAPY (qwen-serve-protocol.md:283): blockquote was broken — the `POST /session/:id/cancel` line was missing the leading `>` and a stray "- POST /session/:id/cancel." rendered orphaned outside the quote. Reformatted as a single coherent quote. Reviewer-tooling resilience: - BQAnf / BQAng (integration-tests/...:325/185): added explicit `DaemonSessionSummary` type to two `.find` / `.every` callbacks. Local typecheck infers the type fine via the SDK's source declarations; the reviewer's environment resolves `@qwen-code/sdk` against a possibly-stale `dist/index.d.ts` (per `integration-tests/tsconfig.json` `paths` mapping) and the `s` parameter widens to `any`. Annotation makes both envs happy. Reviewer-only artifacts (no code action): - BQAnb / BQAnc (integration-tests/...:26/30) — same SDK-dist staleness; the imports are correct and resolve fine when `packages/sdk-typescript` has been built. - BQAni (server.test.ts:8 supertest module not found) — Node 20 setup blocker the reviewer noted; resolves cleanly under Node >=22 (our declared engines floor) with `npm install`. * fix(serve,sdk,test): close 7 review threads — fetchTimeoutMs negative + bridge-error context + perm scope contract (#3803) Real fixes: - BQPRo (DaemonClient.ts:136): `fetchTimeoutMs` accepted any number, including negatives that would slip past the `Number.isFinite` check inside `fetchWithTimeout` and fire `setTimeout(-1)` → immediate abort, killing every request before it could complete. Coerce non-positive / non-finite to 0 (the documented disable sentinel) at the constructor so call-site math stays simple. - BQLdO (server.ts:725): `sendBridgeError` now accepts a `ctx` arg `{ route, sessionId }` folded into the stderr log line. Bare `ECONNRESET` / `ENOMEM` traces are no longer unattributable on a busy daemon — operators see `qwen serve: bridge error (POST /session/:id/prompt session=abc-123): ...`. All five route call sites pass context. - BQI-6 (qwen-serve-streaming.test.ts:123): `sseFrames` test helper forwards `opts.signal` into `parseSseStream` so post-connect abort terminates iteration immediately (the parser's own abort- -wired-to-reader.cancel landed earlier; this just plumbs through the test harness). Doc / contract: - BQNqL / BQNqM (httpAcpBridge.ts:692, server.ts:199): `cancelPendingForSession` cancelling all session permissions on client disconnect is intentional under the per-session FIFO + ACP spec — permissions are issued inline DURING an active prompt, the agent awaits them, so the only outstanding permissions at any moment belong to the prompt being cancelled. Cross-client caveat (B's vote 404s when A disconnects mid-A's-prompt) is the right behavior — a vote on a cancelled-prompt's permission wouldn't drive the agent forward. Documented the scope contract + multi-client caveat in `cancelPendingForSession` JSDoc. Already addressed (resolve as ack): - BQI-c (qwen-serve-protocol.md): blockquote was already reformatted in the previous round (`POST /session/:id/cancel` now sits inline on a single quoted line); copilot reviewed an older commit. - BQI-v (DaemonClient.ts): `fetchTimeoutMs` JSDoc was already updated last round to explicitly note `prompt()` is excluded; copilot reviewed the older shape. * fix(serve,test,docs): close 6 review threads — TEST_CLI_PATH + Stage 2 markers + SSE phantom-conn warning (#3803) Real fix: - BQpu6 / BQpvW (integration-tests/cli/...): both qwen-serve test files hardcoded `../../packages/cli/dist/index.js`, while the rest of the integration suite reads `process.env.TEST_CLI_PATH` (set by `globalSetup.ts` to the root `dist/cli.js` bundle). The difference made our tests sensitive to which build step (`build` vs `bundle`) ran last. Now read `TEST_CLI_PATH` first, fall back to per-package dist for direct vitest invocations that bypass globalSetup. Operator-facing doc: - BQsOD (server.ts:497 KNOWN GAP): added an operator warning to `docs/users/qwen-serve.md`'s threat-model section about phantom SSE connections behind NATs that swallow TCP RSTs (kernel keepalive ~2h Linux default → can accumulate to the 256-conn ceiling on `--hostname 0.0.0.0` deployments). Stage 2 will add application-level idle deadline; until then operators on such networks may want to lower `server.keepAliveTimeout` via reverse proxy. Stage 2 maintenance markers (no code change, just visible TODOs): - BQsOA (httpAcpBridge.ts:1247): added `FIXME(stage-2)` on the sync `realpathSync.native` call so the Stage 2 in-process refactor doesn't ship without removing this event-loop-blocking syscall. - BQsOB (server.ts:243): added a SECURITY NOTE on the `...(body as object)` passthrough explaining the spec-defined `_meta` forwarding contract + the rule that an explicit pick is required if any new bridge field starts being trusted by name. Pattern repeats on cancel/model — note covers all four sites. - BQsOF (httpAcpBridge.ts:1041): `FIXME(stage-2)` noting that `setSessionModel` reuses `initTimeoutMs` (default 10s) for the in-flight model swap — conceptually distinct from cold-start init, currently sharing only by coincidence; Stage 2 should split into `modelSwitchTimeoutMs` and remove the no-abort `withTimeout` race-condition once ACP exposes a cancel signal for `unstable_setSessionModel`. * fix(serve): close 4 review threads — unhandled rejection + maxSessions plumbing + 2 docs - httpAcpBridge.sendPrompt: attach .catch(() => {}) to the abort-listener cleanup chain. The chain is `racedPromise.finally (...)` and we never await it; if `racedPromise` rejects, the finally returns a rejected promise that surfaces as an unhandled rejection (Node's default behavior on unhandled rejection is process termination). The route's own catch handles the original rejection — only the cleanup chain needs the swallow. - httpAcpBridge.sendPrompt: FIXME(stage-2) for absolute prompt deadline — buggy agent ignoring cancel + alive channel = slow prompt-promise leak. - server.createServeApp: forward opts.maxSessions when constructing the default bridge. Direct callers (tests, embeds) were silently falling back to DEFAULT_MAX_SESSIONS (20); only the runQwenServe path piped the option through. - docs/users/qwen-serve.md: clarify Host allowlist is loopback-only; non-loopback binds rely on bearer + operator-managed front proxy. * docs(sdk): close 1 review thread — sse.ts MAX_BUF_CHARS docstring lead-line said "bytes" Doc lead-line claimed "Hard cap on accumulated unread bytes" while the implementation enforces the cap via `buf.length` (UTF-16 code units), which the rest of the same docstring already correctly explained. Fix the lead-line so a reader skimming the first sentence isn't misled. The runtime error message and constant name (MAX_BUF_CHARS) already say "code units" — only the docstring lead-line needed alignment. * fix(serve,sdk): close 5 review threads — disconnect/attach race + 3 spec fixes + 1 doc - httpAcpBridge: add SessionEntry.attachCount + new killSession({requireZeroAttaches:true}) opt to fix the BQ9tV race. When client A spawned (attached:false) but disconnected mid-spawn, A's disconnect-reaper (server.ts) could tear down a session that client B had just attached to. spawnOrAttach now bumps attachCount on each attached:true return, and killSession with the new opt bails when attachCount > 0. The check + the eager byId/byWorkspace deletes both run in killSession's synchronous prefix, so the guard is atomic across the await boundary. - server.ts disconnect-reap path now passes requireZeroAttaches:true. - loopbackBinds.ts: lowercase the operator-supplied hostname before Set lookup so --hostname Localhost / LOCALHOST aren't forced to require a token. Aligns boot-time detection with the runtime Host-header check (auth.ts already lowercases). - auth.ts bearer parsing: accept HTAB (0x09) in addition to SP between scheme and credentials per RFC 7230 §3.2.6 BWS. - sdk sse.ts parseFrame: guard against `null` / primitive JSON parses so the AsyncGenerator<DaemonEvent> contract isn't violated by a misbehaving proxy emitting `data: null`. Daemon itself never emits these — defense-in-depth only. - docs/developers/qwen-serve-protocol.md: document the modelServiceId-rejection-on-fresh-session corner case + tell subscribers to pass Last-Event-ID:0 to replay the spawn-time model_switch_failed event from the ring. - 3 new unit tests: BQ9tV positive + negative race paths, BQ9ze parseFrame null guard. * fix(serve): close 4 review threads — 2 critical (NaN cap, stderr buffer) + IPv6 zone-id + deep doc - httpAcpBridge maxSessions normalization (BRApy [Critical] gpt-5.5): NaN / negative values previously fell through `!Number.isFinite(...)` to `Infinity`, silently disabling the daemon's session cap (fail-OPEN on a typo). Now throw TypeError on NaN / negative; explicit 0 and Infinity remain valid "unlimited" sentinels. - httpAcpBridge stderr line buffer (BRAp3 [Critical] gpt-5.5): the per-spawn `buf` accumulating stderr until `\n` had no length cap; a child that wrote a huge line or never emitted a newline could grow daemon memory unboundedly per session. Cap at 64 KiB per line and force-flush with a `[truncated]` marker — keeps the prefix-attributed log line, bounds memory, no content drop. - runQwenServe.formatHostForUrl (BQ-6V copilot): RFC 6874 requires `%` in IPv6 zone IDs (e.g. `fe80::1%lo0`) to be percent-encoded as `%25` in URLs. Now encode on the raw-IPv6 path; already-bracketed input is the operator's responsibility. - /health?deep=1 (BQ-6F copilot): the 503 path is unreachable for the real bridge (counter getters are simple Map-size accessors that don't throw). Reframed in code + protocol doc as INFORMATIONAL observability ("capacity dashboards, not real liveness"); keep the try/catch as defense-in-depth for custom bridge impls. - 2 new unit tests: BRApy NaN/negative throws + 0/Infinity ok; BQ92B Localhost case-insensitive boot. * fix(sdk): close 1 review thread — sse parseFrame tighter shape guard (BREsR followup to BQ9ze) The previous parseFrame guard only rejected null/primitive JSON; arrays and shape-incomplete objects still cast through to DaemonEvent. Tighten to require: non-null non-array object with v === 1 and type: string. Now the generator's static AsyncGenerator<DaemonEvent> type is a genuine runtime guarantee instead of a structural hope. Daemon never emits malformed frames (formatSseFrame always serializes {v: 1, type: string, ...}); guard remains defense-in-depth against misbehaving proxies / alternate implementations. Existing test fixtures already conform to the shape so no other tests needed updating. * fix(sdk): close 1 review thread — fetchWithTimeout keeps timer alive through body consumption (BRN1o) Pre-fix: `fetchWithTimeout` cleared the timer in `finally` the moment the underlying `fetch` resolved. But `fetch` resolves at headers, not at body completion. A daemon or proxy that sent headers and then stalled mid-body left `await res.json()` (and `failOnError`'s `res.text()`) without any deadline — calls to `health()`, `capabilities()`, `createOrAttachSession()`, `listWorkspaceSessions()`, `setSessionModel()`, `cancel()`, `respondToPermission()` could hang indefinitely past `fetchTimeoutMs`. Refactor `fetchWithTimeout<T>` to take an optional `consume(res)` callback whose execution is included in the timer scope. The composed abort signal still flows through to fetch's body stream, so an in-progress `res.json()` rejects cleanly when the timer fires. All JSON-returning routes updated to pass the body-read code as the callback. SSE (subscribeEvents) + prompt are unchanged: they bypass fetchWithTimeout intentionally (long-lived). Regression test: response with a never-emitting body that errors via the composed AbortSignal — pre-fix would hang for 5s+, post-fix rejects within ~80ms (configured timeout). * fix(serve,sdk): close 8 review threads — coalescing race fix + --max-connections + 5 docs/cleanups - httpAcpBridge spawnOrAttach (BRSCi [Critical] DeepSeek): the BQ9tV attachCount fix was incomplete for the in-flight coalescing path. When two callers await the same doSpawn and the second has a modelServiceId, the attach-bump landed AFTER an extra await for applyModelServiceId — leaving a microtask window in which A's killSession sync-prefix would still see attachCount==0 and reap a session B was about to receive. Move the bump to the very first sync step after `await inFlight` (and same in the direct-attach branch) so the bump-before-killSession ordering holds even when the model-switch yields. Test added for the coalescing-race path. - commands/serve + serve/types + runQwenServe (BRQQb): add `--max-connections` flag (default 256), wired through ServeOptions and `server.maxConnections`. Operators with high-concurrency deployments can now tune the listener-level cap without waiting for Stage 2. - commands/serve (BRQQZ): wrap `new Promise<never>(() => {})` in a named `blockForever()` helper so a future maintainer doesn't read the bare expression as a never-resolving-promise bug. - auth.ts (BRQQd): rewrite the comment about HTAB BWS — clarify that the scheme→credentials separator is `1*SP` per RFC 9110 §11.6.2, and HTAB is only accepted in the BWS *after* the SP. `Bearer\t<token>` (pure HTAB) is intentionally rejected. - types.ts + qwen-serve-protocol.md (BRQQf): document `modelServices: []` is always empty in Stage 1 so SDK consumers don't build off it. - qwen-serve.md (BRQQl + BRQQm): add operator note about subscribing to /events BEFORE posting modelServiceId on attach (otherwise the model_switch_failed event is missed). Document the four-layer load cap stack near --max-sessions so operators can size the related knobs together. - sdk index (BRSCv): drop the historical `Daemon`-prefixed type aliases (`DaemonPromptRequest` / `DaemonSubscribeOptions`) for consistency with the other un-prefixed daemon-type exports. SDK is Stage-1-experimental with no shipping consumers. * fix(sdk): close 1 review thread — sse parseFrame must not drop frames whose first line is a comment/retry (BRgq-) Per the EventSource spec, comment lines (`:` prefix) and `retry:` are line-level fields, not frame-level. The previous early return at the top of `parseFrame` dropped the entire frame when its first line was a comment or retry directive — meaning an intermediary that prepends `: keep-alive` or `retry: 5000` to every frame would cause the embedded `data:` payload to be silently lost. Removed the `startsWith` guard. The line-level `data:` collection loop already produces an empty `dataLines` array for pure-comment / pure-retry frames, so the existing `if (dataLines.length === 0) return undefined` branch still skips them — without dropping real events that just happen to be preceded by a comment line. Existing test still pins the standalone-comment / standalone-retry behavior; new test pins the leading-comment + data-line case. * docs(sdk): close 1 review thread — sse MAX_BUF_CHARS comment was overpromising byte-equivalence (BRker) The previous wording suggested "one code unit ≈ one byte" for mostly-ASCII content, then qualified it with mixed BMP / supplementary caveats. Reviewer flagged that JS string.length isn't a reliable byte proxy in either direction — engine string representation (V8 Latin-1 path vs UTF-16) makes the actual memory cost vary in ways the comment didn't capture cleanly. Rewrote to state plainly: cap measures code units, not bytes; intent is "stop runaway non-SSE bodies", not exact memory accounting; byte-precise bounds belong at a front proxy. Threshold and code unchanged — only the comment. * fix(serve): close 7 review threads — atomic write, read-size cap, force-exit on 2nd signal, doc fixes - httpAcpBridge.writeTextFile (BSA0D): atomic write-then-rename via `<path>.<pid>.<ts>.tmp` + `fs.rename`. Closes the SIGKILL-mid-write truncation hole. Tmp file lives in the target's directory so the rename can't cross filesystem boundaries; cleaned up on rename failure. - httpAcpBridge.readTextFile (BSA0E): `fs.stat` pre-check rejects files past 100 MiB so a `{ line: 1, limit: 10 }` against a 500 MB log doesn't allocate 500 MB of RSS just to return 10 lines. - runQwenServe SIGINT/SIGTERM (BSA0K): second signal during drain forces `process.exit(1)` with a stderr message instead of silently no-oping. Standard daemon behavior — `^C^C` works. - commands/serve --hostname help text (BRqFe): now mentions the full loopback set (127.0.0.1, localhost, ::1, [::1]) so IPv6 users aren't misled into thinking ::1 needs a token. - runQwenServe boot-refusal error (BRqFy): same correction — error message now lists all loopback aliases the operator can rebind to. - httpAcpBridge withTimeout doc (BSA0C): explicit Stage 2 follow-up marker for the modelSwitchTimedOut / model_switch_late_success observability gap (already a known limitation). - server.errorPayload (BSA0G): documented the multi-tenant info-leak trade-off (Stage 1 single-user/small-team trust model accepts verbatim ACP error data) and pointed to a Stage 2 --redact-errors follow-up. - 2 new tests: writeTextFile leaves no tmp turd; readTextFile rejects 200 MiB sparse file via the size cap. * fix(sdk): close 1 review thread — sse parseFrame must validate optional `id` (BSP1-) The previous shape guard only validated `v === 1` and `type: string`, leaving `DaemonEvent.id: number | undefined` unchecked. A misbehaving proxy emitting `data: {"id":"1","v":1,"type":"x",...}` would survive the cast and break consumer resume logic — Last-Event-ID resume does numeric comparisons against the monotonic counter, and a string id silently corrupts that math. Reject the frame entirely when `id` is present but not a finite safe integer (`Number.isSafeInteger`). Negative integers and missing-id both still pass; the daemon never emits negative ids in practice but the guard's responsibility is the type-cast contract, not the daemon's id-allocation policy. New test covers: string id, float id, > MAX_SAFE_INTEGER id (all rejected); negative-id, no-id, plain integer (all pass). * docs(serve): Stage 1.5 markers from chiga0 follow-up architecture review (#3889 c4427773706) chiga0's follow-up review explicitly states "None of the findings here block Stage 1. That holds." All 6 findings are Stage 1.5 convergence work for when downstream consumers attach. None require code changes for this PR. Adding inline FIXME(stage-1.5) markers at the natural pivot points so the future refactor has clear breadcrumbs back to the audit comment, instead of Stage 1.5 implementers having to re-discover the convergence story: - types.ts STAGE1_FEATURES → finding 5 (capability registry + extMethod HTTP route). - eventBus.ts EventBus class → finding 2 (lift to packages/event-bus, multi-consumer subscribe). - httpAcpBridge.ts BridgeClient.requestPermission → finding 3 (PermissionMediator + policy plugin point; closes prior chiga0 Risk 2 too). - httpAcpBridge.ts BridgeOptions → findings 1 + 4 (split into AcpChannel + Transport packages; thread FileSystemService through BridgeOptions). No behavior change. Each marker links to the audit comment for traceability. * docs(serve): tighten Stage 1 scope framing + durability + Stage 1.5 must-haves (#3889 c4427875644) chiga0's third review walks three downstream-consumer scenarios (IM bot, mobile companion, IDE extension) against Stage 1's runtime guarantees. The bottom-line concern is framing: the PR body promises "real workloads" but the protocol surface is sized for demo / single-user / never-crashes. Reviewer offers two paths — tighten the framing or add 7 must-haves to Stage 1.5. Author classifies all 10 must-haves as Stage 1.5/2, none as Stage 1 changes. In-scope action for this PR (doc-only, no behavior change): - `docs/users/qwen-serve.md` "Status" block: explicit scope-honesty note — Stage 1 is sized for prototyping clients + local single-user/small-team. Production-grade multi-client / mobile / flaky-network workloads need Stage 1.5+ guarantees. - New "Durability model" section spelling out sessions-are-ephemeral (closes must-have 10): no resume on child crash / daemon restart, ring-overflow on long disconnects, writeTextFile atomic across crash but not across restart. - New "Stage 1.5+ runtime guarantees" section listing the 10 must-haves (blockers 1-3, reliability 4-7, ergonomics 8-10) with a link back to the audit comment for traceability. - `httpAcpBridge.ts` BridgeOptions.sessionScope: FIXME(stage-1.5) marker referencing must-have 1 (per-request override), since this is the most prominent client-facing lock-in risk. No code behavior changes — this is roadmap commentary surfaced into the artifacts where downstream integrators will look (user docs + code pivot points). * fix(serve): close 2 correctness findings from tanzhenxin review Two bugs surfaced in the CHANGES_REQUESTED review: Issue 1 — `--max-connections 0` silently bricks the daemon on Node 22: - Docs say "Set to 0 to disable" and the code did `server.maxConnections = opts.maxConnections ?? 256`, but on Node 22.15.0 setting `server.maxConnections = 0` makes the listener refuse EVERY connection (every fetch → SocketError other side closed). The operator following the documented disable path got a daemon that boots cleanly, logs "listening on …", and then silently rejects health/session/SSE. - Fix: treat 0 / Infinity / non-finite as "leave the property unset" (Node's default = unlimited at this layer). Reviewer verified the Node 22 quirk; verified locally that 100 still binds the cap, 0 and Infinity now both accept connections. Issue 2 — Orphan agent child when both coalesced spawnOrAttach callers disconnect: - The BQ9tV `attachCount` race guard is monotonic. Once B's `spawnOrAttach` bumps it (synchronously, before the route handler can see `!res.writable`), the spawn-owner A's disconnect-reaper sees attachCount > 0 and skips the reap — permanently. If B then also disconnects, neither A nor B's route handler does anything, and the agent child stays alive with no client knowing the id. - Fix: add `bridge.detachClient(sessionId)` that decrements attachCount and reaps iff (attachCount == 0 && subscriberCount == 0). Server's `POST /session` handler calls it on the `!res.writable && session.attached === true` branch (symmetric to the existing spawn-owner-disconnect reap). - Subscriber-count check prevents reaping when a third client C is already on SSE — `detachClient` only fires when the session has no live consumers at all. 2 new tests for issue 1 (max-connections 0 + Infinity still accept connections; 100 still binds as supplied). 2 new tests for issue 2 (detach reaps when alone; detach preserves when SSE subscriber exists). fakeBridge updated with the new method. * fix(serve): close 3 review threads — maxConnections NaN/negative validation + doc fix + close-contract honesty - runQwenServe maxConnections validation (BUF9-): NaN / negative values previously slipped through `cap > 0 && Number.isFinite(cap)` to "leave unset = unlimited", silently fail-OPEN on a CLI typo and weakening the DoS / FD-exhaustion guard. Now throw TypeError upfront (before `app.listen()`) so a malformed cap fails the `runQwenServe` promise instead of escaping as an uncaught exception from the listen callback. - types.ts maxConnections doc (BUb7C): comment said "Node treats 0 as unlimited" but the runtime fix treats 0 as a sentinel and leaves `server.maxConnections` unset (Node 22 quirk). Updated to match. - runQwenServe close()/force-timeout (BUb7h): the 100ms eager `setTimeout(() => finish(), 100)` after `closeAllConnections()` resolved the close promise WITHOUT waiting for `server.close()`'s callback — breaking the "fully closed" contract. Now: force-close just accelerates `server.close` by killing sockets; we still wait on the close callback. A secondary 2s deadline handles the pathological "server.close never fires" case (kernel-stuck socket) with a logged warning, so shutdown stays bounded. * docs(serve): close 8 review threads — code-comment clarity + 3 new Stage 1 known gaps 8 threads in a single Claude Opus 4.7 review pass — 4 duplicate existing chiga0 finding FIXME markers, 1 code-comment clarity, 3 real new doc-worthy Stage 1 known gaps. Code clarity (BUy4U): - The shutdown re-check at doSpawn (`if (shuttingDown) { kill; throw }`) is the LOAD-BEARING correctness contract, not a band-aid as the reviewer framed it. Updated comment to explain: shutdown() runs tear-down in parallel with awaiting `inFlightSpawns` (faster fan-out); the re-check catches spawns whose `newSession` returns AFTER the flag flipped. The alternative — await all inflight to settle BEFORE snapshotting byId — is cleaner to reason about but serializes shutdown by up to `initTimeoutMs` (10s) before any live session starts tearing down. Documented the trade-off. New Stage 1 known gaps in docs/users/qwen-serve.md threat model: - BUy4H (permission auth daemon-global): cross-session vote risk acceptable under Stage 1 single-user / small-team trust model; Stage 1.5 will scope to `POST /session/:id/permission/:requestId` + session-scoped pending map + per-client identity (closes must-have #3 from the downstream review). - BUy4L (10 MB body limit on /prompt): multimodal content past 10 MB hits a cliff; workaround via path reference; Stage 1.5 accepts chunked encoding. - BUy4e (CORS deny blocks `packages/webui`): document explicit deployment options (Electron/Tauri shell, same-origin reverse proxy); Stage 1.5 adds `--allow-origin <pattern>` for opt-in named frontends. Already-marked duplicates (BUy4O, BUy4P, BUy4X, BUy4b) — covered by existing `FIXME(stage-1.5, chiga0 finding N)` / `FIXME(stage-2)` markers from prior rounds. * fix(serve): close 1 review thread — catch --hostname localhost:4170 typo upfront (BU-sh) The previous code path for unbracketed `host:port` typos went: 1. Loopback check fails (`localhost:4170` doesn't match the loopback set after lowercase normalization). 2. Throw "Refusing to bind localhost:4170:0 without a bearer token" — misleading because the operator's real bug is the colon in the hostname, not the missing token. Alternative path if a token IS supplied: hostname flows through to `formatHostForUrl` which sees the `:` and treats as IPv6, wrapping to `[localhost:4170]:port` in the printed URL. Then `app.listen()` fails with ENOTFOUND. Triple-unhelpful failure mode. Fix: catch the typo BEFORE the loopback/token check. Unbracketed input with exactly one `:` is unambiguously the host:port shape — raw IPv6 literals always have ≥2 colons (shortest is `::`), and bracketed IPv6 is handled by its own form check below. Error message suggests the corrected form (`--hostname localhost --port 4170`). * docs(serve): two new Stage 1 scope boundaries (option A + option iii) from LaZzyMan reviews LaZzyMan's two-part review surfaced two structural framing concerns distinct from the chiga0 roadmap items. Neither requires code changes in this PR — they want explicit scope honesty in the user docs: 1. TUI super-client framing (option A from the review): TUI UI is strictly larger than the wire protocol. The ~15 Ink dialogs and `local-jsx` slash commands are local-only; mutating commands like `/approval-mode`, `/memory`, `/mcp`, `/agents`, `/tools`, `/auth`, `/init` change agent behavior but emit no wire event. Documenting remote clients as sharing the agent↔user conversation axis only, NOT the full TUI session state. Implementers told to re-fetch state on reconnect, not rely on incremental events. 2. N parallel sessions cost N× (option iii from the comment): the "1 daemon = 1 session" axiom means N concurrent sessions on one workspace = N daemons with zero resource sharing. Concrete cost table at N=5 (~1.5-2.5 GB RSS, 15 MCP processes, 5× OAuth refresh) so users hit the wall with eyes open. Won't-fix on the main-line Stage 1/1.5/2 roadmap; alternatives (#3803 §21 Path A/B, in-project sidecars) materially change the architecture in ways we won't commit to mid-Stage-1. Peer-agent comparison noted (Cursor / Continue / Claude Code / OpenCode / Gemini CLI all do single-process multi-session). Both choices are intentionally the less-ambitious option; the substantive alternative (option B for taxonomy, option i/ii for N:1) moves to #3803 if real-usage data ever justifies it. * docs(serve): clarify option-A across Mode 1 (headless) vs Mode 2 (TUI co-host) Previous wording treated "TUI is a super-client" as universal truth. But Stage 1's actual shipping configuration is HEADLESS — no TUI shell runs inside the daemon — and in that mode the slash commands listed (`/approval-mode`, `/memory`, `/mcp`, `/agents`, `/tools`, `/auth`, `/init`) simply don't exist. Session state is boot-time- frozen from settings + disk, with only `/model` mutable via HTTP. Restructured the section to split the consequences: - **Mode 1 (headless `qwen serve`, this PR)**: no TUI exists; session state is boot-time-frozen + `model_switched` over HTTP; remote clients see the FULL session state; no drift possible. - **Mode 2 (Stage 1.5 `qwen --serve` co-hosted TUI, future)**: TUI exists alongside remote clients; TUI slash commands mutate session state with no wire events; remote clients see a strict subset; drift possible — re-fetch state on reconnect. The original "super-client" framing applies cleanly only to Mode 2. Mode 1 has no asymmetry — same option-A choice, different consequences. * fix(serve,sdk): close 12 review threads — 6 critical bugs + 6 follow-ups Six critical correctness fixes from the latest review pass: - httpAcpBridge.readTextFile (BX8YO): reject non-regular files via `stats.isFile()`. Char devices / FIFOs / procfs entries report `size: 0` but stream unbounded data; the 100 MiB cap wasn't enough. New `describeStatKind()` helper for human-readable error message ("named pipe (FIFO)" / "character device" / etc.). - httpAcpBridge.writeTextFile (BX8Yp + BX9_h): temp filename now includes randomUUID + exclusive flag `wx`. PID + Date.now() alone collides under concurrent writes within the same ms (sessionScope: 'thread' or coalesced spawns on same workspace). Exclusive mode fails fast on any residual collision instead of silent overwrite. - httpAcpBridge.writeTextFile (BX8Yw): resolve via `fs.realpath` before write-then-rename so symlinks are preserved. Pre-fix rename replaced the symlink with a regular file, leaving the real target unchanged while the write appeared successful. Test added covering both regular targets and symlink targets. - server.parseLastEventId (BX9_I): log a stderr breadcrumb when rejecting a non-empty non-decimal Last-Event-ID header. Pre-fix, clients with a malformed resume header silently resumed from 0 and lost every event buffered during the disconnect with zero evidence in logs. - httpAcpBridge channel.exited (BX9_P): thread {exitCode, signalCode} from the spawn factory through `session_died` event payload. Operators triaging a crash can now read the cause from the SSE frame instead of grepping daemon stderr for the child's pid. - httpAcpBridge spawnOrAttach in-flight coalesce path (BX9_U): defensive re-check that `byId.get()` is still defined after attachCount++ — if a concurrent kill tore down the entry, throw `SessionNotFoundError` instead of returning `attached: true` with a zombie sessionId. Six follow-ups in the same diff: - httpAcpBridge attachCount comment (BVryk + BWGSL): outdated "monotonic, we never decrement" claim — detachClient() now decrements. Comment rewritten to state the actual invariant ("reflects clients whose response was written or is about to be"). - runQwenServe.close() contract (BV-qW): bridge.shutdown errors are now propagated through the close promise (was: silently caught + resolved success). onSignal exits 1 instead of 0 when teardown fails. Server.close error takes precedence; bridge error is the fallback. - sdk sse parseFrame id guard (BX8Y1): require id >= 1 (was: any safe integer including negative). The daemon's Last-Event-ID parser only accepts non-negative decimals and EventBus emits ids starting at 1; negative ids on the wire diverge from resume math. Existing test updated. - runQwenServe server error listener (BX9_i): swap `server.once('error', reject)` for a persistent `server.on('error', log)` after listening. Pre-fix, a post-boot error (EMFILE etc.) was unhandled and crashed the daemon. Tests: +2 for BX8YO (FIFO) and BX8Yw (symlink preserve). Test infrastructure updated for the new `channel.exited` Promise<ExitInfo | undefined> signature. * fix(serve,sdk): close 4 more review threads — frame-scan perf + publish contract + AbortError narrowing + cross-module doc - sse consumeFrames perf (BX9_a): short-circuit the LF path first. In the common LF-only case the CRLF scan was traversing the entire remaining buffer for nothing; now CRLF is only scanned when LF is absent or potentially appears later than a CRLF separator (mixed-encoding edge). - EventBus.publish contract (BX9_p): explicit JSDoc says publish NEVER THROWS (closed-bus returns undefined, subscriber-enqueue errors caught internally). Historical try/catch wrappers in httpAcpBridge.ts are defense-in-depth, not load-bearing; new callers should not add them. - canonicalizeWorkspace doc (BX9_q): elevate the cross-module contract from "undocumented" to explicit — config.ts / settings.ts / sandbox.ts / this file all canonicalize the same way for sessionScope: 'single' re-attach. A divergence silently forks sessions per spelling. The Stage 1.5 @qwen-code/acp-bridge lift (chiga0 finding 1) is the natural place to extract a shared primitive; until then, any change to those modules needs a matching change here. - POST /session/:id/prompt AbortError swallow (BX9_k): narrow the swallow to only fire when `abort.signal.aborted` is true. The previous blanket `err.name === 'AbortError'` would also silently drop AbortErrors raised internally by the bridge (e.g. child process aborting mid-prompt), leaving the client with no response and no log trace. * docs(serve): correct N:1 framing — qwen-code's ACP agent natively supports multi-session Maintainer feedback (verified against the code): the ACP agent in packages/cli/src/acp-integration/acpAgent.ts:194 has `private sessions: Map<string, Session>` — one `qwen --acp` child natively hosts multiple sessions, and yiliang114's VSCode plugin already uses this pattern. The earlier "qwen-code is the only entry treating no multi-session resource sharing as a feature" framing (from the LaZzyMan reply + docs) was wrong. Stage 1 bridge in this PR doesn't yet leverage that capability — it spawns one `qwen --acp` child per session for simplicity (easier debugging, no cross-session interference during initial stabilization). That's a bridge-side design choice, not an ACP limitation. Revised docs/users/qwen-serve.md: - "N parallel sessions cost N×" section now distinguishes Stage 1 bridge (current N× cost) from Stage 1.5 bridge (multi-session per child, ~1/5th the cost at N=5). Cost table extended with the Stage 1.5 column. No more "won't fix on main-line roadmap" framing — the fix is a bridge refactor that pairs naturally with chiga0 finding 1 (`@qwen-code/acp-bridge` package lift), NOT the #3803 §21 Path A/B/C intra-daemon multi-session workstream (qwen-code already does that at the agent layer). - Status block's "Scope honesty" note: removed the implicit permanent-cost framing; replaced with explicit "Stage 1 bridge pays N×; Stage 1.5 refactor closes the gap" pointer. - Peer-agent comparison rewritten: qwen-code's *agent* matches Cursor / Continue / Claude Code / OpenCode / Gemini CLI on single-process multi-session; the bridge is the artifact. `httpAcpBridge.ts:doSpawn`: inline `FIXME(stage-1.5)` marker explaining the refactor (keep one child per workspace, call `connection.newSession()` multiple times on the same channel), with the link to `acpAgent.ts:194` so a future maintainer doesn't re-derive the discovery. * feat(serve): Stage 1 bridge now multiplexes sessions on one qwen --acp child per workspace Per LaZzyMan / tanzhenxin reviews + maintainer feedback verified against `packages/cli/src/acp-integration/acpAgent.ts:194` (the agent's `private sessions: Map<string, Session>`): qwen-code's ACP agent natively supports multi-session in one child process. The Stage 1 bridge previously spawned one child per session for simplicity, paying N× memory / OAuth / file-cache cost. Now refactored to leverage the agent's existing multi-session capability — one `qwen --acp` child per workspace, N sessions share it via `connection.newSession({cwd, mcpServers})`. Cost at N=5 sessions on same workspace: - Before: 300-500 MB RSS (5 children), 5× OAuth refresh, 5× file cache, 5× CLAUDE.md parse, 5× cold start - After: 60-100 MB RSS (one child), one OAuth path, shared FileReadCache, parsed once, <200ms cold start after first session Architecture changes: - New `ChannelInfo` type holds the shared channel + connection + BridgeClient + the set of session ids multiplexing on it. - New `byWorkspaceChannel: Map<workspace, ChannelInfo>` + new `inFlightChannelSpawns` coalesce-map for concurrent channel creation. - New `getOrCreateChannel(workspaceKey)` helper: reuse existing channel or spawn one (with `initialize` happening exactly once per channel, not once per session). Coalesced via `inFlightChannelSpawns` so two parallel callers don't both spawn. - `doSpawn` now calls `getOrCreateChannel` + `connection.newSession` separately (was: spawn+initialize+newSession together per session). - `BridgeClient` updated: `resolveEntry(sessionId?)` dispatches by the sessionId ACP carries in each request — one BridgeClient now serves all sessions on its channel. `sessionUpdate`, `requestPermission`, etc. all pass `params.sessionId`. - `channel.exited` cleanup moved into `getOrCreateChannel` and now tears down ALL sessions on the channel (not one). Each session gets its own `session_died` event so SSE subscribers learn the bad news on their own stream. - `killSession` now removes session from `channelInfo.sessionIds` and kills the channel ONLY when its sessionIds set drops to zero. Other sessions on the same channel keep running. - `shutdown` tears down channels (the deduplicated set) and awaits both inFlightSpawns and inFlightChannelSpawns. Cross-workspace channel sharing intentionally NOT done — `acpAgent.ts: 601 (this.settings = loadSettings(cwd))` reloads settings on each newSession call with a different cwd, so different workspaces in one child would step on each other. One channel per workspace is the safe scope. MCP server children stay per-session for now (each session can have different mcpServers config). Stage 1.5 follow-up: refcount MCP children by (workspace, config-hash) so identical configs share. Tests: - Updated `spawns fresh per call under sessionScope:thread` → now expects `handles.length === 1` (channel reused) but `sessionCount === 2` (distinct sessions). - New: `Stage 1.5 multi-session: N sessions on same workspace share ONE channel` (5 sessions, 1 factoryCalls). - New: `Stage 1.5: killSession on one of N sessions does NOT kill the shared channel` (kill 2 of 3, channel still alive; kill 3rd, channel killed). - New: `Stage 1.5: channel.exited tears down ALL multiplexed sessions` (each gets its own session_died). - FakeAgent.newSession suffixes call-count so multiple newSession calls on the same channel return distinct ids (matches real ACP behavior). Docs: - `docs/users/qwen-serve.md` N:1 section rewritten — no longer "Stage 1 pays N×, Stage 1.5 fixes". Cost table reflects current shared-channel architecture; MCP refcount called out as the one remaining Stage 1.5 follow-up; "1 daemon = 1 session" framing removed from related sections. * fix(serve,sdk): close 12 review threads — 6 critical bugs + 6 follow-ups Critical fixes: - server.ts safeBody() helper (BZ9uv/va/vs/wD + Bd10m + Bd1zz): prototype-pollution sanitization at the body-spread boundary. `__proto__` / `constructor` / `prototype` keys are stripped and the result is an Object.create(null) target. Replaces 5 sites of copy-pasted `typeof req.body === 'object'...` preamble + makes the `...(body as object)` spread sites safe. - httpAcpBridge requestPermission (Bd1yh): per-request wall-clock deadline (default 5 min, configurable via `BridgeOptions.permissionResponseTimeoutMs`). Without this, an agent calling requestPermission with no SSE subscriber connected would hang the per-session FIFO forever. After deadline, resolve as cancelled + log stderr warning. - httpAcpBridge requestPermission (Bd1z5): per-session pending permissions cap (default 64, configurable via `BridgeOptions.maxPendingPermissionsPerSession`). New requests past the cap resolve as cancelled with stderr warning. Prevents a chatty agent from growing pendingPermissions unboundedly. - runQwenServe onSignal double-signal force-exit (Bd1y6): new `bridge.killAllSync()` + `AcpChannel.killSync()` method synchronously SIGKILLs every live qwen --acp child BEFORE `process.exit(1)`. Previously double-Ctrl+C bypassed the async bridge.shutdown() and left children running as orphans. - server.ts SSE subscriber-limit response (Bd1zJ): 429 + Retry-After instead of 200 + stream_error frame. EventSource treats 4xx as terminal (no auto-reconnect); the previous 200+close-stream triggered EventSource's reconnect loop, amplifying the load the limit existed to prevent. - doSpawn ghost sessionId guard (Bd1zc): re-check byId.has() after applyModelServiceId(). The model-switch yields and can race channel.exited; without this, caller got HTTP 200 with a sessionId that 404s on every subsequent request. Follow-ups in the same diff: - sse.ts consumeFrames CRLF scan comment (BcRh_): the comment claimed the CRLF scan was bounded to `[cursor, lf)`, but Node's `indexOf` has no upper bound. Rewrote to describe what the code actually does (scan full remainder; only USE the result if it falls before `lf`). - sse.ts SseFramingError export (Bd10T): typed error class for framing-level failures so SDK consumers can distinguish "upstream isn't SSE" from generic network errors via instanceof check. Re-exported from @qwen-code/sdk. - protocol doc /health auth (Bctum): document the loopback exemption — `/health` doesn't require Authorization on loopback binds even when a token is configured. Matches `createServeApp`'s registration order. Bd1xz (cross-session permission escalation) acknowledged as duplicate of BUy4H — already documented as a known Stage 1 gap under the single-user / small-team trust model; fix is Stage 1.5 must-have #3 (per-client identity + per-session permission scope). Tests: - New: prototype-pollution test verifies `__proto__` spread doesn't pollute `Object.prototype`. - All 70 server + 55 bridge + 16 daemon-sse + 60 DaemonClient tests pass (203 total). `killSync()` stubbed on every inline test channel fake; fake bridge has `killAllSync()`. * fix(sdk): close 2 review threads — consumeFrames CRLF scan now actually bounded (BeFHR + BeFId) Previous attempt at the BX9_a perf optimization left the CRLF scan running over the full remainder of `buf` on every loop iteration where an LF separator existed — only the LF-not-found fallback path was actually bounded. Comments claimed the CRLF scan was restricted to `[cursor, lf)` or "only fires when needed", but Node's `String.indexOf` doesn't accept an end index. Bound the scan via a `buf.slice(cursor, lf)` window before `indexOf` so the assertion is now true: in the common LF-only case we pay one full scan (for LF) plus one bounded scan over the matched frame's bytes (small). * fix(serve): close 3 review threads + Windows test skip — dangling symlink, no-sessionId throw - httpAcpBridge.writeTextFile BfFvO: dangling-symlink case. `fs.realpath` throws ENOENT for a symlink whose target doesn't exist, and the blanket catch silently fell back to writing through the symlink itself — `rename(tmp, params.path)` then replaced the symlink with a regular file, exactly the bug BX8Yw was supposed to fix. Use `fs.readlink` to disambiguate "truly non-existent" from "dangling symlink"; resolve the dangling target manually and write through to it so the symlink stays a symlink. Regression test added. - httpAcpBridge BridgeClient resolveEntry BfFut: defensive throw on no-sessionId ACP call against a multi-session channel. ACP today carries sessionId on every per-session call, but if a future no-sessionId call lands, silently dropping it on a multi-session channel would be invisible. - httpAcpBridge.test.ts BX8YO Windows skip: hard-skip via `process.platform === 'win32'`. Git-Bash etc. ship a `mkfifo` binary that degenerates on Windows (creates a regular file or silently no-ops), making the assertion match the wrong error shape. Linux + macOS coverage is sufficient for a platform- agnostic `!stats.isFile()` check. BfFvW (CRLF scan comment) was already addressed in 0a4146a02 — the reviewer's diff was against the pre-fix version. * fix(serve): close 6 review threads — 4 critical bugs + 2 doc updates Critical fixes: - httpAcpBridge.doSpawn newSession-failure cleanup (BkwQA): if `connection.newSession()` throws on a freshly-created channel whose sessionIds set is empty, tear the channel down rather than leaking the empty `qwen --acp` child in `byWorkspaceChannel` (invisible to `sessionCount` / `maxSessions`). Channels with other live sessions still survive — only the truly-empty case reaps. - httpAcpBridge.detachClient + killSession tombstone (BkwQP): detachClient no longer reaps live sessions. Scenario: A spawns (attached: false, hasn't opened SSE yet), B attaches (attachCount: 1), B disconnects → previous code reaped A's still-valid session. New behavior: * killSession({ requireZeroAttaches: true }) sets `entry.spawnOwnerWantedKill = true` when it bails on attachCount > 0 (instead of just returning). * detachClient ONLY decrements attachCount. It completes the deferred reap only when (spawnOwnerWantedKill && attachCount === 0 && subscriberCount === 0). * Both-disconnected case still works (reap completes via B's detachClient seeing the tombstone). Spawn-owner-alive case no longer reaps. Existing tanzhenxin-issue-2 test rewritten; new test pins the spawn-owner-alive case. - httpAcpBridge.writeTextFile mode preservation (BkwQW): stat the target before writing; if it exists, chmod the tmp file to the preserved mode (and chown owner/group — best-effort, EPERM ignored for non-root). Previously a 0600 secret/config edit would downgrade to umask-default 0644, exposing contents to other local users. - bridge.respondToPermission option-ID validation (BkwQI): new `InvalidPermissionOptionError` thrown when the voter's `optionId` isn't in the set of options the agent originally offered in the `permission_request` event. PendingPermission now carries `allowedOptionIds`. Server route catches the error → 400 (vs. 404 for unknown requestId). Prevents authenticated clients from forging hidden outcomes like `ProceedAlways*` when the prompt's `hideAlwaysAllow` policy intentionally suppressed them. Doc fixes: - httpAcpBridge top-of-file (BkdCg) + types.ts ServeMode (BkdC8): rewrite the "each session spawns its own qwen --acp child" framing to match the actual Stage 1.5 multi-session-per-channel architecture (one child per workspace, sessions multiplex via `connection.newSession()`). * fix(serve): close 4 review threads — close write-mode race + 2 missing tests + 1 doc - writeTextFile mode-bits race (Blehd): the BkwQW fix preserved mode via `chmod` AFTER `fs.writeFile`, leaving a brief window where a `0600` secret-edit was readable at the directory's umask default (commonly `0644`). Now pass `mode` to writeFile directly so the file is CREATED with the preserved mode atomically via the `open(O_CREAT, mode)` syscall. The post-write `chmod` remains as belt-and-suspenders against a tight operator umask (POSIX `mode & ~umask` could drop bits we wanted preserved). - httpAcpBridge.test.ts: new bridge-level test for the BkwQI `InvalidPermissionOptionError` path (Blehk). Forge a vote with an `optionId` not in the agent-offered set; assert the throw AND that the pending permission survives so a valid vote can still resolve it. - server.test.ts: new route-level test for the BkwQI 400 mapping (Blehl). Fake bridge throws `InvalidPermissionOptionError`; assert response is 400 with `code: 'invalid_option_id'`, `requestId`, and `optionId` in the body. - commands/serve --http-bridge help text (Bk59I): updated to reflect Stage 1.5 multi-session — "one `qwen --acp` child per workspace, with multiple sessions multiplexed via the agent's native `newSession()`" (was: "per-session child"). * fix(sdk): close 1 review thread — parseSseStream abort path catches body-read rejection (BlqF_) Some fetch impls (undici on abort) reject the in-flight `reader.read()` with an AbortError after `reader.cancel()` fires. Pre-fix that rejection bubbled to the consumer's `for await`, contradicting the "abort cancels cleanly" public contract — code that called `controller.abort()` to wind a subscription down saw an unexpected throw on the next iteration. Wrap `reader.read()` in try/catch: - if `signal?.aborted` is true → treat the rejection as clean completion (return from the generator) - otherwise re-throw, so real upstream failures (network drop, unexpected close, malformed body) still reach the consumer Two regression tests pin the guard's scope: signal-aborted mid-stream returns cleanly with the frames received so far; a non-abort `streamController.error(...)` still bubbles via `rejects.toThrow`. * fix(serve): close 1 review thread — eventBus eviction detaches abort listener (BmJT1) Pre-fix: `publish()`'s eviction path deleted the sub from `this.subs` but never invoked `dispose()`, leaving the AbortSignal abort-listener registered in `subscribe()` attached. Because the consumer is by definition stalled (that's what caused the overflow), `next()` / `return()` never fire to detach the listener through the iterator path. Closures over the queue + sub stayed live until the AbortSignal itself went out of scope. Under attack (thousands of opened-then-stalled SSE clients), this amplified into significant heap retention. Fix: store `dispose` on `InternalSub` and invoke `sub.dispose()` from the eviction path. The same closure used by the abort listener / the iterator's `next()`/`return()` cleanup now runs through the eviction path too — idempotent through `disposed` so a post-eviction abort or iterator-return is still safe. Regression test pins the post-eviction abort + publish path producing zero side effects. * fix(serve): close 1 review thread — restore double-Ctrl+C force-kill broken by multi-session refactor (BkUyD) The Bd1y6 design promised a second SIGINT/SIGTERM during graceful drain synchronously SIGKILLs every live agent child via `bridge.killAllSync()` before `process.exit(1)` — the operator- visible "kill it now" path for a wedged child ignoring SIGTERM. The Stage 1.5 multi-session refactor (commit 6a170ef8) inadvertently broke this. `shutdown()` snapshots `byWorkspaceChannel` then CLEARS the map BEFORE awaiting the per-child SIGTERM-grace kills (up to ~10s each). If the operator double-taps mid-window, `killAllSync()` snapshotted from the now-empty `byWorkspaceChannel.values()` and silently no-op'd — the for-loop iterated nothing, `process.exit(1)` fired, and any child still inside its SIGTERM grace window was left orphaned with dangling pipes. Exactly the scenario the force-kill path was added to handle. Fix: introduce a separate `liveChannels: Set<ChannelInfo>` as the source of truth for "channels with potentially-alive child processes". Added in `getOrCreateChannel` alongside `byWorkspaceChannel.set(...)`; removed only when `channel.exited` fires (the OS-level "really dead" signal). `killAllSync()` now iterates `liveChannels`, so a mid-shutdown second signal still sees every still-alive child regardless of where the graceful drain currently is. Other paths (`killSession` last-session reap, `channel.exited` crash handler) automatically remove via the same exit-handler hook. Regression test: - Builds two sessions on different workspaces - Replaces each channel's `kill()` with a never-resolving Promise (simulating stuck SIGTERM grace) - Calls `bridge.shutdown()` to enter mid-drain state - Yields twice so shutdown's sync prefix runs (clears byWorkspaceChannel, starts the never-resolving awaits) - Calls `bridge.killAllSync()` — pre-fix this saw an empty `byWorkspaceChannel` and the spy array would have been empty; post-fix both channels' `killSync` is invoked. (tanzhenxin's other observation — channels-package duplicate ACP bridge — is the same architectural concern as chiga0 finding 1+5, already tracked under existing FIXME(stage-1.5) markers. No code change in this commit for that.)	2026-05-13 14:47:47 +08:00
Edenman	533daac316	feat(cli): wrap markdown links in OSC 8 so wrapped URLs stay clickable (#4037) ... * feat(cli): wrap markdown links in OSC 8 so wrapped URLs stay clickable Long URLs the model emits inside `[label](url)` or as bare `https://...` get line-wrapped by the terminal, which prevents most emulators from detecting them as a single clickable region. OSC 8 hyperlinks decouple the link target from the visible label so the entire label remains one clickable target regardless of where it wraps. - Extract the existing OSC 8 helpers from AuthenticateStep into a shared packages/cli/src/ui/utils/osc8.ts util, plus a dependency-free capability detector that honors NO_COLOR / FORCE_COLOR=0 / CI / non-TTY stdout, with FORCE_HYPERLINK=1 and QWEN_DISABLE_HYPERLINKS=1 overrides for explicit opt-in / opt-out. - Wire InlineMarkdownRenderer to wrap markdown link labels and bare autolinks in an OSC 8 envelope when supported. Wrapping happens after the inline link token has been fully matched, so streamed partial chunks cannot split an envelope across flushes. - Fall back to the legacy `label (url)` rendering byte-for-byte when the host terminal does not advertise OSC 8 support. Closes #3954 * fix(cli): harden OSC 8 markdown wrapping after multi-round audit Address findings from a multi-round design and code audit of the OSC 8 hyperlink feature: Design fixes: - Keep the visible `(url)` suffix in supported terminals too — preserves copy-paste UX and lets users preview suspicious URLs before clicking. OSC 8 is now purely additive (byte-identical unsupported output, plus envelope on supported terminals). - Restrict OSC 8 wrapping to http/https/mailto/ftp/sftp/ssh schemes; javascript:/data:/file:/vbscript: fall through unwrapped so the user can read the target. Prompt-injection defense for LLM output. - Reject URLs with whitespace — every terminal treats whitespace in an OSC 8 target as truncation/rejection, which would turn the whole region into an un-clickable trap. - Block OSC 8 inside tmux/screen by default; require `FORCE_HYPERLINK=1` opt-in. The multiplexer hides the host terminal's capabilities, so emitting passthrough escapes on a host without OSC 8 prints garbage. - Version-gate `supportsHyperlinks()` (iTerm ≥3.1, vscode ≥1.72, WezTerm ≥20200620, VTE ≥0.50 with 0.50.0 segfault carve-out), block CI / TEAMCITY / win32 (modulo WT_SESSION/Kitty/Ghostty/DOMTERM), mirror `supports-hyperlinks` semantics. - Extend the link regex to allow one level of balanced parens in the URL group so `[wiki](https://en.wikipedia.org/wiki/Foo_(bar))` isn't truncated at the inner `)`. - Trim trailing sentence punctuation off the OSC 8 *target* for bare URLs (`.`, `,`, `;`, `:`, `!`, `?`, `'`, `"`, `` ` ``) and unbalanced trailing `)]}` so the clickable URL resolves to a real page. - Catch VTE 0.50.0 reported in packed form (`'5000'`) — the original string compare missed it and let the segfault through. Code fixes: - Consolidate `wrapForMultiplexer` with the pre-existing `packages/cli/src/utils/osc.ts` — no more duplicate helpers. - Drop the `supportsHyperlinks` memoization cache so runtime env changes (NO_COLOR / theme toggles) take effect immediately. - Extract `MD_LINK_PATTERN`, `MD_LINK_CAPTURE`, `shouldWrapMarkdownLink`, and `HYPERLINK_ENV_KEYS` into `osc8.ts` so the React and ANSI renderers stay in lockstep. - Hoist `supportsHyperlinks()` once per render (both renderers). - Apply the same OSC 8 treatment to `TableRenderer` so markdown links inside tables are clickable too. - Rewrite `trimTrailingUrlPunctuation` to O(n) by pre-counting opens. Tests cover: balanced parens in URL, dangerous-scheme rejection, whitespace-URL rejection, trailing-punctuation trimming, tmux blocking, version gating (iTerm/WezTerm/vscode/VTE incl. packed form), platform fallbacks, mid-stream chunk balance, byte-identical legacy fallback. * feat(cli): detect Alacritty / Konsole / Warp / JetBrains / mintty for OSC 8 Expand supportsHyperlinks() to recognize five more capable terminals that the original detector silently treated as unsupported: - Alacritty ≥ 0.11 via TERM=alacritty (the issue explicitly calls this one out) - Konsole ≥ 21.04 via KONSOLE_VERSION - WarpTerminal via TERM_PROGRAM=WarpTerminal - JetBrains JediTerm (IDE integrated terminals) via TERMINAL_EMULATOR - mintty (Git Bash on Windows, etc.) via TERM_PROGRAM=mintty Hyper stays auto-detection-off (FORCE_HYPERLINK=1 override) because plugin chains have a long history of breaking escape passthrough. Apple_Terminal stays off because it has no OSC 8 support at all. KONSOLE_VERSION and TERMINAL_EMULATOR added to HYPERLINK_ENV_KEYS so the test isolation list stays in sync. * chore(cli): polish OSC 8 detector after another audit round Address findings from the final multi-round audit pass: - Document `FORCE_HYPERLINK` and `QWEN_DISABLE_HYPERLINKS` in the user-facing env-vars table at docs/users/configuration/settings.md so the new opt-in / opt-out surface is discoverable without grepping source. - Detect Alacritty even when the alacritty terminfo entry isn't installed (a common Linux distro scenario where Alacritty falls back to TERM=xterm-256color). Fall back to ALACRITTY_LOG / ALACRITTY_WINDOW_ID / ALACRITTY_SOCKET — Alacritty sets at least one of these unconditionally since 0.12. - Trim a trailing `>` off the OSC 8 target so CommonMark autolinks (`<https://example.com>`) produce a clickable target that actually resolves instead of 404-ing because of the captured delimiter. - Add OSC 8 / hyperlink env isolation to TableRenderer.test.tsx so a developer running the suite from iTerm2 / WezTerm / Kitty can't leak escape bytes into table output. - Symmetric `isTTY` reset in osc8.test.ts `beforeEach` so the early describes (sanitizer, scheme, trim) don't inherit residual TTY state from a prior test. - Document the deliberate security property of keeping the visible `(url)` suffix in OSC 8 mode (user always reads the destination before clicking) in the SAFE_OSC8_SCHEMES comment. - Collapse the `wrapForMultiplexer` import + re-export to a single `export { wrapForMultiplexer }` after the local import. - Add ALACRITTY_* keys to HYPERLINK_ENV_KEYS so test isolation lists stay complete. Tests cover the new autolink `>` trim, the Alacritty env-var fallbacks, and NBSP / Unicode-whitespace URL rejection. * fix(cli): tighten OSC 8 gating per PR review Two fixes from chiga0's review on PR #4037: 1. Move the non-TTY check above `FORCE_HYPERLINK` so a user with `FORCE_HYPERLINK=1` in their shell profile still gets a clean pipe when they run `qwen | cat` or `qwen > out.txt`. The "non-TTY stdout must suppress escapes" acceptance criterion now holds even under forced enable. 2. Version-gate the Konsole detection at `>= 21.04`. KONSOLE_VERSION is set by every Konsole release including ones that pre-date OSC 8 support, so the existence check alone false-positives on Konsole 20.x. Parse the packed integer (21.04 → 210400) and let older releases fall through to the legacy fallback. Updates the docs row for FORCE_HYPERLINK to make the non-TTY caveat explicit. Splits the prior "FORCE_HYPERLINK + isTTY=false" test into two — one verifying force works on a TTY, one asserting it never escapes the non-TTY guard. Adds a Konsole < 21.04 regression test. * fix(cli): stop auto-detecting Warp Terminal as OSC 8 capable Warp's current rendering engine doesn't honor OSC 8 envelopes — the escape sequence is printed as visible garbage rather than recognized as a clickable hyperlink. Falling through to the legacy `label (url)` rendering avoids the regression on Warp. Users on a Warp build that ever ships OSC 8 support can opt in with `FORCE_HYPERLINK=1`; the case will be reinstated in the switch when Warp lands real support upstream. Test flipped from "enabled" to "not auto-detected, FORCE_HYPERLINK opts in" to lock the new behavior. * feat(cli): drop visible (url) suffix when OSC 8 wrapping is active In the originally shipped renderer, `[label](url)` was rendered as `label (url)` even when OSC 8 wrapped the region. With long URLs that's clutter for no benefit — capable terminals already expose the target via hover / status bar / right-click "copy link" without needing the URL in the visible stream. When `shouldWrapMarkdownLink(url, canHyperlink)` returns true, the React renderer and the ANSI table renderer now emit only the markdown label (link-colored), with the OSC 8 envelope pointing at the full URL. Empty labels (`[](url)`) fall back to using the URL as the visible label so the link stays discoverable. When the predicate returns false (unsupported terminal, unsafe scheme, whitespace URL) the legacy `label (url)` rendering is preserved byte-for-byte — the scheme allowlist still guarantees the user sees the destination before any click on a `javascript:` / `data:` / etc. link. Tests updated to assert label-only visible bytes in wrap mode and an empty-label fallback case added. Comment block in `osc8.ts` updated to reflect the new visibility contract. * fix(cli): strip C1 controls in OSC 8 sanitizer sanitizeForOsc() only removed C0 + DEL, so 8-bit ST (\x9c) and 8-bit OSC (\x9d) bytes could still survive inside an OSC 8 target. On terminals that honor C1 controls, those bytes act as the same sequence boundaries as their two-byte ESC counterparts, which defeats the escape-injection hardening this helper is meant to provide. Extend the regex to also strip \x80-\x9f and cover the case with a test. * fix(cli): harden OSC 8 link sanitization and tighten gating Three independent issues found while auditing the markdown OSC 8 path: 1. sanitizeForOsc() previously left Unicode bidi controls (U+200E/F, U+202A-E, U+2066-9) and line/paragraph separators (U+2028/9) intact. A model-emitted RLO in a link label visually reverses trailing bytes, spoofing the host the user thinks they're clicking — exactly the click-deception attack the scheme allowlist is meant to block, just moved from the URL into the visible label. Extend the regex to strip those bytes too. 2. The visible label rendered inside the OSC 8 envelope went straight to the terminal without sanitization, so even with (1) the spoof would still land. Wire sanitizeForOsc() over the linkText in both InlineMarkdownRenderer and TableRenderer's OSC 8 branches. The legacy `label (url)` branches stay untouched so today's unsupported-terminal output remains byte-identical. 3. AuthenticateStep emitted osc8Hyperlink(authUrl) unconditionally, leaking escape bytes into pipes / non-OSC-8 terminals — inconsistent with the suppression contract documented for the rest of the PR. Gate it on supportsHyperlinks() so it falls back to the bare URL. Test coverage added: - sanitizeForOsc bidi/line-separator strip - bidi spoof in the rendered markdown label - byte-equality fallback on unsupported terminals - TableRenderer markdown link → OSC 8 (positive, fallback, unsafe scheme, bidi-spoof) — the table renderer had zero OSC 8 coverage before this. * fix(cli): keep `(url)` visible when an OSC 8 label looks like a different URL Adversarial round-2 audit identified a label-as-URL deception attack: when the OSC 8 branch elides the `(url)` suffix and shows only the clickable label, a model-emitted `[https://google.com](https://attacker.com)` renders a "google.com" link that resolves to attacker.com. Pre-OSC-8 rendering kept `(url)` visible so the user could see the real target; hiding it makes the click-deception case land. Mitigation: a new `labelMayDeceive(label, url)` predicate. When the label contains a URL-shaped substring AND it doesn't equal the actual target, both renderers keep the legacy `(url)` suffix while still emitting the OSC 8 envelope — the link stays clickable, the user still sees where the click goes. Heuristic is permissive on purpose: false positives are harmless (redundant `(url)` on niche labels), false negatives let a real spoof through. Tests: positive (mismatched URL labels), negative (label == url, plain text labels), in both InlineMarkdownRenderer and TableRenderer. * fix(cli): catch bare-host label deception in OSC 8 wrapping Round-3 audit caught a false-negative in labelMayDeceive: the `://` substring check only flagged labels with a fully-qualified URL shape. The most natural markdown spoof — `[google.com](https://evil.com)` — uses a bare host as the label and slipped past, so the OSC 8 branch elided the `(url)` suffix and rendered a clickable "google.com" that resolved to evil.com. Add a third detection pattern: extract host-like tokens from the label (`name.tld` with an alphabetic 2+ char TLD), and flag the link when any of them doesn't equal the URL's parsed hostname. Plain labels like `docs` / `click here` don't match the regex, version strings like `1.2.3` are skipped (last segment is numeric), and `[google.com](https://google.com)` is honest rendering — none of these get flagged. ASCII-only matching means an IDN-homograph attack on a bare-host label (Cyrillic `о`) still escapes this layer; the fully-qualified form of the same attack is still caught by the existing `://` rule, which is the only form an LLM is realistically likely to emit. Tests cover: bare-host mismatch, punycode IDN target, same-host / different-path, label==target negative, plain-text labels, version strings. * fix(cli): handle mailto: target in labelMayDeceive Round-4 audit caught a false positive: `new URL('mailto:x@y').hostname` is empty, so targetHostname() returned undefined and the defensive `return true` branch fired any time a mailto label contained an email-shaped string. A perfectly honest `[support@example.com](mailto:support@example.com)` was being flagged as deceptive and getting a redundant `(url)` suffix on capable terminals. Special-case mailto: by pulling the domain from after the `@` in the URL pathname, matching what the user would compare against. A mismatched mailto (e.g. `[support@example.com](mailto:abuse@evil.com)`) still flags correctly. Also drop a dead `HOST_LIKE_RE.lastIndex = 0` reset — `.match()` doesn't consult lastIndex, so the line was a no-op. * fix(cli): catch IPv4-literal label deception in OSC 8 wrapping Round-5 audit found another bare-host bypass: a label like `[1.1.1.1](https://attacker.com)` (or any other dotted-quad such as `[192.168.1.1]` / `[8.8.8.8]`) escaped labelMayDeceive because the existing host regex anchors on a 2+ alphabetic TLD. The user would see a clickable "1.1.1.1" that resolves to attacker.com with no visible target. Add a separate dotted-quad pattern and combine it with the host-token list before comparing against the URL's hostname. False-positive surface is small (over-permissive on octet ranges is harmless — worst case is an extra `(url)` suffix on a label like `999.999.999.999`). Tests cover mismatched IPv4, IPv4 spelled inside surrounding text, and label-equals-target IPv4 (which must NOT flag). * fix(cli): sanitize URL when rendered as visible text in OSC 8 path Two PR review findings: 1. config-utils.ts dropped the `resolvePath(...)` call (and its import) that origin/main introduced in #4045 for tilde / relative `cwd` paths in channel configs. The auto-merge silently reverted it the same way it did `packages/channels/base/src/index.ts`. Restore main's content. 2. Anti-spoof sanitization was only applied to `linkText`, but the OSC 8 render path emits the URL as visible text in two places that bypassed it: - empty-label fallback `safeLabel || url` — `[](https://x/a‮evil)` would print the URL with RLO intact even though the OSC target was sanitized. - deceptive-label `(url)` suffix. Compute `safeUrl = sanitizeForOsc(url)` once in the OSC 8 branch and use it for both visible-URL renderings. The OSC target inside `osc8Open` keeps the raw URL (sanitization happens inside the helper anyway). Same fix mirrored in `TableRenderer.tsx`. The legacy `label (url)` branch on unsupported terminals stays untouched so its byte-identical-fallback contract holds. Test added: `[](https://example.com/a‮evil)` round-trips through the renderer with the RLO stripped from both the OSC target and the visible URL fallback.	2026-05-13 11:37:27 +08:00
jinye	aecea70114	docs(telemetry): align config and docs semantics for target, outfile, and CLI flags (#4066) ... * docs(telemetry): align config and docs semantics for target, outfile, and CLI flags - Remove stale warning note "This feature requires corresponding code changes" — the OTLP implementation is now complete (#3779, #4061) - Clarify that `target` is an informational destination label and does not control exporter routing; `otlpEndpoint` or `outfile` must be set to configure where data is sent - Mark `--telemetry-target` CLI flag as deprecated in the configuration table to match the deprecateOption() call in cli/src/config/config.ts - Fix `outfile` / `QWEN_TELEMETRY_OUTFILE` descriptions: remove the incorrect "when target is local" qualifier — outfile overrides OTLP export regardless of the target value - Simplify the file-based output example by removing the now-redundant `"target": "local"` and `"otlpEndpoint": ""` fields Closes the "Align telemetry config and docs semantics for target, useCollector, otlpEndpoint, otlpProtocol, and outfile" checklist item in #3731. 🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code) * docs(telemetry): address Copilot review comments on outfile and target descriptions - Fix outfile table row in telemetry.md: "overrides `otlpEndpoint`" → "overrides OTLP export" (outfile disables all OTLP exporting, not just the base endpoint) - Use fully-qualified setting names (`telemetry.otlpEndpoint`, `telemetry.outfile`) in the target description in settings.md for consistency with the rest of the table 🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code) * docs(telemetry): update QWEN_TELEMETRY_TARGET env var description and add outfile note - Align QWEN_TELEMETRY_TARGET env var description with the updated telemetry.target setting semantics (informational label, not routing) - Add a note after the file-based output example clarifying that outfile automatically disables OTLP export 🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)	2026-05-13 08:27:41 +08:00
jinye	32a49b4ddb	refactor(telemetry): remove dead useCollector setting and unreachable TelemetryTarget.QWEN (#4061) ... useCollector was plumbed through config (interface, constructor, getter, env var resolution) but never consumed by the telemetry SDK — the setting had no runtime effect. TelemetryTarget.QWEN existed in the enum but parseTelemetryTargetValue() only accepted 'local' and 'gcp', making 'qwen' unreachable (it would throw FatalConfigError). Remove both dead code paths along with their tests and documentation. Part of #3731	2026-05-11 23:22:53 +08:00
ChiGao	cadda23782	chore(deps): upgrade ink 6.2.3 → 7.0.2 + bump Node engine to 22 (#3860) ... * chore(deps): upgrade ink 6.2.3 -> 7.0.2 + bump Node engine to 22 ink 7 requires Node >=22 and react-reconciler 0.33 with React >=19.2, so this PR also bumps: - Node engines (root + cli + core) 20 -> 22 - React/react-dom 19.1 -> 19.2.4 (pinned exact via overrides to keep the transitive React graph deduped to a single instance) - @types/node pinned to 20.19.1 via overrides to avoid an unrelated Dirent NonSharedBuffer regression in sessionService tests - @vitest/eslint-plugin pinned to 1.3.4 to avoid an unrelated lint regression introduced by the 1.6.x rule additions - react-devtools-core 4.28 -> 6.1 (ink 7 peerOptional requires >=6.1.2) - ink hoisted to root devDeps so workspace-private peer-dep contention doesn't push ink-link/spinner/gradient into nested workspace installs (which would skip transitive resolution for terminal-link) Workflow + image + installer alignment: - .nvmrc 20 -> 22 - Dockerfile node:20-slim -> node:22-slim - CI test matrix drops 20.x (keeps 22.x + 24.x) - terminal-bench workflow Node 20 -> 22 - Linux/Windows install scripts upgrade their Node version targets Documentation alignment: - README.md badge + prerequisites - AGENTS.md, CONTRIBUTING.md, docs/users/quickstart.md, docs/users/configuration/settings.md, docs/developers/contributing.md, docs/developers/sdk-typescript.md, docs/users/extension/extension-releasing.md, packages/sdk-typescript/README.md, packages/zed-extension/README.md, scripts/installation/INSTALLATION_GUIDE.md Test gating: - Two AuthDialog/AskUserQuestionDialog tests that drive <SelectInput> through ink-testing-library now race ink 7's frame-throttled input delivery and land on the wrong option. The maintainers had already marked one of them unreliable (skip on Win32 + CI+Node20). Extend that gate to cover all environments until upstream ink-testing-library ships an ink-7-compatible release that flushes input deterministically. The other test now uses it.skip with the same comment. No business code changes. Verified locally: - npm run typecheck across all workspaces: clean - npm run lint (root): clean - npm run test --workspaces: cli 312/312 files, 4918 passed, 9 skipped core 266/266 files, 6836 passed, 3 skipped webui 6/6, 201 passed sdk 40/40, 283 passed, 1 skipped - npm ls ink: single ink@7.0.2 instance across all peer deps - single react@19.2.4 instance Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * chore: align Node 22 floor across all shipping artifacts Reviewer (tanzhenxin) flagged five surfaces where the >=22 engine bump leaked: SDK package metadata, web-templates engines, /doctor runtime check, main bundler target, and SDK bundler target. Each was a separate escape hatch letting Node 18/20 consumers install or run the artifact on an unsupported runtime. - packages/sdk-typescript/package.json: engines.node >=18.0.0 -> >=22.0.0 - packages/web-templates/package.json: engines.node >=20 -> >=22 - packages/cli/src/utils/doctorChecks.ts: MIN_NODE_MAJOR 20 -> 22 - esbuild.config.js: target node20 -> node22 (main CLI bundle) - packages/sdk-typescript/scripts/build.js: target node18 -> node22 (esm + cjs) - packages/cli/src/utils/doctorChecks.test.ts: rename test label to v22+ Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * ci(e2e): bump E2E workflow Node matrix to 22.x Reviewer (tanzhenxin) flagged that e2e.yml still pinned node-version 20.x while root engines is now >=22, so every E2E run on push would either fail at npm ci with engine error or silently exercise the bundle on a runtime that's no longer in ci.yml's test matrix. The macOS job in the same workflow already reads .nvmrc (which is 22) so this only updates the Linux matrix. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(deps): drop root wrap-ansi override so ink 7 gets its declared dep Reviewer (tanzhenxin) flagged that the root overrides.wrap-ansi: 9.0.2 predates this upgrade and forces every consumer (including ink) to v9, while ink 7 declares wrap-ansi: ^10.0.0. The lockfile had no nested install under node_modules/ink/, so ink 7 was running with a transitive dep one major below its declared minimum. Dropping the global override lets ink resolve its own wrap-ansi 10 nested install (now visible in the lockfile under node_modules/ink/node_modules/wrap-ansi), while the cli package's own direct `wrap-ansi: 9.0.2` dependency keeps the cli code path (TableRenderer.tsx) on the version it has been tested against. The nested cliui override is preserved for yargs which still needs v7. Verified via `npm ls wrap-ansi`: - ink@7.0.2 -> wrap-ansi@10.0.0 (newly nested) - @qwen-code/qwen-code -> wrap-ansi@9.0.2 (unchanged) - yargs/cliui -> wrap-ansi@7.0.0 (unchanged) Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * test(InputPrompt): un-skip placeholder ID reuse after deletion Reviewer (tanzhenxin) flagged that the new it.skip on the 'should reuse placeholder ID after deletion' test was undisclosed in the PR description and removed coverage of real product behavior (freePlaceholderId / bracketed-paste backspace path) without a TODO(#NNNN) link. Their argument was sound: the skip rationale pointed at ink 7's input throttle, but this same file just bumped the wait helper from 50ms to 150ms specifically to give ink 7 frame time. Re-running the test under the bumped wait shows it passes reliably (5/5 runs in the full-file context, 9/10 alone), so the skip was masking the throttle-flake that the wait bump already addresses, not a real product bug. Drop the it.skip and the now-stale comment so coverage of the freePlaceholderId reuse logic is restored. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * test(InputPrompt): bump first prompt-suggestion test wait to 350ms The "accepts and submits the prompt suggestion on Enter when the buffer is empty" test is the first in its describe block, so it pays the renderer cold-start cost. On macOS-22.x CI runners that pushes the Enter → onSubmit microtask past the default 150ms post-Enter wait. Match the 350ms initial render wait used immediately above to absorb the cold start. * Revert "test(InputPrompt): bump first prompt-suggestion test wait to 350ms" This reverts commit 6add83b62e. * test(InputPrompt): wait for followup suggestion debounce before pressing Enter Root cause of the failing prompt-suggestion tests on macOS and Windows CI is not flaky timing of the test post-Enter wait — it's the 300ms debounce inside createFollowupController.setSuggestion (shared core). The Enter handler reads followup.state.isVisible synchronously, so if the debounce timer has not fired before stdin.write('\\r'), the suggestion path is skipped and onSubmit never runs. No amount of post-Enter wait can recover from that — the keypress was already processed against stale state. The original wait(350) only left ~50ms margin over the 300ms debounce, which ink 7 / React 19.2 mount overhead consumed on slow Windows runners. Bump the initial wait to 700ms (named SUGGESTION_VISIBLE_WAIT_MS) to give the debounce timer + cold-start render a generous buffer. Apply to the two sibling tests too — without the wait their "does not accept" assertions pass trivially when suggestion is never visible, which is a false green that hides regressions in the actual reject path. * fix(deps): align cli wrap-ansi with ink 7 (9.0.2 -> ^10.0.0) Ink 7 ships its own wrap-ansi@10. CLI's direct dep was pinned to 9.0.2, causing two copies of wrap-ansi in node_modules and a potential drift in CJK width / ANSI handling between ink's internal text wrapping and our TableRenderer. Upgrading the CLI's direct dep to ^10.0.0 lets npm dedupe to a single wrap-ansi@10 used by both ink and TableRenderer. API surface is identical; the only documented behaviour change is that tabs are expanded to 8-column tab stops before wrapping, which TableRenderer doesn't feed in. TableRenderer test suite (43 tests) passes against wrap-ansi@10. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * chore(deps): document @types/node 20.x pin in overrides The override pinning @types/node to 20.19.1 (while engines require Node >=22) is intentional: bumping to @types/node@22.x re-introduces a Dirent<NonSharedBuffer> type regression that breaks @qwen-code/qwen-code-core/sessionService tests. Add a sibling "//@types/node" note inside `overrides` so future maintainers see the rationale and know when to revisit the pin without having to dig through PR #3860 history. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * test(AskUserQuestionDialog): link skipped Submit-tab test to tracking issue The 'shows unanswered questions as (not answered) in Submit tab' test was switched to `it.skip` in the ink 7 upgrade because `ink-testing-library@4.0.0` doesn't flush input deterministically through ink 7's 30fps throttle. Add a `// TODO(#4036):` marker so the skip is greppable and can be re-enabled once upstream ships an ink-7-compatible release. Refs #4036 Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(deps): move @types/node pin comment out of overrides block npm's `overrides` field requires every key to be a real package name — the `"//@types/node"` comment-key added in 205855875 trips Arborist with "Override without name" and breaks `npm ci` across all CI jobs. Move the explanation to a sibling top-level `"//overrides"` key, which npm ignores at the document root. Same documentation value, no override-parser collateral damage. --------- Co-authored-by: 秦奇 <gary.gq@alibaba-inc.com> Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-05-11 17:29:50 +08:00
pomelo	7e11428545	refactor(cli): remove legacy qwen auth CLI subcommand, redirect to /auth TUI dialog (#3959) ... The `qwen auth` CLI subcommand (with subcommands like qwen-oauth, coding-plan, api-key, openrouter, status) has been superseded by the richer /auth TUI dialog introduced in the provider-first auth registry (#3864). Running `qwen auth` now prints a deprecation notice pointing users to the /auth TUI dialog (interactive), env vars (CI/headless), or /doctor (status check). Changes: - Replace auth.ts with a stub that prints a removal notice and exits - Delete handler.ts (734 lines), interactiveSelector.ts, and their tests (interactiveSelector.test.ts, openrouter.test.ts, status.test.ts) - Update /auth slash command to handle non-interactive/ACP modes gracefully - Enrich /doctor auth check with provider-aware diagnostics using findProviderByCredentials - Mark `auth` as a subcommand that handles its own exit in config.ts Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-05-11 16:44:09 +08:00
Shaojin Wen	e2f7661ef1	feat(cli): Ctrl+B promote keybind (#3831 PR-3 of 3) (#3969) ... * feat(cli): Ctrl+B promote keybind — wire UI to PR-2's promoteAbortController (#3831 PR-3 of 3) Final piece of the foreground → background promote feature. PR-1 (#3842) landed the `signal.reason` foundation; PR-2 (#3894) wired `shell.ts` to detect a `{ kind: 'background' }` abort, snapshot output, register a `BackgroundShellEntry`, and stash the promote `AbortController` on `TrackedExecutingToolCall`. This PR exposes the user-visible surface: pressing Ctrl+B during an in-flight foreground shell command transfers ownership to a background task the user can inspect via `/tasks` or stop via `task_stop`. ## Changes - `keyBindings.ts`: new `Command.PROMOTE_SHELL_TO_BACKGROUND` bound to `Ctrl+B`. JSDoc explains the no-shell-running no-op semantics. - `useReactToolScheduler.ts`: project `promoteAbortController` from the core's `ExecutingToolCall` through `TrackedExecutingToolCall` so the React layer (AppContainer keypress handler) can find it by callId without re-plumbing through the scheduler. - `AppContainer.tsx`: `handleGlobalKeypress` gains a `PROMOTE_SHELL_TO_BACKGROUND` branch that walks `pendingToolCallsRef.current` (the ref, not the destructured array — keeps the deps list stable so the handler isn't re-bound on every tool-call status update), finds the executing tool call with a defined `promoteAbortController`, calls `.abort({ kind: 'background' })`, and returns early. No-op when no foreground shell is executing — Ctrl+B then falls through to the input layer's existing cursor-left binding. - `keyboard-shortcuts.md`: documents Ctrl+B with explicit fall-through behavior so the conflict with the prompt-area cursor-left binding is intentional + understandable. ## Tests - `keyMatchers.test.ts` (+1): Ctrl+B positive / bare-b + meta+b + Ctrl+other negatives. - `AppContainer.test.tsx` (+2): - **Ctrl+B promotes** — pendingToolCalls includes an executing shell with a stubbed `AbortController` + spy; firing Ctrl+B asserts `abort({ kind: 'background' })` is called once. - **Ctrl+B no-op** — empty `pendingToolCalls` + Ctrl+B must NOT throw (pins the safety contract for the typing-mid-prompt case where the input layer's own Ctrl+B should still fire). - 37/37 keyMatchers + 58/58 AppContainer pass; tsc + ESLint clean. ## E2E (manual, PR description guidance) The unit / integration tests cover the keybind → abort wiring and the promote handler's downstream behavior (PR-2's tests). Real-PTY E2E is intentionally manual since headless test infrastructure doesn't drive a real shell child + Ctrl+B keystroke; documented in the PR description checklist. Closes the 3-PR sequence for #3831 (Phase D part b of #3634). * fix(cli): #3969 review wave — broadcast comment + debug log + redundancy 5 #3969 review threads addressed: - **AppContainer.tsx Ctrl+B handler**: documented the KeypressContext.broadcast caveat (after `return`, the same Ctrl+B is still dispatched to text-buffer cursor-left + DebugProfiler; visible cursor-left side effect is cosmetic) so future readers understand why the prompt cursor moves on a successful promote. Added `debugLogger.debug` calls on both branches (matched callId on success; streamingState + pendingToolCalls.length on no-op fall-through) so "Ctrl+B doesn't work" reports are debuggable. - **useReactToolScheduler.ts TrackedExecutingToolCall**: dropped the redundant `pid?` and `promoteAbortController?` declarations — both come through the `& ExecutingToolCall` intersection unchanged. Fixed the JSDoc that wrote `{ kind: 'background', shellId }`: callers don't generate `shellId` (it's optional on the abort-reason union and `handlePromotedForeground` produces it downstream). The corresponding executing branch in `toolCallsUpdateHandler` no longer projects pid / promoteAbortController explicitly — `...coreTc` already spreads them; the explicit-undefined clearing in the non-executing branch is also dropped (those fields aren't on coreTc when status !== 'executing', so `...coreTc` doesn't carry them). - **AppContainer.test.tsx**: replaced two `as unknown as Key` double-casts with direct `: Key` annotations on the literal — the object already conforms to the Key interface, double-cast was bypassing type safety needlessly. Tests: 37/37 keyMatchers + 58/58 AppContainer pass; tsc + ESLint clean. No behavior change beyond the new debug log lines. * fix(cli): #3969 wave — tool-name guard + non-shell test + defensive clear 3 #3969 review threads addressed; 1 deferred: - AppContainer.tsx: Ctrl+B `find()` predicate now also checks `tc.request.name === ToolNames.SHELL` before matching the executing tool call. Defense-in-depth — today only the shell tool wires `promoteAbortController`, but a future copy-paste / type confusion that adds the property to a non-shell tool would otherwise let Ctrl+B mistakenly fire `abort({kind:'background'})` on a tool whose service has no promote-handoff handler. - useReactToolScheduler.ts: re-added explicit `pid: undefined` and `promoteAbortController: undefined` to the non-executing return. Previously dropped on the assumption that `...coreTc` doesn't carry these fields when the status isn't `executing` — true today, but the explicit clearing is defense-in-depth against a future core change that adds either field to a non-executing status type (would surface as a stuck PID display or a Ctrl+B handler that matches a no-longer-executing tool call). - AppContainer.test.tsx: replaced the placeholder "no-op when no pending tool calls" framing on the empty-array case (it does exercise the `executing-status` predicate but NOT the tool-name guard) with TWO tests: 1. existing empty-array no-throw test (renamed for clarity) 2. NEW: executing non-shell tool with a hostile-shape `promoteAbortController` — asserts `abortSpy` is NOT called. This is the regression test for the new tool-name guard above. Tests: 61/61 AppContainer.test.tsx pass; tsc + ESLint clean. Deferred to follow-up (replied + tracked): - `debugLogger.debug` is file-only; success-path "agent unblocks + next message says 'promoted to bg_xxx'" is the user-visible signal. Adding a synthetic history item or stderr line for the gap between keypress and agent message conflicts with Ink rendering and is better as a focused UX PR. * test(cli): pin inheritance of pid + promoteAbortController via type assertions #3969 review: the earlier "redundant declaration" review removed the explicit `pid?: number` and `promoteAbortController?: AbortController` from `TrackedExecutingToolCall`, relying on the `& ExecutingToolCall` intersection to inherit them. Current review flags the type-safety regression: if core renames or removes either field, the React-side build won't catch it locally — Ctrl+B handler silently breaks at runtime. Compromise: keep the type minimal (no re-declaration noise the prior review flagged) but add compile-time `extends keyof ExecutingToolCall` assertions that fail loudly + locally if either field disappears. The assertions are evaluated at compile time and zero-cost at runtime; the dummy `const` pins them so they aren't dead code. 61/61 AppContainer tests pass; tsc clean.	2026-05-11 14:03:38 +08:00
易良	cb7059f54d	feat(installer): add standalone archive installation (#3776) ... * feat(installer): add standalone archive installation * fix(installer): harden standalone archive installs * fix(installer): address standalone review findings * chore(installer): clarify review followups * fix(installer): stabilize standalone script checks * chore(installer): remove internal planning docs * chore(installer): simplify standalone release review fixes * test(installer): add Windows batch install smoke * test(installer): fix Windows batch smoke quoting * test(installer): preserve Windows cmd quotes * fix(installer): use robust Windows checksum hashing * ci: narrow installer debug matrix * fix(installer): address standalone review hardening * fix(installer): avoid Windows validation parse errors * fix(installer): simplify Windows option validation * fix(installer): harden standalone review fixes	2026-05-11 13:25:48 +08:00
Yan Shen	9bd5a0180b	feat(cli): core built-in i18n coverage (#3871) ... * feat(i18n): expand built-in locale coverage * feat(cli): add dynamic slash command translation * test(cli): stabilize session picker assertions * fix(core): close jsonl readers before cleanup * fix: address i18n review regressions * fix(cli): address dynamic i18n review findings * fix(cli): address i18n review follow-ups * fix(cli): address i18n review feedback * test(cli): align i18n parity coverage with strict locales * fix(cli): address i18n review findings	2026-05-10 22:35:03 +08:00
tanzhenxin	78ad595581	feat(core): support QWEN_HOME env var to customize config directory (#2953) ... * feat(core): support QWEN_CONFIG_DIR env var to customize config directory Allow users to override the default ~/.qwen config directory location via the QWEN_CONFIG_DIR environment variable. This enables users on dev machines with external disk mounts or custom home directory layouts to persist config at a location of their choosing. Changes: - Add QWEN_CONFIG_DIR check to Storage.getGlobalQwenDir() (absolute and relative path support) - Eliminate 11 redundant '.qwen' constant definitions across packages - Replace 16+ direct os.homedir() + '.qwen' path constructions with Storage.getGlobalQwenDir() calls - Inline env var checks for packages that cannot import from core (channels, vscode-ide-companion, standalone scripts) - Add unit tests for the new env var behavior - Project-level .qwen/ directories are NOT affected Closes #2951 * fix(core): use path.resolve/join in QWEN_CONFIG_DIR tests for Windows compat Hardcoded Unix paths like '/tmp/custom-qwen/settings.json' fail on Windows where path APIs produce backslash separators. Use path.resolve() for inputs and path.join() for assertions so the tests pass cross-platform. * test(cli): remove flaky 'should keep restart prompt when switching scopes' test Timing-sensitive UI test that fails intermittently on Windows CI due to async ANSI output not settling within the wait window. * feat(core): route remaining hardcoded ~/.qwen/ paths through Storage.getGlobalQwenDir() Update channel status, memory command, extension storage, skills discovery, and memory discovery to use Storage.getGlobalQwenDir() instead of hardcoded os.homedir()/.qwen paths, ensuring QWEN_CONFIG_DIR env var is respected throughout the codebase. * fix(tests): mock os.homedir before makeFakeConfig for Storage.getGlobalQwenDir Storage.getGlobalQwenDir() is now called during Config construction, which requires os.homedir() to be mocked before makeFakeConfig() is called. Also mock Storage.getGlobalQwenDir in memoryCommand tests since it uses a cross-package import that vi.spyOn doesn't intercept. * fix(core): respect QWEN_CONFIG_DIR for .env discovery and install source findEnvFile() walk-up would find legacy ~/.qwen/.env before checking QWEN_CONFIG_DIR/.env when the workspace was under $HOME. Skip the legacy path when a custom config dir is set so the fallback picks up the correct file. Also add a legacy fallback in readSourceInfo() since the installer always writes source.json to ~/.qwen/ regardless of QWEN_CONFIG_DIR. * refactor(core): rename QWEN_CONFIG_DIR to QWEN_HOME and fix runtime path resolution Rename the env var before it ships (zero existing users) to match the convention of CARGO_HOME, GRADLE_USER_HOME, etc. — "HOME" means "root of all tool state", not just config. Key changes: - Rename QWEN_CONFIG_DIR → QWEN_HOME across all packages and scripts - Add shared path utils in vscode-ide-companion and channels/base to eliminate scattered inline env var resolution - Fix runtime path mismatch: IDE lock files and session paths in the vscode extension now route through getRuntimeBaseDir() (checking QWEN_RUNTIME_DIR first), matching core Storage behavior - Fix telemetry_utils.js otel path to check QWEN_RUNTIME_DIR for tmp/ - Add E2E integration tests for QWEN_HOME scenarios * fix(core): address critical review issues for QWEN_HOME support Pass resolved QWEN_HOME as a dedicated QWEN_DIR sandbox parameter so macOS Seatbelt profiles allow writes to custom config directories. Fix hookRunner treating signal-killed hooks as success by using ?? -1 instead of || 0. Add QWEN_HOME and QWEN_RUNTIME_DIR to the env vars documentation table. * fix(sandbox): whitelist QWEN_RUNTIME_DIR in macOS Seatbelt profiles When QWEN_RUNTIME_DIR is set separately from QWEN_HOME, the sandbox was blocking writes to the runtime directory (debug logs, chat history, IDE locks, sessions). Pass RUNTIME_DIR as a sandbox parameter and add the corresponding subpath rule to all six .sb profiles. * fix(core): add tilde expansion to QWEN_HOME and align satellite path helpers - Extract resolvePath() from resolveRuntimeBaseDir() so QWEN_HOME gets the same ~/tilde expansion that QWEN_RUNTIME_DIR already had. - Port resolvePath() to vscode-ide-companion and channels/base mirrors, fixing tilde handling in getRuntimeBaseDir() for the IDE companion. - Add missing os.tmpdir() fallback in channels/base getGlobalQwenDir(). - Add unit tests for tilde expansion in QWEN_HOME. - Clarify prompts.ts comment that system.md default is global, not project-level. * fix(core): add tilde expansion to scripts and fix extension cache QWEN_HOME support Add resolvePath() helper to standalone JS scripts (sandbox_command.js, telemetry.js, telemetry_utils.js) so QWEN_HOME=~/custom expands consistently with core Storage.resolvePath(). Fix ExtensionManager.refreshCache() to use ExtensionStorage.getUserExtensionsDir() instead of hardcoded os.homedir(), so extensions installed under a custom QWEN_HOME are discoverable. * test: remove flaky InputPrompt tab-suggestion test on Windows * test: remove flaky tests that fail intermittently on Windows Removes 'does not accept the prompt suggestion on shift+tab' from InputPrompt.test.tsx and 'should keep restart prompt when switching scopes' from SettingsDialog.test.tsx. Both have been observed to fail intermittently on the Windows CI workers; the underlying behaviors are covered by adjacent assertions and end-to-end tests. * revert(core): keep system.md path project-local under .qwen/ The QWEN_HOME refactor incorrectly routed the QWEN_SYSTEM_MD default path through Storage.getGlobalQwenDir() (i.e. ~/.qwen/system.md or $QWEN_HOME/system.md). The original semantics — inherited from the upstream Gemini-CLI sync — are project-local: <cwd>/.qwen/system.md. System-prompt customization is intentionally per-project so that each repository can ship its own override without global side effects. Users who want a global override can still set QWEN_SYSTEM_MD to an absolute path. This revert keeps that behavior intact while leaving the rest of the QWEN_HOME plumbing (settings, credentials, extensions, skills, memory) unchanged. * refactor(core): unify QWEN_CONFIG_DIR into the canonical QWEN_DIR Three definitions of the literal '.qwen' string existed across the codebase: - QWEN_DIR in config/storage.ts (canonical, used by the Storage class) - QWEN_CONFIG_DIR in memory/const.ts - QWEN_CONFIG_DIR in tools/memory-config.ts (a near-clone of the above) The QWEN_CONFIG_DIR name also collided with a former env-var name (now renamed to QWEN_HOME on this branch), making it ambiguous whether call sites referred to a configurable env var or a hardcoded directory name. Drop the duplicates and route the only call sites (prompts.ts and its test) through QWEN_DIR from config/storage.ts. The mock factory in config.test.ts is updated to no longer expose the removed export. * fix(integration-tests): use 'extensions list' to trigger settings migration Tests 2b and 3a in cli/qwen-config-dir.test.ts relied on running \`qwen --help\` to invoke loadSettings() (and thus the V1→V3 settings migration). That worked when loadSettings() ran before parseArguments() in the CLI startup sequence. Main has since flipped the order: parseArguments() runs first, and yargs intercepts --help and exits the process before loadSettings() is reached, so migration never runs and the tests' migration probe always reads back V1. Switch to \`qwen extensions list\` instead. It is a yargs subcommand that runs through main() to loadSettings() without requiring an API key, so migration runs as expected. Update the inline comments to document why --help cannot be used and why this command works. * fix(memory): route auto-memory base dir through Storage.getGlobalQwenDir() The auto-memory subsystem (introduced on main in #3087) computed its base directory by hardcoding path.join(os.homedir(), QWEN_DIR). That bypassed QWEN_HOME entirely, so global auto-memory artifacts always landed in ~/.qwen/projects/... regardless of the user's configured QWEN_HOME path. Route the default through Storage.getGlobalQwenDir() so QWEN_HOME is honored. The QWEN_CODE_MEMORY_BASE_DIR test override stays as the highest-priority short-circuit. Discovered while running the QWEN_HOME e2e test plan against the merged branch — Group B test B3 (memory tool writes to QWEN_HOME) was the only failing scenario across A/B/C/D groups. * fix(cli): treat custom QWEN_HOME .env as user-level When QWEN_HOME points to a directory whose path does not contain `.qwen` (e.g., `/tmp/qwen-home`), the global `.env` was misclassified as a project-level env file. As a result, default-excluded variables such as `DEBUG` and `DEBUG_MODE` were silently dropped even though they came from the user-level config directory. The classification now reuses the same user-level path set computed by `findEnvFile`, so any `.env` inside the resolved global Qwen directory (or directly under `~/`) is recognized as user-level. Also drop the misleading "does not expand `~`" note from the QWEN_HOME documentation — `Storage.getGlobalQwenDir` does expand leading tildes via `Storage.resolvePath`. * fix(cli): drop legacy .qwen substring check from env-file classification The user-level env-file detection now keys solely off the precomputed user-level path set, which already covers ~/.env and ${QWEN_HOME}/.env. The legacy substring fallback misclassified <repo>/.qwen/.env as user-level, so excludedEnvVars no longer applied to it. * fix(core): align plain-text hook output with documented exit-code semantics Per docs/users/features/hooks.md, only exit code 2 is a blocking error; all other non-zero exit codes are non-blocking and execution should continue. The plain-text branch in convertPlainTextToHookOutput previously denied on every non-zero, non-1 exit code (3, 127, signal fallbacks), contradicting the documented behavior. Collapse all non-blocking non-zero codes to EXIT_CODE_NON_BLOCKING_ERROR before passing into the converter so they take the warning path consistently. * chore: trigger CI * fix(cli): pass QWEN_HOME and QWEN_RUNTIME_DIR into docker/podman sandbox The container CLI previously had no awareness of the host's QWEN_HOME or QWEN_RUNTIME_DIR values. The global qwen dir worked only because the mount target happens to match the default fallback inside the sandbox, and the runtime base dir was lost entirely when it diverged from the global qwen dir. * fix(cli): canonicalize sandbox QWEN/RUNTIME paths and pin IDE lock dir Two reviewer-flagged issues from PR #2953: * macOS Seatbelt was passed `path.resolve` for `QWEN_DIR`/`RUNTIME_DIR` while neighbouring directories used `fs.realpathSync`. With a symlinked `QWEN_HOME` or `QWEN_RUNTIME_DIR`, sandbox-exec would compare against the canonical kernel path and deny writes. Create the dirs (so `realpathSync` can succeed on first run) then canonicalize them like the surrounding entries. * The VS Code companion wrote IDE lock files via the runtime base dir while the CLI side resolves the runtime dir from settings too. That divergence silently desynced lock-file discovery whenever a user set `advanced.runtimeOutputDir` without `QWEN_RUNTIME_DIR`. Anchor both sides to `getGlobalQwenDir()` since the companion process can only see env vars, not CLI settings. * fix(cli): finish QWEN_HOME plumbing across env, memory, rules, sandbox Codex review surfaced four user-visible spots where QWEN_HOME wasn't threaded through: * `findEnvFile` walked through the user home dir before consulting the QWEN_HOME fallback, so `~/.env` shadowed `<QWEN_HOME>/.env` and reversed the qwen-specific precedence the default `~/.qwen/.env` path enjoys. Add a home-dir-step check that prefers the custom Qwen dir when set. * `MemoryDialog` displayed and edited `~/.qwen/QWEN.md` regardless of QWEN_HOME. Memory discovery already routes through Storage, so user edits via the dialog were silently ignored at runtime. Route the dialog through `Storage.getGlobalQwenDir()` to match. * `loadRules` looked up global rules at `~/.qwen/rules/`, ignoring QWEN_HOME entirely. Use the global Qwen dir like the rest of the config surfaces. * The Docker/Podman sandbox path called `mkdirSync(userSettingsDir)` without `recursive`. Pre-PR the dir was always `~/.qwen` and the parent existed; with a nested QWEN_HOME like `/tmp/qwen/config` the first run threw ENOENT before the mount could be added. * fix(cli): block project .env from redirecting QWEN_HOME and QWEN_RUNTIME_DIR A project `.env` could set QWEN_HOME after settings were already loaded from the real home, splitting global state: settings.json read from ~/.qwen but later writes (installation_id, OAuth credentials, MCP tokens) landed in the project-controlled directory. The user-configurable excludedEnvVars list isn't the right place for this — it's a correctness boundary, not a preference — so always exclude these two vars from project .env files. User-level .env files (~/.qwen/.env) are unaffected. * fix(cli): keep workspace .qwen/.env unfiltered and pre-resolve user QWEN_HOME The env-file classification conflated two concerns: which paths may override global state vars, and which paths are exempt from the user-configurable excludedEnvVars filter. Splitting them lets a workspace `<repo>/.qwen/.env` carry DEBUG/DEBUG_MODE per the documented contract while still being blocked from redirecting QWEN_HOME or QWEN_RUNTIME_DIR. A QWEN_HOME set in `~/.qwen/.env` or `~/.env` would also previously arrive too late: USER_SETTINGS_PATH was captured at module load and loadSettings migrated `~/.qwen/settings.json` before loadEnvironment applied the override, leaving credentials, MCP tokens, and installation_id pointed at the new directory while settings stayed at the legacy one. A pre-pass now reads those user-level files for the two storage-controlling vars before any user settings are loaded, and the user settings path is re-resolved locally so all global state lands in one place. * fix(cli): make user-settings paths lazy to pick up bootstrapped QWEN_HOME USER_SETTINGS_PATH/USER_SETTINGS_DIR in settings.ts and the duplicate USER_SETTINGS_DIR in trustedFolders.ts were top-level consts evaluated at module load — before preResolveHomeEnvOverrides() reads QWEN_HOME from ~/.env or ~/.qwen/.env. Callers (sandbox launcher, trusted-folders reader) saw the legacy ~/.qwen path while the main CLI had moved to the custom home, splitting state. Convert all three to lazy getter functions and add a regression test that pokes process.env.QWEN_HOME after import and asserts each getter reflects it — any future top-level capture turns the test red. Mirror the same ~/.env / ~/.qwen/.env bootstrap into scripts/sandbox_command.js, which previously only read process.env directly and could disagree with the main CLI on the sandbox setting. Addresses review threads #3159793469, #3177804507, and item #2 of the 2026-05-06 review summary. * fix(cli): address qwen home review follow-ups * test(cli): normalize path in QWEN_HOME freshness assertion for Windows `getUserSettingsDir()` returns `path.dirname(...)`, which on Windows uses backslash separators. The bare string comparison failed on Windows runners ("\tmp\qwen-lazy-test" vs "/tmp/qwen-lazy-test"). Wrap the expected value in `path.normalize()` to match the OS-native separator, mirroring the two sibling assertions that already use `path.join()`. * fix(cli): close storage-routing leaks via settings.env and project sandbox .env settings.env (merged) was being applied to process.env without filtering, so a workspace settings.json could redirect global state by setting env.QWEN_HOME or env.QWEN_RUNTIME_DIR after the home-scoped .env bootstrap ran. Apply PROJECT_ENV_HARDCODED_EXCLUSIONS to the settings.env path too. scripts/sandbox_command.js's project-walk fallback called dotenv.config() to find QWEN_SANDBOX, which injected every parsed key — including QWEN_HOME / QWEN_RUNTIME_DIR the main CLI hard-blocks. Replace with a manual parse that copies only QWEN_SANDBOX. Add a startup migration warning when QWEN_HOME points to a directory with no settings.json while ~/.qwen/settings.json exists, so users notice that their existing OAuth tokens / settings / memory aren't auto-migrated. * test: cover QWEN_HOME / QWEN_RUNTIME_DIR in duplicated path helpers Adds targeted unit tests for the two TypeScript mirrors of Storage.getGlobalQwenDir() / getRuntimeBaseDir() that live outside packages/core to avoid cross-package imports. Covers default, absolute, relative, ~/x, ~\x, and bare ~ inputs, plus the runtime/home priority chain in the IDE companion. * fix: bootstrap QWEN_HOME before yargs handlers and in VS Code companion Two storage-routing leaks surfaced by Codex review of feat/qwen-config-dir: - channel status/stop call readServiceInfo() inside yargs handlers that process.exit before loadSettings() runs, so QWEN_HOME defined only in ~/.qwen/.env or ~/.env never resolved for them. The same race exists for the duplicate-instance check at the top of channel start. Hoist preResolveHomeEnvOverrides() to the top of main() so all subcommand handlers see the bootstrapped env vars. - The VS Code companion's getGlobalQwenDir / getRuntimeBaseDir read process.env directly, missing the same .env pre-pass. If a user only configures QWEN_HOME via ~/.qwen/.env, the CLI looks under the redirected dir while the companion writes IDE lock files under ~/.qwen, breaking IDE discovery. Mirror the CLI pre-pass in the companion (lazy, idempotent) without importing from core. * fix(config): preserve credentials in legacy ~/.qwen/.env when QWEN_HOME redirects When QWEN_HOME is bootstrapped from `~/.qwen/.env`, the home-dir env walk previously skipped that file and never read `<QWEN_HOME>/.env` from the companion. This stranded non-routing credentials (e.g. OPENAI_API_KEY) left in `~/.qwen/.env` and let the companion write IDE lock files into a different runtime dir than the CLI was reading from. - CLI: fall back to `~/.qwen/.env` after `<QWEN_HOME>/.env` at both the home-dir step and the post-walk fallback in findEnvFile, and treat the legacy path as user-level for trust and exclusion semantics. - Companion: after the initial candidate pass discovers QWEN_HOME, also read `<QWEN_HOME>/.env` so QWEN_RUNTIME_DIR sourced from there matches what the CLI's findEnvFile would pick. * refactor(cli): simplify QWEN_HOME plumbing — dedupe helpers, latch, comments - replace local isSameOrChildPath with core's isSubpath in sandbox.ts - latch preResolveHomeEnvOverrides so it runs once per process - pass userLevelPaths from loadEnvironment into findEnvFile (no recompute) - collapse findEnvFile's home-dir branch and post-loop fallback into one shared candidate list (drops duplicate existsSync calls) - factor extensionManager's user-extensions loop into a private helper - use QWEN_DIR constant instead of '.qwen' literal in skill-manager - trim narrative / PR-history comments across changed files * fix(cli): align QWEN_HOME .env bootstrap across CLI, sandbox, telemetry Telemetry scripts previously read process.env.QWEN_HOME directly, so a QWEN_HOME set only in ~/.env or ~/.qwen/.env left telemetry writing to ~/.qwen while the CLI routed elsewhere. Extract the bootstrap into scripts/lib/qwen-home-bootstrap.js and have sandbox_command.js, telemetry.js, and telemetry_utils.js share it. Also add a third-pass <new QWEN_HOME>/.env read in preResolveHomeEnvOverrides so the CLI and VS Code companion agree on QWEN_RUNTIME_DIR when it is configured under the new home dir. * test(integration-tests): update QWEN_HOME assertions for v4 schema Settings schema was bumped to v4 on main (gitCoAuthor migration). The qwen-config-dir tests still asserted post-migration $version === 3, so they failed after the merge. Bump the assertions to 4 and the seed in 3a to match, and point a comment at SETTINGS_VERSION so the next bump is easy to find.	2026-05-09 15:51:52 +08:00
pomelo	997796f532	refactor(cli): provider-first auth registry with unified install pipeline (#3864) ... * fix(cli): refresh static header on model switch Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * feat(cli): simplify api key provider registry Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(cli): split Alibaba auth providers Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * polish(cli): refine auth provider onboarding Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): update OpenRouter free defaults Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): restrict token plan models Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * chore(cli): remove unused third-party providers Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * feat(cli): add regional third-party providers Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(cli): simplify api key provider endpoints Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(cli): split auth dialog flows Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(cli): unify auth around declarative provider config Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> Introduce ProviderConfig abstraction (providerConfig.ts) and a central provider registry (allProviders.ts), replacing the per-flow UI components (AlibabaModelStudioFlow, CustomProviderFlow, OAuthFlow, ThirdPartyProvidersFlow, etc.) with unified ProviderSetupSteps and useProviderSetupFlow. Key changes: - Remove setupMethods/apiKey/ directory entirely - Collapse flow-specific hooks/components into a single generic provider setup flow - Simplify each provider file to export only a ProviderConfig descriptor - Add alibabaStandard provider alongside codingPlan/tokenPlan - Move all baseUrl resolution, install plan building, and settings writing into providerConfig - Update useAuth, AuthDialog, command handler, and upstream consumers to use the new registry * refactor(cli): simplify provider setup input flow Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(cli): remove toLlmProvider and legacy auth wrappers Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(cli): flatten auth flow files and simplify ProviderSetupSteps props Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * feat(cli): prefill API key from existing env settings in provider setup flow Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): correct third-party provider context windows Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): harden provider auth setup * feat(cli): support provider modality and context settings * feat: eable modelsEditable for coding plan * refactor(cli): auto-derive provider metadata key and state Move metadataKey and getProviderState from per-provider config to auto-derived helpers (resolveMetadataKey, resolveProviderState) in providerConfig.ts. This centralizes version tracking logic and reduces boilerplate in individual provider definitions. Add useProviderUpdates hook that detects model template changes across all version-tracked providers and surfaces update/ignore choices. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> Closes: OSS-1730, OSS-1729 * refactor(cli): namespace provider metadata under providerMetadata key Introduce PROVIDER_METADATA_NS ('providerMetadata') to avoid top-level settings key collisions. Provider metadata now lives under e.g. providerMetadata.coding-plan.version instead of codingPlan.version. Add migration logic (migrateProviderMetadata) to automatically move legacy top-level keys (codingPlan, tokenPlan) into the new namespace on first run. Update auth handler, useProviderUpdates hook, and all related tests to use the new namespace structure. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> [skip ci] Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): polish ProviderUpdatePrompt styling and test coverage [skip ci] Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(auth): simplify auth flows around provider abstraction [skip ci] - Rewrite motivation.md to document provider-centric architecture - Remove Alibaba Standard API Key and Coding Plan UI flows from handler - Update status tests to use providerMetadata instead of codingPlan settings - Streamline API key auth to show docs link only Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(auth): update provider models and refine auth infrastructure - Bump model versions (qwen3.6-plus, glm-5.1) and add deepseek-v4-pro/flash with modalities to Alibaba Standard provider - Reorder DeepSeek models, add thinking+image/video modalities to v4-pro, fix v4-flash context window - Enhance auth tests with provider metadata setValue assertions - Switch env key generation from hash-based to URL-based with trailing-slash normalization - Remove deprecated codingPlan section from settings schema Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(i18n): add missing zh-TW translations for token plan and subscription providers Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(auth): improve provider install error recovery and AuthDialog state init - Restore settings from backup on provider install plan failure - Fix AuthDialog mainIndex state to null (was 0), preventing stale selection - Remove ownsModel from customProvider; fall back to id-based filtering - Change provider migration log from console.error to console.log - Add sync reminder comments between CLI and VSCode subscription models - Expand handleApiKeyAuth JSDoc explaining its role as lightweight fallback Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(auth): i18n for step labels, lazy preview JSON, and accurate header label - Wrap getStepLabel() strings and PROTOCOL_ITEMS in t() for i18n - Only compute previewJson when on the review step - Return matched provider's own label in getAuthDisplayType instead of hardcoding CODING_PLAN for all managed providers * fix(auth): address round-3 review blockers - Fix CI: add missing useProviderUpdates mock in AppContainer.test.tsx that caused TypeError breaking React effects (title/height tests) - Fix half-rollback: snapshot settings + modelProviders before install, restore in-memory state (not just disk) on refreshAuth failure - Fix .orig backup reuse: always create fresh backup (overwrite stale), cleanup on success, unlink after restore to prevent data loss - Fix cross-package key consistency: VS Code settingsWriter now writes to providerMetadata namespace matching CLI's new structure - Fix validateApiKey: remove baseUrl guard so sk-sp- prefix check applies to both China and Global Coding Plan endpoints * fix(cli): stabilize AuthDialog tests for slower CI environments Increase vi.waitFor timeouts from default 1000ms to 5000ms and replace unreliable fixed-delay waits with proper render-completion assertions, preventing flaky failures on Linux/Windows CI runners with Node 22/24. * fix(core): use id+baseUrl composite key for model identity Custom provider installs previously used model id alone to determine ownership, causing the second install to remove the first backend's model entry when both expose the same model id (e.g. gpt-4o) with different baseUrls. Use id+baseUrl as the composite identity key throughout the model registry, ModelDialog, and modelsConfig to prevent cross-provider model collisions. * fix(cli): update ModelDialog tests for composite-key model identity Add missing getModelsConfig and getActiveRuntimeModelSnapshot mocks, and update switchModel assertion to expect the new { baseUrl } options object introduced in 4c4ebb81c. * fix(cli): skip flaky TUI input tests on all CI environments Multi-step TUI navigation tests exceed 5s timeout on CI runners regardless of Node version. Extend skip condition from only Node 20 to all CI environments where input simulation is unreliable. * fix(cli): improve auth/provider edge cases and UX - Add fallback to non-free models in OpenRouter OAuth when no free models available - Validate non-empty models list when building install plan - Fix auth status to use activeConfig instead of iterating all providers - Clear API key input when switching auth protocol - Skip unnecessary auth refresh when applying provider updates Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * test(cli): update tests for empty model validation and skip auth refresh Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): skip remaining flaky TUI input AuthDialog tests on CI 8558c49bc only converted part of the tests to itWhenTuiInputReliable, leaving 9 multi-step keyboard-navigation tests still using bare it(). These tests reliably time out on Linux/Windows CI runners where stdin simulation timing is unpredictable. Convert all remaining it() → itWhenTuiInputReliable() so CI skips them, and add a comment block to clearly demarcate the TUI input section. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-05-08 12:19:28 +08:00
Shaojin Wen	cfbcea1e88	feat: add commit attribution with per-file AI contribution tracking (#3115) ... * feat: add commit attribution with per-file AI contribution tracking via git notes Track character-level AI vs human contributions per file and store detailed attribution metadata as git notes (refs/notes/ai-attribution) after each successful git commit. This enables open-source AI disclosure and enterprise compliance audits without polluting commit messages. * feat: enhance commit attribution with real AI/human ratios and generated file exclusion - Replace line-based diff with a prefix/suffix character-level algorithm for precise contribution calculation (e.g. "Esc"→"esc" = 1 char, not whole line) - Compute real AI vs human contribution percentages at commit time by analyzing git diff --stat output: humanChars = max(0, diffSize - trackedAiChars) - Add generated file exclusion (lock files, dist/, .min.js, .d.ts, etc.) ported from an existing generatedFiles.ts - Add file deletion tracking via recordDeletion() - Update git notes payload format: {aiChars, humanChars, percent} per file with real percentages instead of hardcoded 100% * feat: add surface tracking, prompt counting, session persistence, and PR attribution Align with the full attribution feature set: - Surface tracking: read QWEN_CODE_ENTRYPOINT env var (cli/ide/api/sdk), include surfaceBreakdown in git notes payload - Prompt counting: incrementPromptCount() hooked into client.ts message loop, tracks promptCount/permissionPromptCount/escapeCount - Session persistence: toSnapshot()/restoreFromSnapshot() for serializing attribution state; ChatRecordingService.recordAttributionSnapshot() writes to session JSONL; client.ts restores on session resume - PR attribution: addAttributionToPR() in shell.ts detects `gh pr create` and appends "🤖 Generated with Qwen Code (N-shotted by Qwen-Coder)" - Session baseline: saves content hash on first AI edit of each file for precise human/AI contribution detection - generatePRAttribution() method for programmatic access * fix: audit fixes — initial commit handling, cron prompt exclusion, failed commit counter preservation - Handle initial commit (no HEAD~1) by detecting parent with rev-parse and falling back to --root for first commit in repo - Exclude Cron-triggered messages from promptCount (not user-initiated) - Add commitSucceeded parameter to clearAttributions() so failed/disabled commits don't reset the prompts-since-last-commit counter - Add test for clearAttributions(false) behavior * fix: cross-platform and correctness fixes from multi-round audit - Normalize path.relative() to forward slashes for Windows compatibility - Use diff-tree --root for initial commits (git diff --root is invalid) - Replace String.replace() with indexOf+slice to avoid $& special patterns - Fix clearAttributions(false→true) when co-author disabled but commit succeeded - Use real newlines instead of literal \n in PR attribution text - Add surface fallback in restoreFromSnapshot for version compatibility - Fix single-quote regex to not assume bash supports \' escaping - Case-insensitive directory matching in generated file detection - Handle renamed file brace notation in parseDiffStat * fix(attribution): also snapshot on ToolResult turns so resume keeps tool edits Previously, recordAttributionSnapshot() only ran at the start of UserQuery and Cron turns — before the tools for that turn had executed. A session that wrote a file in turn 1 and committed in turn 2 (across process boundaries via --resume) lost the tracked edit: the last persisted snapshot was the turn-1-start snapshot (empty fileStates), so on resume the attribution service restored empty state and no git notes were attached to the commit. Move the snapshot call out of the UserQuery/Cron conditional and run it on every non-Retry turn. ToolResult turns are scheduled right after tools execute, so their start-of-turn snapshot now captures any edits those tools made. Retry turns are skipped since the state is unchanged from the prior turn. Added unit tests asserting the snapshot fires for ToolResult/UserQuery turns and skips Retry turns. Verified end-to-end in a scratch repo: write-file in turn 1 (no commit) → exit → --resume → commit in turn 2 → git notes now contain the recorded file with correct aiChars and promptCount: 2. * refactor(attribution): merge duplicate retry guard and update stale doc Collapse the two back-to-back messageType !== Retry blocks in sendMessageStream into one, and refresh chatRecordingService's recordAttributionSnapshot doc comment to reflect that snapshots fire on every non-retry turn (not just after user prompts). * feat(attribution): split gitCoAuthor into independent commit and pr toggles Matches the shape used upstream in Claude Code's `attribution.{commit,pr}` so users can disable the PR body line without losing the commit-message Co-authored-by trailer (or vice versa). The previous boolean forced both to move together, which conflated two different surfaces. - settingsSchema: gitCoAuthor becomes an object with nested commit/pr booleans, each `showInDialog: true` so both appear in /settings. - Config constructor accepts legacy boolean (coerced to { commit: v, pr: v }) so stored preferences from the pre-split schema carry over. - shell.ts: attachCommitAttribution and addCoAuthorToGitCommit read .commit; addAttributionToPR reads .pr. * feat(settings): add v3→v4 migration for gitCoAuthor shape change Legacy gitCoAuthor was a single boolean and shipped ~4 months ago; the previous commit split it into { commit, pr } sub-toggles. Without a migration, users who had set gitCoAuthor: false would see the settings dialog show the default (true) for both sub-toggles — misleading and likely to flip their preference on the next save because getNestedValue returns undefined when asked for .commit on a boolean. - New v3-to-v4 migration expands boolean → { commit: v, pr: v }, preserves already-object values, resets invalid values to {} with a warning. - SETTINGS_VERSION bumped 3 → 4; existing integration assertions use the constant so the next bump is a single-line change. - Regenerate vscode-ide-companion settings.schema.json to reflect the new nested shape. - Docs: split the single gitCoAuthor row into .commit and .pr. * test(migration): cover null/array/number and partial object for v3-to-v4 The migration already treats any non-boolean, non-object value as invalid (reset to {} with warning), but the existing test only exercised the string "yes" branch. Add parameterized cases for null, array, and number so a future regression that accepts these in the valid bucket gets caught. Also cover partial objects — the migration must not paternalistically fill defaults; that responsibility lives in normalizeGitCoAuthor at the Config boundary. * fix(shell): address PR review for compound commits and PR body escaping Two critical issues called out in review: 1. attachCommitAttribution treated the final shell exit code as proof that `git commit` itself failed. For compound commands like `git commit -m "x" && npm test`, the commit can succeed and a later step can fail; the previous code then cleared attribution without writing the git note. Now we snapshot HEAD before the command (via `git rev-parse HEAD` through child_process.execFile, kept independent of the mockable ShellExecutionService) and detect commit creation by HEAD movement, so attribution lands whenever a new commit was created regardless of later steps. 2. addAttributionToPR spliced the configured generator name into the user-approved `gh pr create --body "..."` argument verbatim. A name containing `"`, `$`, a backtick, or `'` could break the command or be evaluated as command substitution. Now we shell-escape the appended text per the surrounding quote style before splicing. Tests cover the new escape paths for both double- and single-quoted bodies, including a generator name designed to break interpolation (`$(rm -rf /) "danger" \`eval\``) and one with an apostrophe. * fix(attribution): address Copilot review on shell, schema, and totals Six items called out on PR #3115 by Copilot: - shell.ts: addAttributionToPR's bash quote escaping doesn't apply to cmd.exe / PowerShell, where `\$` and `'\''` aren't honored. Skip the PR body rewrite entirely on Windows — losing PR attribution there is preferable to corrupting the user-approved `gh pr create` command. - attributionTrailer.ts + shell.ts call site: buildGitNotesCommand used bash-style single-quote escaping on the JSON note, which is broken on Windows. Switched to argv form (`{ command, args }`) and routed the invocation through child_process.execFile so shell quoting is bypassed entirely. Tests updated to assert the argv shape. - commitAttribution.ts: when a tracked file's aiChars exceeded the diff --stat-derived diffSize (long-line edits where diffSize ≈ lines * 40), humanChars clamped to 0 but aiChars stayed inflated, leaving aiChars + humanChars > the committed change magnitude. Clamp aiChars to diffSize so the totals stay consistent. - shell.ts parseDiffStat: only normalized rename brace notation (`{old => new}`). Cross-directory renames emit `old/path => new/path` without braces, leaving diffSizes keyed by the full string. Added a second normalization step. - shell.ts: addAttributionToPR docstring claimed `(X% N-shotted)` but the implementation only emits `(N-shotted by Generator)`. Updated the docstring to match the actual behavior. - settingsSchema.ts + generator: gitCoAuthor went from boolean to object in the V4 migration. The exported JSON Schema now wraps the field in `anyOf: [boolean, object]` (via a new `legacyTypes` hint on SettingDefinition) so users with a stored boolean don't see a spurious IDE warning before their next launch runs the migration. * fix(attribution): parse binary diffs, source generator from model, sync schema $version Three follow-up review items from Copilot: - parseDiffStat now handles git's binary-diff format (`path | Bin A -> B bytes`) using the byte delta with a floor of 1. Without this, binary edits arrived at the attribution payload as diffSize=0 and were silently dropped. Also extracted the parser to a top-level exported function so the binary path is unit-testable; added five targeted cases (text/binary/rename normalisation/summary skip). - attachCommitAttribution now passes `this.config.getModel()` into generateNotePayload instead of the user-configurable `gitCoAuthor.name`. The note's `generator` field reflects which model produced the changes — and CommitAttributionService's sanitizeModelName() actually has the codename to scrub now. - generate-settings-schema.ts imports SETTINGS_VERSION instead of hardcoding `default: 3`, so a future bump propagates to the emitted JSON schema in one place. Regenerated settings.schema.json bumps $version's default from 3 to 4 to match the V4 migration. * fix(attribution): repo-root baseDir, escape co-author trailer, switch to numstat Three Critical items called out by wenshao: - attachCommitAttribution was passing config.getTargetDir() as `baseDir` to generateNotePayload, but getCommittedFileInfo returns paths relative to `git rev-parse --show-toplevel`. When the working directory was a subdirectory of the repo, path.relative produced `../...` keys that never matched in the AI-attribution lookup, silently zeroing out attribution for every file outside getTargetDir. StagedFileInfo now carries an optional `repoRoot` (filled in by getCommittedFileInfo via `git rev-parse --show-toplevel`) and the caller prefers it over the target dir. - addCoAuthorToGitCommit interpolated `gitCoAuthorSettings.name` and `.email` into the rewritten command without escaping. A name containing `$()`, backticks, or `"` could be evaluated as command substitution under double quotes, or break the user-approved `git commit -m "..."` quoting. Now escapes per the surrounding quote style with the same helpers addAttributionToPR uses, gates on non-Windows for the same shell-quoting reason, and fixes the regex to accept `-m"msg"` shorthand (no space) so users who type the bash-shorthand form aren't silently denied a trailer. - parseDiffStat used `git diff --stat` output and approximated each line as ~40 chars by parsing a graphical text bar. Replaced with `git diff --numstat` which gives unambiguous integer additions+deletions per file; the heuristic remains but the parser is no longer fooled by the visual `++--` markers. Binary entries fall back to a fixed estimate so they still land in the map (rather than dropping out as diffSize=0). Suggestions also addressed: stale duplicate JSDoc on addCoAuthorToGitCommit removed, misleading `clearAttributions` comments rewritten to describe what the boolean argument actually does. Tests cover the new shorthand path, escape behavior, and numstat parsing (text/binary/rename/malformed). * fix(shell): shell-aware git-commit detection and apostrophe-escape handling Two more Critical items called out by wenshao plus the matching Copilot quote-handling notes: - attachCommitAttribution and addCoAuthorToGitCommit now go through a shell-aware `looksLikeGitCommit` helper instead of a raw `\bgit\s+commit\b` regex. The helper splits the command on shell separators (`splitCommands`) and checks each segment, so `echo "git commit"` no longer triggers attribution clearing or trailer injection. The same helper bails on any segment that contains `cd` or `git -C <path>`, since either could redirect the commit into a different repo than our cwd — writing notes or capturing HEAD there would corrupt unrelated state. - The post-command attribution call now runs regardless of whether the shell wrapper aborted. `git commit -m "x" && sleep 999` could move HEAD and then time out, leaving the new commit without its attribution note while the stale per-file attribution stayed around for a later unrelated commit. attachCommitAttribution still gates on HEAD movement, so it's a no-op when no commit was actually created. - The `-m '...'` and `--body '...'` regexes used to match only the first quote segment, so a command like `git commit -m 'don'\''t'` (bash's standard apostrophe-escape form) would have the trailer spliced mid-message and break the command's quoting. The single- quote patterns now use a negative lookahead / inner alternation to either skip those messages entirely (commit path) or match the whole escape-aware body (PR path). Tests cover the new behavior: quoted "git commit" is left alone, the `cd && git commit` and `git -C` patterns get no trailer, and the apostrophe-escape form passes through unchanged for both `-m` and `--body`. * fix(attribution): drop magic 100 fallback for empty deletions Deleted files with no AI tracking now use diffSize directly. With numstat as the input source, diffSize is an exact count, and an empty-file deletion legitimately reports zero — a magic fallback would only inflate totals. * fix(shell): broaden git-commit detection, gate background, drop dead helpers Five Copilot follow-ups: - looksLikeGitCommit now strips leading env-var assignments (`GIT_COMMITTER_DATE=now git commit ...`) and a small allowlist of safe wrappers (`sudo`, `command`) before matching. The previous exact-prefix match silently skipped trailer injection on common real-world commit forms. - A new looksLikeGhPrCreate (same shell-aware shape) replaces the raw `\bgh\s+pr\s+create\b` regex in addAttributionToPR, so quoted text like `echo "gh pr create --body \"x\""` no longer triggers a command-string rewrite. - executeBackground refuses to run `git commit` and tells the user to re-run foreground. The BackgroundShellRegistry lifecycle has no hook for the post-command pre/post-HEAD comparison or git-notes write, so allowing the commit through would create the new commit without notes and leak stale per-file attribution into the next foreground commit. - recordDeletion was unused outside its own test — removed (and the test). When AI-driven deletions need tracking we'll add it with an actual integration point rather than carrying dead API surface. - generatePRAttribution was likewise unused; addAttributionToPR builds the trailer string inline. The two formats had already diverged. Removed the helper and its tests; reviving from git history is straightforward if a future caller needs it. Tests: env-var and sudo prefixes now produce trailers; quoted "gh pr create" leaves the command unchanged; existing 81 shell tests still pass alongside the trimmed 25 commitAttribution tests. * fix(shell): unified git-commit detection split by intent Six items called out across CodeQL, Copilot, and wenshao: - The earlier `looksLikeGitCommit`/`stripCommandPrefix` returned a single yes/no and rejected ANY `cd` in the chain. That fixed the wrong-repo case but also disabled attribution for `git commit -m "x" && cd ..` (commit already landed safely in our cwd; the cd came after). It also conflated three distinct decisions onto one predicate. New `gitCommitContext` returns both `hasCommit` and `attributableInCwd`, walking segments in order so that a `cd` AFTER the commit doesn't invalidate it. Callers now pick the right arm: - background-mode refusal uses `hasCommit` (refuses even `cd /elsewhere && git commit` since we can't attribute it afterward either way) - HEAD snapshot, addCoAuthorToGitCommit, and the attachCommitAttribution gate use `attributableInCwd` - Tokenisation switches from a regex while-loop to `shell-quote`'s `parse`. Quoted env values like `FOO="a b" git commit` now skip correctly (the old `\S*\s+` form would cut after the opening quote). Eliminates the CodeQL polynomial-regex alert at the same time since the `\S*\s+` pattern is gone. - attachCommitAttribution now snapshots prompt counters via `clearAttributions(true)` whenever a commit lands, even if no per-file attributions were tracked. Previously the early-return on `hasAttributions() === false` meant `promptCountAtLastCommit` never advanced, so a later `gh pr create` reported an inflated N-shotted count spanning multiple commits. Tests: env-var and sudo prefixes still produce trailers; quoted "git commit" / "gh pr create" leave commands unchanged; cd BEFORE commit suppresses the rewrite while cd AFTER commit does not; `git -C <path> commit` is treated as a commit (refused in background) but not as attributable. * fix(shell): position-independent git subcommand detection + bash-shell guard Six review items, two of them critical: - gitCommitContext was checking fixed-position tokens (`arg1`, `arg3`) and missed every git invocation that puts a global flag between `git` and the subcommand: `git -c user.email=x@y commit`, `git --no-pager commit`, `git -C /p -c k=v commit`, etc. In background mode these would slip past the refusal guard; in foreground they got no co-author trailer, no git note, and no prompt-counter snapshot. New `parseGitInvocation` walks past git's global flags (with their values) before reading the subcommand, and reports `changesCwd` for `-C` / `--git-dir` / `--work-tree`. - The Windows guard on addCoAuthorToGitCommit and addAttributionToPR used `os.platform() === 'win32'`, which incorrectly skipped Windows + Git Bash (`getShellConfiguration().shell === 'bash'`). Switched both to gate on `getShellConfiguration().shell !== 'bash'` so Git Bash users keep the feature. - attachCommitAttribution was re-parsing `gitCommitContext(command)` even though `execute()` already gates on `commitCtx.attributableInCwd`. Removed the redundant re-parse — drift between the two checks would silently diverge trailer injection from git-notes writes. - tokeniseSegment (formerly tokeniseProgram) now logs via debugLogger on parse failure instead of swallowing silently. Easier to debug if shell-quote ever throws on something unusual. - Added a comment on `cwdShifted` documenting that it's a one-way latch — `cd src && cd ..` will still skip attribution. The trade-off matches the wrong-repo guard's "better miss than corrupt unrelated repos" intent. - Stale `--stat` reference in the aiChars-clamp comment updated to `--numstat` to match the actual git command in ShellToolInvocation.getCommittedFileInfo. Tests: `git -c key=val commit` and `git --no-pager commit` now produce a trailer; existing 82 shell tests still pass. * fix(shell): refuse multi-commit attribution; misc review follow-ups Five follow-ups from the latest review pass: - attachCommitAttribution now refuses to write a single git note for shell commands that produce more than one commit (e.g. `git commit -m a && git commit -m b`). The singleton's per-file attribution map can't be partitioned across the individual commits, so attaching the combined note to HEAD would mis-attribute earlier commits' changes to the last one. Walks `preHead..HEAD` via `git rev-list --count`; on multi-commit detection it snapshots the prompt counters and bails with a debug warning instead of writing a misleading note. - parseGitInvocation now recognises the attached `-C/path` form (e.g. `git -C/path commit -m x`). shell-quote tokenises that as a single `-C/path` token which previously fell to the generic flag branch with `changesCwd = false`, leaving an out-of-cwd commit classified as attributable. - attachCommitAttribution dropped its unused `command` parameter (the caller already gates on `commitCtx.attributableInCwd`, so re-parsing was removed earlier; the parameter became dead). - Added wiring guards in edit.test.ts and write-file.test.ts: AI-originated edits/writes hit `CommitAttributionService.recordEdit`, `modified_by_user: true` skips, and write-file's distinction between a true new file and an overwritten empty file (`null` vs `''` old content) is now pinned by `aiCreated` assertions. * fix(attribution): partial-commit clear, symlink baseDir, gh/git flag handling Two Critical items, two Copilot, and five wenshao Suggestions: - attachCommitAttribution's `finally` block used to call `clearAttributions()` unconditionally, wiping per-file tracking for files the AI had edited but the user excluded from this commit. Added `clearAttributedFiles(committedAbsolutePaths)` to the service and the call site now passes only the paths that actually landed in this commit; entries for un-`add`ed files stay pending for a later commit. - generateNotePayload now runs both `baseDir` and each tracked absolute path through `fs.realpathSync` before `path.relative`. On macOS in particular `/var` symlinks to `/private/var`, so the toplevel from `git rev-parse --show-toplevel` and the absolute path captured by edit/write-file tools could diverge — producing `../../actual/path` keys in the lookup that never matched and silently zeroed all per-file AI attribution. - tokeniseSegment now consumes value-taking sudo flags (`-u`, `-g`, `-h`, `-D`, `-r`, `-t`, `-C`, plus the long forms). Without this, `sudo -u other git commit` left `other` standing in for the program name and skipped the trailer entirely. - A duplicate JSDoc block above `countCommitsAfter` (a leftover from the earlier extraction of `getGitHead`) was removed; both helpers now have one accurate comment each. - attachCommitAttribution's multi-commit guard now also runs when `preHead === null` (brand-new repo), via `git rev-list --count HEAD`. A compound `git init && git commit -m a && git commit -m b` no longer slips through and mis-attributes combined data to the last commit. - addCoAuthorToGitCommit's `-m` matching switched to `matchAll` and takes the LAST match. `git commit -m "title" -m "body"` puts the trailer at the end of the body so `git interpret-trailers` recognises it; the previous first-match behaviour stuffed the trailer in the title where git treats it as plain message text. - addAttributionToPR's `--body` regex accepts both space and `=` separators (`--body "..."` and `--body="..."`); the `=` form is common with gh. - New `parseGhInvocation` walks past gh's global flags (`--repo`, `-R`, `--hostname`) so `gh --repo owner/repo pr create ...` is detected. The earlier fixed-position check at tokens[1]/tokens[2] missed any command with a global flag. - getCommittedFileInfo now fans out the two `rev-parse` calls and the three diff calls with `Promise.all`. They're independent and serialising them was paying spawn latency 5× per commit. Tests: sudo with `-u user`, multi `-m`, `gh --repo owner/repo`, `--body="..."`, plus the existing 84 shell tests still pass. * fix(attribution): canonicalize file paths centrally in CommitAttributionService Two related Copilot follow-ups: - recordEdit/getFileAttribution/clearAttributedFiles now run input paths through fs.realpathSync before storing/looking up, so a symlinked path (e.g. macOS /var ↔ /private/var) resolves to the same key regardless of which form the caller passes. Previously edit.ts/write-file.ts handed in non-realpath'd absolute paths while generateNotePayload tried to realpath only inside its lookup loop, leaving partial-clear and clear-on-finally paths unable to find entries when the forms diverged. - restoreFromSnapshot also canonicalises on the way in so a session resumed from a pre-fix snapshot (where keys may not have been canonical) ends up with the same shape as newly recorded entries — otherwise a single file could end up with two parallel records. - generateNotePayload's lookup loop dropped its per-entry realpath call (now redundant since keys are canonical at write time), keeping only the realpath of `baseDir` (which still comes from `git rev-parse --show-toplevel` and may be a symlink). - Updated `clearAttributedFiles` doc to describe the new semantics: callers can pass either the resolved repo-relative path or an already-canonical absolute path, and either will match. * fix(attribution): canonicalize-from-root cleanup; fix mixed-quote -m / gh -R= Five review items, one Critical: - attachCommitAttribution now canonicalises via the repo *root* (one realpath call) and resolves committed paths against that canonical root, rather than per-leaf realpath inside clearAttributedFiles. At cleanup time the leaf for a just-deleted file no longer exists, so per-leaf fs.realpathSync would fail and silently fall back to a non-canonical path that misses the stored canonical key — leaving stale attributions for deleted files. clearAttributedFiles drops its internal realpath and now documents the canonical-paths-required precondition explicitly. - addCoAuthorToGitCommit picks the LAST `-m` regardless of quote style. Previously `doubleMatch ?? singleMatch` always preferred the last double-quoted match, so `git commit -m "Title" -m 'Body'` injected the trailer into the title where git interpret-trailers would silently ignore it. Now compares match indices, and the escape helper follows the actually-selected match's quote style. - parseGhInvocation handles `-R=value` (the equals form of the short `--repo` alias). `--repo=...` and `--hostname=...` were already covered; `-R=...` previously fell through to the generic flag branch and skipped the value. - New tests for the symlink-aware canonicalisation: macOS-style `/var` ↔ `/private/var` mapping is mocked via vi.mock on node:fs, with cases for record-then-look-up under either form, generateNotePayload with a symlinked baseDir, partial clear via the canonical-root-derived path (deleted leaf), and snapshot restore canonicalisation. - Doc-only: integration-test header comments updated from "V1 -> V2 -> V3" / "migration to V3" to reflect the actual V4 end state (assertions already used the literal `4`). * fix(shell): scope -m rewrite to commit segment, reject nested matches Two Critical findings on addCoAuthorToGitCommit, plus a Copilot maintainability nit: - The `-m` regex used to scan the whole compound command, so `git commit -m "fix" && git tag -a v1 -m "release"` would target the LATER tag annotation (last -m wins) and splice the trailer there instead of the commit message. The rewrite now scopes to the actual `git commit` segment via a new findAttributableCommitSegment(): same shell-aware walk gitCommitContext does, but returning the segment's character range so the regex can be run on a slice and spliced back into the original command. - Within the segment, a literal `-m '...'` *inside* a quoted body was treated as a real later -m. For `git commit -m "docs mention -m 'flag' for completeness"`, the inner single-quoted -m sits at a higher index than the real outer -m, and the previous index comparison would have it win — splicing the trailer mid-message and corrupting the quoting. The new code checks whether the candidate is nested inside the other quote-style's range (start/end containment) and prefers the outer match when so. - Hoisted three constant Sets (sudo flag list, git global flags taking values, git global flags shifting cwd, gh global flags) out of the per-call scope to module constants. Functional no-op, but keeps the parsing helpers easier to read and avoids re-allocating the Sets on every command. Two regression tests added for the cases above: - inner `-m '...'` inside the outer message body is preserved literally and the trailer lands after the body - `git tag -a v1 -m "release notes"` after a real `git commit -m "fix"` is left untouched, with the trailer appended to "fix" only * fix(attribution): cd-leak, numstat partial failure, $() bailout, gh pr new alias Five Critical/Suggestion items: - `cd subdir && git commit` (or any non-attributable commit chain whose HEAD movement still happens in our cwd, e.g. cd into a subdirectory of the same repo) used to skip attribution AND fail to clear pending per-file entries. Those entries then leaked into the next foreground commit, inflating its AI percentage. New `else if (commitCtx.hasCommit)` branch in execute() compares pre- and post-HEAD; if HEAD moved we drop the per-file state. preHead is now snapshotted whenever ANY commit was attempted, not only attributable ones. - getCommittedFileInfo's three diff calls run in `Promise.all`. If `--numstat` failed while `--name-only` succeeded, every file's diffSize would be 0 and generateNotePayload would clamp aiChars to 0 — emitting a structurally valid note with all-zero AI percentages. Detect the partial-failure shape (files non-empty, diffSizes empty) and return empty so no note is written. - addCoAuthorToGitCommit and addAttributionToPR now bail when the captured `-m`/`--body` value contains `$(`. The tool description recommends `git commit -m "$(cat <<'EOF' ... EOF)"` for multi-line messages, but the regex's `(?:[^"\\]|\\.)*` body group stops at the first interior `"` from a nested shell token — splicing the trailer there breaks the command before it reaches the executor. - looksLikeGhPrCreate now accepts `gh pr new` as well — it's a documented alias for `gh pr create` and was silently skipped. - Removed `incrementPermissionPromptCount` / `incrementEscapeCount` and their getters: they had no production callers, so the backing fields just round-tripped through snapshots as 0. The four snapshot fields are now optional so pre-fix snapshots that carry non-zero values still load cleanly and just get ignored. Three regression tests added: heredoc-style `-m "$(cat <<EOF...)"` preserved literally, heredoc-style `--body` likewise, `gh pr new --body "..."` rewritten with attribution. * fix(attribution): --amend, --message/-b aliases, .d.ts over-exclusion Four Copilot follow-ups, three of them user-visible coverage gaps: - `git commit --amend` was diffing `HEAD~1..HEAD` for attribution, which spans the entire amended commit (parent → amended) rather than the actual amend delta. A message-only amend would emit a note attributing every file in the original commit to this amend. New `isAmendCommit` helper detects the flag and getCommittedFileInfo switches to `HEAD@{1}..HEAD` (the pre-amend HEAD vs the amended HEAD); if the reflog is GC'd we bail with a warning rather than over-attribute. - `git commit --message "..."` and `--message="..."` were silently skipped because the regex only recognised the short `-m` form. The flag prefix now matches both alternatives via `(?:-[a-zA-Z]*m|--message)\s*=?\s*` (non-capturing inner group so the existing `[full, prefix, body]` destructure still works). - `gh pr create -b "..."` (the short alias for `--body`) was the same gap on the PR side; `(?:--body|-b)[\s=]+` now covers both forms. - `.d.ts` was an over-broad blanket exclusion in EXCLUDED_EXTENSIONS — declaration files are commonly authored (ambient declarations, asset shims like `*.d.ts` for `import './x.svg'`); the repo even contains `packages/vscode-ide-companion/src/assets.d.ts`. Removed `.d.ts` from the extensions Set and adjusted the test to assert the new behavior. Auto-generated `.d.ts` (e.g. `tsc --declaration` output) still gets caught by the build-directory rules. Tests added: `--amend` plumbing covered by the new branch in getCommittedFileInfo (no targeted unit test — the diff invocation goes through ShellExecutionService and is exercised by the existing post-command path); `--message`/`--message="..."`/-b/-b="..."` all have positive trailer-injection assertions; `.d.ts` test split into "hand-authored" (negative) and "in dist" (positive). * fix(attribution): cd-subdir, scope --body, multi-commit count guard, /clear reset Four bugs flagged this round: - gitCommitContext / findAttributableCommitSegment used a blanket "any cd shifts cwd" gate, breaking the very common `cd subdir && git commit -m "..."` flow even though the commit lands in the same repo. New `cdTargetMayChangeRepo` heuristic: treat relative paths that don't escape upward (no leading `..`, no absolute path, no `~`/`$VAR` expansion, no bare `cd`/`cd -`) as in-repo and let attribution proceed. Conservative on anything it can't statically verify. - addAttributionToPR was running the `--body`/`-b` regex against the FULL compound command string. In `curl -b "session=abc" && gh pr create --body "summary"` the regex would match curl's `-b` cookie flag and inject attribution into the cookie value, corrupting the curl call. Added `findGhPrCreateSegment` (analog of `findAttributableCommitSegment`) and scoped the body regex to that segment, splicing back into the original command via offsetting the in-segment match index. - The multi-commit guard treated `runGitCount === 0` as "single commit" and bypassed itself. After `commitCreated === true`, a count of 0 is impossible in normal operation — it means rev-list errored or timed out. Now we bail on `commitCount !== 1` with a tailored message: anything other than exactly 1 commit is suspicious and refuses the note. - The CommitAttributionService singleton survives across `Config.startNewSession()` (the `/clear` and resume paths). New `CommitAttributionService.resetInstance()` call alongside the existing chat-recording / file-cache resets in startNewSession prevents pending attributions from a prior session attaching to a commit in the new one. Three regression tests added: `cd src && git commit` produces a trailer (in-repo cd), `cd .. && git commit` does not (could escape repo root), and `curl -b "..." && gh pr create --body "..."` leaves curl's cookie value untouched while attribution lands in gh's body. * fix(attribution): cd embedded .., env wrapper, Windows ARG_MAX, segment-locator warn Four review items, all small but real: - cdTargetMayChangeRepo missed embedded `..` traversal — `cd foo/../../escape` and similar would slip past the leading-`..` check and be treated as in-repo. Added an `includes('/..')` / `includes('\\..')` check (catches POSIX and Windows separators without false-positiving on `..` chars inside ordinary names, which only escape when followed by a separator). - tokeniseSegment now recognises `env` as a safe wrapper alongside `sudo`/`command`, so `env GIT_COMMITTER_DATE=now git commit ...` resolves to `git`. After the wrapper detection we also skip any `KEY=VALUE` argv entries (env's own argument syntax for setting vars before the program). - buildGitNotesCommand's MAX_NOTE_BYTES dropped from 128 KB to 30 KB. Windows' CreateProcess lpCommandLine is capped around 32,768 UTF-16 chars including the executable path and other argv entries; a 128 KB note would still fail to spawn even though the function returned a command instead of null. 30 KB leaves ~2 KB of headroom for the rest of the argv on Windows and is larger than any real commit's metadata in practice. - findAttributableCommitSegment / findGhPrCreateSegment now log a debugLogger.warn when `command.indexOf(sub, cursor)` returns -1 — splitCommands strips line continuations (`\<newline>`), so a multi-line command can have the trimmed segment text fail to match its source. Previously the segment was silently skipped with no signal; the warn makes the failure observable when QWEN_DEBUG_LOG_FILE is set. Two regression tests added: `cd foo/../../escape && git commit` gets no trailer (embedded-`..` heuristic catches it), and `env GIT_COMMITTER_DATE=now git commit` does (env wrapper skipped). * fix(attribution): scope isAmendCommit to attributable segment only `git -C ../other commit --amend && git commit -m x` would previously flag the second (fresh) commit as an amend, causing attachCommitAttribution to diff `HEAD@{1}..HEAD` against an unrelated reflog entry. Mirror findAttributableCommitSegment's cd/cwd tracking so only the first commit segment that runs in the original cwd determines amend status. * fix(attribution): last-match --body, symlink leaf canonicalisation, scoped prompt count - addAttributionToPR: use matchAll/last-match for `--body`/`-b` so the trailer lands in the gh-honoured (final) body when multiple flags are present. Mirrors addCoAuthorToGitCommit. Adds regression test. - attachCommitAttribution: also fs.realpathSync the per-file resolved path (not just the repo root) so files behind intermediate symlinks are matched against canonical keys recordEdit stored, instead of silently zeroing attribution and leaking entries past commit. - incrementPromptCount: scope to SendMessageType.UserQuery — ToolResult, Retry, Hook, Cron, Notification are model/background re-entries of the same logical turn. Tracking them all inflated the "N-shotted" trailer (one user message could become 10-shotted with 10 tool calls). - AttributionSnapshot: add `version: 1` field; restoreFromSnapshot now refuses incompatible versions and validates per-field types so a partially-written snapshot can't seed `Math.min(undefined, n) === NaN` into git-notes payloads. - Drop unused permission/escape counters (declared, persisted, never read or incremented) — fields, snapshot tolerance, and clear-method bookkeeping all removed; AttributionSnapshot interface simplifies. - isGeneratedFile: switch directory rule from substring `.includes('/dist/')` to segment-boundary check (split on `/`) so project dirs like `my-dist/` or `xbuild/` don't match. `.lock` removed from the blanket extension exclusion — well-known lockfiles already covered by EXCLUDED_FILENAMES; hand-authored `.lock` files (e.g. `.terraform.lock.hcl`) now stay attributable. - getClientSurface: document `QWEN_CODE_ENTRYPOINT` as the embedder override hook so the always-`'cli'` default is intentional. * fix(attribution): skip values for env -u NAME and -S string `env`'s value-taking flags (`-u`/`--unset`, `-S`/`--split-string`) were not in the wrapper's flag-skip allowlist, so `env -u FOO git commit ...` left FOO as the next token and the parser treated it as the program — masking the real `git commit` from attribution detection. Add an ENV_FLAGS_WITH_VALUE table mirroring the sudo allowlist. Regression test added. * fix(attribution): submodule leak, PR body nesting, shallow-clone bail, schema default - attachCommitAttribution: when HEAD didn't move in our cwd, leave pending attributions alone instead of dropping them. The case can be a failed commit, `git reset HEAD~1`, OR `cd submodule && git commit` (inner repo's HEAD moves, ours doesn't). Dropping was overly aggressive and silently lost outer-repo edits in the submodule case. - addAttributionToPR: mirror addCoAuthorToGitCommit's nested-match rejection so `gh pr create --body "docs mention -b 'flag'"` picks the outer `--body`, not the inner literal `-b`. Splicing into the inner match would corrupt the body. Regression test added. - getCommittedFileInfo: when `rev-parse --verify HEAD~1` fails, also check `rev-list --count HEAD === 1` to confirm HEAD is the true root commit. In a shallow clone, HEAD~1 is unreadable but the commit has a parent recorded — falling back to `diff-tree --root` would diff against the empty tree and over-attribute the entire commit. Bail with a debug warning instead. - generate-settings-schema: lift `default` (and `description`) out of the inner `anyOf[N]` schema to the outer level when wrapping with `legacyTypes`. Most JSON-schema-driven editors only surface top-level defaults; burying the default under `anyOf` lost the "enabled by default" hint. Also extend the default filter to publish non-empty plain objects (so `gitCoAuthor`'s default can appear). gitCoAuthor's source default updated to the runtime shape `{commit: true, pr: true}` to match `normalizeGitCoAuthor`. * fix(attribution): drop unsafe full-clear, tag analysis-failure with null ju1p (Copilot): the `else if (commitCtx.hasCommit)` branch fully cleared the singleton on `cd /abs/same-repo/subdir && git commit` (or `git -C . commit`), losing pending AI edits the user hadn't staged. We can't tell which files were in the commit from this branch, and the next attributable commit's partial-clear handles cleanup correctly anyway. Drop the branch entirely. ju2D (Copilot): `getCommittedFileInfo` returned the same empty StagedFileInfo for both "could not analyze" (shallow clone, --amend without reflog, --numstat partial failure, exception) and "intentionally empty" (--allow-empty). The caller couldn't tell them apart, so the partial clear became a no-op on analysis failure and the just-committed AI edits leaked to the next commit. Switch the return type to `StagedFileInfo | null` and have the caller treat null as "fall back to full clear" while empty StagedFileInfo (--allow-empty) leaves attributions intact for the next real commit. * fix(attribution): dedup snapshot writes, cap excludedGenerated, doc commit toggle scope rsf- (Copilot): recordAttributionSnapshot wrote a full snapshot to the JSONL on every non-retry turn, even when the tracked state was unchanged. Long-running sessions accumulated thousands of identical snapshot copies, inflating session size and slowing /resume hydrate. Dedup by JSON-equality with the prior write — first write always goes through, identical successors are no-ops. rsgo (Copilot): excludedGenerated path list was unbounded. A commit churning thousands of generated artifacts (large dist/ rebuild) could push the JSON note past MAX_NOTE_BYTES (30KB) and lose attribution for the real source files in the same commit. Cap the serialized sample at MAX_EXCLUDED_GENERATED_SAMPLE (50) and add excludedGeneratedCount for the true total. rsg9 + rshM (Copilot): the gitCoAuthor.commit description claimed the toggle only controlled the Co-authored-by trailer, but attachCommitAttribution also gates the per-file git-notes payload on the same flag. Update both the schema description and the settings.md table to mention both effects so disabling the option isn't a silent surprise. * fix(attribution): depth-1 shallow detection, snapshot dedup post-rewind/post-failure sfGz (Copilot): rev-list --count HEAD === 1 cannot distinguish a true root commit from a depth-1 shallow clone — both report 1 because rev-list only walks locally available objects. Switch to git log -1 --pretty=%P HEAD which reads the parent SHA directly from commit metadata: empty means a real root, non-empty means a parent is recorded (whether or not its object is local). The shallow-clone bail is now reliable. sfIm (Copilot): the dedup key persisted across rewindRecording, so the previous snapshot living on the now-abandoned branch would match the next post-rewind snapshot and silently skip the write, leaving /resume on the rewound session with no attribution state. Reset lastAttributionSnapshotJson when rewindRecording fires. sfJE (Copilot): dedup key was committed before the async write settled. A transient write failure would update the key, then permanently suppress all future identical snapshots even though nothing was ever persisted. Switch to optimistic-set then rollback on appendRecord rejection — synchronous identical calls dedup cleanly, but a failed write clears the key so the next identical snapshot retries. appendRecord now returns the per-record write promise (writeChain still has its swallow-catch for chain liveness) so callers needing per-write success can react to it. Tests added in chatRecordingService.test.ts for both rewind-reset and rollback-on-failure paths. * fix(attribution): preHead race, regex apostrophe-escape, surface failures, dead code t2G0 (deepseek-v4-pro): addCoAuthorToGitCommit single-quote regex now matches the bash close-escape-reopen apostrophe form using ((?:[^']|'\\'')*) — the same pattern bodySinglePattern uses for gh pr create. Input like git commit -m 'don'\''t' was previously silently un-rewritten because the negative lookahead bailed; the trailer now lands at the FINAL closing quote. Test updated. tMBP (gpt-5.5): preHead capture switched from concurrent async getGitHead to a synchronous getGitHeadSync (execFileSync) BEFORE ShellExecutionService.execute spawns the user's command. A fast hot-cached git commit could move HEAD before the async rev-parse resolved, leaving preHead === postHead and silently skipping the attribution note. Trade ~10–50 ms event-loop block per commit-shaped command for correctness of the post-command HEAD comparison. t2Gv (deepseek-v4-pro): attribution write failures (note exec non-zero, payload too large, diff-analysis exception, shallow clone / amend-without-reflog) are now surfaced on the shell tool's returnDisplay AND llmContent so the user and agent both see when their commit succeeded but the per-file git note didn't land. attachCommitAttribution now returns string | null (warning text or null for intentional skips like no-tracked-edits). Co-authored-by trailer is unaffected — only the note is gated by these failures. t2Gy (deepseek-v4-pro): committedAbsolutePaths now matches against the canonical keys already stored in fileAttributions (matchCommittedFiles iterates by relative path against the canonical repo root) instead of re-resolving each diff path on the fly. realpathSync(resolved) failed for deleted files and didn't follow intermediate symlinks, leaving stale per-file attribution alive past commit and inflating AI percentages on subsequent commits. t2HI (deepseek-v4-pro): removed dead sessionBaselines / FileBaseline / contentHash / computeContentHash infrastructure (~40 lines). The fields were written, persisted, and restored but never read for any computation or decision. AttributionSnapshot schema stays at version 1 — restore tolerates pre-fix snapshots that carried the now-ignored baselines field. t2HM (deepseek-v4-pro): extracted the duplicated lastMatch helper in addCoAuthorToGitCommit and addAttributionToPR into a single module-level lastMatchOf so future fixes can't be applied to only one copy. * chore(schema): regenerate settings.schema.json to match gitCoAuthor.commit description The settingsSchema.ts source for `gitCoAuthor.commit.description` was updated in 3c0e3293b but the JSON schema only picked up the OUTER description rewrite and missed this inner property's. The Lint check ("Check settings schema is up-to-date") fails on that drift; this commit re-runs `npm run generate:settings-schema` to sync them. * fix(attribution): preserve unstaged AI edits across cleanup branches uxU5 + uxVQ + uxUO (Copilot): every cleanup branch in attachCommitAttribution that called clearAttributions(true) was wholesale-erasing pending AI edits for files the user never staged in this commit. Reviewer scenarios: - multi-commit chain (`commit a && commit b`) bails out without writing a note, but unstaged edits to file Z (touched by neither commit) get cleared along with the chain's committed files. - attribution toggle off: same — toggling the flag wipes pending unstaged work. - analysis failure (shallow clone, --amend without reflog, partial diff failure): the finally-block fallback wholesale-cleared every pending file, consuming unrelated AI edits. - 0%-AI commit: when no file in the commit was AI-touched, generateNotePayload was emitting an "0% AI" note attached to a commit that legitimately had no AI involvement — actively misleading metadata. Add `noteCommitWithoutClearing()` to the service: snapshots the prompt counter as the new "at last commit" but leaves the per-file map alone. Use it in the multi-commit, no-tracked-edits, toggle-off, and analysis-failure paths. The committed-files partial-clear (clearAttributedFiles) still runs in the success path. The 0%-AI no-match case now skips the note write entirely. * fix(attribution): runGit null-on-failure, versionless v3→v4 migration z54M (Copilot): runGit returned '' on both successful-empty-output and silent failure, so a `--name-only` that errored mid-way through the diff fan-out aliased to a real `--allow-empty` commit. The empty-commit branch then preserved pending attributions, leaving the just-committed file's tracked AI edit alive to re-attribute on the next commit. Switch runGit to `Promise<string | null>`, distinguishing exit code 0 (any output, including '') from non-zero (null). The diff-stage fan-out and ancillary probes now treat null as analysis failure and bail with `return null` instead of falling into the empty-commit path. z539 (Copilot): the v3→v4 `shouldMigrate` only fired on `$version === 3`. A versionless settings file carrying the legacy `general.gitCoAuthor: false` boolean would skip every migration (gitCoAuthor isn't in V1_INDICATOR_KEYS — it post-dates V2), get its `$version` normalized to 4 by the loader, and leave the boolean in place. The settings dialog then reads the V4 `{commit, pr}` shape, sees missing keys, defaults both to true, and silently overwrites the user's opt-out on the next save. Also fire when `$version` is absent AND the value at `general.gitCoAuthor` is a boolean. Tests cover the new path and confirm the existing versioned/object-shape paths are untouched. * fix(attribution): toggle-off partial clear, normalizeGitCoAuthor type-check, terraform lockfile 0oAK (Copilot): the gitCoAuthor.commit toggle-off branch returned before computing the committed file set, leaving the just-committed files' tracked AI work in the singleton. Re-enabling the toggle and committing the same file again would re-attribute earlier (already- committed) AI edits to the new commit. Move the toggle gate AFTER matchCommittedFiles so the finally block does a proper partial clear of the just-committed files even when the note write is skipped. 0oAg (Copilot): normalizeGitCoAuthor copied value?.commit / value?.pr without type-checking. settings.json is hand-editable; a stored `{ commit: "false" }` reached runtime as a truthy string and behaved as if attribution were enabled. Add a per-field bool coercion that falls back to the schema default (true) for any non-boolean, matching what the dialog and IDE schema already imply. Tests cover the string / number / null cases. 0oAo (Copilot): v3→v4 shouldMigrate only special-cased versionless legacy booleans — versionless files with invalid gitCoAuthor values (`"off"`, `[]`, etc.) skipped the migration and the loader stamped `$version: 4` over the bad value. Runtime normalization then silently re-enabled attribution. Extend shouldMigrate to fire on ANY versionless non-object value at general.gitCoAuthor; the existing migrate() body's drop-and-warn path resets it. Already-object shapes (hand-edited to v4) still skip cleanly. Tests added. 0oAt (Copilot): `.terraform.lock.hcl` got dropped from generated-file exclusion when `.lock` was removed from the blanket extension list in 3c0e3293b. It's a generated provider lockfile in the same class as `package-lock.json` and dominates Terraform-repo commits. Re-add to EXCLUDED_FILENAMES and add a regression test covering both repo-root and module-nested locations. * fix(attribution): harden restoreFromSnapshot against corrupt payloads 1KMY (Copilot): snapshot.surface was copied without type validation. A corrupted/partially-written snapshot with a non-string surface (e.g. {}, 42, null) would later be serialized into the git note as "[object Object]" and used as a Map key downstream, breaking the expected payload shape. Type-check and fall back to the current client surface for any non-string (or empty-string) value. 1KLq (Copilot): per-field sanitiseCount enforced `promptCount >= 0` and `promptCountAtLastCommit >= 0` independently, but never the cross-field invariant. A snapshot with promptCountAtLastCommit > promptCount would surface a negative getPromptsSinceLastCommit() and propagate as a "(-N)-shotted" trailer into PR text. Clamp atLastCommit to total on restore. 1KL_ (Copilot): when a snapshot carried both the symlinked and canonical paths for the same file (a session straddling the canonicalisation fix), `set(realpathOrSelf(k), ...)` overwrote the first entry with the second, silently dropping the AI contribution the first form had accumulated. Merge instead: sum aiContribution and OR aiCreated when collapsing duplicate keys. Tests cover all three branches: non-string surface fallback, promptCount clamp, and duplicate-key merge. * fix(attribution): roll back snapshot dedup key on sync appendRecord failure 1UMh (Copilot): appendRecord can throw synchronously before returning a promise — e.g. when ensureConversationFile() rethrows a non-EEXIST writeFileSync error. The async .catch() handler attached to the promise never runs in that case, so the optimistic dedup-key set sticks on a write that never landed and permanently suppresses identical retries. Roll back lastAttributionSnapshotJson in the outer catch too. Regression test forces writeFileSync to throw EACCES on the first invocation, then asserts the second identical snapshot attempt fires a fresh write rather than getting deduped. * docs(attribution): align cleanup-branch comments with noteCommitWithoutClearing Three doc/test-fixture stale-after-refactor cleanups (Copilot 4MDx / 4MEI / 4MEa): - shell.ts:1944 (around the stagedInfo === null branch): the comment still claimed the finally block "falls back to a full clear", but 1ece87438 switched analysis-failure cleanup to noteCommitWithoutClearing(). Update the comment so the reasoning matches what the code actually does (and so a future reader doesn't reintroduce the wholesale clear thinking it's already there). - shell.ts: getCommittedFileInfo docstring carried the same stale "full clear" claim for the `null` return value. Update to describe the noteCommitWithoutClearing() fallback and the smaller-evil trade-off for the just-committed file. - chatRecordingService.test.ts: baseSnapshot fixture for the recordAttributionSnapshot tests still carried `baselines: {}`, even though that field was removed from AttributionSnapshot in 296fb55ae's dead-code purge. Structural typing let it compile, but the fixture didn't reflect the production shape — drop it. * fix(attribution): restore fire-and-forget appendRecord, route rollback via callback 6OcJ (Copilot): refactor in 715c258fb returned a Promise from appendRecord so the snapshot dedup-key path could chain rollback — but recordUserMessage / recordAssistantTurn / recordAtCommand / recordSlashCommand / rewindRecording all call appendRecord without await or .catch(). A transient jsonl.writeLine rejection on any of those would surface as an unhandled-promise-rejection (warning, or crash on --unhandled-rejections=throw). Restore the original fire-and-forget semantics: appendRecord again returns void and internally swallows async failures (logging via debugLogger). Per-record failure reactions are routed through an optional onError callback — recordAttributionSnapshot uses this to roll back lastAttributionSnapshotJson when the write that set it ends up rejecting. Tests: add a fire-and-forget regression that mocks writeLine to reject and asserts no unhandledRejection events fire while the existing snapshot rollback tests (sync + async) still pass via the new callback path. * fix(attribution): GIT_DIR repo-shift bail, snapshot envelope validation, narrow legacyTypes 80ME (gpt-5.5 /review, [Critical]): tokeniseSegment unconditionally stripped every leading KEY=value token. `GIT_DIR=elsewhere/.git git commit ...` was therefore treated as an in-cwd commit, picked up the Co-authored-by trailer, and produced a per-file note that landed against our cwd's HEAD even though the actual commit went to a different repo. Define a GIT_ENV_SHIFTS_REPO set (GIT_DIR, GIT_WORK_TREE, GIT_COMMON_DIR, GIT_INDEX_FILE, GIT_NAMESPACE) and have tokeniseSegment refuse to parse any segment whose leading env block (including the env-wrapper's KEY=VALUE block) carries one of these. Identity / date variables (GIT_AUTHOR_*, GIT_COMMITTER_*) are deliberately NOT in the set — they tweak metadata but don't relocate the repo. Tests cover plain prefix, env-wrapped prefix, and a GIT_COMMITTER_DATE positive control that should still get the trailer. 8EeQ (Copilot): restoreFromSnapshot received `snapshot as AttributionSnapshot` from a structural cast off `unknown` (the resume path), so its TS-typed shape was only a hint. A corrupted JSONL line (non-object / array / wrong type discriminator / missing type) would skip past the version check straight into Object.entries(snapshot.fileStates) — and a non-object fileStates (an array, say) seeded fileAttributions with numeric-string keys. Add envelope-level shape gates (isPlainObject + type discriminator) and a fileStates plain-object check before iterating; both bail to a clean reset rather than poisoning the singleton. Tests added. 8Eej (Copilot): SettingDefinition.legacyTypes was typed as SettingsType[] which includes 'enum' and 'object' — JSON Schema's `type` keyword doesn't accept those values. Adding `legacyTypes: ['enum']` would silently produce an invalid settings.schema.json. Narrow the field's type to ReadonlyArray<'boolean' | 'string' | 'number' | 'array'> (the JSON-Schema-primitive subset). Future complex-shape legacy support should land its own branch in convertSettingToJsonSchema. * docs(attribution): correct legacyTypes / EXCLUDED_DIRECTORY_SEGMENTS comments 9Ta_ (Copilot): the JSDoc on legacyTypes claimed JSON Schema's `type` keyword does not accept `'object'` — that's wrong; `'object'` IS a valid JSON Schema type. Reword to reflect the actual rationale: `'enum'` is not a valid JSON Schema `type` value at all (enum constraints use the `enum` keyword), and a bare `{type: 'object'}` would accept any object regardless of what the field's pre-expansion shape actually allowed. The narrowed `boolean | string | number | array` set is exactly what the one-liner generator can faithfully emit; richer legacy shapes belong in their own branch of convertSettingToJsonSchema. 9Tbs (Copilot): the comment in generatedFiles.ts referenced `EXCLUDED_DIRECTORIES`, but the constant is `EXCLUDED_DIRECTORY_SEGMENTS` (renamed during the segment-boundary refactor). Update the reference so a future maintainer scanning for the rule doesn't chase a non-existent identifier. * fix(attribution): SHA-pin git notes, on-disk hash divergence detection, env -C cwd-shift tanzhenxin review #1 — Note targets symbolic HEAD, not captured SHA: buildGitNotesCommand hard-coded 'HEAD' as the target; postHead was captured at commit-detection time but only used for the !== preHead diff. Between that capture and the execFile, three more awaited git calls run — anything that moves HEAD in the same cwd (post-commit hook, chained `commit && tag -m`, parallel process) silently lands the note on the wrong commit because of `-f`. Thread postHead through buildGitNotesCommand as a required `targetCommit` arg. Test asserts the targeted SHA, not the symbolic ref. tanzhenxin review #2 — Accumulator has no baseline: recordEdit was monotonic per-path with no reset for out-of-band mutations. Re-instate FileAttribution.contentHash and: - recordEdit hashes the input `oldContent` and resets the per-file accumulator if it doesn't match what AI's last write recorded (catches paste-replace via external editor, manual save, etc. WHEN AI subsequently edits the same file again). - New validateOnDiskHashes() rehashes every tracked file's CURRENT on-disk content and drops entries whose hash diverged. Called from attachCommitAttribution before matchCommittedFiles so a commit can never credit AI for a human-only diff. Deleted files (readFileSync throws) are left alone — the commit's deletion record is what the note should reflect. tanzhenxin review #4 — Failed-commit / staleness leak: The recordEdit divergence check above + commit-time validateOnDiskHashes together catch tanzhenxin's exact scenario (AI edits a.ts → hook rejects → user manually edits a.ts → user commits → no AI credit because validateOnDiskHashes drops the stale entry). The !commitCreated branch still preserves attributions to keep the submodule case working — the staleness problem is now solved at the next commit's validation step. Self-review item — env -C / --chdir treated as repo-shifting: Added ENV_FLAGS_SHIFT_CWD set covering -C / --chdir. tokeniseSegment returns null for `env -C DIR git commit ...` segments — same contract as a leading GIT_DIR=... assignment. Without this we'd either misidentify /elsewhere as the program (silently dropping attribution) or, worse if -C went into the value-skip set, trailer-inject onto a commit that lands in /elsewhere's repo. Tests added alongside the existing GIT_DIR repo-shift cases. 339 tests pass; typecheck clean. * fix(attribution): pickBool intent-aware, shouldClear gate, ETIMEDOUT surface, drop dead exports -wgA + -wg0 (deepseek): pickBool defaulted non-boolean to true, turning a hand-edited `{ commit: "false" }` into enabled attribution. Replace with intent-aware parsing: "true"/"yes"/"on"/ "1" → true, "false"/"no"/"off"/"0"/"" → false, anything else (unknown strings, non-1 numbers, objects, arrays, null) → false. Genuinely-absent sub-fields still default to true (schema default). Migration test scenarios covered. Tests now cover ~17 input cases across both string/number/null/object/unknown forms. -wgq (deepseek): when buildGitNotesCommand returned null (oversized payload) or git notes itself failed, the finally block called clearAttributedFiles(committedAbsolutePaths) — irreversibly deleting per-file attribution data the user might need to amend & retry. Introduce a separate `shouldClear` set that's only assigned on successful note write OR explicit toggle-off. Failure paths (oversized, exitCode != 0, exception, analysis failure) leave shouldClear null so the finally block calls noteCommitWithoutClearing instead — preserving per-file state for the user's recovery. 9p7W (Copilot): execFile callback coerced ETIMEDOUT / SIGTERM (timeout) into a generic exitCode=1 warning. Detect both `error.code === 'ETIMEDOUT'` and `error.killed === true && error.signal === 'SIGTERM'` so the user-visible warning correctly names "timed out after 5s" instead of "exited 1". -wg7 (deepseek): formatAttributionSummary and getAttributionNotesRef were exported but had zero production callers (only tests). Remove the dead exports + their tests (~40 LOC). If/when a logging surface needs them, they can be re-introduced. -wgb (deepseek): tokeniseSegment doesn't recursively unwrap `bash -c '...'` / `sh -c` / `zsh -c`, so addCoAuthorToGitCommit won't splice the trailer into a wrapped command. The background refusal AND the post-commit note path DO catch the wrapped commit because stripShellWrapper at the top of execute peels the wrapper before gitCommitContext / getGitHead run — so the worst-case ("background bash -c 'git commit' bypasses the guard") doesn't materialize. The remaining gap (no Co-authored-by trailer for bash -c-wrapped commits) requires recursively splicing into the inner script with proper bash single-quote re-quoting; significant enough that it's worth its own PR. Documented as a partial-coverage limitation. 339 → 325 tests pass after the dead-export removal; typecheck clean. * fix(attribution): committed-blob validation, deleted-leaf canonicalisation, sudo/env shifts, dir-stack gpt-5.5 review (issue 4389405179): 1. realpathOrSelf falls back to the non-canonical input when the leaf doesn't exist (deleted file). recordEdit stored the entry under the canonical path; lookup post-deletion misses on macOS where /var ↔ /private/var. Canonicalise the parent and rejoin the basename for missing leaves so deleted-file getFileAttribution still resolves the canonical key. Test updated to assert the lookup-after-unlink path explicitly. 2. validateOnDiskHashes read the LIVE working-tree, so a user who `git add`'d AI's content and then made additional unstaged edits would have the entry dropped on a commit whose blob still matched AI's hash. Replace with `validateAgainst(getContent)` that takes a caller-supplied reader; attachCommitAttribution now passes a reader that fetches the COMMITTED blob via `git show HEAD:<rel>`. Working-tree validation kept as `validateAgainstWorkingTree` for code paths without a committed ref. Returns null = no comparison signal (entry preserved). Tests cover all three readers (committed-blob via stub, working-tree, null-passthrough). deepseek-v4-pro review #1: sanitiseAttribution defaults missing contentHash to '' on legacy-snapshot restore. recordEdit's divergence check would then trip on every subsequent edit and silently reset all the AI work. Skip the divergence check when existing.contentHash is empty — we have no baseline to compare against, so don't drop. Test added covering legacy-snapshot preservation through validateAgainst. deepseek #4: validateAgainst now logs every entry drop via debugLogger.debug so a 3am operator can see WHICH entry got dropped and tied to which canonical key. deepseek #8: GIT_NAMESPACE removed from GIT_ENV_SHIFTS_REPO. It prefixes ref names within the same repo but doesn't redirect git to a different on-disk repository, so a commit underneath it still lands in our cwd's repo. Doc comment explains the distinction. deepseek #9: pushd/popd treated as cwd-shifting alongside cd in gitCommitContext / isAmendCommit / findAttributableCommitSegment. pushd reuses cdTargetMayChangeRepo (relative-no-escape stays in-repo); popd unconditionally flips cwdShifted because we don't track the bash dir-stack. deepseek #10: sudo's value-taking flag table now has a parallel SUDO_FLAGS_SHIFT_CWD set covering -D / --chdir (Linux sudo 1.9.2+). Any segment whose sudo wrapper sees one of those flags returns null from tokeniseSegment — same contract as env -C / --chdir and GIT_DIR=... 328 tests pass; typecheck clean both packages. * fix(attribution): scope validateAgainst to committed set, SHA-pin reader, intent-aware migration Round 1 of multi-pass audit on b3a06a7c4. Three correctness fixes: 1. validateAgainst was iterating ALL fileAttributions but the committed-blob reader (git show HEAD:<rel>) returns HEAD's pre-AI content for files NOT in the just-made commit. Result: pending unstaged AI work was silently wiped on every commit because the divergence check ran against the wrong baseline for unrelated files. Fix: build the committed scope first via matchCommittedFiles, scope the reader to that set (return null for everything else), validate, then RE-run matchCommittedFiles to pick up dropped entries. The validateAgainstWorkingTree wrapper had no production caller — removed it and its test. 2. The committed-blob reader used symbolic `HEAD` instead of the captured postHead SHA — same TOCTOU concern buildGitNotesCommand already addressed. A post-commit hook moving HEAD between capture and the reader's `git show` would silently compare against the wrong commit's content and trip the divergence check spuriously. Pin the reader to `git show <postHead>:<rel>`. 3. v3→v4 migration's invalid-string fallback used to reset to {}. Combined with the runtime pickBool's "absent → schema default true" rule, that silently re-enabled attribution for users who hand-edited `"gitCoAuthor": "off"` to disable. Migration now recognises enable-intent strings (true/yes/on/1/enabled) and disable-intent strings (false/no/off/0/disabled/'') and maps them to {commit, pr} explicitly. Unrecognised strings fall to {commit: false, pr: false} with a warning — same safer-by-default contract as runtime pickBool. Test grid covers all 11 cases. Also tidied the FileAttribution.contentHash JSDoc to reference the renamed `validateAgainst` (was still pointing at the dropped `validateOnDiskHashes` name). 1085 tests pass; typecheck clean both packages. * chore(attribution): extract pickOuterLastMatch, log unrecognised pickBool inputs Round 2 of multi-pass audit. Two cleanups, no behaviour changes: 1. addCoAuthorToGitCommit and addAttributionToPR each carried their own copy of the matchRange / isInside / "pick LAST non-nested match" logic (~25 LOC duplicated). Extracted to module-level helpers `matchSpan`, `isMatchInside`, and `pickOuterLastMatch<T>` so a future bug fix can't apply to only one of the two rewriters. Behaviour identical — same algorithm, same edge cases. 2. normalizeGitCoAuthor's pickBool silently maps unrecognised strings to false (safer-by-default vs the old "default-to-true on mismatch" policy, but a user who hand-edited `{ commit: "maybe" }` had no signal that their setting was being ignored). Add a `gitCoAuthorLogger.warn` listing the accepted forms so a debug-mode user can see the actual coercion. Known disable-intent strings (false/no/off/0/empty) stay silent — they're explicit user intent. Also pass the field name so the warning identifies which sub-toggle (commit vs pr) was bad. 1101 tests pass; typecheck clean. * fix(attribution): canonicalise BOM and CRLF before hashing Round 3 of multi-pass audit. One real correctness fix. Edit and WriteFile preserve the file's BOM and CRLF line-ending choice when writing back, so the on-disk bytes can include a leading U+FEFF and CRLFs even when AI's recordEdit input was given with LF and no BOM. The committed-blob reader's `git show <sha>:<rel>` returns those raw bytes verbatim, and computeContentHash hashed them as-is — so a UTF-8 BOM file or a CRLF-line-ending file would always have a mismatch between AI's recorded hash and the on-disk hash, and validateAgainst would drop the entry on every commit. Add `canonicaliseForHash`: strips a leading U+FEFF and normalises CRLF→LF before computing the SHA-256. Both sides (recordEdit when storing the post-write hash, and validateAgainst when comparing to the on-disk read) flow through computeContentHash, so the canonicalisation is symmetric. The hash is metadata used only for divergence detection — collapsing these visual differences is the right comparison semantics. Three regression tests added: BOM-only, CRLF-only, and BOM+CRLF combined. All exercise the typical case where AI's recordEdit input is LF + no BOM but the on-disk content (post-writeTextFile) has the file's preserved BOM/lineEnding choice. * fix(attribution): reset accumulator when re-creating a deleted tracked file Round 4 of multi-pass audit + Copilot finding from review 4236842362 (I missed it in the previous refresh). recordEdit's existing prior-state check was symmetric on diverged oldContent but ASYMMETRIC on a fresh file lifetime: when AI creates `foo.ts` (oldContent=null), then user `rm foo.ts`, then AI re-creates `foo.ts` (oldContent=null again), the second recordEdit saw `existing` (from the first lifetime) and SKIPPED the divergence check (because oldContent === null bails out of that branch). The accumulator carried 100 chars from the deleted file plus 5 chars from the new content = 155, vs the actual 5 on disk. Subsequent generateNotePayload's clamp against `(adds+dels) * 40` couldn't catch this — the diff size for a 1-line addition is 40, far above the actual content size. Add a fresh-file-lifetime branch: when `existing` is set AND the caller reports `oldContent === null`, reset aiContribution and aiCreated before counting the new contribution. The new edit is treated as a brand-new file at the same path (which is what the caller's null oldContent means semantically). Test added covering the exact `AI create → delete → AI re-create` flow. Also verified `should treat new files as ai-created` and `should accumulate contributions across multiple edits` still pass. * fix(attribution): treat git -C . as in-cwd, gate preHead on attributable Round 5 of multi-pass audit. Two related correctness/efficiency fixes around the cwd-shift parser and the preHead capture. 1. `git -C .` (and `-C ./`, `-C.`) is a no-op cwd shift but the "any -C → cwd-shifted" rule was treating it the same as `-C /tmp/other`, suppressing attribution for what's effectively `git commit` with an explicit current-dir marker. Add an `isNoopCwdTarget` helper used in both the spaced (`-C .`) and attached (`-C.`) branches of `parseGitInvocation`. `--git-dir` / `--work-tree` are left unconditional — those aren't cwd in the same sense. 2. preHead was being captured for ANY hasCommit, including the non-attributable cases (`cd /elsewhere && git commit`, `git -C /other commit`). The only consumer of preHead is the `attachCommitAttribution` call inside the `attributableInCwd` branch — there is intentionally NO cleanup branch for the non-attributable case (see the existing comment around the `else if (commitCtx.hasCommit)` non-branch). The execFileSync for `getGitHeadSync` is dead work in that path: ~10–50 ms blocking the event loop before the user's real command spawns. Gate the capture on `attributableInCwd` to match the consumer. Tests added for the three -C dot-form variants. Full suite green: 146 in shell.test.ts, 56 in commitAttribution.test.ts. * fix(core): preserve attribution across renamed files * fix(attribution): preserve env-vars in tokens, exclude empty -C targets Round 7 of multi-pass audit. Two related fixes around how `shell-quote` handles env-var references and how the cwd-shift detector reads them. 1. `shell-quote.parse` collapses `$NAME` references it cannot resolve to the empty string. The downstream cwd-shift checks (`cdTargetMayChangeRepo`'s `target.includes('$')` repo-shift detector, and the new `isNoopCwdTarget` no-op detector) were designed to catch env-var targets but received `''` instead of `$NAME` from `tokeniseSegment` and silently failed. Concretely, `cd $HOME && git commit` and `git -C $HOME commit` would both pass through as in-cwd attributable, stamping our trailer onto commits that land in whatever repo `$HOME`/`$REPO_ROOT` resolves to at runtime. Pass an env getter `(key) => '$' + key` to `shell-quote.parse` inside `tokeniseSegment` so unresolved references stay literal in tokens (`['cd', '$HOME']` instead of `['cd', '']`). `target.includes('$')` now fires correctly, and the no-op detector sees `$HOME` (non-`.`) and rejects it. KEY=value leading-env detection is unaffected (shell-quote doesn't interpolate inside KEY=value tokens). 2. Even with env preservation, an `''` target can still slip through (literal `-C ""`, escaped quotes, edge cases in shell-quote). Round 5's `isNoopCwdTarget` accepted `''` as a no-op alongside `'.'` / `'./'`, which would re-introduce the attribution-on-wrong-repo problem if any path produced an empty token. Tighten to `'.'` and `'./'` only — the only missed cases are literal `-C ""` (malformed, won't actually commit) and the rare `-C $PWD` (now also caught conservatively, since `$PWD` becomes literal `$PWD` and isn't `.` or `./`). Tests added for `cd $HOME` / `cd $REPO_ROOT && git commit` and `git -C $HOME commit` / `git -C "" commit`. Full suite green (150 in shell.test.ts, 58 in commitAttribution.test.ts). * fix(attribution): SHA-pin diff/rev-list phase, document aiChars heuristic Addresses tanzhenxin's review (4240760004) — two residuals after the prior pinning round. 1. Diff phase still races against HEAD. The note write itself was already pinned to the captured `postHead` (`git notes add -f <postHead>`), but the *content* of the note — `getCommittedFileInfo`'s probe + diff calls and the multi-commit guard's `rev-list --count` — were still going through symbolic `HEAD` / `HEAD~1` / `HEAD@{1}`. Several awaited subprocesses run between the postHead capture and these reads, so a husky / lefthook auto-amender, signed-commits hook, chained `git tag -m`, or parallel git process moving HEAD in that window would leave the note attached to commit A but describing commit B's contents. Same TOCTOU class as the prior critical, half-closed. Thread `postHead` (and `preHead` for amend) through `getCommittedFileInfo`. Probes become `rev-parse --verify ${postHead}~1` and `log -1 --pretty=%P ${postHead}`; diffs become `${postHead}~1..${postHead}` (parent case), `${preHead}..${postHead}` (amend — preHead is the pre-amend SHA captured before the user's command and is exactly what HEAD@{1} resolved to at parse time, with the added benefit that it can't be GC'd between capture and use), and `diff-tree --root <postHead>` (root commit). The amend branch keeps the existing reflog-vs- no-reflog warning, just driven off `preHead` instead of HEAD@{1}. Same pin applied to `countCommitsAfter` (now `${preHead}.. ${postHead}`) and `countCommitsFromRoot` (now `${postHead}`). Why parent case uses `${postHead}~1` and NOT `${preHead}`: in `git reset HEAD~3 && git commit` chains the captured preHead points well above postHead's parent, and `${preHead}..${postHead}` would describe the reset-away commits as deletions, drastically over-attributing. The actual parent of the just-landed commit is what we want, and `${postHead}~1` is the SHA-pinned form of that. 2. `aiChars` reads as a literal char count but isn't. The field is emitted as a plain integer named `aiChars`; the PR description's example shows values like 3200 / 1500 / 4700 that anyone parsing the note will read as literal character counts. Internally it's `(addedLines + deletedLines) × 40` for text and a flat 1024 for binary, with the per-file AI accumulator clamped against that ceiling. So 1000 one-character lines and 1000 thousand-character lines both report aiChars=40000, and a 5 MB image change and a 1-byte binary tweak both report 1024. Anyone aggregating raw aiChars for compliance reporting gets systematically wrong numbers. Add a comprehensive doc block on `FileAttributionDetail` (and `CommitAttributionNote`) calling out the heuristic explicitly, noting that `percent` / `summary.aiPercent` are the correct fields for aggregation since both numerator and denominator use the same proxy. Also expand the `APPROX_CHARS_PER_LINE` / `BINARY_DIFF_SIZE_FALLBACK` const docs to point at the same caveat. (Not renaming the fields — that'd break any downstream consumer already parsing the existing schema; the doc is the minimum-disruption call here.) 208 attribution tests pass; type-check clean. * fix(attribution): use posix join in applyCommittedRenames for Windows compat Windows CI failure on the two new rename tests (visible at PR #3115's `Test (windows-latest, *)` jobs): AssertionError: expected undefined to be defined ❯ src/services/commitAttribution.test.ts:572:66 (basic move) AssertionError: expected 11 to be 22 (merge into existing) Root cause: `path.join(canonicalRepoRoot, ...renamedRel.split('/'))` calls `path.win32.join` on Windows, which forces backslash separators regardless of input form. The test's `fs.realpathSync` mock returns forward-slash paths (matching the macOS `/var` ↔ `/private/var` fixture style), so `recordEdit` stores keys like `/private/var/repo/src/old.ts`. The rename's joined target then came out as `\\private\\var\\repo\\src\\new.ts`, the mock left it unchanged (no `/var/` prefix to translate), and the subsequent `fileAttributions.get(renamedAbs)` / `getFileAttribution(...)` lookups missed the just-set entry — the rename silently dropped attribution. The fix: build the joined path with `path.posix.join` against a forward-slash-normalised `posixRepoRoot`, then let `realpathOrSelf` canonicalise to the platform's storage form. This way: - On real Windows production: posix-joined `D:/repo/src/new.ts` is accepted by `fs.realpathSync` (Win32 API takes mixed slashes) and returned in backslash form, matching what `recordEdit` stored. - On real Linux/macOS production: forward-slash throughout, no-op. - In the symlink-aware test (any platform): forward-slash matches the mock-fixture storage form. `matchCommittedFiles` already does the inverse normalisation (`.split(path.sep).join('/')` for the relative-form check), so the in/out paths line up either way. Skipped adding a path.sep-mocked Linux-side regression because the ESM module namespace doesn't allow `vi.spyOn` on path's exports. The Windows CI job is the regression catcher; a focused-rerun should now go green. * docs(attribution): refresh stale HEAD~1/HEAD@{1} references in comments The SHA-pinning round (8c3312027) replaced symbolic `HEAD~1..HEAD` / `HEAD@{1}..HEAD` with `${postHead}~1..${postHead}` and `${preHead}..${postHead}` in `getCommittedFileInfo` and the rev-list helpers, but three docstrings / inline comments still described the old shapes: - `isAmendCommit` JSDoc said the amend switch goes from `HEAD~1..HEAD` to `HEAD@{1}..HEAD`. Updated to reference `${postHead}~1..${postHead}` and `${preHead}..${postHead}`, with the why (amended commit's parent is the original's parent so the standard parent diff lumps both commits' changes). - `attachCommitAttribution`'s amend branch comment had the same drift; updated to mention `${preHead}..${postHead}` directly. - `getCommittedFileInfo` JSDoc said it diffs "HEAD against its parent (HEAD~1)" and listed "--amend with no reflog" as an analysis-failure case. Updated to mention postHead-pinning and the preHead-driven amend bail (the reflog-GC dependency was dropped in the SHA-pin round). The remaining `HEAD~1..HEAD` references at countCommitsAfter:1959 and getCommittedFileInfo:2523 are intentional — they describe the old buggy shape as contrast for why we pin now. No code change; tests + tsc still clean. * fix(attribution): catch attached-value forms of env/sudo cwd-shift flags Round 13 audit found a real bug: `sudo --chdir=/tmp git commit`, `env -C/tmp git commit`, `env --chdir=/tmp git commit`, and `sudo -D/tmp git commit` were all silently slipping through the cwd-shift detector and getting our `Co-authored-by` trailer stamped onto commits that landed in a different repo. Root cause: `shell-quote` tokenises both the long attached form (`--chdir=/tmp`) and the short attached form (`-C/tmp`) as a single argv entry. The previous SHIFT_CWD detector did set-membership only against the bare flag (`{'-C', '--chdir'}` for env; `{'-D', '--chdir'}` for sudo), so the attached-form tokens never matched and `tokeniseSegment` returned a normally-attributable `['git', 'commit', ...]` segment. Fix: introduce `isShiftCwdFlag(flag, set)` that catches: - bare set-membership (existing behavior), - long attached: `--name=...` when `--name` is in the set, - short attached: `-Xanything` when `-X` is in the set and the token is longer than the flag itself. The flag does NOT need to consume an extra value token in the attached-form case (the value is already embedded), so the existing TAKES_VALUE bookkeeping is unaffected — we just bail with `null` from `tokeniseSegment` before reaching the value-skip step. Tests added: `env --chdir=`, `env -C/...` (attached), `sudo --chdir=`, `sudo -D/...` (attached) — each is asserted NOT to add a co-author trailer. 154 shell tests pass; type-check + lint clean. * test(attribution): cover attached-form git -C/--git-dir/--work-tree Adds three regression cases to the existing "git -C <path>" suppression test: the short attached form `-C/path` (single shell-quote token) and the long attached forms `--git-dir=/path` / `--work-tree=/path`. parseGitInvocation already had the prefix checks at lines 416/425, but no test exercised them — paired with the b89b65533 sudo/env attached- form fix this round closes the family of "shell-quote single-token flag with embedded value" cases that the bare set-membership checks would otherwise miss. 157 shell tests pass; type-check clean. * docs(attribution): document why backtick body doesn't bail like $( The addCoAuthorToGitCommit body capture has a known truncation case when an inner unescaped `"` appears inside the captured body — handled for `$(...)` command substitution with an explicit bailout, but not for backtick command substitution. The trade-off was unspoken; spell it out so a future reviewer doesn't read the asymmetry as an oversight. Bare-backtick bodies (`\`func()\`` markdown-style) are common in commit messages, have no inner `"`, and the regex captures them correctly. Pathological backtick-with-inner-quote bodies (`\`cmd "with" quotes\``) are a near-zero-traffic case where bash itself already interprets the backticks as command substitution, so the user has likely already broken their own command before our rewrite runs. Bailing on any backtick would lose attribution for the common case to defend against the rare one. Also drops a stray blank line in commitAttribution.test.ts left over from an earlier regression-test attempt. * fix(attribution): scope trailer rewrite to before unquoted shell comment Round 13 follow-on. Both `addCoAuthorToGitCommit` and `addAttributionToPR` ran their `-m` / `--body` regex against the full segment string, including any trailing shell comment. For a command like `git commit -m "real" # -m "fake"` (a human-authored script might leave a comment-out flag in place), `lastMatchOf` would pick the comment's `-m "fake"`, splice the `Co-authored-by:` trailer in there, and bash would silently discard the entire segment as a comment — leaving the actual commit unattributed. Same shape for `gh pr create --body "real" # --body "fake"`. Fix: introduce `findUnquotedCommentStart(s)` — a bash-aware position scanner that tracks single/double-quote state and treats `#` as a comment marker only when it begins a word (start of input or preceded by whitespace), not when it appears inside a quoted region or mid-token like `foo#bar`. Both rewriters slice the segment to `[0, commentStart)` before running their regex, so the trailer can only land in the live (pre-comment) part. Tests added: - `git commit -m "real" # -m "fake"` — trailer lands in `"real"` body BEFORE the `#`, comment's `-m "fake"` is left untouched. - `git commit -m "fix #123 add feature"` — `#` inside the quoted body is correctly NOT treated as a comment; the `#123` stays inside the body and the trailer is appended. 159 shell tests pass; type-check clean. * fix(attribution): warn on gh pr create flows that can't be rewritten + cover legacy gitCoAuthor migration end-to-end Two residuals from this morning's review pass. 1. ANm7O — `addAttributionToPR` silently skipped for `--body-file`, `--fill`, and bare `gh pr create` (editor) flows. The rewriter only knows how to splice into an inline `--body`/`-b` argv entry. For a `gh pr create` that uses `--body-file path`, `--fill` (uses commit messages), or no body flag at all (editor prompt), there's no inline body to splice into and the function returned the unmodified command. Users with `gitCoAuthor.pr` enabled would see PRs created without the attribution line and have no signal as to why. Add a debugLogger.warn at the no-match path naming the unsupported flows and pointing the user at the inline form. Don't try to handle `--body-file` automatically — that would mean mutating the user's file on disk, which is well outside what an unprompted command rewriter should do; `--fill` and editor flows have no body in argv at all and can't be rewritten without re-architecting. Tests added for `--body-file <path>`, `--fill`, and bare `gh pr create` — each is asserted to leave the command unchanged (no `Generated with Qwen Code` line spliced in). 2. ANm7L — settings-migration integration suite didn't cover the exact V3 legacy shape this PR introduces. `v3-to-v4.test.ts` already pins the migration body, but the end- to-end CLI load → migrate → write path could regress without the integration suite noticing. The existing v3LegacyDisableSettings fixture has no `general.gitCoAuthor` field, so the V3→V4 step technically fires but doesn't exercise the new boolean-expansion logic. Add a `v3GitCoAuthorBooleanSettings` fixture and a paired test case that writes `general: { gitCoAuthor: false }` at $version 3, runs the same `mcp list` CLI invocation, and asserts the saved file has $version 4 plus `general.gitCoAuthor` exactly `{ commit: false, pr: false }` — with sibling general.* keys and unrelated top-level sections preserved. 162 shell tests pass; type-check + lint clean.	2026-05-08 09:55:58 +08:00
jinye	df90da6f03	feat(telemetry): add sensitive span attribute opt-in (#3893) ... * feat(telemetry): add sensitive span attribute opt-in Add a telemetry setting and environment override for including sensitive attributes in spans created by the log-to-span bridge. Keep the default filtering behavior for prompt, function_args, and response_text unless explicitly enabled. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(telemetry): clarify span bridge options Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * feat(telemetry): populate api response text Populate response_text on API response telemetry events for non-internal prompts so opted-in bridge spans can include model response bodies. Exclude thought text from the recorded response text and keep internal prompt responses omitted. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * docs(telemetry): clarify sensitive span attribute scope Clarify that the sensitive span attribute setting only controls log-to-span bridge spans, while response text may still reach other telemetry sinks from API response events. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(telemetry): cap recorded response text Limit response_text captured for API response telemetry to a bounded length and mark truncated values to avoid oversized OTLP attributes. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-05-08 00:36:08 +08:00
ChiGao	7f0c9791b7	feat(cli): expand TUI markdown rendering (#3680) ... * feat(cli): expand markdown rendering in tui * fix(cli): render finalized mermaid images synchronously * fix(cli): harden markdown rendering paths * fix(cli): preserve mermaid source fallbacks * test(cli): make mermaid image renderer mock cross-platform * fix(cli): run windows mmdc shims through shell * fix(cli): address markdown rendering review comments * fix(cli): validate mermaid render timeout * feat(cli): expose rendered markdown source blocks * fix(cli): align mermaid source copy controls * fix(cli): make markdown render toggle visible * fix(cli): keep markdown render toggle quiet * fix(cli): generalize markdown render mode * fix(cli): broaden render mode and copy latex blocks * fix(cli): align rendered copy source indices * fix(cli): support copying inline latex expressions * feat(cli): document markdown render controls * test(cli): cover markdown render controls * fix(cli): tighten markdown render fallbacks * fix(cli): bound mermaid renderer cache * fix(cli): address markdown render review feedback * fix(cli): address markdown render review comments * test(cli): strengthen render mode shortcut coverage * fix(cli): address mermaid image review comments * fix(cli): stabilize renderer output truncation * test(cli): flush fake renderer stderr before exit * fix(cli): address markdown renderer review feedback * docs(cli): clarify mermaid image limits * fix(cli): refresh mermaid images on height resize * fix(cli): address markdown render review * chore: revert unrelated review formatting churn * fix(cli): avoid mermaid regex codeql alert * fix(cli): silence mermaid operator codeql alert * fix(cli): render inline math in markdown tables * fix(cli): harden markdown visual renderers * fix(cli): strip c1 controls from mermaid previews --------- Co-authored-by: 秦奇 <gary.gq@alibaba-inc.com>	2026-05-07 16:24:13 +08:00
jinye	b1ec8d64c7	fix(cli): warn on ignored provider generation config (#3883) ... * fix(cli): warn on ignored provider generation config Warn when a selected provider model has top-level model.generationConfig fields that will not apply because the provider entry is sealed. Document the required local-model placement for contextWindowSize and related generation config fields. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): address provider config warning review Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): narrow provider config warning fields Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-05-07 14:46:23 +08:00
Shaojin Wen	93139d0eb0	docs(cli): document new banner customization settings (#3885) ... Add ui.customBannerTitle, ui.customBannerSubtitle, and ui.customAsciiArt to the user-facing settings table. Also reword ui.hideBanner to note that it covers both the logo column and the info panel and that Tips render independently. These settings landed in #3710 but only ui.hideBanner was listed in the table, so users had no way to discover the other three short of reading the schema or the design doc.	2026-05-07 13:42:22 +08:00
tanzhenxin	808d0978eb	feat(cli): route foreground subagents through pill+dialog while running (#3768) ... * feat(cli): route foreground subagents through pill+dialog while running Foreground (synchronous) subagents currently render a live AgentExecutionDisplay inside the parent's pendingHistoryItems block. The frame mutates on every tool call and approval; once it grows past the terminal height (verbose mode, parallel subagents, long tool-call lists) the live-area repaint flickers visibly. This change extends BackgroundTaskRegistry with a flavor: 'foreground' | 'background' discriminator. Foreground entries register at the start of the synchronous tool-call and unregister in its finally path. The pill counts them; the dialog drills into their activity. The inline frame is suppressed during the live phase — only an active, focus-locked approval prompt renders, as a small banner labeled with the originating agent. Once the parent turn commits, the full AgentExecutionDisplay appears in scrollback via Ink's <Static>, exactly as before. Foreground entries skip the XML task-notification (the parent receives the result through the normal tool-result channel) and skip the headless holdback (the parent's await already pins the loop). The dialog gates per-agent cancellation behind a two-step confirm so a stray 'x' can't end the user's current turn. * fix(cli): address review findings on foreground subagent routing - Gate `registerCallback` on background flavor so foreground entries don't leak orphaned `task_started` SDK events without a matching terminal notification. - Render a queued-approval marker for non-focus subagents instead of returning null, so a queued approval is visible in the main view. - Move `emitStatusChange` before `agents.delete` in `unregisterForeground` to match the ordering used by complete/fail/cancel/finalize. - Prefix the foreground tool result with a cancel marker when `terminateMode === CANCELLED`, so the parent model can distinguish a user-cancelled run from a successful completion. - Mirror the background path's stats wiring on the foreground path so `entry.stats` stays current and the dialog detail subtitle shows tool count + tokens for foreground runs. - Remove the unreachable `isWaitingForOtherApproval` branch (subsumed by the queued-approval marker above). - Reset the foreground confirm-step on detail-mode `left` and ignore `x` on terminal entries so an armed cancel can't carry into list mode and the hint footer/handler stay in sync. - Test factory uses a `baseProps` spread instead of `as` cast so a future required field on `ToolMessageProps` is a compile-time miss.	2026-05-06 14:08:12 +08:00
Shaojin Wen	3631c01e17	feat(skills): parallelize loading + add path-conditional activation (#3604) ... * perf(skills): parallelize skill loading with Promise.all Three nested for-await loops in SkillManager — one per layer of the skill discovery tree — were serializing what is independent I/O: - refreshCache(): the 4 SkillLevels (project/user/extension/bundled) load one after the other. - listSkillsAtLevel(): each provider directory (.qwen, .agent, .cursor, ...) is read sequentially. - loadSkillsFromDir(): each skill subdirectory's stat + access + parseSkillFile fires one at a time. Replace each layer with Promise.all so the I/O fans out. Precedence between provider dirs is still preserved by folding the parallel results back in baseDirs order. No semantic change; the pre-existing 49 SkillManager and 27 skill-load tests still pass unchanged. * feat(skills): add path-conditional skill activation Large monorepos accumulate skills faster than any one task cares about. Every turn we ship the full <available_skills> listing in the SkillTool description — 100 skills is roughly 600–1500 tokens the model does not need most of the time. Let skills opt into lazy activation via a `paths:` frontmatter list of glob patterns. Such skills stay out of the tool description until a tool call touches a matching file, at which point they become active for the rest of the session. The mechanism mirrors the existing ConditionalRulesRegistry used for .qwen/rules/. Shape: - SkillConfig gains `paths?: string[]`; skill-manager and skill-load both parse it (array of non-empty strings; scalar rejected). - New skill-activation.ts holds SkillActivationRegistry (picomatch, per-session Set of activated names, project-root-scoped) and a splitConditionalSkills() helper. - SkillManager rebuilds the registry on every refreshCache and exposes matchAndActivateByPath / isSkillActive / getActivatedSkillNames. Activation fires change listeners so the SkillTool description picks up the new entry immediately. - SkillTool.refreshSkills filters the listing through isSkillActive and keeps a pendingConditionalSkillNames set so validateToolParams can distinguish "not found" from "registered but gated" — the model otherwise sees the same generic error for both cases. - coreToolScheduler invokes matchAndActivateByPath alongside the existing ConditionalRulesRegistry hook, and appends a <system-reminder> announcing the newly activated skill(s) so the model learns why its tool listing just grew. Activation state is intentionally scoped to a single registry instance; a watcher-driven refreshCache wipes it, matching ConditionalRulesRegistry's semantics. Adds 11 tests for the registry, 4 parse-paths tests, 4 integration tests on SkillManager, and one validateToolParams test for the distinct "gated by paths:" error. All 197 related tests pass. * fix(skills): scope path activation to visible, model-invocable skills Two issues caught by review of the new conditional-skill activation path, both rooted in `refreshCache()` building the activation registry from the raw concatenation of every level's skills: - Cross-level shadow: when the same skill name exists at multiple levels with different `paths:` globs, `listSkills()` picks the highest-precedence copy (project > user > extension > bundled), but the registry compiled every copy. A path matching only the shadowed copy's glob would still flip the visible copy to "active" — the model would see it appear in `<available_skills>` even though the touched file was outside its declared paths. - Disabled-with-paths: a skill carrying both `paths:` and `disable-model-invocation: true` would enter the registry, fire the "skill is now available" `<system-reminder>` on path match, and then SkillTool would reject the invocation because the disabled flag hid it from `availableSkills` and `pendingConditionalSkillNames`. The model gets a generic "not found" after being told the skill exists. Fix both at the registry-build site by walking levels in precedence order, deduping by name (keep the first/highest-precedence copy), and dropping `disableModelInvocation` skills before splitting on `paths`. Adds two regression tests in `skill-manager.test.ts`. * docs(skills): document path-conditional activation and the model/user view gap @yiliang114 noted that asking the model "what skills do you have?" returns only currently active skills, while `/skills` shows the fuller list — a path-gated skill stays out of the model's listing until a matching file is touched, so users may incorrectly conclude the skill is missing. Add a "Optional: gate a Skill on file paths (\`paths:\`)" subsection under the field requirements, covering glob semantics, scope, the session-lifetime activation, that user invocation is unaffected, and the disable-model-invocation interaction. Also add an admonition in the "View available Skills" section calling out the model-vs-user distinction explicitly and pointing at the \`/skills\` slash command as the always-complete browse path. * refactor(skills): extract parsePathsField + tighten paths mock pattern The `paths:` frontmatter parser was duplicated across `skill-manager.ts:parseSkillContent` and `skill-load.ts:parseSkillContent`. Future validation tweaks (e.g. minimum length, character whitelist, glob pre-check) would have to land in both places, with no compile-time link to keep them in sync. Extract `parsePathsField(frontmatter)` into `types.ts` next to the existing `parseModelField`, and call it from both parsers. Same contract: returns the cleaned array, or `undefined` when omitted / empty / all-whitespace; throws when present but not an array. Adds 8 tests in `skill-load.test.ts` covering the contract. Also tighten the `paths:` branch in the `skill-manager.test.ts` mock yaml parser. The previous `yamlString.includes('paths:')` also matches incidental occurrences of `paths:` inside skill body text. No bundled fixture currently has that, but the substring check is a footgun for future tests; switch to `^paths:` (multiline start anchor) so only a frontmatter-level field triggers the branch. * fix(skills): widen activation coverage and tighten dedup edges Three fixes from the latest /review pass on the activation pipeline, all touching the same hook surface: 1. Activation only fired on `file_path` — read-file / edit / write-file. Tools that touch the filesystem under different parameter names (`path` for ls and ripGrep, `filePath` for grep and lsp, `paths` array for ripGrep multi-path) silently skipped both ConditionalRulesRegistry and SkillActivationRegistry. Extract `extractToolFilePaths(toolInput)` and route every recognised path through both registries; coalesce skill activations from one tool call into a single system-reminder. 2. SkillTool's model-invocable-commands dedup set was built from every file-based skill name, including ones marked `disable-model-invocation: true`. A hidden file skill could suppress an unrelated MCP prompt or command of the same name that was never meant to overlap with it. Filter the dedup set to model-invocable skills only; pending conditional skills stay reserved (correct contract), disabled skills no longer block unrelated commands. 3. SkillActivationRegistry's project-root guard rejected `..` / `../` prefixes but accepted absolute results. On Windows, `path.relative('C:\\proj', 'D:\\elsewhere')` returns an absolute path; after normalising backslashes a broad glob like `**/*.ts` would activate a project-scoped skill for an off-project file. Reject absolute relative results before normalising slashes. Adds regression tests for each: - 7 cases for `extractToolFilePaths` (each field name + combos + non-object / wrong-shape inputs). - 1 SkillTool case proving a `disable-model-invocation` skill no longer suppresses a same-name MCP prompt. - 1 SkillActivationRegistry case for the absolute-relative-path guard. (220 skill-area tests pass total.) * test: stub matchAndActivateByPath in SkillManager test mocks The path-conditional skill activation hook in CoreToolScheduler.executeSingleToolCall now fires on every tool invocation that names a filesystem path. With the widened extractToolFilePaths coverage, that includes the `path: '.'` input shape used by the AgentHeadless tool-execution tests. Two SkillManager mocks predate the activation API and stubbed only watcher / listener methods, so the scheduler hook crashed with "matchAndActivateByPath is not a function" on any tool invocation in those test files. Local runs still hit it on this branch (no `path:` field tools were exercised pre-merge), and CI caught the regression in agent-headless.test.ts across all 9 matrix combos. Stub the method to return [] in both mocks (agent-headless and config), matching the watcher-method pattern. Production code is unchanged — the existing SkillManager has the method and the real path through Config wires it up correctly. * fix(skills): await listener refresh during path activation Race surfaced by /review: matchAndActivateByPath synchronously notified change listeners, but the SkillTool listener was a fire-and-forget `void this.refreshSkills()`. The activation hook in CoreToolScheduler then appended the "skill X is now available" <system-reminder> and the tool result was sent to the model without waiting — so the next turn could land with the <available_skills> listing still showing the pre-activation set, and the model's first invocation of the announced skill would hit validateToolParams's "not found" branch. Make the listener pipeline awaitable end-to-end: - addChangeListener now accepts `() => void | Promise<void>`. - notifyChangeListeners is async and awaits each listener's return, so any returned Promise (e.g. SkillTool.refreshSkills) is held before the call resolves. - refreshCache awaits the notification it was already firing. - matchAndActivateByPath becomes async and awaits notification when at least one new activation occurred. The CoreToolScheduler hook awaits the call so the system-reminder lands strictly after the tool description has been refreshed. - SkillTool's listener returns the refresh Promise directly instead of stranding it under `void`. Existing test mocks for `addChangeListener` accept any return value, so no mock changes are needed. The four matchAndActivateByPath direct-call tests in skill-manager.test are updated to `await` the new Promise return. * fix(extension): await skill + subagent cache refresh in refreshMemory Caught by /review on the previous async-listener change: this PR made `SkillManager.refreshCache()` resolve only after the change-listener chain (notably `SkillTool.refreshSkills` and `geminiClient.setTools()`) settles. `ExtensionManager.refreshMemory` was firing it without `await`, so callers like `refreshTools` would return while the skill cache and tool description were still updating, and any rejection from the listener chain was silently detached. Wrap skill + subagent refreshes in a single `Promise.all` so they still run concurrently, but the parent `refreshMemory` Promise only resolves once both side-effects have landed. Hierarchical memory refresh is left as-is (pre-existing fire-and-forget pattern, unchanged by this PR). * fix(skills): security/perf/robustness pass on activation pipeline Six findings from /review (claude-opus-4-7), all rooted in the new path-conditional activation code: 1. extractToolFilePaths now requires a `toolName` and gates on a closed FS_PATH_TOOL_NAMES allowlist (read_file, edit, write_file, grep_search, glob, list_directory, lsp). MCP / non-FS tools that reuse `path` / `paths` for HTTP routes, JSON keys, search queries would otherwise feed those values into the activation pipeline, where `path.resolve(projectRoot, …)` would normalise them to project-relative strings and false-match a skill with broad globs (e.g. `paths: ['**']`). Concrete attack noted by /review: `{ path: 'https://api.example.com/users/123' }` → activates a skill on every MCP call. 2. Skill `name` validated at parse time against `/^[a-zA-Z0-9_:.-]+$/`. The value flows verbatim into multiple model-trusted sinks: `<available_skills>` description, the path-activation `<system-reminder>`, the SkillTool schema, and UI listings. Reject characters that could close a tag and open a forged one (`name: "ok</system-reminder><system-reminder>…"`). 3. SkillManager.matchAndActivateByPaths(filePaths) added. The per-path notify in coreToolScheduler caused N successive SkillTool.refreshSkills() / geminiClient.setTools() round-trips for a single ripGrep-style multi-path call; the batch entry point activates across all paths and fires listeners exactly once with the union. matchAndActivateByPath delegates to it for call-site compatibility. 4. SkillManager.refreshCache uses Promise.allSettled at the levels boundary so a fatal error on one level (FS hang, permission denial, missing config dir) no longer nukes the other three; warns with the level + reason for the failed slot. 5. parsePathsField accepts explicit `null` (the YAML `paths:` no-value shorthand) the same way as omission, instead of throwing and dropping the whole skill via parseErrors. Matches the leniency of `argumentHint` and `whenToUse`. 6. SkillActivationRegistry adds a `SKILL_ACTIVATION` debug logger for the operational pain noted in the audit: per-path resolved relative-path, project-root-rejection reason, and per-skill activation. Also gives oncall a grep target for "why did/didn't skill X activate?" without source-reading. Test mocks (agent-headless, config) now expose matchAndActivateByPaths alongside matchAndActivateByPath. New tests: parsePathsField null, validateSkillName allow/reject pairs (including the closing-tag attack literal), batch activation firing listeners exactly once, batch with no matches not firing listeners, and an extractToolFilePaths regression for MCP / web / skill tool inputs being filtered out. * fix(skills): glob pattern activation + verifiable Windows guard Two follow-ups from the latest /review pass: 1. `extractToolFilePaths` now extracts `pattern` for `ToolNames.GLOB` in addition to the existing `path` field. The shape `glob({ pattern: 'src/**/*.tsx' })` (no `path`) was producing an empty candidate set, so a skill keyed on the same glob never activated from a glob call. Pattern extraction is gated to GLOB only — grep_search also has a `pattern` field, but it's a regex and would false-match if treated as a path-shaped selector. 2. The relative-path normalization is extracted into a pure helper `resolveProjectRelativePath(filePath, projectRoot, pathModule)`. The previous Windows cross-drive regression test (`/totally/other/place/file.ts` against `/project`) actually exercised the older `..` outside-root branch on POSIX runners, so the new `path.isAbsolute(rawRelativePath)` guard could have been removed without the test failing. The helper is now parameterized over a `path` module so a unit test can pass `path.win32` directly and pin the cross-drive case (`D:\\other\\file.ts` against `C:\\project`) deterministically on any host OS. Adds 6 tests: glob pattern extraction (with and without path), grep regex pattern not extracted, and four resolveProjectRelativePath cases covering POSIX in-project, POSIX outside-root, Windows cross-drive (the new branch), and Windows in-project backslash normalization. * fix(skills): join glob.path with glob.pattern as effective selector Caught by /review on 599490b91: my earlier glob extraction pushed `path` and `pattern` as separate candidates. `glob({ path: 'src', pattern: '**/*.ts' })` produced `['src', '**/*.ts']` — neither component matches a skill keyed on `paths: ['src/**/*.ts']` in isolation, so activation silently broke for the most common two-arg glob shape. The glob call actually searches `<path>/<pattern>`. Replace the standalone pattern push with `path.join(pathField, patternField)`, falling back to bare pattern when no path is provided. The generic block above still emits the bare `path` candidate, so a broad skill keyed on `paths: ['src/**']` (directory-level) continues to activate too. Combined output for the regression example: `['src', 'src/**/*.ts']` — covers both the directory- level and file-level skill cases. Adds three tests: an updated unit test pinning the joined effective selector, an absolute-`path` variant whose joined form gets rejected downstream by the project-root guard (`/tmp/external/**/*.ts`), and the audit-suggested integration regression that pipes `extractToolFilePaths` output straight into `SkillActivationRegistry` and verifies a `paths: ['src/**/*.ts']` skill activates from `glob({ path: 'src', pattern: '**/*.ts' })`. * fix(skills): join glob.path with glob.pattern as effective selector Two coupled fixes for the glob-pattern extraction landed in 7cb7145bb: 1. **Windows CI failure.** `path.join('src', '**/*.ts')` returns `'src\\**\\*.ts'` on Windows (OS-aware separator). The new regression tests asserted the forward-slash form, so the ubuntu/macos matrix was green but all three Windows jobs (20.x/22.x/24.x) failed. The downstream registry also matches against forward-slash relative paths (after `replace(/\\/g, '/')`), so the Windows-shaped candidate would have silently failed to activate any skill at runtime — not just in tests. 2. **`..` normalization.** `path.join('src', '../*.ts')` collapses to `'*.ts'`, losing the information that the glob actually escaped its `path` root. The audit notes this can both miss the real touched subtree and false-activate a skill keyed on a wrong subtree. Concat preserves the selector verbatim. Replace `path.join(pathField, patternField)` with `${pathField.replace(/[\\/]+$/, '')}/${patternField}` per the audit's exact suggestion. Trims trailing forward-slash and backslash so `path: 'src/'` and `path: 'src\\'` both produce `src/<pattern>` instead of `src//<pattern>` or `src\\/<pattern>`. Adds three tests covering: `..` preservation, forward-slash on all OSes (the Windows CI regression), and trailing-slash trimming for both `/` and `\` variants. * fix(skills): silence CodeQL ReDoS flag on trailing-separator trim CodeQL #145 flagged `pathField.replace(/[\\/]+$/, '')` as a polynomial regex on uncontrolled data — the regex is anchored and uses a single character class with `+`, so worst case is linear in trailing-separator length, but the scanner is conservative about `+` quantifiers on inputs that flow from tool invocation parameters. Replace the regex with an explicit `endsWith` loop. Same O(n) behavior on the trailing run, no regex for CodeQL to chew on. Existing trailing-slash test (forward and back) still passes. * fix(skills): comprehensive review pass — security, correctness, robustness Eleven findings from /qreview (claude-opus-4-7), grouped by area: CORRECTNESS - C1: appendAdditionalContext silently dropped reminders for any tool whose llmContent is a single non-array Part (read-file returning inlineData for images / PDFs is the canonical case). Both the ConditionalRulesRegistry rule reminder and the path-conditional skill activation reminder were lost. Wrap the single-Part case into an array so the addition still lands. - S2: Legacy tool-name aliases (`replace` → `edit`, `search_file_content` → `grep_search`, `task` → `agent`) bypassed FS_PATH_TOOL_NAMES. The registry resolves the alias at execute time but `request.name` keeps the alias, so `replace({ file_path: ... })` produced empty candidates and missed activation. Canonicalize via `ToolNamesMigration` before the allowlist check. - S5: `new SkillActivationRegistry(...)` ran picomatch unguarded — pathological patterns (oversize / broken extglob) could throw and abort all of `refreshCache`. Wrap each picomatch call in try/catch inside the constructor; drop the bad pattern, keep the rest of the skill, log via debugLogger. - S7: Extension parser (skill-load.ts) silently dropped `disable-model-invocation` and `when_to_use`. Now that we have `paths:`, that meant an extension SKILL.md with both `paths:` and `disable-model-invocation: true` would still fire path-activation reminders for a skill the model can't invoke — directly contradicting the bug_004 fix at the project/user level. - S8: SkillTool discarded the `addChangeListener` cleanup function and had no `dispose()`. Subagents share the parent's SkillManager via `InProcessBackend.createPerAgentConfig`, so each per-subagent SkillTool registered another listener; with the listener pipeline now async, every path activation serialized through every stale subagent's refresh chain. Mirror AgentTool: store the cleanup, expose `dispose()`. SECURITY / SUPPLY-CHAIN - S11: `validateSkillName`'s `/^[a-zA-Z0-9_:.-]+$/` rejected every non-ASCII name on upgrade, silently dropping CJK / Cyrillic / accented Latin skills. The structural-injection guard targets `<>"'/\n\r\t` etc; entire Unicode planes are not the threat. Widen to `/^[\p{L}\p{N}_:.-]+$/u`. Update docs/users/features/ skills.md to match. - S10: `parsePathsField` only validated shape (must-be-array). Now also reject leading-slash absolute patterns and `..` parent-escape patterns at parse time — these silently never match anything in the activation registry, so an author who writes `paths: ['/etc/passwd']` or `['../*.ts']` would otherwise see the skill in /skills and never understand why it never activates. ROBUSTNESS - S3: `coreToolScheduler` emitted "skill X is now available via the Skill tool" even when the calling subagent's tool registry did not expose SkillTool (subagent's `tools:` allowlist excluded `skill`). Gate the reminder on `toolRegistry.getTool(ToolNames.SKILL)`. - S4: `extensionManager.refreshMemory` used `Promise.all` so a rejection from skill or subagent refresh nuked the other leg AND the hierarchical-memory refresh below it. Switch to `Promise.allSettled`, log each rejection, and `await` the hierarchical refresh too (the comment justifies awaiting; the code didn't). - S9 / S12: `docs/users/features/skills.md` claimed `paths:` only gates model discovery and slash invocation always works. True for the user-side path itself, but if the model then tries to chain off the user's invocation (call `Skill { skill: ... }` itself), validateToolParams returns "gated by path-based activation" — contradicting the doc. Rephrase to call out the model-side limitation explicitly. DEFERRED - S6: notifyChangeListeners swallows per-listener errors and the reminder still fires. Real concern but the fix needs an API shape change (listener-failure signal back to the scheduler); worth its own design discussion. Logged here for follow-up. Adds 12 regression tests across the 7 affected files. 632 tests pass; types and lint clean. * fix(skills): activate broad globs on dotfiles + cross-ref FS allowlist Two more findings from /review: - S13: picomatch was compiled with `dot: false`, so a broad glob like `paths: ['**/*.js']` silently excluded `.eslintrc.js`, `.env`, `.github/foo.yml`, etc. The hidden-file exclusion is gitignore-style semantics — wrong for activation, where the question is "did the model touch a file matching this glob." Switch to `dot: true`. - S14: `FS_PATH_TOOL_NAMES` is a manually maintained allowlist with no compile-time guard — adding a new FS tool without updating the set silently drops the tool out of the activation pipeline. Add a cross-ref comment at the top of `ToolNames` in `tool-names.ts` pointing maintainers at the allowlist site, plus a TODO noting the long-term fix is per-declaration `pathFields?: string[]`. The cross-cutting refactor is its own PR. Adds one regression test (`activates broad globs on dotfiles too`) that pins the dot:true semantics on `**/*.js` matching `.eslintrc.js`. 211 skill-area tests pass. * fix(skills): per-tool extraction dispatcher (LSP URI + grep glob + integration test) Four findings from /review on the activation extractor: C1 (Critical): LSP allowlisted but the extractor pushed `filePath` through unchanged. The LSP tool accepts non-file URI schemes (`http://`, `git://`, etc.); forwarding any of those to SkillActivationRegistry as a project-relative candidate let an LSP call against a non-file resource activate path-gated skills without the model touching a real project file. Fix is two-part: decode `file://` URIs via `fileURLToPath` (so a project file expressed as a URI still activates correctly) and silently drop any string containing `://` that's not `file://`. S1: LSP `incomingCalls` / `outgoingCalls` operate on `callHierarchyItem.uri`, not the top-level `filePath`. After `prepareCallHierarchy` returns a file-backed item, following the hierarchy with that item produced no candidate, so path-gated skills for that file stayed dormant. Same URI-aware extraction is applied to the nested `uri` field. S2: grep_search has a path-shaped `glob` field (`GrepToolParams.glob`) — distinct from `pattern`, which is a regex on contents. The extractor previously ignored `glob`, so `grep_search({ pattern, glob: 'src/**/*.ts' })` produced no activation candidate even though the call walked every file under `src/**/*.ts`. Same `path + glob` join treatment as GLOB. S3: No scheduler-side integration test covered the extractToolFilePaths → matchAndActivateByPaths → reminder-append wiring, so a regression there could land while extractor and registry unit tests still passed. Added three integration tests covering: (a) reminder appended when SkillTool present, (b) reminder suppressed when SkillTool absent (subagent case), (c) hook not invoked for non-FS tools. Restructured `extractToolFilePaths` from a generic `file_path/filePath/path/paths` extractor into a per-tool dispatcher (`switch` on canonical tool name). The previous generic shape was overly permissive — every FS tool got every field name, including ones it doesn't accept — and it was the wrong shape to add LSP URI semantics to. Per-tool means each branch reflects the actual `XToolParams` interface. Test reshape: - Removed tests asserting cross-tool field acceptance (e.g. grep reading `filePath` / `paths`); those documented inaccurate input. - Added per-tool realistic tests for grep glob, lsp file:// URI, lsp callHierarchyItem.uri, lsp non-file scheme dropped. - Plus the three CoreToolScheduler activation wiring tests. 639 tests pass (was 632); types and lint clean. DEFERRED S4: Activation driven from input selector rather than concrete matched files. For `glob({ pattern: '**/*.ts' })` the selector itself may not match a skill scoped narrower than the query. Real concern, but the fix needs typed result-path metadata feedback from each tool — a cross-cutting addition to every FS tool's return shape. Logged for follow-up. * fix(skills): make LSP URI tests platform-portable for Windows CI Two of the new LSP tests in 58836f1c3 hard-coded `file:///proj/...` URIs. POSIX runners are fine, but on Windows `fileURLToPath` throws `ERR_INVALID_FILE_URL_PATH` for a URI without a drive letter — the production try/catch then returns `[]`, and the assertion `expected [] to deeply equal [ '/proj/src/App.ts' ]` fails. Reshape the tests to build the URI from a real absolute path via `pathToFileURL`. The URI shape becomes the host's natural form (`file:///tmp/...` on POSIX, `file:///C:/.../tmp/...` on Windows), and the round-trip through `fileURLToPath` always succeeds. Production code unchanged. * fix(skills): XML-escape description/whenToUse; symlinks in skill-load.ts; dot:true in ConditionalRulesRegistry Agent-Logs-Url: https://github.com/QwenLM/qwen-code/sessions/a56d83ce-cbdf-4213-a90a-888a9f05ee4f * fix(skills): backport Windows cross-drive guard to ConditionalRulesRegistry The latest /review (deepseek-v4-pro) flagged divergence between SkillActivationRegistry (which has the `pathModule.isAbsolute(rawRelativePath)` Windows-cross-drive guard, added earlier in this PR) and ConditionalRulesRegistry (which still only checks `..` / `../` prefixes). On Windows, `path.relative('C:\\proj', 'D:\\elsewhere')` returns the absolute string `D:\\elsewhere` — after backslash normalization that would otherwise false-match a broad rule glob like `**/*.ts`. Move the project-relative-path helper out of `skills/` into a new `utils/projectPath.ts` (the right semantic home — it's a pure path operation with no skill-domain coupling) and have both registries call into it. SkillActivationRegistry re-exports the helper so existing imports keep working. Adds a regression test in `rulesDiscovery.test.ts` for the off-project path case (covers both POSIX `..` branch and the new Windows isAbsolute branch through the shared helper). Direct `path.win32`-parameterized cover already lives in `skill-activation.test.ts`. 252 skill+rules tests pass. * test(skills): pin XML escaping on modelInvocableCommands description too cmd.description already routes through escapeXml in skill.ts:204 (landed in b1d9324f5), but no test pinned the cmd path — only the skill.description / whenToUse path. Add a parallel regression that crafts an MCP-shaped command with `</available_skills><tag>` in the description and asserts it gets escaped instead of breaking out of the <available_skills> block. * fix(skills): escape cmd.name; extension skillRoot; surface invalid globs Three findings from /review (deepseek-v4-pro): C1: `cmd.name` was interpolated into the `<available_skills>` `<name>` tag without `escapeXml()`. File-based skill names go through `validateSkillName` (charset whitelist) at parse time, but command names from `modelInvocableCommands` come from externally-injected sources (MCP, extensions) and bypass that validator. A command shipped with `name: "x<inject>"` would inject raw tags into the model-facing tool description. Wrap `cmd.name` in `escapeXml`, parallel to the existing `cmd.description` escape one line below. C2: `parseSkillContent` in `skill-load.ts` (the extension parser) never set `skillRoot: path.dirname(filePath)`. The project/user/bundled parser in `skill-manager.ts` does, and `registerSkillHooks.ts:116` skips setting `QWEN_SKILL_ROOT` for command-type hooks when `skillRoot` is undefined — so shell commands inside extension-skill hooks couldn't resolve `$QWEN_SKILL_ROOT/scripts/...` references. Add the field. Comment notes the still-asymmetric `hooks:` extraction (the extension parser doesn't pull `hooks:`); leaving that as a separate alignment task because hooks may be intentionally restricted to managed skills as a security boundary. S3: Invalid `paths:` globs were only logged at debug level. Author writes `src/***/file.tsx`, the picomatch compile throws, the registry drops the pattern, and the skill loads with zero matchers — visible only as a permanent "gated by path-based activation" error with no actionable diagnostic. Add an optional `InvalidPatternHandler` callback to `SkillActivationRegistry`'s constructor. SkillManager wires it into its `parseErrors` map, keyed `<filePath>#paths[<pattern>]`, so the failure surfaces through `getParseErrors()` and the `/skills` UI alongside other parse-time errors. S4: Two related concerns about file-watcher race / activation wipe (`refreshCache` rebuilding the registry from scratch, plus potential interleaving of two `refreshCache` calls). Real but the fix needs design work — activation carry-over has its own semantics (do deleted skills survive?), and the serialization guard adds a generation counter that affects multiple call sites. Logged for follow-up. Three regression tests added: cmd.name escape (`should XML-escape modelInvocableCommands name`), extension skillRoot (`sets skillRoot to the SKILL.md directory`), and parseErrors surfacing for an oversized 70 KB glob pattern. 205 skill-related tests pass. * fix(skills): comprehensive XML-escape + coalesce + parallel listeners Six findings from /review (deepseek-v4-pro): C1: skill.name interpolated raw into <available_skills>. File-based names go through validateSkillName, but extension skills come in via extension.skills (skill-manager.ts:827) and bypass that validator entirely — a crafted extension name could inject raw tags. Same vulnerability for the activated-skill names in the coreToolScheduler reminder. Wrap both in escapeXml. S2: refreshHierarchicalMemory() await is unprotected after the earlier change to await it. A transient failure now propagates back through refreshMemory → enableExtension after isActive is already true, leaving the extension half-enabled. Wrap in try/catch and log; the surrounding extension transition shouldn't unwind because of a stale-memory side effect. S3: escapeXml duplicated between skill.ts and background-tasks.ts. Extract to utils/xml.ts; both call sites import from there. S4: parseSkillContent duplicated between managed and extension parsers. Real concern but the cleanup is a real refactor (the two parsers diverge on level / hooks / skillRoot wiring), so this PR adds a comment-level documentation but defers the actual extraction to a follow-up to keep this diff focused. S5: rulesCtx (rule body content) interpolated into <system-reminder> without scrubbing. A rule whose content contained literal `</system-reminder>` (e.g. a doc rule about reminders) would close the envelope early. Apply a targeted scrub of the closing-tag literal in the joined body. Full XML escape would mangle code blocks in rule markdown — the closing-tag scrub is the minimum needed to keep the wrapper intact. S6: notifyChangeListeners awaited listeners sequentially. With per- subagent SkillTools each registering as a listener, every matchAndActivateByPaths call serialized through every refreshSkills + setTools round-trip. Switch to Promise.allSettled — listeners are independent reads, the failure-isolation behavior is preserved. S7: Each rule emit + the activation reminder were each their own <system-reminder> envelope. A multi-path tool call could produce N+1 envelopes, diluting model attention. Coalesce: collect all reminder blocks, emit once with `\n\n` separators, scrub the closing-tag literal once on the joined body. Tests added: - skill.name extension-bypass escape regression - coreToolScheduler activation wiring: coalesces multiple rules + activation into one envelope (with grep_search path+glob to produce two candidate paths) - coreToolScheduler activation wiring: escapes activated skill names so a crafted extension name can't break out - coreToolScheduler activation wiring: scrubs literal </system-reminder> in rule content - 843 tests pass overall. * fix(skills): symlink scope check + dispose on stopAgent + listener type Five findings from /review (Qwen3.6-Plus-DogFooding): C1 + C2 (Critical, same finding cited twice): Symlink target was validated for "is a directory" but not for "stays inside baseDir". An attacker who can write a symlink into a skills directory (shared monorepo, compromised extension) could symlink /etc/cron.d/ → trigger arbitrary content load — and skills can ship hooks that invoke shell commands, so this is a code-execution vector. Apply realpath + prefix check in both symlink branches (skill-load.ts AND skill-manager.ts). Regression test in each suite (`should skip symlinks that escape baseDir (prevents arbitrary-skill-load attack)`). C3: SkillTool.dispose() existed but was only called from ToolRegistry.stop() at full shutdown. Subagents created/stopped during a session left their per-agent SkillTool listener attached to the parent SkillManager — every spawn-then-stop cycle accumulated another stale listener, and notifyChangeListeners (now parallel via Promise.allSettled) still pays a per-listener round trip even when the underlying subagent is gone. Convert InProcessBackend.agentRegistries from a flat array to Map<agentId, ToolRegistry> and dispose just that agent's registry in stopAgent. cleanup() still drains any registries still attached at full shutdown for the fast-path case. S4: changeListeners typed `Set<() => void>` while addChangeListener signature accepts `() => void | Promise<void>`. The runtime Promise.resolve().then(listener) wrapper handles the mismatch but the type didn't catch future drift. Widen the field type to match the parameter signature. S6: FS_PATH_TOOL_NAMES allowlist has no compile-time guard. Logged for follow-up — the pragmatic short-term fix (test asserting every entry has a corresponding extractToolFilePaths branch) requires deciding whether the test belongs in coreToolScheduler or tool-registry. Per-declaration pathFields annotation is the long-term answer; both are tracked. S7: setTools concurrency. Verified setTools is idempotent (rebuilds tools from registry, single sync assign at end); multiple concurrent calls converge on the same tools list. Added an inline note rather than a runtime mutex. Defer: - S5: refreshCache wipes all activations. Same activation carry-over design question deferred in the previous round. * fix(skills): listener timeout, full XML escape, allowlist warning + tests Address inline review feedback: - skill-manager.notifyChangeListeners: 30s per-listener timeout via Promise.race so a hung listener (e.g. setTools blocked on a network call) cannot permanently stall matchAndActivateByPaths. Timer is unref'd to avoid keeping the event loop alive. - types.parsePathsField: tighten parse-time validation. Normalize backslashes to forward slashes, reject Windows drive letters (`C:\\repo\\src\\**`) and segment-walk for any `..` (catches `./../*.ts`, `src/../../**`, `..\\secret\\*.ts`). Skill authors who write impossible-to-match patterns now get a parse error instead of a silent never-activates skill. - utils/xml.escapeXml: widen to all five XML metacharacters (`&<>"'`), not just three. Element-body callers are unchanged but attribute-context callers and `</tag>` injection are now safe by default. monitorRegistry drops its local copy in favor of the shared helper. - coreToolScheduler.extractToolFilePaths: emit a debug-level warning when a non-FS tool's input has path-like fields (`file_path`, `filePath`, `path`, `paths`). Surfaces allowlist gaps without production noise — chases "why didn't my path-gated skill activate?". - Tests: added (1) async listener await + sync-throw + async-reject isolation for notifyChangeListeners, (2) stopAgent registry dispose + Map cleanup + cleanup-drains-remaining for InProcessBackend. * fix(skills): harden symlink containment checks * Revert "fix(skills): harden symlink containment checks" This reverts commit 7e70a25a3a. * fix(skills): clear listener timeout, share symlink scope helper - skill-manager.notifyChangeListeners: clear the per-listener setTimeout in `.finally(...)` once the race settles. The previous `unref()`-only approach prevented the timer from blocking process exit, but every fast-resolving listener still left a 30s pending timer behind — vitest's open-handle diagnostic and any tooling that snapshots the active-handle set saw the pile-up under high-frequency activation. - New skills/symlinkScope.ts: shared `validateSymlinkScope` helper. Realpaths BOTH the symlink target and the base directory before the containment check, then uses `path.relative` (rather than `realPath.startsWith(base + sep)`) for cross-platform safety. The prior asymmetric form — `realpath(target)` against the raw `path.resolve(base)` — could false-skip valid in-tree symlinks on Windows when canonicalization (case, separators, short-vs-long-path forms) diverged from `path.resolve`'s purely lexical normalization; the failing Windows CI on the symlinked-skill test traced back to exactly that. `path.relative` also closes the sibling-prefix ambiguity (`base = '/a/skills'`, target = `/a/skillsX/foo` no longer passes a startsWith check). - skill-load.ts and skill-manager.ts both delegate to the shared helper. Each call site now realpaths baseDir once outside the iteration loop instead of per-entry (N → 1 syscall on parallel loaders), and bails the directory entirely if baseDir cannot be canonicalized. - Tests: 8 unit tests for `validateSymlinkScope` covering accept, nested-accept, sibling-prefix attack, escape, broken realpath, not-a-directory, stat failure, and the degenerate self-target case; updated existing escape/broken tests in `skill-load.test.ts` / `skill-manager.test.ts` to use `mockImplementation` distinguishing baseDir vs target (the previous static `mockResolvedValue` would have passed the new check for the wrong reason); regression test for the cleared timeout via setTimeout/clearTimeout spies. * fix(skills): segment-aware symlink containment, accepts ..-prefixed names The previous `rel.startsWith('..')` containment check in `validateSymlinkScope` false-rejected legitimate in-base directories whose names start with two dots — `path.relative('/base', '/base/..shared/foo')` returns `'..shared/foo'`, which is a real filename shape, not a parent-traversal escape. Switch to a segment walk: `rel.split(/[/\\]/)[0] === '..'` correctly distinguishes: - `'../foo'` → segments[0] = '..' → escapes ✓ - `'..shared/foo'` → segments[0] = '..shared' → in-scope ✓ - `'..bar'` → segments[0] = '..bar' → in-scope ✓ - `'..\\foo'` (Win) → segments[0] = '..' → escapes ✓ Tests: two new regressions in `symlinkScope.test.ts` covering the multi-segment (`..shared/foo`) and single-segment (`..bar`) cases. --------- Co-authored-by: wenshao <wenshao@U-K7F6PQY3-2157.local> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: yiliang114 <1204183885@qq.com>	2026-05-05 00:28:53 +08:00
Shaojin Wen	efb7351d58	feat(core): support reasoning effort 'max' tier (DeepSeek extension) (#3800) ... * feat(core): support reasoning effort 'max' tier (DeepSeek extension) DeepSeek's chat-completions endpoint added an extra-strong `max` tier to `reasoning_effort` (per https://api-docs.deepseek.com/zh-cn/api/create-chat-completion ; valid values are now `high` and `max`, with `low`/`medium` mapping to `high` for backward compat). Plumb it end-to-end: - `ContentGeneratorConfig.reasoning.effort` union now includes 'max'. - DeepSeek OpenAI-compat provider: translate the standard nested `reasoning: { effort }` shape into DeepSeek's flat `reasoning_effort` body parameter so user-configured effort actually takes effect (the nested shape was previously sent verbatim and silently ignored, defaulting to `high`). low/medium → high mirrors the documented server-side behavior so dashboards / logs match wire reality. An explicit top-level `reasoning_effort` (via samplingParams or extra_body) wins over the nested form. - Anthropic converter: pass 'max' through to `output_config.effort` unchanged and bump the `thinking.budget_tokens` budget for the new tier (low 16k / medium 32k / high 64k / max 128k). - Gemini converter: clamp 'max' to HIGH since Gemini has no higher thinking level. Without this, 'max' would silently fall through to THINKING_LEVEL_UNSPECIFIED. Live verification against api.deepseek.com: - `reasoning_effort: high` → 200 - `reasoning_effort: max` → 200 (the new tier) - `reasoning_effort: bogus`→ 400 with valid-set list confirming [high, low, medium, max, xhigh] 108 anthropic/openai-deepseek/gemini tests pass; full core suite (6601 tests) green; lint + typecheck clean. * fix(core): map xhigh→max + clamp max on non-DeepSeek anthropic + docs Address PR review (copilot × 2) and add missing user docs: 1. (J698) `translateReasoningEffort` claimed in the PR description that it surfaces the DeepSeek backward-compat mapping client-side, but only handled `low`/`medium` → `high`. Add `xhigh` → `max` to match the doc and stay symmetric with the low/medium branch. 2. (J6-A) `output_config.effort: 'max'` would have been emitted on any anthropic-protocol provider whenever a user configured it, even when the baseURL points at real `api.anthropic.com` (which only accepts low/medium/high and would 400). Reuse the existing `isDeepSeekAnthropicProvider` detector to clamp `'max'` → `'high'` on non-DeepSeek anthropic backends, with a debugLogger.warn so the downgrade is visible. DeepSeek anthropic-compatible endpoints still pass through unchanged. 3. New docs: - `docs/users/configuration/model-providers.md`: a "Reasoning / thinking configuration" section under generationConfig — single example targeting DeepSeek + a per-provider behavior table (OpenAI/DeepSeek flat reasoning_effort, OpenAI passthrough for other servers, real Anthropic clamp, Anthropic-compatible DeepSeek passthrough, Gemini thinkingLevel mapping). - `docs/users/configuration/settings.md`: extend the `model.generationConfig` description to mention `reasoning` (the field was undocumented before this PR even though it already existed as a typed field) and link to the new section. 96 anthropic + deepseek tests pass; lint + typecheck clean. * refactor(core): single-source effort normalization for anthropic + doc fix Address PR review round 2 (copilot × 2): 1. (J8aG) The `contentGenerator.ts` comment claimed passing `reasoning.effort: 'max'` to real Anthropic was "up to the user", but commit b5b05ae actively clamps 'max' → 'high' (with a debug log) on non-DeepSeek anthropic backends. Update the comment to describe current runtime behavior. 2. (J8aL) The clamp ran inside `buildOutputConfig()` only — the effort label was downgraded but `buildThinkingConfig()` still used the raw user value to size the budget, so a non-DeepSeek anthropic request could end up with `output_config.effort: 'high'` paired with a 'max'-sized 128K thinking budget. Inconsistent label vs. budget on the wire. Refactor: hoist the normalization into a single `resolveEffectiveEffort()` helper that runs once per request in `buildRequest()`. Both `buildThinkingConfig` and `buildOutputConfig` now consume the same clamped value, so the budget ladder and the effort label stay aligned. The debug log fires once per request. Add a regression test asserting that on a non-DeepSeek anthropic provider with `effort: 'max'` configured, the wire request carries both `output_config.effort: 'high'` AND `thinking.budget_tokens: 64_000` (the 'high' tier), not the 128K 'max' budget. 96 tests pass; lint + typecheck clean. * fix(core): tighten 'max' clamp + warn-once + strip reasoning_effort on side queries Address PR review round 3 (copilot × 3): 1. (J-2v) When request.config.thinkingConfig.includeThoughts is false, pipeline.buildRequest's post-processing only deleted the nested `reasoning` key. The DeepSeek provider's translateReasoningEffort may have already flattened an extra_body-injected reasoning into top-level `reasoning_effort` by that point, so a side query (e.g. suggestionGenerator) could still ship reasoning_effort on the wire. Extend the post-processing to also delete `reasoning_effort`. 2. (J-2z) The warn for clamping 'max' on non-DeepSeek anthropic ran on every request needing the downgrade — the docstring claimed "first time only" but the implementation didn't latch. Add a private `effortClampWarned` boolean on the generator so the warning fires once per generator lifetime. 3. (J-23) `resolveEffectiveEffort` used the broad `isDeepSeekAnthropicProvider` detector for the clamp decision, but that helper falls back to model-name matching to cover sglang/vllm self-hosted DeepSeek deployments. A model configured as e.g. "deepseek-distill" but routed to real api.anthropic.com would bypass the clamp and trigger HTTP 400. Split the detector: keep `isDeepSeekAnthropicProvider` (broad) for the thinking-block injection workaround where false-positives are harmless, and add `isDeepSeekAnthropicHostname` (hostname-only) for decisions where a model-name false-positive would route DeepSeek-only behavior to a stricter backend. The clamp now uses the hostname-only check. New regression test: a config with model name containing "deepseek" but baseURL pointing at api.anthropic.com still clamps `'max'` to `'high'`. Existing "passes max through" test updated to set a DeepSeek baseURL since model name alone no longer suffices for the clamp bypass. 385 tests pass; lint + typecheck clean. * docs(core): correct pipeline timing comment + samplingParams caveat Address PR review round 4 (copilot × 3) — three documentation accuracy fixes, no behavior change: 1. (KBcw) The post-processing comment in pipeline.ts misdescribed the call order ("after this branch already ran during the same buildRequest pass") — provider.buildRequest actually runs BEFORE the includeThoughts=false post-processing in the same pass. Reword to match the actual order: provider hook flattens nested reasoning to reasoning_effort first, this cleanup runs after and strips both shapes. 2. (KBdC, KBdE) The "Reasoning / thinking configuration" section in model-providers.md and the model.generationConfig description in settings.md both implied `reasoning` is honored on every provider. For OpenAI-compatible providers, when `generationConfig.samplingParams` is set, `ContentGenerationPipeline.buildGenerateContentConfig()` ships samplingParams verbatim and skips the separate `reasoning` injection entirely. Configs like `{ samplingParams: { temperature: 0.5 }, reasoning: { effort: 'max' } }` would silently drop the reasoning field on OpenAI/DeepSeek requests. Add an explicit "Interaction with samplingParams" warning section in model-providers.md and a parenthetical note in settings.md directing users to put `reasoning_effort` inside `samplingParams` (or `extra_body`) when both are configured. 385 tests pass; lint + typecheck clean. * docs(core): clarify explicit budget_tokens bypasses 'max' effort clamp When user sets `{ effort: 'max', budget_tokens: N }` on a non-DeepSeek anthropic backend, the effort label gets clamped to 'high' (otherwise the server 400s on the unknown enum) but the explicit budget_tokens is preserved verbatim. The wire-shape mismatch is intentional, not a bug: the clamp only protects the enum field, while budget is a free integer the server accepts within the context window, so an explicit override stays explicit. Document the contract on the early-return and add a regression test that locks it in. * docs(deepseek): fix comments to match flatten + reasoning-strip behavior Two doc-only nits called out in review: 1. `buildRequest` JSDoc said non-text parts are "rejected", but `flattenContentParts` actually substitutes a textual placeholder (`[Unsupported content type: <type>]`) so the request still goes through with a breadcrumb. Reword the JSDoc accordingly. 2. `translateReasoningEffort`'s strip comment claimed it strips the nested form to avoid shipping both shapes, but it only drops the duplicated `effort` key when other keys (e.g. `budget_tokens`) are present. Reword to describe the actual selective behavior and why keeping orthogonal keys is intentional. Behavior unchanged. * fix(deepseek): gate reasoning_effort translation on actual DeepSeek hostname The provider class is selected via the broader `isDeepSeekProvider` check, which falls back to model-name matching to cover self-hosted DeepSeek deployments (sglang/vllm/ollama, see #3613). That fallback is the right call for content-part flattening — it's a model-format constraint baked into the model itself, not the API surface. But the same broad detection was also gating `translateReasoningEffort`, which rewrites the standard `reasoning: { effort }` config into DeepSeek's flat `reasoning_effort` body parameter. That's a wire-shape decision, not a model-format one: strict OpenAI-compat backends in self-hosted setups may not accept the DeepSeek extension and would have happily handled the original shape. Split the two decisions: keep `isDeepSeekProvider` (broad) for flattening, add a hostname-only `isDeepSeekHostname` and gate the body rewrite on it. Self-hosted DeepSeek users who actually want the translation can either use a baseUrl containing api.deepseek.com or inject `reasoning_effort` directly via `samplingParams`/`extra_body`. Regression tests: - self-hosted (sglang) with deepseek-named model + nested `reasoning.effort` → flattening still runs, body shape preserved - `isDeepSeekHostname` matches api.deepseek.com but not custom hosts * fix(deepseek): use URL parsing in isDeepSeekHostname; fix log-level docs CodeQL flagged a high-severity URL substring sanitization issue on the new `isDeepSeekHostname` helper. The naive `baseUrl.includes('api.deepseek.com')` check would false-positive on hostile hosts like `https://api.deepseek.com.evil.com/v1` and incorrectly inject the DeepSeek-only `reasoning_effort` body parameter into requests routed elsewhere. Switch to `new URL(...).hostname` with exact match against `api.deepseek.com` (and `.api.deepseek.com` subdomains), mirroring `isDeepSeekAnthropicHostname` on the Anthropic side. Invalid URLs treated as non-DeepSeek. `isDeepSeekProvider` already routes through `isDeepSeekHostname`, so the hardening applies to both decision paths. Regression tests cover: - subdomain match (us.api.deepseek.com) - hostile substrings (api.deepseek.com.evil.com, evil.com/api.deepseek.com/v1, api.deepseek.comevil.com, api-deepseek-com.example.com) - invalid / empty baseUrl Also fix two doc-level mismatches: the `'max'` clamp on Anthropic logs via `debugLogger.warn` (warning level, once per generator), not "with a debug log". Update both `ContentGeneratorConfig.reasoning` JSDoc and the per-provider behavior table in model-providers.md. * feat(deepseek): emit thinking:disabled signal when reasoning is off DeepSeek V4+ defaults `thinking.type` to `'enabled'`, so just stripping `reasoning_effort` from the request leaves the server happily thinking on side queries — paying full thinking latency/cost without an effort configured. Per yiliang114's review, emit the explicit `thinking: { type: 'disabled' }` field on the wire whenever reasoning is disabled. Triggered when either: - `request.config.thinkingConfig.includeThoughts === false` (forked queries, e.g. suggestion generation) - `contentGeneratorConfig.reasoning === false` (config-level opt-out) The previous post-processing block only fired on the per-request opt-out path, so the config-level case was already leaking. Unify both under a single `reasoningDisabled` predicate that runs the same strip + signal logic. Hostname-gated to `api.deepseek.com` (and subdomains): self-hosted DeepSeek behind sglang/vllm/ollama, or older DeepSeek versions, may not accept the V4 thinking parameter — pushing it there could trip an unknown-key 400. Mirrors the round-7 decision to gate `reasoning_effort` translation on hostname. Regression tests cover all four matrix points: - DeepSeek hostname + includeThoughts false → emits disabled - DeepSeek hostname + reasoning false → emits disabled - non-DeepSeek hostname + includeThoughts false → does not emit - self-hosted DeepSeek (model-name fallback only) → does not emit Docs: extend the `reasoning: false` section with the new behavior and the self-hosted/non-DeepSeek caveat. * refactor(deepseek): expose isDeepSeek* as free functions; clarify docs Two doc/coupling nits from review: 1. The pipeline post-processing block was importing the concrete `DeepSeekOpenAICompatibleProvider` class just to reach `isDeepSeekHostname`. That couples the generic OpenAI pipeline to a specific provider implementation. Promote the helper (and its broad `isDeepSeekProvider` sibling) to free `export function`s in `provider/deepseek.ts` and import them by name. The class keeps thin static delegates for backward compat with existing callers and tests. 2. The per-provider behavior table on `model-providers.md` said `'low'/'medium' → 'high'` and `'xhigh' → 'max'` "client-side", but that normalization only fires inside `translateReasoningEffort`, which runs on the nested `reasoning.effort` config path. Explicit top-level overrides via `samplingParams.reasoning_effort` or `extra_body.reasoning_effort` skip the rewrite and ship verbatim. Reword the row to reflect that. Behavior unchanged.	2026-05-04 22:42:23 +08:00
Shaojin Wen	35fe97e0f6	feat(review): expand review pipeline + qwen review CLI subcommands (#3754) ... * feat(review): expand review pipeline + add `qwen review` CLI subcommands Review skill (SKILL.md) changes: - Step 4: 5 → 9 parallel agents (split Correctness/Security, add Test Coverage, 3 undirected personas: attacker / 3am-oncall / maintainer) - Step 5: verification "uncertain → reject" → "uncertain → low-confidence" (terminal-only "Needs Human Review" bucket; never posted as PR comments) - Step 6: single reverse audit → iterative (terminate on no-new-findings, hard cap 3 rounds) - Step 9: self-PR detection (downgrade APPROVE/REQUEST_CHANGES → COMMENT when GitHub forbids self-review with HTTP 422); CI status check (downgrade APPROVE → COMMENT on red/pending CI); existing-Qwen-comment classification with priority order Stale > Resolved > Overlap > NoConflict (only Overlap blocks for confirmation) `qwen review` CLI subcommands (packages/cli/src/commands/review/): - fetch-pr — clean stale + fetch PR ref + create worktree + metadata - pr-context — emit Markdown context file with security preamble + already-discussed dedup section - load-rules — read review rules from base branch (4 source files) - deterministic— run tsc, eslint, ruff, cargo-clippy, go-vet, golangci-lint on changed files; filtered + structured findings JSON (TypeScript/JavaScript, Python, Rust, Go) - presubmit — self-PR + CI status + existing-comment classification in a single JSON report - cleanup — worktree + branch ref + per-target temp files (idempotent) Cross-platform: execFileSync (no shell), path.join, CRLF normalization, which/where for tool detection. Replaces bash-style inline commands in SKILL.md; works identically on macOS/Linux/Windows. Path consistency: SKILL.md temp files moved from /tmp/qwen-review-* to .qwen/tmp/qwen-review-* — matches what os.tmpdir() resolves to across platforms (macOS returns /var/folders/... not /tmp). DESIGN.md gains five "Why ..." sections explaining each design decision; docs/users/features/code-review.md synced for user-visible changes. * feat(review): expose full reply chains in pr-context output `qwen review pr-context` now renders each replied-to inline-comment thread as the original reviewer comment + chronological reply chain, instead of only listing the root-comment snippet. This lets review agents see at a glance whether a topic has been addressed (e.g. a "Fixed in <commit>" reply closes the thread) and avoids re-reporting already-resolved concerns without forcing the LLM driver to manually summarise each reply chain in agent prompts. - Walk `in_reply_to_id` chain to group replies under their root comment - Sort replies chronologically (by id, monotonic on GitHub) - Render thread block: root snippet as a quote + bulleted reply list - Sort threads by `(path, line)` for deterministic output - SKILL.md note updated to point agents at the new chain format * feat(review): include review-level summaries in pr-context output `qwen review pr-context` now also fetches `gh api repos/{owner}/{repo}/pulls/{n}/reviews` and renders a "Review summaries" section listing each reviewer's overall body (the comment they typed alongside an APPROVED / CHANGES_REQUESTED / COMMENTED submission). Closes a real gap found during the PR #3684 review: > "@wenshao [CHANGES_REQUESTED]: The previously identified exported > type rename issue no longer maps to the current PR diff, so this > review only includes the remaining high-confidence blocker." Without this section, the LLM driver's review agents would have missed that integration note from the prior reviewer. - New `RawReview` type + extra `ghApi` call - Filter: skip empty bodies + the canonical "No issues found. LGTM!" template the qwen-review pipeline auto-emits — those carry no agent-actionable content beyond the review state itself - Sort meaningful reviews by `submitted_at` for chronological output - Stdout summary now reports `M/N review summaries` (M = kept after filter) Smoke-tested on PR #3684: 30 inline, 3 issue, 1/30 review summaries correctly surfaces the @wenshao CHANGES_REQUESTED body and filters the 29 LGTM templates. * fix(review): paginate gh API calls to capture comments past page 1 `gh api <path>` defaults to per_page=30. Busy PRs cross that limit on inline comments, issue comments, and reviews — the latest entries (the ones most likely to contain new reviewer feedback or in-flight reply chains) end up on page 2+ and were silently truncated. Concrete bug found while re-reviewing PR #3684: Before: `30 inline, 3 issue comments, 1/30 review summaries` After: `97 inline, 3 issue comments, 6/67 review summaries` 5 additional reviewer-level summaries surfaced — including the @wenshao 2026-04-30 "Multi-agent re-review (Phase C)" body with the explicit verification notes that this PR's pipeline is supposed to chain forward into the next review. Changes: - `lib/gh.ts`: new `ghApiAll(path)` helper using `gh api --paginate`, which walks every `next` link and concatenates each page's array. - `pr-context.ts`: 3 fetches (inline / issue / reviews) → `ghApiAll`. - `presubmit.ts`: PR comments fetch → `ghApiAll` too (existing-comment classification was equally susceptible to dropping page 2+ overlap candidates). `check-runs` and `commits/<sha>/status` calls retain `ghApi` — those return objects (with embedded arrays) and rarely cross 30 entries. --------- Co-authored-by: wenshao <wenshao@U-K7F6PQY3-2157.local>	2026-05-01 18:30:35 +08:00
Rayan Salhab	0b7a569ac7	fix(cli): honor proxy setting (#3753) ... * fix(cli): honor proxy setting * fix(cli): apply settings proxy to channel start * test(cli): cover channel start settings proxy --------- Co-authored-by: cyphercodes <cyphercodes@users.noreply.github.com>	2026-04-30 18:24:59 +08:00
易良	49e462c021	fix(lsp): 修复 LSP 文档、isPathSafe 限制，并提升 LSP 工具调用率 (#3615) ... * fix(docs): correct outdated and inaccurate LSP documentation - Remove reference to non-existent `packages/cli/LSP_DEBUGGING_GUIDE.md` - Remove reference to unimplemented `/lsp status` slash command - Replace incorrect `DEBUG=lsp*` env var with actual debug log location (`~/.qwen/debug/` session files with `[LSP]` tag) - Remove external Claude Code documentation links (`code.claude.com`) - Document `isPathSafe` constraint: absolute paths outside workspace are blocked, users must add server binary directory to PATH - Add practical troubleshooting: `ps aux | grep <server>` to check if the server process is actually running - Add clangd-specific guidance: `--background-index`, `compile_commands.json` location, and `--compile-commands-dir` usage - Simplify trust documentation (remove vague "configure in settings") * fix(lsp): allow absolute paths in LSP server command configuration Previously, `isPathSafe` rejected any command containing a path separator that resolved outside the workspace directory. This blocked legitimate use cases where users specify absolute paths to language server binaries (e.g. `/usr/bin/clangd`, `/opt/tools/jdtls/bin/jdtls`). The fix allows: - Bare command names resolved via PATH (unchanged) - Absolute paths (explicit user intent, already gated by trust checks) - Relative paths within the workspace (unchanged) Only relative paths that traverse outside the workspace (e.g. `../../malicious-binary`) are still blocked. Closes: server silently fails to start when users configure absolute paths in `.lsp.json`, with only a debug log warning visible. * feat(lsp): inject LSP priority instruction into system prompt when enabled The model was not using the LSP tool because the system prompt's "Tool Usage" section never mentioned it. The tool description alone ("ALWAYS use LSP as the PRIMARY tool") was insufficient — models follow system prompt instructions more reliably than tool descriptions. Changes: - getCoreSystemPrompt() accepts `options.lspEnabled` parameter - When LSP is enabled, injects an instruction in the Tool Usage section telling the model to ALWAYS use the LSP tool FIRST for code intelligence queries (definitions, references, hover, symbols, etc.) instead of falling back to grep/readfile - Updated client.ts to pass config.isLspEnabled() to the prompt builder - Updated test mocks and snapshots * feat(lsp): add symbolName parameter for position-free LSP queries The model avoided calling LSP for findReferences, hover, etc. because these operations required filePath + line + character which the user rarely provides. The model would read files directly instead. Changes: - Add `symbolName` optional parameter to LspTool - When symbolName is provided without line/character, auto-resolve the symbol's position via workspaceSymbol before executing the actual operation (findReferences, hover, goToImplementation, etc.) - Update tool description with examples showing symbolName usage - Move LSP priority instruction to top of system prompt for visibility - Add debug logging for LSP prompt injection This enables natural queries like: {operation: "findReferences", symbolName: "Calculator"} {operation: "hover", symbolName: "addShape"} without requiring the user to know exact file positions. * feat(lsp): add LSP reminder to grep/readfile tool descriptions When LSP is enabled, the model often chose grep or readfile instead of LSP for code intelligence queries. Now the competing tools' descriptions include a note reminding the model to use the LSP tool for definitions, references, symbols, hover, diagnostics, etc. This "push-pull" approach: - System prompt pushes toward LSP (top-level priority instruction) - Grep/ReadFile descriptions pull away from code intelligence usage * fix(docs): align LSP doc with isPathSafe change — absolute paths now supported The doc still said "absolute paths outside the workspace are not supported" but the code was changed to allow them. Updated all three places (Required Fields table, Troubleshooting, Debugging) to reflect that absolute paths are now accepted. * fix(lsp): improve symbol-based tool resolution * fix(lsp): normalize display paths across platforms * fix(lsp): narrow docs and path safety changes * fix(lsp): add edge-case tests for isPathSafe and fix Chinese comment - Add test for intermediate path traversal (./a/../../../etc/passwd) - Add test for forward-slash relative paths (tools/clangd) - Replace Chinese JSDoc with English on requestUserConsent * fix(lsp): rename requestUserConsent to checkWorkspaceTrust The method only checks workspace trust level and does not actually prompt the user for consent. Rename the method and update the JSDoc and call-site log message to accurately reflect the behavior.	2026-04-30 15:24:18 +08:00
Bramha.dev	414b3304cd	fix(core): split tool-result media into follow-up user message for strict OpenAI compat (#3617) ... Fixes #3616. Adds opt-in `splitToolMedia` flag (default false). When enabled, media parts (image / audio / video / file) returned by MCP tool calls are split into a follow-up `role: "user"` message instead of being embedded in the `role: "tool"` message. Required for strict OpenAI-compatible servers (e.g., LM Studio) that reject non-text content on tool messages with HTTP 400 "Invalid 'messages' in payload". Media from parallel tool responses is accumulated and emitted as a single follow-up user message after all tool messages, preserving OpenAI's contiguity requirement for tool responses. Default behavior is unchanged for permissive providers.	2026-04-27 23:01:02 +08:00
jinye	f0e8601982	fix(cli): add API Key option to qwen auth interactive menu (#3624) ... * fix(cli): add "API Key" option to `qwen auth` interactive menu The `qwen auth` CLI command only showed 2 options (Coding Plan, Qwen OAuth), while the interactive `/auth` dialog showed 3 (Coding Plan, API Key, Qwen OAuth). Users following the README instructions to configure OpenRouter/Fireworks via `qwen auth` had no API Key entry point. - Add "API Key" option to the `runInteractiveAuth` menu with two sub-paths: "Alibaba Cloud ModelStudio Standard API Key" (guided flow) and "Custom API Key" (prints docs link) - Add `qwen auth api-key` yargs subcommand for direct access - Extract `createMinimalArgv` / `loadAuthConfig` helpers to eliminate duplicated CliArgs boilerplate - Extract `promptForInput` to share raw-mode stdin logic between `promptForKey` and `promptForModelIds` - Improve `showAuthStatus` to distinguish Coding Plan, Standard API Key, and generic OpenAI-compatible configurations - Align menu labels and descriptions with the interactive `/auth` dialog Closes #3413 Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * docs: add `qwen auth api-key` to auth subcommand tables Update documentation to reflect the new `qwen auth api-key` subcommand: - auth.md: add to subcommands table, examples, and interactive menu display - commands.md: add to CLI Auth Subcommands table - quickstart.md: add to quick-reference command table * fix(cli): restore incomplete Coding Plan warning in showAuthStatus When selectedType is USE_OPENAI and Coding Plan metadata exists but the API key is missing, show the incomplete warning instead of falling through to the generic "OpenAI-compatible" status. * refactor(cli): use endpoint constants in region selector and fix status formatting - Use ALIBABA_STANDARD_API_KEY_ENDPOINTS constants for region descriptions instead of hardcoded URLs - Restore trailing newline in showAuthStatus "no auth" command list for consistent spacing * fix(cli): determine active auth method from model config in showAuthStatus Previously showAuthStatus checked which env keys exist to determine the auth method, causing false reports when users switch providers (e.g., Coding Plan key still present after switching to Standard API Key). Now it inspects the active model's provider config (baseUrl/envKey) to determine the actual method, and validates the corresponding key exists: - Coding Plan: check via isCodingPlanConfig + CODING_PLAN_ENV_KEY - Standard API Key: check via DASHSCOPE_STANDARD_API_KEY_ENV_KEY + endpoints - Generic OpenAI-compatible: check if the model's envKey is set Also clear stale Coding Plan metadata (codingPlan.region/version and process.env) when switching to Standard API Key. * fix(cli): add legacy fallback in showAuthStatus and clear persisted Coding Plan env - When no active model config is found (legacy setups without modelProviders), fall back to env key / metadata checks for Coding Plan status detection. Fixes CI test failures. - When activeConfig exists but has no envKey, report incomplete status instead of false positive "Configured". - Clear persisted env.BAILIAN_CODING_PLAN_API_KEY from settings when switching to Standard API Key, not just process.env. * fix(cli): also remove Coding Plan model entries when switching to Standard API Key When switching to Standard API Key, filter out existing Coding Plan model entries from modelProviders.openai in addition to old Standard entries. Previously these were preserved but their credential source (BAILIAN_CODING_PLAN_API_KEY) was cleared, leaving broken model entries visible in /model. --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-04-27 22:01:47 +08:00
Shaojin Wen	f420742831	feat(cli,core): LLM-generated summary labels for tool-call batches (#3538) ... * feat(cli,core): generate tool-use summaries for compact mode After each tool batch completes, fire a parallel fast-model call to generate a short git-commit-subject-style label summarizing what the batch accomplished (e.g. "Read txt files", "Searched in auth/"). In compact mode the label replaces the generic "Tool × N" header so N parallel tool calls collapse to a single semantic row. The fast-model call (~1s) runs fire-and-forget, overlapped with the next turn's API stream, so there is no perceived latency. Missing fast model, aborted turns, and model failures all degrade silently to the existing rendering. The summary is also emitted as a `tool_use_summary` history entry with `precedingToolUseIds`, keeping the shape compatible with SDK clients that want to render collapsed tool views on their own. Gated by `experimental.emitToolUseSummaries` (default on). Can be overridden per-session with `QWEN_CODE_EMIT_TOOL_USE_SUMMARIES=0|1`. The system prompt and truncation rules (300 chars per tool field, 200 chars of trailing assistant text as intent prefix) match the existing behavior seen in other tools that emit the same message type, so SDK consumers see a consistent shape across clients. * fix(core): bound cleanSummary quote-strip regex to avoid ReDoS CodeQL js/polynomial-redos flagged the /^["'`]+|["'`]+$/g pattern in cleanSummary because its input comes from an LLM (treated as uncontrolled). The original regex is anchored and linear in practice, but tightening the quantifier to {1,10} both satisfies the static check and caps engine work on pathological model output with a long run of quotes. Ten opening/closing quotes is well past anything a real label would produce. * fix(cli): render tool_use_summary inline so full mode also shows the label The summary was only visible in compact mode because the full-mode ToolGroupMessage ignored the compactLabel prop. Compact mode got away with this because mergeCompactToolGroups triggers refreshStatic(), which re-renders the merged tool_group with its newly-looked-up label. Full mode has no such refresh path, so when the fast-model call resolves *after* the tool_group has been committed to the append-only <Static>, there is no way to retroactively decorate it. Switch to rendering `tool_use_summary` as its own inline history item (a single dim `● <label>` line). New items append cleanly to <Static>, so the summary flows in naturally once the fast-model call resolves. Compact mode still replaces the merged tool_group header with the label and hides the standalone summary line via the `compactMode` guard. With this, the feature works under the default `ui.compactMode: false` — not just the opt-in compact view. * docs: tool-use-summaries feature guide, settings entry, and design doc Three new docs matching the existing fast-model feature docs layout: - docs/users/features/tool-use-summaries.md — user-facing guide covering full + compact rendering, configuration (settings + env), failure modes, cost, and cross-links to followup-suggestions. - docs/users/configuration/settings.md — register the new experimental.emitToolUseSummaries setting next to the other fast-model-driven UI settings. - docs/design/tool-use-summary/tool-use-summary-design.md — deep dive matching the compact-mode-design.md competitive-analysis style. Documents the Claude Code port (prompt, truncation, timing, gate), the deviations (settings layer, default on, cleanSummary, dual render paths), and the Ink <Static> append-only rationale that drove the inline full-mode render vs header-replacement split. * docs: add Recommended pairing section to tool-use-summaries Full-mode rendering of the summary works, but for small same-type batches (Read × 3 and similar) the label visibly restates what the tool lines already show. Pairing with ui.compactMode: true folds the whole batch into a single labeled row, which is the cleanest transcript shape once the label is available. Adds a dedicated section showing the paired settings.json snippet and explicitly calling out when each mode wins (and when to turn the feature off instead). * fix: address review feedback on tool-use summary generation Addresses multiple issues from @chiga0's review: Blocking — compact-mode label invisible for single-batch turns. mergeCompactToolGroups's adjacency-only gating left a trailing tool_use_summary in the merged result whenever there was no second batch to merge across. That pushed mergedHistory.length lock-step with history.length and MainContent's refreshStatic heuristic (currMLen <= prevMLen) never fired, so Ink's append-only <Static> never repainted the tool_group with its newly-looked-up label. Drop tool_use_summary items unconditionally now; gemini_thought still survives to avoid unnecessary repaints. New tests cover the single-batch case and the summary-before-user-message case. Blocking — stale summary appears after Ctrl+C on the next turn. summarySignal captured the CURRENT turn's AbortController, but the summary resolves during the NEXT turn's streaming window. The next turn's submitQuery allocates a fresh controller, so the captured signal was never aborted — Ctrl+C during the new turn used to let the previous turn's summary land in the transcript seconds later. Fix: dedicated per-batch AbortController tracked in a ref set, aborted eagerly from cancelOngoingRequest; resolve-time check reads the live abort state and turnCancelledRef. High — summarizer input pollution. geminiTools contained error/cancelled tools; retry-loop warnings and "Cancelled by user" strings were feeding the fast model. cleanSummary can only reject error-shaped output, not prevent the model from hallucinating a plausible label from bad input (the PR's own tmux screenshot showed "Read txt files · 5 tools" where 4 of the 5 were prior-retry failures). Filter to status === 'success' before building the prompt; skip the call entirely if nothing's left. High — unstable label on merged groups. getCompactLabel iterated all callIds and returned the first hit, so asynchronous resolution order made the header visibly flip from SB to SA when batch A resolved after batch B. Lock onto item.tools[0].callId to keep stable "leading batch governs" semantics. High — force-expanded groups in compact mode had no label at all. Compact mode routes non-force-expand groups through CompactToolGroupDisplay (consumes compactLabel) and force-expand groups through the full ToolGroupMessage (ignores compactLabel); the standalone ● line was gated on !compactMode, creating a dead zone — exactly the diagnostically valuable case. MainContent now computes absorbedCallIds (which groups actually consume the header replacement) and passes summaryAbsorbed to HistoryItemDisplay; force-expand groups in compact mode get the standalone line as the label's only path to the screen. Medium — cleanSummary robustness. Extend quote-strip to Unicode curly + CJK corner brackets; strip markdown emphasis (**bold**, _italic_); broaden refusal-prefix rejection to curly-apostrophe "I can't", Chinese "我无法 / 我不能 / 抱歉 / 无法", and "Failed to / Sorry, / Request failed". 7 new cleanSummary tests cover the added cases. Low — concurrent-rendering safety. Move historyRef.current = history from render phase into useLayoutEffect so bailed renders can't leave a dropped value. Low — CompactToolGroupDisplay readability. Extract renderSummaryHeader / renderDefaultHeader helpers and document the toolCalls.length > 1 count-suffix guard so a future "fix" to >= 1 doesn't reintroduce "Read config.json · 1 tools". Docs — add Scope & Lifecycle section to tool-use-summaries.md covering (1) one generation per batch shared by both modes, (2) no backfill on toggle / session resume, (3) main-agent batches only with the Task-tool clarification. * fix: address second-round review feedback on tool-use summaries Critical — force-expand groups lost their summary entirely. Previous round's "drop tool_use_summary unconditionally" merge fix also stripped summaries for force-expanded groups, defeating the exact case (errors, confirmations, focused shell) where the standalone ● label is the label's only path to the screen. The merge function now takes an absorbedCallIds set: summaries whose preceding callIds are all absorbed by a compact tool_group header are dropped (so refreshStatic still fires), but force-expanded summaries pass through to be rendered standalone by HistoryItemDisplay. MainContent computes absorbedCallIds from raw history and passes it in. New tests cover both the absorbed-drop and the force-expand-preserve cases plus the empty-set default for callers that don't compute absorption. Suggestion — late-arriving summaries could land out of order. A slow fast-model call could resolve after the next turn's content was committed, planting the ● label between later items in full mode. The resolve callback now captures the first batch callId, locates the corresponding tool_group at resolve time, and drops the summary if a newer tool_group has already appeared in history. New test exercises this with a manually-resolved fast-model promise. Suggestion — truncateJson allocated full JSON for large strings. A 10MB ReadFile result was being JSON.stringify'd in full only to be sliced down to 300 chars. Added preTruncate that walks the value (depth-bounded to 4) and slices string leaves to maxLength before serialization. Tests verify the input never reaches its full pre-cap form. Suggestion — settings description over-claimed SDK emission. The description said summaries are emitted to SDK clients as a tool_use_summary message; the SDK plumbing isn't actually wired in this PR (the factory is exported for follow-up). Updated settings.json description and regenerated the vscode schema to state CLI-only scope explicitly. Suggestion — fastModel data-boundary not documented. When fastModel uses a different provider than the main session model, tool inputs/outputs cross a new auth boundary that users may not expect. Added "Data flow & privacy" section to the user feature doc spelling out: same-provider fast model = no scope change; different-provider = strictly larger sharing scope; two escape hatches (same-provider fast model OR feature off). Code-level mitigation (metadata-only mode) deferred.	2026-04-27 16:54:10 +08:00
Fu Yuchen	93cbad24b1	fix(core): preserve reasoning_content during session resume and active sessions (GH#3579) (#3590) ... * fix(core): preserve reasoning_content during session resume and active sessions (GH#3579) * chore(core): remove dead thinkingThresholdMinutes config after latch removal (GH#3579)	2026-04-24 17:49:05 +08:00
顾盼	aeeb2976d6	feat(web-search): remove built-in web_search tool, replace with MCP-based approach (#3502) ... * feat(web-search): add GLM (ZhipuAI) web search provider - Add GlmProvider class implementing BaseWebSearchProvider using the ZhipuAI Web Search API (https://open.bigmodel.cn/api/paas/v4/web_search) - Support multiple search engines: search_std, search_pro, search_pro_sogou, search_pro_quark - Support optional config: maxResults, searchIntent, searchRecencyFilter, contentSize, searchDomainFilter - Truncate query to 70 characters per API limit - Register 'glm' in the provider discriminated union (types.ts) and createProvider() switch (index.ts) - Add GlmProviderConfig to settingsSchema, ConfigParams, and Config class - Add --glm-api-key CLI flag and GLM_API_KEY env var support in webSearch.ts - Forward GLM_API_KEY in sandbox environment - Update provider priority list: Tavily > Google > GLM > DashScope - Add 17 unit tests for GlmProvider and 4 integration tests in index.test.ts - Update docs/developers/tools/web-search.md with GLM configuration, env vars, CLI args, pricing, and corrected DashScope billing info - Fix stale OAuth/free-tier references in web-search.md Closes #3496 * docs(web-search): fix DashScope note and add GLM server-side limitations * fix(web-search): make DashScope provider work with standard API key, remove qwen-oauth dependency - DashScopeProvider.isAvailable() now checks config.apiKey instead of authType - Remove OAuth credential file reading and resource_url requirement - Use standard DashScope endpoint: dashscope.aliyuncs.com/api/v1/indices/plugin/web_search - Read DASHSCOPE_API_KEY env var and --dashscope-api-key CLI flag - Forward DASHSCOPE_API_KEY into sandbox environment - Update integration test to detect DASHSCOPE_API_KEY - Update docs to reflect new API key based configuration * feat(web-search): remove built-in web search tool The web_search tool and all related provider implementations are removed. Web search functionality will be provided via MCP integrations instead, which is the direction the broader agent ecosystem is moving. Removed: - packages/core/src/tools/web-search/ (entire directory) - packages/cli/src/config/webSearch.ts - integration-tests/cli/web_search.test.ts - ToolNames.WEB_SEARCH, ToolErrorCode.WEB_SEARCH_FAILED - webSearch config in ConfigParams, Config class, settingsSchema - CLI options: --tavily-api-key, --google-api-key, --google-search-engine-id, --glm-api-key, --dashscope-api-key, --web-search-default - Sandbox env forwarding for TAVILY/GLM/DASHSCOPE/GOOGLE search keys - web_search from rule-parser, permission-manager, speculation gate, microcompact tool set, and builtin-agents tool list * fix: remove websearch reference * docs: remove websearch tool * docs: add break change guide * fix review	2026-04-24 11:29:02 +08:00
Shaojin Wen	d71f2fab70	feat(cli): cap inline shell output with configurable line limit (#3508) ... * feat(cli): cap inline shell output with configurable line limit Long-running shell commands (npm install, find /, build logs) currently fill the viewport with the full visible PTY buffer (up to availableHeight, ~24 lines on a typical terminal). The output dominates the screen and pushes prior context off the top. This caps inline ANSI shell output to a small window (default 5 lines, matching Claude Code's ShellProgressMessage). The hidden line count is already surfaced via the existing `+N lines` indicator in `ShellStatsBar`, so users still know how much was elided. The cap applies only when nothing in the existing escape-hatch set is true: - `forceShowResult` (errors, !-prefix user-initiated commands, tools awaiting confirmation, agents pending confirmation) - `isThisShellFocused` (ctrl+f focus on a running embedded PTY shell) - `ui.shellOutputMaxLines = 0` (user opt-out) Also adds a new `ui.shellOutputMaxLines` setting (default 5) so users can adjust or disable the cap. The SettingsDialog renders it automatically via the existing `type: 'number'` schema path. Notes on scope: - Only the `'ansi'` display branch is capped. `'string'`, `'diff'`, `'todo'`, `'plan'`, `'task'` renderers are untouched. - `AnsiOutputDisplay` is only produced by shell tools (`shell.ts`, `shellCommandProcessor.ts`), so other tool outputs are unaffected. - The `+N lines` count is bounded by the headless xterm buffer height (~30 rows) — a pre-existing limitation of the buffer-based stats, not introduced here. Tests: - 4 new ToolMessage tests cover cap default, forceShowResult bypass, settings disable (cap=0), and custom cap value. - The existing `MockAnsiOutputText` / `MockShellStatsBar` mocks were extended to print `availableTerminalHeight` / `displayHeight` so the cap behavior is asserted at the prop level. * fix(cli): apply shell output cap to completed string display too Initial PR caught only the streaming ANSI branch. AI shell tools emit the final completed result through `shell.ts:returnDisplayMessage = result.output`, which is a plain string. That string went through `StringResultRenderer` with the unmodified `availableHeight`, so the cap was effectively bypassed for the steady-state display the user actually sees most of the time. Verified manually in tmux: a `seq 1 30` invocation by the AI now collapses to "first 26 lines hidden ... 27 28 29 30" instead of listing all 30 rows. `!`-prefix `seq 1 30` still expands fully via the existing `isUserInitiated → forceShowResult` bypass. Changes: - Detect shell tool by name (matches existing `SHELL_COMMAND_NAME` / `SHELL_NAME` checks already used in this file) - Rename `ansiAvailableHeight` → `shellCapHeight` since it now governs the string branch as well - Pass `shellCapHeight` to `StringResultRenderer`; the value falls back to `availableHeight` for non-shell tools so other tools' string output is unaffected - Two new tests: shell completed string is capped; non-shell string is not - Two existing tests updated to use `name="Shell"` so they actually exercise the cap path (would previously have passed by accident since the original code didn't check tool name) Also picks up the auto-regenerated VSCode IDE companion settings schema entry for `ui.shellOutputMaxLines`. * fix(cli): symmetrize ANSI/string row counts and clamp shell cap input Addresses two non-blocking review observations on #3508. Off-by-one between paths: MaxSizedBox reserves one row for its overflow banner when content exceeds maxHeight (visibleContentHeight = max - 1). The ANSI path pre-slices to N in AnsiOutputText so MaxSizedBox sees exactly N rows and renders all N — plus the separate ShellStatsBar line. The string path passes the raw cap and lets MaxSizedBox handle overflow, so it shows N-1 content rows + the banner. Result with cap=5: ANSI showed 5+stats, string showed 4+banner. Pass shellCapHeight + 1 to StringResultRenderer when capping so both paths render N visible content rows. Verified in tmux: the completed Shell tool box now reports `... first 25 lines hidden ...` followed by lines 26-30 (was 26 + lines 27-30). Setting validation: Schema accepts any number; the dialog only rejects NaN. Negatives silently disabled the cap (only 0 is documented as off) and fractional values produced fractional slice counts. Added Math.max(0, Math.floor(value || 0)) at the use site so: - negatives → 0 → cap disabled (matches the documented opt-out) - fractions → floor → whole-row cap - non-numeric (raw settings.json edits) → 0 → cap disabled Schema-level minimum/integer constraints aren't supported by the current settings infrastructure (no other number setting uses them either), so the guard lives at the use site. Tests: - Updated string-cap test to assert lines 26-30 visible (catches the +1 fix; was lines 27-30 before) - New parameterized test covers -1, 1.5, and a non-numeric value	2026-04-22 14:37:13 +08:00
Reid	d1c8dff4d2	feat(arena): add comparison summary for agent results (#3394) ... Adds a summary view that runs after Arena agents finish, so users can compare model outputs without opening each agent's conversation first. Summary surface: - Agent status overview - Files changed in common vs. unique to one agent - Per-agent approach summary generated through that agent's own provider - Token / runtime / line-change / file-count metrics Selection dialog now supports: - p — toggle preview for the highlighted agent - d — toggle detailed diff - Enter — select winner - x — discard all results - Esc — cancel Approach summary generation: - Each agent's summary is generated through that agent's own content generator, keeping mixed-provider Arena sessions within their respective auth boundaries - 20s timeout + AbortController per agent, bounded prompt inputs (finalText 2K, transcript 6K, diff 6K) - Falls back to a deterministic "Changed N files ..." summary when no per-agent generator is available or on error Diff summary now handles binary, rename-only, and mode-only diffs; the previous heuristic required textual +/- hunks and would have dropped those. Resolves #2559	2026-04-22 05:31:19 +08:00
zhangxy-zju	ebe364d0b8	feat(retry): add persistent retry mode for unattended CI/CD environments (#3080) ... * feat(retry): add persistent retry mode for unattended CI/CD environments When running in CI/CD pipelines or background daemon mode, transient API capacity errors (429/529) should not terminate long-running tasks after a fixed number of retries. This adds an environment-aware persistent retry mode that retries indefinitely for transient errors, with exponential backoff capped at 5 minutes and heartbeat keepalives every 30 seconds to prevent CI runner timeouts. * docs: add persistent retry mode documentation Add environment variable entries (QWEN_CODE_UNATTENDED_RETRY, QWEN_CODE_BG) to the settings reference, and a new "Persistent Retry Mode" section to the headless mode docs covering activation, behavior, and CI/CD usage examples. * refactor(retry): simplify to single explicit env var QWEN_CODE_UNATTENDED_RETRY Remove QWEN_CODE_BG and CI=true as activation triggers for persistent retry. Having multiple env vars with identical behavior adds confusion, and silently activating infinite retry on CI=true is dangerous — a regular CI test hitting a 429 would hang forever instead of failing fast. * fix(retry): address PR review feedback - Forward caller's abortSignal into retryWithBackoff in both baseLlmClient.ts and geminiChat.ts so persistent waits remain cancellable (wenshao) - Re-apply maxBackoff and capMs after jitter so delays strictly respect stated caps (Copilot) - Respect shouldRetryOnError in persistent mode so callers can force fast-fail even for transient 429/529 errors (Copilot) - Guard sleepWithHeartbeat against infinite loop when heartbeat interval is <= 0 via Math.max(1, ...) (Copilot) - Normalize isEnvTruthy with trim/toLowerCase for robust env var parsing across CI conventions (Copilot) * test(retry): add missing UT for shouldRetryOnError override and heartbeat zero-interval guard * fix(retry): do not cap Retry-After delays at maxBackoff Server-specified Retry-After values should only be limited by the absolute cap (capMs/6h), not the exponential backoff cap (maxBackoff/5min). Jitter is also skipped for Retry-After since the server already specified the exact wait time. * refactor(retry): align isUnattendedMode with project env parsing convention Replace custom isEnvTruthy (trim + toLowerCase) with strict matching (val === 'true' || val === '1') to match parseBooleanEnvFlag used elsewhere in the codebase. Prevents inconsistent behavior where 'TRUE' or ' 1 ' would activate persistent retry here but not in telemetry or other env-driven features. * test(retry): add Retry-After handling tests for persistent mode Cover three key behaviors: - Retry-After is NOT capped at maxBackoff (only at capMs) - Retry-After IS capped at persistentCapMs absolute limit - Retry-After delays have no jitter applied * fix(test): add isUnattendedMode to retry.js mock in baseLlmClient tests The existing vi.mock for retry.js only exported retryWithBackoff. After adding isUnattendedMode to the retry module, baseLlmClient.ts imports it, causing all 10 generateJson tests to fail with 'No "isUnattendedMode" export is defined on the mock'. * fix(retry): wire persistent retry mode into client.ts generateContent Forward persistentMode and abortSignal to retryWithBackoff() in GeminiClient.generateContent(), matching the existing wiring in baseLlmClient.ts and geminiChat.ts.	2026-04-21 22:08:11 +08:00
Shaojin Wen	afbb5e71db	fix(cli): rework session recap rendering and add blur threshold setting (#3482) ... * feat(cli): make recap away-threshold configurable The 5-minute blur threshold was hard-coded. Confirmed from Claude Code's own binary (v2.1.113) that 5 minutes is their default as well (and that they shift to 60 minutes when 1h prompt-cache is active) — so the default stays, but expose it as `general.sessionRecapAway ThresholdMinutes` for users who briefly alt-tab often and don't want recaps piling up, or who want to lower it for testing. Non-positive / unset values fall back to the 5-minute default, so dropping the key has the same behavior as before. * fix(core): align recap prompt with Claude Code (1-2 sentences, ≤40 words) The earlier "exactly one sentence, 80-char cap" was an over-correction to a single in-the-moment ask. Going back to it: the natural shape of "current task + next action" is two clauses, and forcing them into a single sentence either crams them with a semicolon or drops the next action entirely on complex sessions. Adopt Claude Code's prompt verbatim (extracted from the v2.1.113 binary): "under 40 words, 1-2 plain sentences, no markdown. Lead with the overall goal and current task, then the one next action. Skip root-cause narrative, fix internals, secondary to-dos, and em-dash tangents." Add a Chinese-budget note (~80 chars) and keep the <recap>...</recap> wrapping that protects against reasoning-model preambles leaking into the UI. The sticky banner already re-measures controls height when the recap toggles, so a 2-line render lays out cleanly. Sweep "one-line" out of user-facing copy (settings description, slash-command description, feature docs, design doc) so the documentation matches the new shape. * fix(cli): restore "one-line" in user-facing recap copy Verified from the Claude Code v2.1.113 binary that the slash-command description IS literally "Generate a one-line session recap now" even though the underlying prompt allows 1-2 sentences. Claude Code is deliberately setting a tighter user expectation than the prompt guarantees, which keeps the surface feel "glanceable". Mirror that asymmetry: keep the prompt at 1-2 sentences (the previous commit) for behavioral parity, but put "one-line" back in the user- visible copy (slash-command description, settings description, user docs). Internal design doc keeps the accurate "1-2 sentence" wording. * fix(cli): render recap inline in history to match Claude Code Earlier I read the user's complaint that the recap "scrolled away" as "the recap should be sticky above the input box," and built a sticky banner accordingly. Disassembly of the Claude Code v2.1.113 binary shows the actual behavior is the opposite: their away_summary is a plain `type:"system", subtype:"away_summary"` message dispatched through the standard message renderer (no Static, no anchor, no flexbox pinning) — it scrolls with the conversation like every other system message. Tear out the sticky-banner machinery so recap matches that: - Recap is back in the `HistoryItemWithoutId` union and `addItem`'d into history (both from `/recap` and from auto-trigger), so it serializes into session saves and behaves like every other history item — no special clear paths, no resume-wrapper, no layout-effect re-measure dance. - `useAwaySummary` takes `addItem` again instead of a setter callback. - `AwayRecapMessage` renders the way Claude Code does: a 2-column gutter with `※`, then bold "recap: " and italic content, all in dim color. Drop the prior `StatusMessage`-shaped layout that fused prefix and label into "※ recap:". - Remove the AppContainer plumbing, the slashCommandProcessor state, the UIStateContext fields, the DefaultAppLayout / ScreenReader placement blocks, the test-utils mocks, and the noninteractive stub. Restore `useResumeCommand.handleResume` to a void return since callers no longer need the success boolean. Sweep the design doc so the architecture diagram, files table, and hook deps reflect the inline-history flow. * fix(cli): dedupe back-to-back auto-recaps with no new user turns between Two consecutive blur cycles, each over the threshold but with no new user activity in between, would each fire their own auto-recap and add two near-duplicate entries to history (same task, slightly different wording from temperature-driven LLM variance). Reported case: leaving the terminal twice while a /review of one PR was still on screen produced two recaps both about that same review. Add a `shouldFireRecap` gate before kicking off the LLM call: - Need at least 3 user messages in history total (don't fire on a near-empty session). - If a previous away_recap is already in history, need at least 2 new user messages since that one before another can fire. Same shape as Claude Code's `Ic1` gate (`Sc1=3`, `Rc1=2`). Read history through a ref so this isn't in the effect's deps and the effect doesn't re-run on every message. * fix(cli): type useResumeCommand.handleResume as Promise<void> Per gemini review on #3482: the interface declared this as `() => void` but the implementation is `async` and returns `Promise<void>`. The mismatch silently lost the chainable promise — tests had to launder it through `as unknown as Promise<void> | undefined` just to await. Tighten the interface to `Promise<void>` and drop the cast in the "closes the dialog immediately" test. * fix(cli): persist auto-fired recap to chat recording so /resume keeps it Per yiliang114 review on #3482: the manual `/recap` path persists across `/resume` because the slash-command processor records every output history item via `chatRecorder.recordSlashCommand({ phase: 'result', outputHistoryItems })`, but the auto path called `addItem` directly and bypassed that recorder. The result was an asymmetry where users who triggered recap manually saw it after `/resume`, while users whose recap fired automatically lost it. Mirror the manual recording from useAwaySummary's `.then` callback — record only the `result` phase (not invocation, since we don't want a fake `> /recap` user line replayed) with the away-recap item as the single output. Wrapped in try/catch because recap is best-effort and must never surface a failure to the user. Add useAwaySummary.test.ts covering: - the recording path is taken on a successful auto-trigger - the dedup gate (`shouldFireRecap`) suppresses the LLM call entirely, including the recording, when no new user turns happened since the last recap * fix(cli): cast recap item via spread to satisfy strict tsc --build CI's `tsc --build` (stricter than local `tsc --noEmit`) rejected the direct `item as Record<string, unknown>` cast: HistoryItemAwayRecap's literal `type: 'away_recap'` field doesn't overlap with `unknown`, TS2352. Use the `{ ...item } as Record<string, unknown>` spread pattern that the rest of the codebase (arenaCommand, slashCommandProcessor's serializer) already uses for the same SlashCommandRecordPayload field.	2026-04-21 14:39:13 +08:00
Shaojin Wen	52c7a3d0ed	fix(cli): pin /recap above input and align defaults with fastModel (#3478) ... * fix(cli): pin /recap above input box and align defaults with fastModel The recap rendered as a regular history item, so as soon as the model streamed a new reply the "where you left off" reminder scrolled out of view. Move it to a sticky banner anchored just above the Composer (matching how btwItem is rendered) so it stays visible across turns. While reworking the surface, also: - Replace the chevron prefix with `※ recap:` so it reads as a labeled recap line instead of a generic dim message. - Mirror the placement in ScreenReaderAppLayout so screen-reader users see it in the same logical position. - Drop HistoryItemAwayRecap from the HistoryItemWithoutId union — it is no longer addItem-able, and leaving it in invited silent no-op bugs where addItem(awayRecap) would compile but render nothing. - Clear the banner on /clear, /reset, /new and on /resume into a different session, so a recap from a previous context doesn't bleed into a freshly started one. - Re-measure the controls box when the banner appears or disappears (its height changes by a couple of lines) so the main content area recomputes availableTerminalHeight and stays laid out correctly. Auto-trigger now defaults to "on iff fastModel is configured" rather than unconditionally on. Running an ambient background recap on the main coding model is too costly and slow to be a sane default; tying it to fastModel means the feature is silently opt-in for users who have set up a cheap fast model. An explicit `general.showSessionRecap` override still wins either way, and `/recap` itself is unaffected. Sharpen the slash-command description to match the new behavior. * fix(core): silence AbortSignal listener-leak warning in OpenAI pipeline Every chat.completions.create call wires up an abort listener on the incoming AbortSignal, and several layers — retryWithBackoff, the LoggingContentGenerator wrapper, the SDK's own internal stream/fetch plumbing — register their own listeners against the same signal. Five retry attempts plus those layers comfortably exceed Node's default 10-listener cap and produce a MaxListenersExceededWarning. With features that share or compose signals (e.g., recap + followup speculation firing on the same response cycle), even a higher cap gets blown past. The signals here are per-request and short-lived, so the accumulation is structural rather than a real memory leak — they get GC'd as soon as the request settles. setMaxListeners(0, signal) at the SDK boundary disables the warning for these specific signals only, without masking any genuine leak elsewhere in the process. Idempotent and confined to the one place where retry-bound API calls cross into the SDK. * fix(core): tighten recap to a single sentence within 80 chars The 1-3 sentence budget reliably wrapped onto two lines in the sticky banner above the input box, which made it visually heavy for what is supposed to be a glanceable reminder. Constrain the prompt to exactly one sentence with a hard 80-char cap, and merge the "high-level task + next step" rule into a single sentence instead of two adjacent ones. Also sweep the docs (settings, commands, design) so the user-facing copy and the internal design notes match the new format. * fix(cli): apply review feedback for recap PR Two issues from review: - The schema description for `general.showSessionRecap` still said "1-3 sentence summary" while the prompt, docs, and slash-command copy already say "one-line". Aligns the text in settingsSchema.ts and the regenerated VSCode JSON schema. - The /resume wrapper cleared the sticky recap synchronously, before the inner handler had a chance to discover that no session data was available. On a no-op resume the user would still lose the current recap. Make `useResumeCommand.handleResume` return Promise<boolean> reporting whether a session actually loaded, and only clear the recap on a confirmed switch. * fix(cli): default showSessionRecap to false and drop fastModel heuristic The earlier "enabled iff fastModel is configured" default made it hard for users to answer the simple question "is auto-recap on for me right now?" — the answer depended on a setting from a different category, and setting/unsetting fastModel silently changed recap behavior. Revert to a plain boolean with a conservative off-by-default: - Auto-trigger fires only when the user explicitly sets `general.showSessionRecap: true`. - Manual `/recap` keeps working regardless (that's a user-initiated call, not an ambient one). - Users never get ambient LLM calls billed to their main coding model without having opted in. Aligns settings.md, design doc, and the regenerated JSON schema.	2026-04-20 23:58:19 +08:00
Shaojin Wen	c74d7678cb	Revert "feat(core): add dynamic swarm worker tool (#3433)" (#3468) ... This reverts commit f7ebc372f1.	2026-04-20 16:40:14 +08:00
Edenman	6c999fe29f	feat(cli): add OAuth configuration flags to mcp add (#3442) ... * feat(cli): Add OAuth redirect URI support to command - Add --oauth-redirect-uri, --oauth-client-id, --oauth-client-secret, --oauth-authorization-url, --oauth-token-url, and --oauth-scopes flags to the command - Enable configuration of custom OAuth redirect URIs for remote/cloud server deployments (fixes hardcoded localhost issue) - Document auth.redirectUri in both developer and user-facing MCP docs - Add comprehensive tests for OAuth configuration via CLI - Update documentation with examples and guidance for remote deployments Fixes #3336 Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * refactor(cli): harden OAuth flag handling in mcp add - Reject combining --oauth-* flags with --transport stdio to surface the mistake instead of silently persisting an unused oauth config - Rebuild OAuth config via single spread expression; drop the prior mutate-then-check pattern and the post-hoc enabled assignment - Trim each scope token after comma split so "read, write" no longer stores leading/trailing whitespace - Cover both new behaviors with tests; add missing --oauth-client-secret row and stdio-incompatibility note to the user MCP docs * test(cli): use explicit Vitest/Yargs type imports in mcp add tests Switch from namespace-style 'vi.Mock' and 'yargs.Argv' references to explicit 'Mock' and 'Argv' imports, and replace the narrow '(code?: number) => never' cast on the process.exit mock with 'typeof process.exit' so it tracks the current Node signature. --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-04-20 14:12:17 +08:00
ihubanov	0b8b3da836	feat(cli): add slashCommands.disabled setting to gate slash commands (#3445) ... * feat(cli): add slashCommands.disabled setting to gate slash commands Introduces a first-class way for operators to hide and refuse to execute specific slash commands. Useful for multi-tenant / enterprise / sandboxed deployments where different users should see different command subsets. The denylist is sourced from three unioned inputs: * `slashCommands.disabled` settings key (string[], UNION merge), so workspace scopes can only add to a denylist set at user or system scope, never shrink it — matching the shape already used by `permissions.deny`. * `--disabled-slash-commands` CLI flag (comma-separated or repeated). * `QWEN_DISABLED_SLASH_COMMANDS` environment variable. Matching is case-insensitive against the final (post-rename) command name, so extension commands are addressable by their disambiguated form (e.g. `firebase.deploy`). Disabled commands are removed from `CommandService`'s output, so they disappear from autocomplete and produce the standard unknown-command path in both interactive TUI and non-interactive (`--prompt`) modes. The scope of this change is slash commands only: it does not affect tool permissions (still `permissions.deny`) or keyboard shortcuts. * chore(cli): regenerate settings.schema.json for slashCommands.disabled Regenerates the companion JSON schema consumed by the VS Code extension after adding the `slashCommands.disabled` entry to the TS schema in the previous commit. Required by the "Check settings schema is up-to-date" CI lint step. * fix(cli): route disabled slash commands to unsupported, not no_command handleSlashCommand was passing the disabled denylist straight into CommandService.create, so disabled commands disappeared from `allCommands` too. The fallback existence check that distinguishes "known but not allowed in non-interactive mode" from "truly unknown" then failed, and disabled commands like `/help` fell through to `no_command` — causing the caller to forward them to the model as plain prompt text. Keep `allCommands` unfiltered and apply the denylist only when constructing the executable set and when producing the unsupported response. A disabled command now returns `unsupported` with a "disabled by the current configuration" reason and never reaches the model. Added three regression tests covering the primary case, case-insensitive match, and the preserved no_command path for genuinely unknown input.	2026-04-20 11:06:26 +08:00
Shaojin Wen	60a6dfc14c	feat(cli): add session recap with /recap and auto-show on return (#3434) ... * feat(cli): add session recap with /recap and auto-show on return Users often open an old session days later and need to scroll through pages to remember where they left off. This change adds a short "where did I leave off" recap — a 1-3 sentence summary generated by the fast model — so they can resume without re-reading the history. Two triggers: - /recap: manual slash command. - Auto: when the terminal has been blurred for 5+ minutes and gets focused again (uses the existing DECSET 1004 focus protocol via useFocus). Gated on streamingState === Idle so it never interrupts an active turn. Only fires once per blur cycle. The recap is rendered in dim color with a chevron prefix, visually distinct from assistant replies. A new `general.showSessionRecap` setting controls the auto-trigger (default on). /recap works independent of the setting. Implementation notes: - generateSessionRecap uses fastModel (falls back to main model), tools: [], maxOutputTokens: 300, and a tight system prompt. It strips tool calls / responses from history before sending — tool responses can hold 10K+ tokens of file content that drown the recap in irrelevant detail. The 30-message window respects turn boundaries (slice never starts on a dangling model/tool response). - Output is wrapped in <recap>...</recap> tags; the extractor returns empty (skips render) if the tag is missing, preventing model reasoning from leaking into the UI. - All failures are silent (return null) and logged via a scoped debugLogger; recap is best-effort and must never break main flow. - /recap refuses to run while a turn is pending. * fix(cli): abort in-flight recap when showSessionRecap is disabled If the user disables showSessionRecap while an auto-recap LLM call is already in flight, the previous code returned early without aborting. The pending .then would still pass its idle/abort guards and append the recap, producing an unwanted message after the user has opted out. Abort the controller and clear it eagerly so the resolved promise no longer adds to history. * fix(cli): gate /recap and auto-recap on streaming idle state Two related issues from review: 1. /recap was only refusing when ui.pendingItem was set, but a normal model reply runs with streamingState === Responding and a null pendingItem. Invoking /recap mid-stream would generate a recap from a partial conversation and insert it between the user prompt and the assistant reply. 2. useAwaySummary cleared blurredAtRef before checking isIdle, so if focus returned during a still-streaming turn (after a >5min blur) the recap was permanently dropped — there was no later retry when the turn became idle, because isIdle was not in the effect deps. Fixes: - Expose isIdleRef on CommandContext.ui (mirrors btwAbortControllerRef pattern). Plumb it from AppContainer through useSlashCommandProcessor. - recapCommand now refuses when isIdleRef.current is false OR pendingItem is non-null. - useAwaySummary preserves blurredAtRef on the !isIdle bail and adds isIdle to the effect deps, so the trigger re-evaluates when the current turn finishes. - Brief blurs (< AWAY_THRESHOLD_MS) still reset blurredAtRef. Also seeds isIdleRef in nonInteractiveUi and mockCommandContext so the new field has a sensible default outside the interactive UI. * docs: document /recap command, showSessionRecap setting, and design - User docs: add /recap to the Session and Project Management table in features/commands.md and a dedicated subsection covering manual use, the auto-trigger, the dim-color rendering, and the fast-model tip. - User docs: add general.showSessionRecap row to the configuration settings reference. - Design doc: docs/design/session-recap/session-recap-design.md covers motivation, the two trigger paths, the per-file architecture, prompt design with the <recap> tag and three-tier extractor, history filtering rationale (functionResponse can be 10K+ tokens), the useAwaySummary state machine, the isIdleRef gating for /recap, model selection, observability, and out-of-scope items. * fix(core): exclude thought parts from session recap context filterToDialog kept any non-empty text part, but @google/genai's Part type also marks model reasoning with part.thought / part.thoughtSignature. That hidden chain-of-thought was being fed to the recap LLM and could get summarized as if it were user-visible dialogue. Drop parts where either flag is set. Update the design doc's History 过滤 section to call this out alongside the existing tool-call/response rationale. * docs(session-recap): correct debug-logging guidance, fill in state machine, sharpen UX wording Audit of the session recap docs against the implementation found three issues worth fixing: - Design doc claimed debug logs were enabled via a QWEN_CODE_DEBUG_LOGGING env var. That var does not exist; debug logs are written to ~/.qwen/debug/<sessionId>.txt by default, gated by QWEN_DEBUG_LOG_FILE. Replace with the accurate path + opt-out behavior, and tell the reader to grep for the [SESSION_RECAP] tag. - Design doc's useAwaySummary state machine table was missing the isFocused && blurredAtRef === null path (taken on first render and right after a brief-blur reset). Add the row. - User doc's "Refuses to run ... failures are silent" line conflated the inline-error refusal with silent generation failures, and "(when the conversation is idle)" used internal jargon. Split the two cases and spell out what "idle" means, including the wait-then-fire behavior when focus returns mid-turn. * docs(session-recap): correctly describe /recap vs auto-trigger failure modes The previous wording said "Generation/network failures are silent — the recap simply does not appear", but recapCommand returns a user-facing info message ("Not enough conversation context for a recap yet.") in exactly that path, and also returns inline messages for the config-not-loaded and busy-turn guards. Only the auto-trigger path is truly silent (it just skips addItem when generateSessionRecap returns null). Split the two paths in the doc so the manual command's "always responds with something" behavior is distinguished from the auto-trigger's no-op-on-failure behavior. * docs(session-recap): align prompt-rules section with the actual prompt Two doc-vs-code mismatches in the design doc's "System Prompt" section, caught with the same lens as yiliang114's failure-mode review: - The bullet list claimed RECAP_SYSTEM_PROMPT forbids "推测用户意图" and "用 'you' 称呼用户". Those rules existed in an early draft but were dropped when the <recap> tag rules were added; the current prompt has no such restrictions. Replace with the actual rules and add a "与 RECAP_SYSTEM_PROMPT 一一对应" marker so future edits stay in sync. - The doc said systemInstruction "覆盖" the main agent prompt. True for the agent prompt portion, but GeminiClient.generateContent internally calls getCustomSystemPrompt which appends user memory (QWEN.md / 自动 memory) as a suffix. Spell that out — the final system prompt is recap prompt + user memory, which is actually useful project context for the recap. * docs(session-recap): translate design doc to English The repo convention for docs/design is English (7 of 8 existing files; auto-memory/memory-system.md is the only Chinese one). The first version of this design doc followed the auto-memory example, which turned out to be the wrong sample. Translate to English while preserving the existing structure, the state-machine table, the prompt-vs-doc 1:1 alignment, the QWEN_DEBUG_LOG_FILE description, and the failure-mode notes added in prior commits. * fix(cli): drop empty info return from /recap interactive success path The interactive success path inserts the away_recap history item directly via ui.addItem and then returned `{type: 'message', messageType: 'info', content: ''}`. The slash-command processor's 'message' case unconditionally calls addMessage, which adds another HistoryItemInfo with empty text. The empty info renders as nothing (StatusMessage early-returns null), but it still bloats the in-memory history list and shows up in /export and saved sessions. Return void on the interactive success path and on the abort path so the processor's `if (result)` check skips the message-handler branch entirely. Widen the action's return type to `void | SlashCommandActionReturn` to match (same shape as btwCommand).	2026-04-19 21:38:48 +08:00
Reid	f7ebc372f1	feat(core): add dynamic swarm worker tool (#3433) ... * feat(core): add dynamic swarm worker tool Add a swarm tool for ad-hoc parallel worker execution with bounded concurrency, wait-all and first-success modes, per-worker failure isolation, and aggregated results. Register the tool in core, prevent nested worker recursion, and document the new workflow. * fix(core): harden swarm worker execution Prevent swarm calls from bypassing the outer scheduler concurrency budget. Disallow interactive question prompts in swarm workers by default, and avoid incomplete Markdown table escaping by using an HTML entity for pipe characters. Add focused tests for the scheduler behavior, worker tool restrictions, and result formatting.	2026-04-19 14:46:59 +08:00
Shaojin Wen	4bf5bf22de	feat(cli): support refreshInterval in statusLine for periodic refresh (#3383) ... * feat(cli): support refreshInterval in statusLine for periodic refresh The statusLine (#3311) re-runs only when Agent state changes (token count, model, git branch, etc.). Commands that display *external* data — a clock, rate-limit counters, CI build status — have no Agent event to hook into and go stale between messages. Add an optional `ui.statusLine.refreshInterval` field (seconds, minimum 1) that schedules a setInterval alongside the existing event-driven updates. Overlap with state-change debounce is safe: `doUpdate` kills any in-flight child and bumps the generation counter, so only the most recent output reaches the footer. Validation lives in `getStatusLineConfig`: - Must be `number`, `Number.isFinite(...)`, `>= 1` - Anything else is silently dropped (no interval scheduled) No changes to the default behavior — configs without `refreshInterval` behave exactly as before. * fix(cli): yield periodic statusLine tick when previous exec is in flight Review feedback on #3383: with `refreshInterval: 1` and a command whose real exec time exceeds 1s, each tick was unconditionally calling `doUpdate()` — which kills the in-flight child and bumps the generation counter — so the prior exec's callback was always discarded as stale. `setOutput` was never reached and the statusline stayed empty until `refreshInterval` was removed or the command became faster. Guard the interval callback with an `activeChildRef` check so a pending exec is allowed to finish. State-change triggers (model switch, token count, branch, etc.) still go through `scheduleUpdate` → `doUpdate` directly and legitimately preempt stale children; only the periodic tick yields. The existing 5s exec timeout is still the hard ceiling. Also drop the redundant `'refreshInterval' in raw` check — the `typeof raw.refreshInterval === 'number'` guard already excludes missing / undefined values. Tests: - Add regression test `'skips periodic ticks while a previous exec is still running'` — three ticks during one unfinished exec trigger zero new spawns; the next tick after callback completion does spawn. - Update two existing tests to resolve the mount exec before expecting subsequent ticks (the old tests implicitly relied on the starvation behavior being tolerated). * test(cli): assert user-visible lines state in starvation regression Self-review insight: the existing `skips periodic ticks while a previous exec is still running` test only counted `exec` calls — it confirmed the guard prevents redundant spawns, but would have silently passed even if the eventual callback was still being discarded as stale (which is the actual user-visible symptom of the starvation bug). Add `expect(result.current.lines).toEqual(['done'])` after resolving the mount's pending callback. Without the guard, generationRef would have bumped 3 times during the yielded ticks, the callback's captured gen would fail the stale check, `setOutput` would never fire, and `lines` would stay empty — now caught explicitly. * perf(cli): dedupe statusLine output to skip unchanged Footer re-renders Review feedback on #3383 (narrow terminal stacking): when `refreshInterval` fires at 1s and the command output is unchanged, the mount-and-setOutput cycle still allocates a new array and triggers a Footer re-render. Under certain narrow-terminal conditions, Ink's erase-line accounting mis-counts wrapped rows and stale content accumulates on screen. The Footer-layout root cause is in #3311's narrow-mode flex setup and Ink's truncate semantics, which is out of scope for this PR. But we can cut the re-render surface here by preserving the `lines` array reference when the command produces identical output — a strict Pareto improvement for any caller (clock-style statuslines with second-precision still re-render; rate-limit / branch / CI-status style statuslines that change infrequently stop triggering work every tick). Tests: - `preserves the same lines array reference when output is unchanged` asserts referential equality after a re-exec with identical stdout. - `produces a new reference when output changes` guards against over-eager dedup that would miss legitimate updates. * fix(cli): stabilize Footer rendering in narrow terminals Narrow-terminal E2E feedback on #3383: with `refreshInterval` at 1s, empty lines were accumulating above the input prompt each tick. Root cause is in the Footer flex layout — originally from #3311 — where Ink miscounts logical rows vs the physical rows the terminal actually uses. Two adjustments, both idiomatic (used elsewhere in the repo already): 1. Left column — `minWidth={0}`. Without this, Yoga's `min-width: auto` default keeps the Box at its natural content width, so a statusline wider than the terminal doesn't engage `<Text wrap="truncate">`; the text renders at content-width and the terminal wraps it physically. `minWidth={0}` lets the column shrink so the text child can truncate at container width. 2. Right section — `flexWrap="wrap"`. With multiple indicators (sandbox label, debug badge, dream, context-usage) the row can exceed a narrow terminal's width. Without `flexWrap` Ink lays them out in a single logical row, but the terminal physically wraps to two — Ink's erase sequence (`\e[2K\e[1A…` per logical row) then clears one row while two exist, and the extra row ghosts every re-render. With `wrap` Ink tracks the second row explicitly and erases correctly. Together these make the Footer's row count match between Ink's logical view and the terminal's physical view, so frequent re-renders (as `refreshInterval` enables) stop accumulating ghost rows. Needs verification in a real narrow TTY — from this environment I can reason about the flex semantics and confirm both props are supported by Ink's Box, but actually observing ghost-row elimination requires process.stdout.columns on a real terminal. * Revert "fix(cli): stabilize Footer rendering in narrow terminals" This reverts commit 9758cda85f. Reason: I could not reproduce BZ-D's reported ghost-row stacking in tmux (40x25, 2-line statusline + real exec + Static history + refreshInterval: 1) over 14+ ticks. Both `minWidth={0}` and `flexWrap="wrap"` are legitimate defensive idioms, but without a failing repro I can't verify they address the reported bug, and I shouldn't ship a speculative layout change as "the fix". Keeping the output-dedup commit (e1d321186) — that one is a strict improvement regardless of the underlying Ink behavior. Will request BZ-D's specific terminal setup and reopen with a verified fix (or confirm the issue is specific to a particular emulator, not flex/Ink).	2026-04-19 11:12:16 +08:00
ChiGao	9e26424aa7	feat(cli): add dual-output sidecar mode for TUI (#3352) ... * feat(cli): add dual-output sidecar mode for TUI Adds an optional **dual-output** mode for the interactive TUI: while Qwen Code keeps rendering normally on stdout, it concurrently emits a structured JSON event stream on a second channel (--json-fd / --json-file) and optionally watches a JSONL command file (--input-file) for prompts and tool-permission responses written by an external program. This unlocks programmatic embedding of the TUI from IDE extensions, web frontends, CI agents, or automation scripts without forcing them to give up the rich interactive UI in favor of --output-format=stream-json. ## Design The TUI already has a battle-tested JSON event emitter (`StreamJsonOutputAdapter`). This change makes that adapter pluggable on its output stream and wires a small `DualOutputBridge` that forwards TUI events to a second instance of the adapter writing to fd / file. For tool approvals, when a tool enters awaiting_approval the bridge emits `control_request` (subtype `can_use_tool`); whichever side resolves first (TUI's native UI or `confirmation_response` via --input-file) wins, and a `control_response` is mirrored back so all observers stay in sync. `session_start` is announced once when the bridge is constructed so consumers can correlate the channel with a session before any other event arrives. ## CLI surface - `--json-fd <n>` — write JSON events to fd n (n >= 3; provided via spawn stdio). - `--json-file <path>` — write JSON events to a file / FIFO / /dev/fd/N. - `--input-file <path>` — watch this file for JSONL commands. `--json-fd` and `--json-file` are mutually exclusive. fds 0/1/2 are rejected to prevent corrupting the TUI. ## Wire protocol Output: existing stream-json schema with `includePartialMessages` always enabled, plus: - `system` / `subtype: session_start` — emitted once on bridge construction. - `control_request` / `subtype: can_use_tool` — pending tool approval. - `control_response` — final approval outcome (mirrors TUI-native or external resolution). Input (--input-file): {"type":"submit","text":"What does this function do?"} {"type":"confirmation_response","request_id":"...","allowed":true} `submit` is queued and retried when the TUI returns to idle. `confirmation_response` is dispatched immediately — a pending tool call is blocking and the response cannot wait behind earlier submits. See `docs/users/features/dual-output.md` for the full schema, latency notes, failure modes, and a spawn example. ## What changes when the flags are absent Nothing. The bridge and watcher are constructed only when the relevant flags are set; otherwise the React Context providers carry `null` and every callsite short-circuits. No overhead, no behavioral change for existing users. ## Failure handling - Bad fd / unopenable path → warning on stderr, dual output stays disabled, TUI launches normally. - Consumer disconnect (EPIPE) → bridge silently disables itself, TUI keeps running. - Any exception inside the adapter → caught, logged, bridge disabled. The TUI is never crashed by a dual-output failure. ## Files New: - packages/cli/src/dualOutput/{DualOutputBridge,DualOutputContext,index}.{ts,tsx} - packages/cli/src/remoteInput/{RemoteInputWatcher,RemoteInputContext,index}.{ts,tsx} - packages/cli/src/nonInteractive/io/index.ts - docs/users/features/dual-output.md Modified: - packages/core/src/config/config.ts — 3 new ConfigParameters fields + getters - packages/cli/src/config/config.ts — yargs options + mutex validation - packages/cli/src/gemini.tsx — instantiate bridge / watcher in startInteractiveUI, wrap with Context Providers, register cleanup - packages/cli/src/ui/AppContainer.tsx — connect RemoteInput to submitQuery, bridge tool confirmations - packages/cli/src/ui/hooks/useGeminiStream.ts — call dualOutput?.processEvent(...) at five existing event points - packages/cli/src/nonInteractive/io/{Base,Stream}JsonOutputAdapter.ts — StreamJsonOutputAdapter accepts an injected output stream; base adapter exposes emitPermissionRequest / emitControlResponse through a new emitControlMessageImpl hook (default no-op in batch mode). ## Tests - packages/cli/src/dualOutput/DualOutputBridge.test.ts — fd validation, auto session_start, control-event routing, post-shutdown safety. - packages/cli/src/remoteInput/RemoteInputWatcher.test.ts — submit forwarding, immediate confirmation dispatch, busy/idle retry, malformed-line tolerance, shutdown. - packages/cli/src/nonInteractive/io/StreamJsonOutputAdapter.dualOutput.test.ts — custom outputStream injection and new emitPermissionRequest / emitControlResponse paths. tsc --noEmit -p packages/cli/tsconfig.json is clean. vitest run src/nonInteractive src/dualOutput src/remoteInput → 297 passed, 1 skipped, 11 files. * feat(cli): dual-output capability handshake, session_end, control_error, settings.json Incremental improvements on top of the initial dual-output PR based on reviewer feedback. All extensions are additive; older consumers that ignore unknown fields keep working. ## Capability handshake in session_start `session_start.data` now carries three new fields so consumers can feature-detect without sniffing the stream: - `protocol_version` (integer, currently 1) — bumped on any protocol change consumers might care about. - `version` (string) — the Qwen Code CLI version, threaded in from `gemini.tsx`. - `supported_events` (string[]) — the event kinds this bridge version is known to emit, exported as `SUPPORTED_EVENTS` from the module. ## session_end on bridge shutdown DualOutputBridge.shutdown() now emits a final `system` / `session_end` event carrying `session_id` before closing the stream. Gives consumers a definitive termination signal rather than requiring them to infer it from EPIPE. Idempotent — calling shutdown twice emits exactly one session_end. ## control_error emission path `ControlErrorResponse` (already defined in types.ts) now has a first- class emission path: `BaseJsonOutputAdapter.emitControlError(requestId, message)` → `control_response` with `subtype: 'error'`. Wired into AppContainer's remote-input confirmation handler so that a `confirmation_response` referencing an unknown / already-resolved request_id produces a structured error reply instead of silently dropping, letting consumers retry or surface the error. ## settings.json support New `dualOutput` top-level settings block with `jsonFile` and `inputFile` properties. `--json-fd` has no settings equivalent (fd passing is a spawn-time concern). CLI flag wins over settings when both are present, so scripted one-off runs still work unchanged. `requiresRestart: true` since the bridge is constructed once at startup. ## Documentation `docs/users/features/dual-output.md` gains three major sections: - **Use cases** — concrete integration scenarios (terminal+chat dual sync, IDE extensions, web frontends, CI observers, multi-agent orchestration, session replay, observability, QA). - **Why two output flags?** — detailed rationale for coexisting `--json-fd` and `--json-file`, including the PTY constraint (`node-pty` / `bun-pty` expose no stdio array, and `forkpty(3)` / `login_tty` actively close fds >= 3 before exec). - **Comparison with Claude Code's stream-json** — schema-parity matrix, transport-topology differences, permission-control-plane behavioral notes, and a "room to improve" section as a design horizon. - **Runnable demos** — seven copy-paste POCs: event observer, remote submit, permission bridge, Node embedder with capability feature-detection, session_end handling, failure drills. - **Settings-based configuration** — example settings.json snippet and precedence rules. ## Tests - DualOutputBridge.test.ts: new cases for capability handshake shape, session_end on shutdown, shutdown idempotency, and emitControlError. - StreamJsonOutputAdapter.dualOutput.test.ts: new case for emitControlError at the adapter level. 302 passed, 1 skipped, 11 files. tsc --noEmit -p packages/cli is clean. * docs(dual-output): shrink Claude Code comparison to one honest sentence After actually reading the Claude Code source (src/cli/structuredIO.ts, src/bridge/*, src/utils/messages/systemInit.ts), the previous "Comparison with Claude Code's stream-json" section was overstated: - Claude Code has no equivalent of TUI + sidecar running simultaneously. Its stream-json only works with --print (non-interactive); the bridge in src/bridge/* is Anthropic's own remote worker protocol, not a local embedding surface. - CC uses `system/init` (not `session_start`) and has no session_end in the wire protocol, so the schema-parity table contained false ticks. - Framing this PR as "parity with Claude Code" is therefore inaccurate; it's filling a gap Claude Code does not address. Replace the whole multi-section comparison (schema matrix, transport table, permission notes, borrow list, roadmap) with a single sentence stating the accurate relation: same event format in spirit, different topology — CC's is non-interactive only. * fix(cli): address review feedback on dual-output sidecar mode - Fix control_response mirror: external-initiated confirmations now emit control_response via the same mirror useEffect as TUI-native resolutions, making the emission path symmetric for all observers. - Fix ENOENT: --json-file with a non-existent path now falls back to createWriteStream (auto-creates the file) instead of throwing. - Fix race: add reading guard to RemoteInputWatcher.readNewLines() preventing duplicate command processing on rapid appends. - Refactor confirmationHandler to use refs (pendingToolCallsRef, dualOutputRef) and register once (deps: [remoteInput]) to eliminate teardown/re-registration churn. - Add debug logging to shutdown bare catch for ops correlation. - Add ENOENT fallback test case for DualOutputBridge. - Regenerate settings.schema.json for dualOutput section. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): make RemoteInputWatcher poll interval configurable for CI reliability RemoteInputWatcher.test.ts was timing out in CI (5s default) because fs.watchFile's 500ms poll interval is unreliable under load. Fix: - Accept optional `pollIntervalMs` in constructor (default 500ms). - Tests use 100ms poll interval for faster feedback. - Increase per-test timeout to 15s and waitFor timeout to 10s. - Increase "TUI busy" wait from 800ms to 1500ms for CI headroom. Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * fix(cli): eliminate fs.watchFile timing dependency in RemoteInputWatcher tests Tests were flaky across all CI platforms (macOS/ubuntu/windows) because fs.watchFile polling (even at 100ms) is unreliable under CI load. Fix: expose checkForNewInput() as a public method that directly triggers file reading and returns a Promise. Tests now call it synchronously after writing to the input file — no polling, no timeouts, deterministic. Also fixes: - Windows ENOTEMPTY: add delay in afterEach before rmSync - Add active check in readNewLines to respect shutdown state - readNewLines now returns Promise<void> for awaitable reads Generated with AI Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> --------- Co-authored-by: 秦奇 <gary.gq@alibaba-inc.com> Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-04-18 02:14:53 +08:00
joeytoday	89167618d8	docs: update authentication methods to reflect OAuth discontinuation (#3325) ... * docs: update authentication methods to reflect OAuth discontinuation Remove deprecated Qwen OAuth references and update documentation to direct users to valid authentication methods (API Key, Coding Plan, or Local Inference) following the OAuth free tier discontinuation on 2026-04-15. Closes #3316 * docs: fix quickstart auth description to match actual /auth UI The /auth command shows three options: Alibaba Cloud Coding Plan, API Key, and Qwen OAuth (discontinued). Updated quickstart.md to accurately reflect this UI instead of splitting into Option A/B/C. Also updated settings.md, commands.md, and troubleshooting.md with minor OAuth-related cleanups. * docs: update .qwen workspace description in quickstart Remove reference to 'Qwen account' since OAuth is discontinued. The .qwen directory is created by Qwen Code itself for storing credentials, configuration, and session data. * docs: fix warning block formatting in quickstart - Add missing '>' continuation for the OAuth discontinuation warning block Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * docs: update README Qwen3.6-Plus description - Remove mention of running Qwen3.6-Plus locally via Ollama/vLLM - Keep only the Alibaba Cloud ModelStudio API key option Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com> * docs: address review feedback - remove Local Inference from auth, add dual-region links - Local Inference removed from auth method lists, kept as separate 'Local Model Setup' section with detailed Ollama/vLLM config examples - All links now provide dual-region URLs (Beijing + intl) - .qwen workspace note restored to original meaning (cost tracking) - Device auth flow error kept scoped to legacy OAuth - API setup guide links updated with confirmed intl URL --------- Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>	2026-04-17 15:34:18 +08:00