chore(release): v0.23.1

[qwen-code-review-bot]

Automated release PR for v0.23.1. Syncs package.json versions and CHANGELOG.md on main.

[qwen-code-dev-bot]

Automated approval for the release version bump.

[qwen-code-ci-bot]

Automated second approval for the release version bump.

[qwen-code-ci-bot]

✅ Qwen Triage finished — view run. See the stage comments in this thread for the result.

✅ Qwen Triage 已完成 —— 查看运行。结果见本线程中的各阶段评论。

[qwen-code-ci-bot]

Gate check for the v0.23.1 release PR.

This is the repo's own release automation. v0.23.1 was tagged at d9331e6f — the PR's first commit — and published 2026-09-08 15:56 UTC; this syncs that version bump and the regenerated changelog from release/v0.23.1 back into main. The body is the workflow's one-line boilerplate, the same shape as every prior release PR (#10914, #10424, #10166), so the PR-template gate doesn't apply here. No linked issues, which is expected for a release sync-back.

• Problem: observed by construction — v0.23.1 is already published while main still reads 0.23.0 everywhere and has no 0.23.1 changelog section.
• Direction: the release process delivering its standard artifact. Release is a sensitive lane, so worth saying plainly: nothing here changes release behaviour, it only writes back the numbers the release already produced.
• Size: no core source paths touched — all 25 files are release manifests (23 package.json / qwen-extension.json), CHANGELOG.md, and package-lock.json. Production logic lines: 0. The 25-file breadth is a uniform one-to-two-line sweep across the workspace, not depth; noting it for awareness, not treating it as an escalation.
• Approach: exactly two automation commits — the bump d9331e6f, which is the commit tagged v0.23.1, and the changelog sync 256fa27f (the head). Nothing else rode along on the branch.
• Risk: no high-risk path matches among the changed files; no elevated risk signals.

One thing I want on the record before the code review, because it's the only non-mechanical part of this diff: main has moved two commits ahead of the release branch (7e6a6350 sdk-typescript v0.1.9 and b9f5d15a CI fix), and the branch was cut roughly two seconds before the sdk-typescript bump landed. I checked what that does to the merge — details in Stage 2.

Moving on to code review. 🔍

中文说明

v0.23.1 release PR 的入口检查。

这是仓库自己的发布自动化：v0.23.1 已在 d9331e6f（本 PR 的第一个提交）打标签，并于 2026-09-08 15:56 UTC 发布；本 PR 把该版本提升和重新生成的 changelog 从 release/v0.23.1 同步回 main。PR 描述是工作流的一行样板文本，与之前所有 release PR（#10914、#10424、#10166）形状一致，因此 PR 模板检查在这里不适用。没有关联 issue——release 回同步本就如此。

• 问题： 由构造即成立——v0.23.1 已经发布，而 main 上仍是 0.23.0，也没有 0.23.1 的 changelog 段落。
• 方向： 发布流程产出其标准结果。release 属于敏感通道，所以明确说明：这里没有改动发布行为，只是把发布已经产生的版本号写回来。
• 规模： 完全没有触及核心源码路径——25 个文件全部是发布清单（23 个 package.json / qwen-extension.json）、CHANGELOG.md 和 package-lock.json。生产逻辑行数为 0。25 个文件的广度是整个 workspace 上每个文件一两行的一致性扫改，不是深度改动；仅作提示，不视为升级处理。
• 方案： 恰好两个自动化提交——版本提升提交 d9331e6f（即打 v0.23.1 标签的提交）和 changelog 同步提交 256fa27f（PR head）。分支上没有夹带任何其他内容。
• 风险： 变更文件中未命中任何高风险路径，无升级风险信号。

在进入代码审查之前先记录一点，因为这是本次 diff 中唯一非机械的部分：main 已比 release 分支多出两个提交（7e6a6350 sdk-typescript v0.1.9 与 b9f5d15a CI 修复），而该分支是在 sdk-typescript 版本提升落地前约两秒切出的。我已核对这对合并的影响——详见 Stage 2。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 256fa27f28d947deb3cb16d05223cb1fa00ce3f7 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Code review

I wrote my independent proposal before opening the diff: for a post-tag sync-back I'd bump every manifest on the 0.23.x train to 0.23.1 — including the sandboxImageUri config and the pinned @qwen-code/channel-base dependencies — regenerate the lockfile, prepend the generated 0.23.1 changelog section, and touch nothing else, in two commits. That is exactly what this PR is.

