Bump baked version in install scripts, CD workflow default, and
README examples to 0.7.1 so the release pipeline picks up the
correct version. Add docs/0.7.1-coord-norm-fixes.md documenting
all fixes in this release.
* fix(cua-driver): denormalize from_zoom click coords in normalized mode
When CUA_DRIVER_RS_COORDINATE_SPACE=1 (0-1000 normalized coordinates),
from_zoom=true clicks were skipping denormalization entirely, causing the
model's 0-1000 values to be treated as raw pixel offsets in the zoom
image — landing clicks at the wrong position.
- Add ZOOM_SIZE_CACHE: cache zoom image dimensions (width/height) from
zoom tool results, keyed by pid (matching platform ZoomRegistry)
- denormalize_args: when from_zoom=true and cache exists, denormalize
x/y against zoom image dimensions instead of skipping
- rewrite_coord_desc: rewrite from_zoom description from "pixel
coordinates" to "0-1000 normalized coordinates" so the model sends
normalized values
- ingest_zoom_size: new output hook called after zoom tool execution to
populate the cache
* fix(cua-driver): error on missing coord cache + normalize scroll/mouse tools
Two additional fixes for the 0-1000 normalized coordinate mode:
1. denormalize_args now returns Result<(), String> and errors when a
required size basis is missing (SIZE_CACHE, SCREEN_SIZE,
DESKTOP_SCREENSHOT_SIZE, ZOOM_SIZE_CACHE), instead of silently
passing through unconverted normalized coordinates that would land
clicks at wrong positions. The error messages guide the model to call
the appropriate query tool (get_window_state, get_screen_size,
get_desktop_state, zoom) first.
2. Add scroll, mouse_button_down, mouse_button_up, mouse_drag to
input_coord_fields so their x/y coordinates are denormalized in
normalized mode. scroll x/y specify where to deliver the wheel event
(not scroll amount); Linux mouse tools are stateful press/drag/release
with window-local coordinates.
* chore(cua-driver): bump version to 0.7.1
* fix(cua-driver): stop rewriting screenshot_width/height in normalized mode
normalize_result was rewriting get_window_state and get_desktop_state
screenshot_width/height to 1000, conflicting with elements[].frame
which stays in pixels. The model received contradictory coordinate
information: screenshot dimensions said 1000 but element positions
were in real pixels (e.g. x=1444).
Query tool results should be returned unmodified. The model is guided
to use 0-1000 coordinates through tool schema descriptions and MCP
instructions, not by tampering with return values.
* fix(cua-driver): address review — normalize_result + parallel_mouse_drag
1. Stop rewriting screenshot_width/height to 1000 in normalized mode.
Query results now return real pixel values; the model is guided to
use 0-1000 coords through schema descriptions and instructions only.
2. Fix parallel_mouse_drag per-item window_id lookup: each drag item
resolves its own (pid, window_id) from SIZE_CACHE instead of using
the caller-level screenshot_w/h (which is always 0 since the tool
has no top-level pid/window_id).
3. Add x_from/x_to conversion for fn-expression domain bounds.
4. Prevent from_zoom early return from skipping nested coord handler.
5. Fix misleading comments about "non-empty entry" and "nested rewrite".
- Change issue-autofix concurrency group from global `qwen-autofix-issue`
to per-issue `qwen-autofix-issue-${{ issue_number }}`, allowing multiple
issues to be fixed in parallel instead of serializing all runs.
- Add concurrency group to the route job with `cancel-in-progress: true`,
so stacked empty runs from rapid label events cancel each other instead
of queuing up (previously 9+ runs queued for 39+ minutes).
- Add `assigned` event trigger: when an issue is assigned to the autofix
bot, the route job routes directly to the issue phase, bypassing the
label gates. The assignee itself serves as the trust signal.
Co-authored-by: Qoder <noreply@qoder.com>
The daemon-managed channel worker reads each channel's settings (tokens, proxy, per-channel model) once when it starts, so applying settings.json changes previously required restarting the whole daemon. This adds an explicit reload that stops and relaunches the worker so it re-reads settings.json, without bouncing the daemon or its live sessions.
The reload is exposed as a strict-gated POST /workspace/channel/reload route, an SDK reloadChannelWorker() method, and a qwen channel reload CLI command, advertised through a channel_reload capability only when the daemon was started with --channel. The worker supervisor gains a restart() that coalesces concurrent reloads onto a single relaunch, resets the crash-restart budget so a failed worker recovers, and latches a disposed flag on hard shutdown so a racing reload cannot relaunch a worker into a tearing-down daemon.
Refs #5976
* fix(cli): forward user input to MCP prompts with no declared arguments
When a prompt declares no arguments, parseArgs() silently discarded
all user input. Forward named args as-is and positional input under
the "input" key, matching Claude Code's behavior.
Fixes#6563
* fix(cli): strip quotes and guard input key in MCP prompt arg forwarding
- Use positionalArgs.join(' ') instead of positionalArgsString to
properly strip quotes from positional input, consistent with the
existing single-arg path.
- Guard against overwriting a user-provided --input named arg with
positional text.
- Add comment explaining the input key convention.
* fix(cli): update help text for no-argument MCP prompts
The help text previously said the prompt 'has no arguments', which is
now misleading — user input is forwarded as-is. Updated to explain
that free-form text is accepted and how it maps to the input key.
Suggestion-level findings were routed to a single updatable issue comment
(the "suggestion summary") while only Critical findings became inline review
comments. That split traded away two things that turned out to matter more
than the convergence it bought:
- An issue comment has no lifecycle. GitHub folds an inline review thread away
as Outdated once the author edits the line it is anchored to, so an addressed
finding removes itself from the page. The summary comment just sits in the PR
conversation forever; PATCHing it to "all addressed" replaces its content but
not the comment. The mechanism meant to prevent clutter was the clutter.
- A Markdown table cannot carry a one-click fix. GitHub renders a ```suggestion
fence as an applicable change only inside a review comment on a diff line.
Suggestion findings are exactly the mechanical, localized cleanups that
benefit most from one-click apply, so the split withheld the feature from the
findings that needed it most.
Both severities now post as inline comments, distinguished by a **[Critical]**
or **[Suggestion]** body prefix. The `qwen review post-suggestions` subcommand
and its plumbing are removed.
Follow-on changes required by the reroute:
- pr-context: the "Previous suggestion summary" section is gone. Legacy summary
comments are still recognised so they stay out of "Already discussed", but the
exclusion is now marker-only rather than author-gated. The author check missed
summaries posted by the *other* identity: /review runs as a maintainer locally
and as qwen-code-ci-bot in CI, and roughly half of the last 60 PRs carry a
bot-authored summary. Those leaked into "Already discussed" and told the review
agents not to re-report the findings listed there. The check originally guarded
promotion into a trusted rendering section; that section no longer exists, so
it only gated exclusion, where a third party embedding the marker merely hides
their own comment.
- qwen-autofix: the workflow filters "suggestion summaries" out of the autofix
bot's actionable queue, but only on the issue-comment channel. With Suggestions
now inline, they entered the unfiltered inline channel and the bot would apply
non-blocking recommendations and spend a review round on them. The inline
channel now applies the same gate, keyed on the **[Suggestion]** prefix plus
the /review footer so a human quoting the prefix stays actionable.
- Step 7 gains a 422 fallback. Create Review is all-or-nothing, so one Suggestion
anchored outside the diff would take the Critical findings down with it — a risk
that did not exist when Suggestions travelled on a line-agnostic issue comment.
GitHub's 422 does not name the offending entry, so the model rechecks anchors
against the diff, relocates failing Criticals into the body, discards failing
Suggestions, and degrades to an all-prose review rather than posting nothing.
COMMENT reviews now always carry a one-line body: an empty body is only known
to be accepted alongside inline comments on REQUEST_CHANGES, and a Suggestion-
only review is the common case for a clean PR.
* feat(cli): VP mode — inline thought expand on click + auto-hiding scrollbar
Two VP-mode (ui.useTerminalBuffer) UX improvements:
1. Thinking: clicking a thought now expands it inline, in place, instead of
opening a full-screen modal. The expanded thought becomes part of the
conversation and scrolls with it, matching the lighter inline pattern.
A thought spans the `gemini_thought` head plus its trailing
`gemini_thought_content` continuations, so expansion is keyed by the head
id (buildThoughtHeadIdMap) and one click expands/collapses the whole group.
Alt+T still toggles all thoughts at once.
The full-screen ThinkingViewer modal (and its context) is removed: it only
ever opened in VP, where an inline-expanded thought is already scrollable
via the viewport, so it was redundant. Drops ThinkingViewer.tsx,
ThinkingViewerContext.tsx, and the now-dead thinkingFullText plumbing.
2. Scrollbar: the VP scrollbar now auto-hides — it renders as blank cells while
idle (keeping width 1 so the viewport never reflows) and pops in only while
scrolling, then fades out. Adds `ui.showScrollbar` (default true) to hide it
entirely.
Generated with AI
Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
* feat(cli): advertise click in the collapsed thought hint (VP only)
The collapsed thinking line only hinted "option+t to expand", so the new
click-to-expand affordance was undiscoverable. Show "(click or option+t to
expand)" when the click handler is actually active — i.e. VP mode
(ui.useTerminalBuffer) — and keep the plain "(option+t to expand)" in non-VP,
where clicking does nothing (native scrollback is preserved).
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>
* feat(scheduled-tasks): add isolated run mode via create_sub_session tool
Introduce a new `create_sub_session` tool (daemon-only) that spawns a
fresh top-level sub-session with its own clean context and transcript.
Wire it into the cron scheduler as an `isolated` run mode so each
scheduled fire dispatches its prompt into a fresh sub-session instead
of accumulating in one shared transcript.
- Add `create_sub_session` tool with `first-turn` and `sent` completion modes
- Add `SubSessionLauncher` in cli/serve with concurrency cap, timeout, and truncation
- Extend ACP bridge `extMethod` dispatch for child→daemon sub-session requests
- Add `runMode` field (`shared`|`isolated`) to DurableCronTask, CronJob, and API types
- Add run-mode radio picker to ScheduledTasksDialog UI
- Fix AuthMessage hardcoded placeholder to use i18n key
* fix(scheduled-tasks): dispatch isolated fires daemon-side, not via the model
An `isolated` fire was relayed through the model: the fired prompt was
wrapped with an instruction to call `create_sub_session`. That tool's
default permission is `'ask'`, so under `ApprovalMode.DEFAULT` an
unattended fire reached `client.requestPermission`, found no SSE
subscriber, and was cancelled by the daemon's 5-minute permission
timeout. The task never ran, and the cancel was booked as a successful
run — the headline use case of a scheduled task was broken.
Route isolated fires straight to the daemon instead: the cron `onFire`
handler in `Session` calls the sub-session spawner directly, with no
model relay and no tool-permission gate. The prompt was already approved
when the task was created; laundering it back through the model only
re-opened that gate. `create_sub_session` keeps `'ask'` for
model-initiated calls, and the attended "Run now" button keeps its relay
(a user is present to answer the prompt).
Also fix orphan-session cleanup in the launcher. `closeSession` was
guarded only by `.catch()`, which covers an async rejection but not a
synchronous throw; because the call sits inside the launcher's own
`catch (err)` block, a sync throw escaped and replaced the real launch
error. Guard both shapes.
Tests:
- Cover isolated routing: dispatch, in-session fallback with no spawner,
missed one-shot, dispatch failure (dropped, never run inline), and
shared mode.
- Cover the orphan close, including a `closeSession` that throws.
- Replace the sent-mode concurrency test, which only asserted the slot
was eventually released (moving the release to the drain's *start*
kept it green) with one that asserts the slot is HELD while the drain
runs, plus one that asserts it is released at `turn_complete`.
* fix(scheduled-tasks): honor the caller's AbortSignal and harden the spawn boundary
Four findings from review, all in the model-initiated `create_sub_session`
path (the scheduled `isolated` dispatch reaches none of them).
`execute()` took no parameters, so it silently dropped the parent turn's
`AbortSignal`. `Session.ts` awaits `invocation.execute(signal)` without
racing the abort itself, so cancelling a turn with a `first-turn`
sub-session in flight pinned the caller's tool loop until the daemon's
5-minute ceiling. Accept the signal and return as soon as it fires.
The sub-session is deliberately NOT cancelled and deliberately KEEPS its
concurrency slot: `sendPrompt` has no abort seam, so the sub-session runs
on. Releasing its slot on cancel — as the review suggested — would let the
caller over-admit against sub-sessions that are still consuming a bridge
session and model quota.
`handleCreateSubSession` trusted the child-supplied `callerSessionId`
verbatim, and that id keys the launcher's per-caller concurrency bucket: a
fabricated id starts a fresh bucket at zero (cap evasion) and a victim's id
burns their slots (DoS). Validate it with the connection's existing
`ownsSession` seam.
Every daemon session wires a spawner, sub-sessions included, and each gets
its own cap-sized bucket — so one prompt could fan out 5ⁿ sub-sessions until
`maxSessions` ran dry. Gate nesting at one level: the launcher remembers the
sessions it spawned and refuses to spawn from them. With `callerSessionId`
now authenticated, the gate cannot be sidestepped.
Cap the prompt at 100,000 chars (matching the scheduled-task REST route) and
the display name at 200, both at the bridge trust boundary and, for the
prompt, in the tool's own validation so the model gets an actionable error.
Not changed: `create_sub_session` stays in `PermissionManager.CORE_TOOLS`.
Membership there SUBJECTS a tool to the `coreTools` allowlist; it does not
exempt it. Removing it — as the review suggested — is what would let the
tool bypass a user's allowlist, the way `agent` and `send_message` do today.
* fix(core): do not spawn a sub-session for an already-cancelled turn
`raceCancellation(spawner({…}), signal)` evaluated the spawner as an
argument, so the spawn started before the abort was ever checked. A turn
cancelled before `execute()` ran still created a sub-session on the daemon
— and it kept a concurrency slot — while the tool reported itself
cancelled.
Take a thunk instead, so the pre-abort check happens before any daemon work
is started. Track whether the spawn actually began, and say so: "cancelled
before it started, no sub-session was created" is a different fact from
"a sub-session may already have been created and is not cancelled".
Regression test asserts the spawner is never called for a pre-aborted
signal; it fails against the eager-argument form.
* fix(serve): require callerSessionId and stop misreporting an early stream close
Two findings from review.
`awaitFirstTurn`'s `'incomplete'` stopReason was unreachable. The cleanup
`finally` calls `ac.abort()` unconditionally to tear the subscription down,
so by the time the stopReason ternary read `ac.signal.aborted` it was always
true. An event stream that closed before the turn finished (bridge teardown,
WS drop) was reported as a 5-minute wall-clock `'timeout'` — indistinguishable
from a real one. Track the timer firing in its own flag.
`callerSessionId` was validated only when present. Omitting it handed the
launcher `undefined`, which minted an `anon:<uuid>` bucket — a fresh
concurrency bucket per call, so no cap — and skipped the depth-1 nesting gate
(`info.callerSessionId !== undefined && …`). Authenticating the id closed
forgery but not omission. It is now required at the bridge boundary, and
required in `CreateSubSessionInfo`, so the launcher's anonymous fallback and
the gate's presence check are both gone. Every real caller has a session id —
the tool only ever runs inside a session's turn.
* fix(serve): surface dropped fires and drain timeouts; bound sub-sessions per workspace
Three findings from review.
A dropped `isolated` scheduled fire left no trace. `debugLogger.warn` writes
nothing unless a debug log session is active, and the scheduler persists the
fire as a run before dispatch — so a nightly task could fail forever while its
history claimed it ran. It now also writes to stderr, which the daemon forwards
from the child.
A sent-mode drain that hit its 30-minute ceiling was equally silent: the catch
saw `drainAc.signal.aborted` and skipped logging, the `finally` freed the
concurrency slot, and the sub-session — which the abort does not cancel — kept
burning a bridge session and model quota. The timer now records its own firing
(the controller cannot: `finally` aborts it on every exit path) and the timeout
is written to stderr. The drain ceiling is injectable for tests, mirroring
`firstTurnTimeoutMs`.
The per-caller concurrency cap trusts `callerSessionId`, and the bridge can only
authenticate that id as "a session on this channel". Every session of a
workspace shares one child process, so nothing at the transport can prove which
of them issued the call — and a per-session secret would be readable by the
whole process anyway. Rather than pretend otherwise, add a workspace-wide
ceiling on concurrent sub-sessions that holds no matter which bucket a launch is
charged to.
* fix(ci): detect silent triage failures with empty-response check
The qwen-triage workflow relied on qwen-code-action to surface failures,
but when the CLI exited 0 with empty output the step reported success
with no triage comments posted. Add a post-step that checks the action's
summary output and fails the job if it is empty, making silent failures
visible in the Actions log.
Defense-in-depth for QwenLM/qwen-code#6553 (primary fix in
qwen-code-action).
* ci: bump qwen-code-action pin to 6d08e91
Picks up the stderr visibility fix (QwenLM/qwen-code-action#12) that
always emits stderr to the step log and warns on empty responses.
Bumps all 5 workflows pinned to the action.
* fix(ci): pass triage summary through env
* feat(core): render PDF pages to images when text overflows or fails
Replace the PDF text-only 12000-token dead-end with a bounded page->image
fallback for vision-capable models, mirroring claude-code's approach.
- pdf.ts: add renderPDFPagesToImages / isPdftoppmAvailable (pdftoppm -jpeg
-scale-to), with timeout, error mapping, and a total-bytes cap.
- fileUtils.ts: text-first, then four ordered fallbacks on overflow/failure:
(1) render to the vision main model (explicit read, <=20 pages),
(2) render <=4 pages to the vision bridge (text-only model, scanned @-PDF),
(3) reference (no-pages @-attach), (4) text too-large guidance / error.
Widen ProcessedFileReadResult.llmContent to PartListUnion.
- read-file.ts / readManyFiles.ts / pathReader.ts: handle the Part[] payload;
pathReader now references large @-PDFs, aligning the two @ paths.
WIP: tests not yet migrated.
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* test(core): cover PDF page rendering and vision-bridge fallbacks
- pdf.test.ts: renderPDFPagesToImages (success/sort, page range, Infinity
last page, unavailable, password, corrupt, empty output, byte-cap).
- fileUtils.test.ts: mock renderPDFPagesToImages and assert vision-model
page/whole-doc/scanned rendering, >20-page guidance, truncation notes,
renderer-unavailable fallback, and text-only bridge rendering (scanned @
PDF -> <=4 pages, page-count note, text-first reference, no-flag error).
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* fix(core): never drop PDF pages silently when page count is unknown
Audit follow-up. Both image-render fallbacks could omit pages without a
note when pdfinfo is unavailable (page count null):
- vision no-pages render: when the size heuristic underestimates and the
render fills the per-read page ceiling, add a note (previously only the
byte-cap path was flagged).
- vision-bridge render: when the page count is unknown and the render hits
the image cap, flag it (previously required a known count). Soften the
note wording to not over-promise a later-range read on the @ path.
Adds regression tests for both unknown-page-count paths.
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* Initial plan
* fix(ci): add retry logic to VSCode IDE Companion publish steps
The publish step failed due to a request timeout when publishing the
universal VSIX to the VS Code Marketplace. Add retry logic (up to 3
attempts with 15s delay) to both the Microsoft Marketplace and OpenVSX
publish steps to handle transient network failures gracefully.
Closes#6550
* fix(ci): make OpenVSX publish retries idempotent
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: yiliang114 <effortyiliang@gmail.com>
* feat(web-shell): polish stats table layout and todo panel UI
- Use CSS grid for model usage table with fixed column widths
- Add loading spinner for in_progress todo items
- Add strikethrough for completed todo items
- Introduce nested variant for PivotRow to show thoughts as output sub-item
- Clarify i18n labels: stats.prompt -> Input Tokens, stats.output -> Output Tokens
* fix(web-shell): address review suggestions for stats table and todo panel
- Add prefers-reduced-motion media query for todo spinner (accessibility)
- Right-align numeric columns in model usage table for magnitude comparison
- Consolidate duplicate i18n keys (stats.prompt/output → stats.inputTokens/outputTokens)
* fix(web-shell): address stats review feedback
---------
Co-authored-by: ytahdn <ytahdn@gmail.com>
Co-authored-by: 易良 <1204183885@qq.com>
cdp-mcp-command.ts read process.env directly — via a `= process.env` default on resolveCdpMcpCommand and a direct read in isBrowserAutomationMcpAvailable — which trips the serve process.env guard test (process-env-guard.test.ts) and fails CI on main.
Thread env through both helpers instead: they now take env explicitly, supplied by the already-allowlisted boundary callers (acp-http, run-qwen-serve, serve-features). Behavior is unchanged.
Two inline mock clients still stubbed refreshStartupContextReminder after it was removed from tool-search.ts. makeConfigWithRegistry() was cleaned up in the original PR but these two were missed.
Co-authored-by: Aleks-0 <aleks-0@users.noreply.github.com>
downloadFromGitHubRelease can write a partial archive (or extracted files)
into tempDir before failing - e.g. a repo whose latest GitHub release is a
source tarball that isn't a valid extension archive. The catch block then
reused that dirty tempDir for cloneFromGit, where `git clone <url> ./` fails
with "destination path '.' already exists and is not an empty directory".
On Windows this surfaces as a hard install failure for any extension repo
that has a GitHub release but isn't structured as a release-asset extension
(reproduced with https://github.com/Imbad0202/academic-research-skills).
Recreate a clean tempDir (rm + mkdir) before the fallback clone so the
git clone always runs on an empty directory.
Fixes#6334
estimateTextTokens scanned every string char-by-char via charCodeAt to
classify ASCII vs non-ASCII code units. For pure-ASCII text (code,
English prose - the common case) a single regex scan using V8's
optimized string search replaces the JS loop, and the mixed-text path
now counts only non-ASCII units, deriving the ASCII count from the
length. The token formula is unchanged, so results are byte-identical
for every input; verified exhaustively over all 65536 single code units
plus 20k randomized mixed strings against the previous implementation.
Median of 6 solo benchmark runs over a deterministic mixed fixture set:
51.9ms -> 32.2ms (-38%, 1.61x).
* fix(core): configurable vision bridge timeout + retry with fresh budget
The vision bridge capped image transcription at a hardcoded 30s. On a
slow or proxied vision endpoint one latency spike permanently lost the
image: the retry inside the side query shared the same abort signal, so
a second attempt inherited whatever seconds were left of the first
attempt's budget.
Add a visionBridgeTimeoutMs setting (per attempt; unset keeps 30s,
non-positive values are ignored) and retry a timed-out attempt once at
the bridge level with a freshly created timeout signal. Non-timeout
failures still fail immediately, and user cancellation is still
reported as skipped.
Fixes#6524
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(core): harden visionBridgeTimeoutMs against invalid timer values
Maintainer E2E review found that fractional or out-of-range values such as 30000.5 and 4294967296 could pass the old number-typed config path and Config's Number.isFinite && > 0 guard. Node rejects fractional AbortSignal.timeout values with RangeError and can degrade oversized timer values to a 1ms timeout, which made image turns fail before any model request.
Tighten the Config guard to positive integers within the supported 32-bit timer ceiling, make visionBridgeTimeoutMs a bounded integer setting so /config and the generated JSON schema reject bad values up front, and move AbortSignal.timeout/any creation inside the bridge try block so any future bad value becomes a safe failure result instead of an escaped rejection. Also mark the setting requiresRestart because it is read once in the Config constructor.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Audit findings against the current codebase:
- model-providers.md, auth.md: the documented modelProviders shape used
the reverted `{ protocol, models }` wrapper. The canonical shape is a
bare `ModelConfig[]` array per provider id (a wrapped entry in a
migrated settings file is silently skipped). Update all examples and
prose, document the separate top-level `providerProtocol` map for
custom provider ids, and correct the unknown-key behavior.
- settings.md: correct the default for
`model.chatCompression.screenshotTriggerThreshold` (20, not 50).
- commands.md: add the missing `/reload-plugins` command and note that
`/dream` and `/forget` are registered only when managed auto-memory
is available.
- Add a Computer Use feature page (on-by-default desktop automation via
the cua-driver native driver) and wire it into the features nav and
the qc-helper doc index.
Co-authored-by: Claude <noreply@anthropic.com>
* feat(memory): make background memory agent timeouts configurable
Adds a memory.agentTimeoutMinutes setting that overrides the hardcoded
max runtime of the four background memory agents (extraction, dream,
remember, skill review). Unset keeps each agent's built-in default
(2-5 minutes); 0 disables the time limit entirely.
Local LLM setups load large extraction prompts far slower than hosted
models, so the fixed 2-minute extractor budget times out before the
context even finishes loading — and each retry carries a longer
conversation, making the next timeout more likely.
Fixes#6308
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* fix(memory): address review — wire agentTimeoutMinutes to skill review, clamp negatives, add tests
The auto-skill scheduling path always passed an explicit timeoutMs, so
the new setting never reached the skill review agent; drop the redundant
pass-through so the planner's config fallback applies. Clamp negative
settings values at the Config constructor (schema validation only runs
on interactive edit paths). Add positive override tests for the dream,
remember, and skill review planners, and reduce the settings.md diff to
the single new table row.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test(memory): cover negative-clamp and remember default-timeout paths
Review follow-up: assert the Config constructor treats a negative
memory.agentTimeoutMinutes as unset, and that the remember planner keeps
its built-in 5-minute default when nothing is configured.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
In compareRankedCommandMatches, recentScore was evaluated before nameVsAlias in the sort chain, causing recently-used alias matches to shadow name matches at the same matchStrength level.
The fix swaps the order so nameVsAlias is checked before recentScore, ensuring that a command matched by its primary name always ranks above an alias match, with recency acting as a tie-breaker only within the same match-type bucket.
Adds a regression test that gives an alias match a recentScore and verifies the name match still ranks first.
Signed-off-by: Alex <alex.tech.lab@outlook.com>
* fix(session): bridge broken parentUuid chains instead of truncating history
reconstructHistory walked parentUuid from the newest leaf and stopped at the first missing ancestor, silently dropping every earlier record. A session file with a broken chain (a partial write, or a lost middle segment) therefore lost all history before the break on resume — in both the terminal /resume and the web-shell/ACP replay, which both go through sessionService.loadSession.
Add a shared hardened chain walk (buildOrderedUuidChain) that, on a missing parent, bridges onto the newest still-present earlier connected component (union-find; position-based). It treats /rewind gap children as a barrier and matches the tail's sidechain-ness, so it never resurrects abandoned rewind branches or crosses the main/subagent boundary. sessionService and background-agent-resume now share it.
loadSession returns historyGaps metadata; the terminal /resume and ACP replay render a localized (i18n) visible divider so the recovered halves are not read as contiguous. The bridged child's parentUuid is rewritten (on the aggregated copy) to the bridged record so rebuildTurnBoundaries/rewind re-root correctly.
Read-side only; write-side durability is a separate follow-up.
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* qwen: fix CI failure on PR #6502
* fix(session): use non-recovered copy for history gaps with no bridged island
When a missing-parent gap has no earlier island to bridge onto (bridgedToUuid is null), the divider is the first visible item — the previous copy still said "recovered earlier history is shown above" with nothing above it. Emit a distinct notice for the null-bridge case (both terminal /resume and ACP replay go through formatHistoryGapNotice).
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* fix(i18n): add zh-TW translation for the non-recovered history-gap notice
zh-TW is a strict-parity locale, so the new null-bridge notice key must be translated there too (pre-empts a CI strict-parity failure).
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* fix(session): address history-gap review nits (accuracy, lazy maps, docs, tests)
- conversation-chain: gap duration now uses the target island's last-occurrence timestamp; a uuid can span several streamed records, and the first occurrence overstated the gap.
- conversation-chain: build posByUuid/lastByUuid lazily on the first gap (healthy sessions skip them); early-return for a caller-supplied leafUuid not backed by any record.
- resumeHistoryUtils: reorder createHistoryGapItem so the convertToHistoryItems JSDoc documents its own function again.
- HistoryReplayer: add tests covering the gap-notice replay path (notice emitted before the gap child; none when there are no gaps).
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* fix(acp): thread historyGaps through the qwen/session/loadUpdates replay path
collectHistoryReplayUpdates now accepts gaps from both callers; the loadUpdates ACP surface passed only records, so a bridged (recovered) history was rendered contiguous there with no gap divider. Adds a loadUpdates test asserting the gaps reach the replayer.
🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)
* fix(session): detect-and-mark broken history chains instead of stitching
Read-side, a record whose parentUuid is physically missing is indistinguishable from a lost /rewind marker — where the "earlier" turns are ones the user deliberately discarded. Speculatively stitching the nearest earlier island back on (the previous approach) could therefore resurrect deleted content (wenshao's [Critical]). This mirrors claude-code, which never guesses: it only reconnects across a gap when durable metadata (snip removedUuids, compact re-root) proves it safe, and otherwise truncates.
Replace the connected-component bridging with detect-only: on a missing parent the walk stops (as it always did) and records a HistoryGap, so the terminal /resume and ACP replay surfaces show a visible "earlier history was lost and could not be recovered" marker instead of silently truncating. No earlier records are reconstructed. Renames the option bridgeGaps -> detectGaps, drops the bridgedToUuid/approxLostMs fields and the now-unused "recovered above" i18n copy, and adds a regression test where the rewind marker is missing and the discarded branch must not be restored.
True recovery (keeping the earlier island) requires durable write-side metadata and is left as a follow-up.
* refactor(session): correct stale gap comments and dedup gap indexing
The detect-only rewrite (13c613c9) left doc comments that still described
the removed stitching path — claiming the earlier history was "bridged" or
"stitched back on". Reword them to match the actual behavior: the break is
detected and marked, the lost segment is not recovered.
Also extract the duplicated gap-by-child map construction (identical in both
HistoryReplayer.replay and resumeHistoryUtils.convertToHistoryItems) into a
shared indexGapsByChild helper alongside formatHistoryGapNotice — the one
still-applicable item from the review suggestion summary.
Comments + one small refactor only; no behavior change.
* fix(session): reset pending @-command state at a history-gap divider
Belt-and-braces for the resume renderer: when convertToHistoryItems emits a
history-gap divider it already flushes the pending tool group; also clear
pendingAtCommands so an unconsumed pre-gap at_command can never be shift()-
paired with the post-gap user turn (which would attach @file reads to a turn
the user never wrote them on).
In the current detect-only design reconstructHistory truncates to the tail
island — the gap child is always the first replayed record, so the buffer is
already empty at the divider and this cannot trigger. The reset keeps the
invariant if that ever changes. Adds a regression test at the
convertToHistoryItems boundary.
* fix(session): don't detect history gaps on the background-agent resume path
Addresses wenshao's review: this non-interactive transcript recovery has no
surface to render a gap marker on (unlike interactive /resume via sessionService
and the ACP replay via HistoryReplayer), so passing detectGaps: true only to
emit a debugLogger.warn and then drop the gaps was an inconsistent half-measure
("half-detection is worse than no detection"). Turn detection off here — the
walk truncates at a broken parent link either way, matching this path's
historical behavior. Gap surfacing stays exactly on the two paths that have a
UI for it.
---------
Co-authored-by: qwen-code-dev-bot <qwen-code-dev-bot@users.noreply.github.com>
Split-view panes showed English descriptions for slash commands while
the main view showed Chinese. Two root causes:
1. ChatPane never merged getLocalCommands(t) into the command list,
so ~33 built-in commands (help, model, clear, etc.) lacked i18n
descriptions.
2. localizeBuiltinDescriptions required source === 'builtin-command',
but the daemon omits _meta.source in some SSE event paths
(available_commands_update), causing built-in commands to skip
translation unpredictably across sessions.
3. Skill localization depended on connection.skills, which can be
empty when SSE events deliver commands without availableSkills.
Fix: make the entire localization pipeline name-based and
session-independent — merge local commands, relax the source guard
to also translate when source is missing, and use skillDescriptionKey
directly instead of connection.skills for skill tagging.
Also adds missing autofix skill translation (EN + ZH).
/new (alias of /clear) silently did nothing when typed right after
cancelling a request, for two stacked reasons:
- hasBlockingBackgroundWork() gated on the registry's
hasUnfinalizedTasks(), which counts cancelled-but-not-yet-finalized
entries. That clause exists for the headless holdback loop (every
task_started must pair with a task_notification), but /clear and
session resume abort-and-reset the registry right after the gate —
suppressing that very notification — so blocking on it only made the
switch fail in the window between cancel and finalizeCancelled().
The gate now keys off a new BackgroundTaskRegistry.hasRunningTasks(),
which counts only entries still actually executing; the headless
holdback keeps using hasUnfinalizedTasks() unchanged.
- When genuinely blocked, interactive mode showed only a transient
debug line while non-interactive returned a proper error. Interactive
now returns the same visible error message, so a blocked /clear no
longer looks like a no-op.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
getAutoMemoryRoot() resolved linked worktrees back to the canonical
repository root, so every worktree of a repo shared one project memory.
Focused worktree sessions polluted the shared MEMORY.md index with
unrelated entries, and chats/, workflows/, and team memory were already
per-worktree — project memory was the only shared exception.
Anchor project memory at the nearest git root (same resolution team
memory already uses) so each worktree gets its own memory directory.
The main checkout resolves to the same path as before, so existing
memory is unaffected.
Fixes#6449
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* fix(cli): fixed-width elapsed time below one minute to stop status-line jitter
The loading indicator ticks at 0.5s resolution, so the time string
alternated between forms like "1s" and "1.5s" every tick. The changing
width shifted everything after it on the status line twice a second,
making it distracting and hard to read. Render one fixed decimal below
the minute mark ("1.0s", "1.5s"); the >=1m path is unchanged.
Fixes#6402
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* test(cli): cover the 0s timer-start frame in the fixed-width time test
Review follow-up: useTimer initializes and resets at exactly 0, so
assert the "(0.0s · esc to cancel)" frame too.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* feat(core): add working_dir to the Agent tool for pinning subagents to an existing worktree
Add an opt-in working_dir parameter to the Agent (sub-agent) tool that pins a sub-agent's entire working-directory context to an existing, caller-owned git worktree of the current repository. Unlike isolation: 'worktree', the harness neither provisions nor removes the directory — the caller owns its lifecycle — so a sub-agent can be aimed at a worktree that some earlier step already prepared.
Every "where am I?" surface on the sub-agent's config (target dir, cwd, project root, file discovery, workspace context) is rebound to the worktree, reusing the existing worktree-isolation rebind, so the sub-agent's file and shell tools operate inside that directory and cannot leak into the parent project tree. The path is validated as a worktree registered against the current repository before use, and working_dir is mutually exclusive with isolation.
Wire the /review skill to pass working_dir to every review agent for same-repo PR reviews, so the PR worktree isolation is enforced deterministically at the agent boundary instead of by prompt convention. This makes reviewing multiple PRs concurrently safe.
* fix(core): harden working_dir validation from review feedback
- Reject a working_dir that resolves to the repository's own main working tree. getRegisteredWorktreeBranch accepts the primary checkout too, so `working_dir: "."` or the repo root would otherwise pin a sub-agent to the user's main tree and silently defeat the isolation. A linked worktree has a `.git` file; the main tree has a `.git` directory — require the former.
- Reject working_dir combined with run_in_background. The caller owns the worktree lifecycle and could remove it while a detached agent is still running in it (ENOENT on its own cwd); the isolation: 'worktree' path does not have this problem because the tool owns and reaps the worktree.
- Add an isGitRepository() preflight so a non-repo parent reports the real cause instead of a misleading "not a registered git worktree" error.
- Add tests: repo-relative working_dir resolution (the /review production form), main-working-tree rejection, and the run_in_background guard.
* fix(core): make main-worktree detection robust and tighten working_dir validation
Address a second review round on the Agent tool working_dir parameter.
- Replace the ".git is a file ⟹ linked worktree" heuristic with a reliable check: a linked worktree's per-worktree git dir (--absolute-git-dir) differs from the common git dir (--git-common-dir), while a main working tree's are identical. The heuristic was wrong for a main tree whose .git is a file (git clone --separate-git-dir, submodules), which would have let the main checkout pass the isolation guard. Extracted as GitWorktreeService.isLinkedWorktree(); the fs.stat probe (and its all-errors catch) is gone.
- Reject whitespace-only working_dir (trim before the empty check), matching the worktree-name validation.
- Tests: assert the sub-agent's getCwd()/getWorkingDir() are rebound (not just project root / target dir); cover the monorepo-subdirectory re-anchor branch (getTargetDir() below the repo root); and add real-git coverage for isLinkedWorktree, including the separate-git-dir main tree.
* fix(core): reject working_dir for named teammates
A named teammate spawns via TeamManager with cwd = getCwd() and returns before the working_dir rebind is reached, so the pin was silently ignored and the teammate ran in the parent working tree — a false sense of isolation. Reject working_dir at the point a teammate would actually spawn (name + active TeamManager + top-level session), leaving the name-without-active-team fallback (which spawns a normal sub-agent, where working_dir does apply) untouched. Add a test.
* docs(core): describe working_dir as a cwd pin, not a sandbox
The working_dir parameter description, the interface doc, and the /review skill said the sub-agent "cannot touch"/"cannot leak into" the parent tree. That overstates it: file and shell tools still accept absolute paths, so the isolation is a working-directory pin (cwd-relative operations and search tools stay inside the worktree), not a filesystem sandbox — the same limitation as isolation: 'worktree'. Reword all three to state this accurately.
* test(core): cover working_dir non-git and fail-closed paths; clarify main-tree error
- Add an execute-level test for the working_dir isGitRepository() preflight (non-git parent directory -> "not a git repository").
- Add a test for isLinkedWorktree's fail-closed catch (a non-git path returns false).
- Reword the main-tree rejection error to name both possible causes ("is the main working tree, or its git metadata could not be read"), since isLinkedWorktree also fails closed on a git error rather than only on the main tree.
* fix(core): canonicalize path in isLinkedWorktree; test relative working_dir in a monorepo
- isLinkedWorktree now realpaths the worktree path before comparing --absolute-git-dir (which git returns canonicalized) against --git-common-dir. Without this, a symlinked input (macOS /var → /private/var, os.tmpdir()) made the two diverge for the main working tree and misreported it as linked, letting the main checkout pass the isolation gate.
- Add a test proving a repo-relative working_dir resolves against the subdirectory cwd where fetch-pr actually creates the worktree (git resolves relative worktree paths against cwd), not the repo root — the production monorepo form.
* fix(core): close working_dir gaps from review — classifier, background config, review-workflow coverage
- Include working_dir in toAutoClassifierInput so AUTO-mode permission classification can see the child is rebound to another worktree; a launch could otherwise look benign from subagent_type + prompt alone.
- Reject working_dir when the effective background decision is true — not only for the explicit run_in_background param (already rejected in validateToolParams) but also for a subagent config with background: true, which validateToolParams cannot see. Guard on the resolved shouldRunInBackground so a nested call that downgrades to the foreground is not over-rejected.
- /review skill: extend the working_dir mandate to the Step 4 verification agent and Step 5 reverse-audit agents, which also read files and re-check the diff and would otherwise run against the user's main checkout.
- Add tests for all three.
* test(core): symlink + preserved-suffix coverage; soften working_dir grep/glob wording
- isLinkedWorktree: add a test that passes a symlinked path (the macOS /var → /private/var case, reproduced with an explicit symlink) so the realpath canonicalization is actually exercised.
- Assert a caller-owned worktree run does not emit a spurious "[worktree preserved]" suffix, guarding the externallyManaged cleanup skip against regression.
- Soften the working_dir description: grep/glob default to the worktree as their root but can still be pointed outside via an explicit path, so drop the "enforce it as the workspace boundary" claim.
* fix(core): validate working_dir against the authoritative git worktree registry
- Replace the --git-dir vs --git-common-dir "is it a linked worktree" heuristic with an authoritative check against `git worktree list`. The heuristic could be fooled by a hand-crafted directory carrying a .git file copied from a real linked worktree (structurally a linked worktree, yet not registered); `git worktree list` reads .git/worktrees/<name>/gitdir and excludes such a fake. Renamed isLinkedWorktree -> isRegisteredLinkedWorktree.
- Tests: reject a fake worktree (copied .git file); match a registered worktree through a symlinked input path; and a nested-context test confirming a background: true subagent that downgrades to foreground is NOT rejected by the working_dir background guard (guards the shouldRunInBackground keying against regression).
* fix(core): fix flaky nested working_dir test; harden worktree-registry parsing
- The nested background:true test relied on the default '/test/project' cwd, which does not exist on CI, so simple-git threw at construction instead of the test reaching the isGitRepository() path (this is the red CI on the prior commit). Point it at a real, non-git temp directory instead.
- isRegisteredLinkedWorktree: parse `git worktree list --porcelain -z` (NUL-terminated) so a worktree path that itself contains a newline cannot inject a fake `worktree <path>` entry into a newline-split parse; and reject the primary working tree by canonical path so a linked record whose on-disk path is a symlink onto the main checkout cannot smuggle it through.
* fix(core): fall back when `worktree list -z` is unsupported; add newline-injection regression test
- `git worktree list -z` requires Git >= 2.36. On older git the call threw and the surrounding catch rejected every valid caller-owned worktree with a generic "not a registered linked worktree" error. Fall back to the newline-separated porcelain form instead of hard-failing: that parse is only vulnerable to a worktree path that itself contains a newline, which is a far narrower exposure than rejecting every worktree.
- Add a real-git test that creates a worktree whose path embeds "\nworktree <other>" and asserts the injected path is not accepted while the real (awkwardly named) worktree still validates. Confirmed the test fails when the parser reverts to newline splitting, so it genuinely guards the -z parse.
* fix(core): accept detached-HEAD worktrees for working_dir; cover the failure-path cleanup guard
- getRegisteredWorktreeBranch returns null for a detached-HEAD worktree (its branch reads as 'HEAD'), so a legitimate `git worktree add --detach` target was rejected with a factually wrong "not a registered git worktree" error and the authoritative registry check never ran. Make isRegisteredLinkedWorktree the sole gate and read the branch best-effort: branch is unused for caller-owned worktrees anyway, since cleanup short-circuits on externallyManaged.
- Add a test asserting a detached worktree is accepted and the sub-agent is rebound onto it.
- Add a failure-path test: when the sub-agent throws, the finally / outer-catch path runs cleanupWorktreeIsolation() and the externallyManaged guard must leave the caller's worktree intact. Confirmed both new tests fail without their respective fixes, so they genuinely guard the behaviour.
* fix(core): verify a worktree's registry pointer instead of parsing `git worktree list`
Parsing the registry list forced a bad trade: `--porcelain` alone is newline-delimited, so a worktree path containing a newline can inject a bogus entry, while `-z` needs Git >= 2.36 and would reject every worktree on older git. Verify the single path in question instead:
1. `--git-dir` equal to `--git-common-dir` means the primary working tree, which is rejected.
2. The common dir must be this repository's, or the path belongs to another repo.
3. `<gitDir>/gitdir` records the worktree that registry entry belongs to; it must resolve back to the probed path.
Step 3 is what makes it authoritative: a directory holding a `.git` file copied from a real linked worktree does report a per-worktree git dir, but that entry's pointer names the real worktree, not the copy. No list is parsed, so the newline-injection class of bug is gone on every git version and no `-z` (Git >= 2.36) is required. Detached worktrees, symlinked inputs, separate-git-dir main trees, and other repositories' worktrees are all still handled correctly.
Also bump the real-git integration suite's vitest timeouts to 30s, matching the sibling hooks/symlinks suites, to reduce CI flakiness.
* fix(core): contain working_dir to the repo, tailor the pinned-worktree notice, keep the newline test off Windows
- Containment: a registered worktree can live anywhere on disk, and pinning rebinds the child's WorkspaceContext wholesale, so a model-supplied path could silently move the file tools' boundary outside the repository. Require the resolved path to sit inside the repo (canonical comparison, so a symlink cannot straddle the boundary) and say so in the parameter description. isolation: 'worktree' already had this implicitly.
- Prompt: a caller-owned worktree is the code the agent was asked to work on, not a provisioned copy of the parent's tree. Give it a narrow notice instead of the isolation notice, whose "translate the parent's paths" and "re-read what the parent changed" guidance contradicts the caller's own instructions (/review tells its agents not to cd or prefix absolute paths).
- Skip the newline-injection test on Windows: a path component containing a newline is not representable there (the embedded drive letter makes it invalid), so `git worktree add` errors and the windows test job would fail. The injection cannot occur on Win32 either.
- Add a regression test for a stale registry record whose directory was recreated as a plain directory: `git worktree list` keeps such records for months, and `git rev-parse --show-toplevel` inside one resolves to the MAIN checkout. Probing the path itself rejects it.
* docs(core): correct the working_dir helper's doc comment
The comment still credited getRegisteredWorktreeBranch with enforcing "must be a registered worktree". That gate is now isRegisteredLinkedWorktree (plus the in-repository containment check); getRegisteredWorktreeBranch is consulted only for a best-effort branch label and is deliberately not a gate, since it returns null for a legitimate detached-HEAD worktree.
* fix(core): read the worktree registry from the repo, not the candidate directory
isRegisteredLinkedWorktree derived everything from files inside the directory being validated: `<target>/.git` names a git dir, whose `commondir` and `gitdir` were then trusted. All three are candidate-controlled, so a *fabricated* chain (not merely a `.git` copied from a real worktree) could name itself and be accepted even though git's registry holds no entry for it. The docstring's claim that it consulted "git's own registry entry" was therefore wrong.
Read the registry from the repository instead: some `<commonDir>/worktrees/<name>/gitdir` must name the path. Keep a liveness probe inside the path as well: its own `--git-dir` must be that same entry. The two are complementary. The registry answers "is this path registered?" and so rejects a fabricated chain, a copied `.git` file (the entry names the original), another repository's worktree, and the primary working tree, which has no entry of its own. Only the probe answers "is it a worktree right now?" and so rejects a stale `prunable` record whose directory was deleted and recreated as an ordinary directory.
Add a fabricated-chain regression test, and confirm each of the two tests fails when its corresponding half of the check is removed.
* fix(scripts): handle missing NPM dist-tags gracefully in release versioning (#6476)
getAndVerifyTags now returns null instead of throwing when no baseline
version exists on NPM. getPreviewVersion and getStableVersion fall back
to the package.json base version, matching the pattern already used by
getNightlyVersion. This prevents the release workflow from failing when
no nightly or preview dist-tag has been published yet.
* fix(scripts): harden release versioning against transient NPM errors and missing dist-tags (#6476)
- Distinguish 404 from transient errors in getVersionFromNPM so NPM
outages halt the release instead of silently falling back
- Consult getAllVersionsFromNPM when dist-tag is missing to derive
baseline from published versions rather than returning empty
- Add console.error logging when getAndVerifyTags returns null
- Validate package.json fallback version in getStableVersion and
getPreviewVersion
- Add tests for promote-nightly/patch throw paths, true greenfield
scenario, versions-list derivation, and transient error propagation
* fix(scripts): propagate transient NPM errors in getAllVersionsFromNPM (#6476)
getAllVersionsFromNPM silently swallowed all errors including transient
network failures (ETIMEDOUT, ECONNRESET), which became load-bearing now
that the missing-dist-tag fallback depends on it. Match the same 404-only
pattern already used by getVersionFromNPM. Also fix a DRY violation in
getPreviewVersion, correct misleading test comments, and add test
coverage for the versions-list error path and latest filter branch.
* fix(scripts): tighten 404 detection and tolerate transient versions-list failures (#6476)
- Remove redundant '404' substring check; E404 is the canonical npm error code
and bare '404' could false-match unrelated errors (port 4043, E4040)
- Catch transient versions-list errors in detectRollbackAndGetBaseline when
distTagVersion is already resolved, avoiding hard-blocking a release when
rollback detection is merely a safety net
- Update and add tests for the new fallback behavior and deprecated-versions path
* fix(scripts): guard release version fallback edge cases
* test(scripts): cover greenfield versions list E404
---------
Co-authored-by: Qwen Code Autofix <qwen-code-bot@alibabacloud.com>
Co-authored-by: qwen-code[bot] <qwen-code[bot]@users.noreply.github.com>
Co-authored-by: Qwen Code Autofix <qwen-code@autofix.bot>
Co-authored-by: yiliang114 <effortyiliang@gmail.com>
* Initial plan
* fix(core): detect non-SSE HTTP 200 responses in OpenAI streaming pipeline
When a gateway/proxy intercepts a streaming request and returns HTTP 200
with a non-SSE content-type (e.g. text/html), the OpenAI SDK silently
produces zero chunks, resulting in a confusing "Model stream ended without
a finish reason" error and an empty interaction log (response: null,
error: null).
Add NonSSEResponseError that is thrown early when the response content-type
is incompatible with SSE (not text/event-stream, application/json, etc.).
The error carries diagnostic metadata: HTTP status, content-type, bounded
body prefix, and request-id header — allowing users and maintainers to
distinguish "empty model stream" from "gateway returned non-SSE page".
Uses the OpenAI SDK's withResponse() API to access the raw HTTP response
headers before consuming the stream iterator. Falls back gracefully when
withResponse() is unavailable (e.g. in mocked environments).
ClosesQwenLM/qwen-code#6465
* fix(core): replace non-null assertion with nullish coalescing in content-type check
* fix(core): address non-sse review feedback
* fix(core): expose non-sse request id alias
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: yiliang114 <effortyiliang@gmail.com>