What I verified rather than assumed:

• Nothing was missed and nothing off-train was touched. I enumerated all 52 manifests in the head tree and read the version of every one the PR leaves alone: sdk-typescript 0.1.8, node-repl 0.1.3, mobile-mcp 0.20.1, cua-driver/typescript 0.20.4, live-host 0.0.5, desktop-shell 0.0.1, qwen-live 0.1.0, external-context/qwen-extension.json 1.0.0, plugin-example/qwen-extension.json 0.1.0, docs-site 1.0.0. All independent release lanes, none stranded at 0.23.0.
• The two things people forget are both here: config.sandboxImageUri → ghcr.io/qwenlm/qwen-code:0.23.1 in the root and CLI manifests, and the nine @qwen-code/channel-base dependency pins.
• CHANGELOG is a pure +223 addition of the generated 0.23.1 section at the top, no existing entry rewritten — consistent with the file's "do not edit by hand" header.

No critical blockers. Two observations, neither blocking, and the first one I nearly reported as a defect before checking it:

1. The lockfile diff looks far noisier than a version bump, but it nets out clean. Against the merge-base it deletes 191 lines that are not version strings: the node_modules/@vitest/browser optional-peer tree (@polka/url, mrmime, sirv, totalist, @testing-library/user-event) plus 20 "peer": true markers on the lightningcss platform binaries. #10914 carried no such churn, so this looked like a differing npm resolution riding into main. It isn't — main has independently arrived at the same state. Diffing main's current package-lock.json against the PR head's, every difference is a version string; those entries are already gone on main. So the merge introduces no lockfile drift, and the apparent churn is an artifact of diffing against a stale merge-base.

2. Merge this — don't resolve the lockfile by taking this branch's side. main's lock carries packages/sdk-typescript at 0.1.9; the PR head's carries 0.1.8, because the branch was cut about two seconds before #11393 landed. The PR's own diff never touches that line, so a normal three-way merge keeps main's 0.1.9. The exposure is only in a manual conflict resolution that takes the PR side wholesale: packages/sdk-typescript/package.json (0.1.9, also untouched here) would then disagree with a 0.1.8 lock entry, and npm ci would refuse the tree. GitHub reports MERGEABLE, and main's CI runs npm ci on the merge result, so this would surface loudly rather than silently.

I skipped the changed-files table: 23 of the 25 files carry the identical one-line version change, and a per-file map would just repeat it.

Test evidence

Unattended CI run, so per the gate rules I did not build, install, or execute anything from this branch — everything below is this PR's own CI on 256fa27f, read through the API. PR CI has now finished.

Check	Conclusion
Classify PR	success
Test (ubuntu-latest, Node 22.x)	success
Lint & Static (ubuntu-latest, Node 22.x)	success
Integration Tests (no-AK, No Sandbox)	success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	success
TUI parity snapshots (ink vs opentui)	success
OpenTUI no-flicker gate	success
Capture web-shell visuals (ubuntu-latest, Node 22.x)	success
Real daemon E2E / Java 11	success
Desktop Shell (ubuntu-22.04)	success
Desktop Shell (windows-2022)	success
Install (ubuntu-latest / macos-latest / windows-latest)	success
SDK Java matrix (ubuntu Java 11/17/21, macos Java 21, windows Java 21)	success
Test (macos-latest, Node 22.x)	skipped
Test (windows-latest, Node 22.x)	skipped
route / review-pr	cancelled (bot orchestration superseded by their concurrency groups)
triage	in progress (this run)

Totals on this commit: 28 success, 1 in progress (this triage run), 138 skipped, 2 cancelled. No failures, and zero pull_request workflow runs still pending — the two cancelled checks are bot orchestration lanes killed by cancel-in-progress, not PR CI. Reading the signal honestly rather than as "CI is green":

• The job that actually validates this diff is green. Test (ubuntu-latest, Node 22.x) is the ci.yml job that runs npm ci before the suite — so the regenerated lockfile resolves against the bumped manifests and installs cleanly, and the unit suite passes on top of it. That substantiates observation 1 directly: the lockfile is internally consistent, not merely plausibly so.
• The three green Install (...) jobs are not lockfile evidence. They belong to pnpm-worktree-smoke.yml and exercise the pnpm layout, not package-lock.json. Worth saying because they finished green long before the npm job did, and it would have been easy to cite them for something they don't cover.
• The macOS/Windows Test jobs are skipped, not failed: Classify PR succeeded and this diff is manifests + changelog + lockfile only, so it took the reduced profile that gates the npm ci steps.

Not verified: that the merged tree installs. npm ci passing on the head proves the head is self-consistent; it cannot cover the combination with main's sdk-typescript 0.1.9 lock entry, which only exists post-merge. The check that settles it is npm ci on the merge result, which main's CI runs on merge. I'm naming that instead of a sandboxed lane because there is no behavioural claim here for @qwen-code /verify or @qwen-code /tmux to settle — this diff changes version strings and generated changelog text, nothing at runtime.

中文说明

代码审查

在看 diff 之前我先写下了自己的独立方案：标签发布后的回同步，应当把 0.23.x 发布序列上的每个清单文件提升到 0.23.1（包括 sandboxImageUri 配置和固定版本的 @qwen-code/channel-base 依赖）、重新生成 lockfile、在顶部插入生成的 0.23.1 changelog 段落，此外什么都不动，共两个提交。这个 PR 正是如此。

我实际核对（而非默认）的内容：

• 没有漏改，也没有改到序列之外的东西。 我列举了 head 树中全部 52 个清单文件，并逐个读取 PR 未触碰的那些的版本号：sdk-typescript 0.1.8、node-repl 0.1.3、mobile-mcp 0.20.1、cua-driver/typescript 0.20.4、live-host 0.0.5、desktop-shell 0.0.1、qwen-live 0.1.0、external-context/qwen-extension.json 1.0.0、plugin-example/qwen-extension.json 0.1.0、docs-site 1.0.0。都是独立发布通道，没有一个滞留在 0.23.0。
• 最容易被忘记的两处都在： 根清单与 CLI 清单里的 config.sandboxImageUri 已改为 ghcr.io/qwenlm/qwen-code:0.23.1，以及 9 处 @qwen-code/channel-base 依赖固定版本。
• CHANGELOG 是纯新增 223 行，在顶部加入生成的 0.23.1 段落，没有改写任何既有条目——与该文件"请勿手工编辑"的说明一致。

无阻塞性问题。 两点观察，都不阻塞，其中第一点我在核实之前差点当成缺陷上报：

1. lockfile 的 diff 看起来远比一次版本提升要吵，但最终结果是干净的。 相对 merge-base，它删除了 191 行非版本号内容：node_modules/@vitest/browser 这棵可选 peer 依赖树（@polka/url、mrmime、sirv、totalist、@testing-library/user-event），以及 lightningcss 各平台二进制上的 20 处 "peer": true 标记。#10914 没有这类改动，所以这看起来像是另一套 npm 解析结果被带进 main。事实并非如此——main 已经独立到达了相同状态。把 main 当前的 package-lock.json 与 PR head 的做对比，每一处差异都是版本号字符串；那些条目在 main 上早已不存在。因此合并不会引入 lockfile 漂移，这些看似多余的改动只是对着一个陈旧的 merge-base 做 diff 产生的假象。

2. 请正常合并——不要在解决 lockfile 冲突时整体采用本分支一侧。 main 的 lock 中 packages/sdk-typescript 是 0.1.9，而 PR head 是 0.1.8，因为分支切出时间比 #11393 落地早约两秒。本 PR 的 diff 从未触碰该行，所以正常的三方合并会保留 main 的 0.1.9。风险只存在于手工冲突解决时整体采用 PR 一侧：那样 packages/sdk-typescript/package.json（0.1.9，本 PR 同样未触碰）就会与 0.1.8 的 lock 条目不一致，npm ci 会拒绝安装。GitHub 报告 MERGEABLE，且 main 的 CI 会在合并结果上运行 npm ci，所以这个问题会显式暴露，不会静默通过。

我没有附变更文件表格：25 个文件中有 23 个是完全相同的一行版本改动，逐文件列表只是重复。

测试证据

本次为无人值守 CI 运行，按 gate 规则我没有从该分支构建、安装或执行任何东西——以下全部是通过 API 读取的、该 PR 自身在 256fa27f 上的 CI 结果。PR CI 现已全部跑完。

该提交上的合计：28 项成功、1 项进行中（即本次 triage 运行）、138 项跳过、2 项取消，无失败，且没有任何 pull_request workflow 仍在等待——两项取消的检查是被 cancel-in-progress 终止的 bot 编排通道，不是 PR CI。诚实地解读这些信号，而不是笼统说"CI 绿了"：

• 真正能验证本次 diff 的 job 已经绿了。 Test (ubuntu-latest, Node 22.x) 是 ci.yml 中先执行 npm ci 再跑测试套件的 job——也就是说，重新生成的 lockfile 能与提升后的清单正确解析并干净安装，单元测试也在其上通过。这直接证实了第 1 点观察：lockfile 是内部自洽的，而不只是"看起来可能是"。
• 三个绿色的 Install (...) job 不构成 lockfile 证据。 它们属于 pnpm-worktree-smoke.yml，验证的是 pnpm 布局，不是 package-lock.json。之所以特别说明，是因为它们比 npm job 早很多就变绿了，很容易被拿来当作它们并不覆盖的东西的证据。
• macOS/Windows 的 Test job 是跳过，不是失败： Classify PR 已成功，而本次 diff 只涉及清单、changelog 和 lockfile，因此走了会限制 npm ci 步骤的精简档。

未验证：合并后的树能否正常安装。head 上 npm ci 通过只证明 head 自身自洽，无法覆盖与 main 的 sdk-typescript 0.1.9 lock 条目组合后的情况，因为后者只在合并后才存在。能确认它的是合并结果上的 npm ci，而 main 的 CI 在合并时会运行。我指名这项检查而不是沙箱通道，是因为这里没有可供 @qwen-code /verify 或 @qwen-code /tmux 验证的行为性主张——本次 diff 只改动版本号字符串和生成的 changelog 文本，不涉及任何运行时行为。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 256fa27f28d947deb3cb16d05223cb1fa00ce3f7 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Confidence: 4/5 — a clean mechanical release sync-back with PR CI fully green on the reviewed commit; the only non-trivial thing in it is a lockfile that turned out to be identical to main's apart from version strings.

Going back to my independent proposal: what I said I'd write is what's here, and I couldn't find a simpler version of it. A release sync-back has exactly one correct shape — move every manifest on the train, regenerate the lock, prepend the generated changelog, touch nothing else — and this matches it. The completeness question was the only one worth real effort, so I answered it by enumerating all 52 manifests in the head tree rather than trusting that the automation got them all: nothing on the 0.23.x train was left behind, and the ten manifests it deliberately skips are all on their own version lanes (0.1.8, 0.1.3, 0.20.1, 0.20.4, 0.0.5, 0.0.1, 0.1.0, 1.0.0), not stragglers.

I also want to flag a near-miss in my own review, because it's the reason this is 4/5 and not 5/5 on evidence rather than on the diff. The lockfile deletes 191 lines that aren't version bumps, and #10914 had no such churn — that reads exactly like a differing npm resolution being pushed into main. It took diffing main's lock against the head's to establish that main already reached the same state independently, so the churn is an artifact of the stale merge-base and the merge introduces no drift. Test (ubuntu-latest, Node 22.x) then went green, and since that job runs npm ci before the suite, the regenerated lockfile is confirmed to resolve against the bumped manifests rather than merely looking plausible. The diff was clean; my first read of it wasn't, and the difference only showed up on the second check.

CI is done: every pull_request workflow run on 256fa27f has completed, 28 checks green, none failed. The two cancelled checks are bot orchestration lanes killed by their own concurrency groups, and the one still running is this triage run.

Where the PR stands, and why I'm not adding a review:

• This bot's APPROVED review already stands on 256fa27f — posted by the release lane at 16:33:14Z ("Automated second approval for the release version bump."), one second after qwen-code-dev-bot's. Triage approves once per commit, and only its own approval counts as already cast; that slot is filled, so with CI green there is nothing left for me to add and a second review from the same account would be noise. For the same reason there is no deferred approval to schedule: nothing is waiting on CI to become approvable, because the approval already exists on this exact commit.
• The human approval has since landed. @yiliang114 approved at 17:01:10Z, and reviewDecision is now APPROVED — earlier in this run it was still REVIEW_REQUIRED on the strength of the two bot approvals alone, which is the same shape chore(release): v0.23.0 #10914 needed a human to break. So the requirement is satisfied: nothing is waiting on review, and nothing is waiting on CI.
• Mergeability read UNKNOWN at the time of writing (mergeable and mergeStateStatus both), which is GitHub recomputing after the new review rather than a reported conflict — every read before it reported MERGEABLE. Worth a glance before landing, but I'm not going to call it a blocker on a transient value.

So: nothing to fix in the diff, nothing outstanding on CI or review. One merge-hygiene note for whoever lands it — merge normally, and if the lockfile ever needs a manual resolution, don't take this branch's side wholesale or sdk-typescript's lock entry drops from 0.1.9 to 0.1.8 and npm ci will reject the tree.

中文说明

置信度：4/5 —— 一次干净的机械式发布回同步，所审提交上的 PR CI 已全绿；其中唯一不平庸之处是 lockfile，而它最终被证实除版本号字符串外与 main 完全一致。

回到我的独立方案：我说过会怎么写，这个 PR 就是怎么写，我也找不出更简单的版本。发布回同步只有一种正确形态——提升序列上的每个清单、重新生成 lock、在顶部插入生成的 changelog、其余什么都不动——本 PR 与之吻合。完整性是唯一值得真正下功夫的问题，所以我通过列举 head 树中全部 52 个清单文件来回答它，而不是默认自动化全都改到了：0.23.x 序列上没有遗漏，而它有意跳过的十个清单都在各自的版本通道上（0.1.8、0.1.3、0.20.1、0.20.4、0.0.5、0.0.1、0.1.0、1.0.0），不是漏改。

我还想指出我自己审查中的一次险些误判，这也是为什么就证据（而非 diff 本身）而言我给 4/5 而不是 5/5。lockfile 删除了 191 行非版本提升的内容，而 #10914 没有这类改动——这看起来完全像是把另一套 npm 解析结果推进 main。直到把 main 的 lock 与 head 的 lock 做对比，才确认 main 早已独立到达相同状态，因此这些改动只是陈旧 merge-base 造成的假象，合并不会引入漂移。随后 Test (ubuntu-latest, Node 22.x) 变绿，而该 job 会在跑测试套件之前执行 npm ci，所以重新生成的 lockfile 是被确认能与提升后的清单正确解析，而不只是看起来合理。diff 是干净的；我对它的第一次解读不是，而这个差别只有在第二次核对时才显现。

CI 已完成：256fa27f 上的每个 pull_request workflow 运行都已结束，28 项检查为绿，无失败。两项取消的检查是被各自并发组终止的 bot 编排通道，仍在运行的那一项就是本次 triage 运行。

本 PR 目前的状态，以及我为什么不再追加 review：

• 本 bot 的 APPROVED review 已经在 256fa27f 上生效——由发布通道于 16:33:14Z 提交（"Automated second approval for the release version bump."），比 qwen-code-dev-bot 晚一秒。triage 每个提交只批准一次，且只有它自己的批准才算已投出；该名额已被占用，因此在 CI 已绿的现在我没有需要追加的东西，同一账号再提交一次 review 只是噪音。同理，没有需要延后排期的批准：没有任何东西在等 CI 之后才变得可批准，因为该提交上的批准已经存在。
• 人工批准随后已经到位。 @yiliang114 于 17:01:10Z 批准，reviewDecision 现在是 APPROVED——本次运行早些时候，仅凭两次 bot 批准它还停在 REVIEW_REQUIRED，这与 chore(release): v0.23.0 #10914 需要人工批准才能打破的状态完全相同。所以该要求已满足：既不等 review，也不等 CI。
• 撰写时 mergeability 读数为 UNKNOWN（mergeable 与 mergeStateStatus 都是），这是 GitHub 在新 review 之后重新计算，而不是报告了冲突——在此之前每次读取都是 MERGEABLE。合并前值得再看一眼，但我不会把一个瞬时值当作阻塞项。

结论：diff 中没有需要修改的地方，CI 与 review 也都没有待办事项。给合并者一条合并注意事项——请正常合并；如果 lockfile 确实需要手工解决冲突，不要整体采用本分支一侧，否则 sdk-typescript 的 lock 条目会从 0.1.9 掉回 0.1.8，npm ci 会拒绝该依赖树。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 256fa27f28d947deb3cb16d05223cb1fa00ce3f7 · re-run with @qwen-code /triage}

[qwen-code-ci-bot]

Released in v0.23.2.