chore(release): v0.23.3

[qwen-code-review-bot]

Automated release PR for v0.23.3. 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.3 release PR.

This is the repo's own release automation, not a contribution. v0.23.3 is tagged at b695664b — the PR's first commit — and the release published 2026-09-10 14:56 UTC; this syncs that version bump and the regenerated changelog from release/v0.23.3 back into main. The body is the fixed one-liner finalize-release.yml writes for every release PR, the same shape as #11469, #11400, #10914 and #10424, so the PR-template gate doesn't apply — there is no author here to ask for a test plan. No closing issue references (checked through GraphQL, not a keyword grep), which is expected for a release sync-back. The author account holds write, so the two-tier core gate treats this as maintainer-side work rather than an external PR.

• Problem: observed by construction — v0.23.3 is already published while main still reads 0.23.2 in every manifest and has no 0.23.3 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 — 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 b695664b, which is the commit tagged v0.23.3, and the changelog sync ee2bc9b2 (the head). Nothing else rode along on the branch.
• Risk: the high-risk path list matches none of the changed files; no elevated risk signals.

One timing note, because it shapes what Stage 2 can actually prove: this PR merged at 15:03:36 UTC, eighteen seconds after the human approval landed at 15:03:18 UTC, while its own npm ci-based CI was still running. That is the release lane's --auto merge behaving as configured, and it is how #11469 and #11400 shipped too — not a complaint, just the reason part of the lockfile evidence below is pending rather than green.

Moving on to code review. 🔍

中文说明

v0.23.3 release PR 的入口检查。

这是仓库自己的发布自动化，不是外部贡献。v0.23.3 已在 b695664b（本 PR 的第一个提交）打标签，发布于 2026-09-10 14:56 UTC；本 PR 把该版本提升和重新生成的 changelog 从 release/v0.23.3 同步回 main。PR 描述是 finalize-release.yml 为每个 release PR 写入的固定一行文本，与 #11469、#11400、#10914、#10424 形状一致，因此 PR 模板检查在这里不适用——这里没有可以要求补写测试计划的作者。没有关闭类 issue 引用（通过 GraphQL 核对，而非关键字 grep），这对 release 回同步是正常的。作者账号具有 write 权限，因此核心模块两级门禁把它当作维护者侧工作，而不是外部 PR。

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

有一点时间顺序需要说明，因为它决定了 Stage 2 究竟能证明什么：本 PR 于 15:03:36 UTC 合并，比 15:03:18 UTC 到位的人工批准只晚十八秒，而它自己那批基于 npm ci 的 CI 当时仍在运行。这是发布通道 --auto 合并按配置运作的结果，#11469 和 #11400 也是这样发布的——不是指责，只是下面 lockfile 证据有一部分处于 pending 而非全绿的原因。

进入代码审查 🔍

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

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

[qwen-code-ci-bot]

Code review

My independent proposal before reading the diff: a release sync-back has exactly one correct shape — move every manifest on the version train, regenerate the lock, prepend the generated changelog, touch nothing else. That is what is here, and I could not find a simpler version of it. So the review question is not "is this the right approach" but "is it complete, and did it drag anything along". I checked both at byte level rather than from the file list.

Bump completeness. Enumerating every manifest in the pre-merge tree, exactly 23 carry a 0.23.x version, and the PR changes exactly those 23 — a 1:1 match with nothing left behind and nothing extra. The manifests it deliberately skips are all on their own version lanes, not stragglers: node-repl 0.1.3, live-host 0.0.5, desktop-shell 0.0.1, cua-sdk 0.20.5, the plugin-example extension manifest 0.1.0, and the 1.0.0 examples, docs-site and test fixtures.

Uniformity. All 92 changed version lines are 0.23.2 → 0.23.3 with no strays. That includes the two that are easy to miss: the root config.sandboxImageUri now points at ghcr.io/qwenlm/qwen-code:0.23.3, and the internal workspace dependency pins in the channel and CLI manifests moved with their packages.

Lockfile. The arithmetic accounts for itself exactly: 32 version-line swaps plus 11 single-line removals = the 43 deletions, against 32 additions. Nothing else in the lock changed — no resolved, no integrity, no dependency version. The 11 removals are all "peer": true on lightningcss-* platform binaries (android-arm64, darwin-arm64/x64, freebsd-x64, linux-arm64-gnu/musl, linux-x64-gnu/musl, win32-arm64-msvc, win32-x64-msvc). Each entry keeps "dev": true and "optional": true with an identical version and integrity hash, so the installed tree is unchanged and only npm's record of how those optional binaries are reached differs. Worth knowing about, not worth blocking: this is lockfile metadata drift from regeneration, not a dependency change.

Merge-base drift — the #11400 hazard, checked. The branch point is 1961e974, and main advanced five commits past it before this merged: #11571, #11570, #11581, #11533, #10188. I read each commit's file list rather than assuming. None of the five touches a package.json, package-lock.json, qwen-extension.json or CHANGELOG.md, so the squash merge reverts nothing on main and the sdk-typescript lock regression that made #11400 worth a second look does not recur here.

Changelog accuracy. The v0.23.2...v0.23.3 range holds 59 commits (34 fix, 13 feat, 3 test, 3 chore, 2 refactor, 2 docs, 1 perf, 1 ci). The new section lists 56 entries — 13 feat, 34 fix, 3 test, 2 refactor, 2 docs, 1 perf, 1 ci — an exact per-type match. The three omitted commits are precisely the release sync-back chores (#11469, #11473, and this release's own bump), which is correct to leave out. Six PR numbers appear in the range without a changelog link and all six are accounted for: two are those release chores, and four (#11088, #11346, #11525, #11529) are inner references inside commit subjects whose actual merged PRs (#11094, #11362, #11530, #11537) are listed. The header, date and compare link are right, the new-contributor line for @lorenzozanee matches #11483 which is itself listed, and "No known breaking changes" is correct — no ! commit is in the range. The one breaking change on main, feat(channels)! #11571, landed after the release was cut, so it belongs to v0.23.4, not here. The section shape matches 0.23.2 exactly, placeholder Highlights included.

No correctness blockers and no AGENTS.md violations.

Test evidence

This is an unattended CI run, so I did not build or execute anything from this PR — the evidence below is the PR's own check runs on the reviewed commit, read through the API. 176 checks in total: 18 success, 8 still in progress, 4 cancelled, 146 skipped, 0 failed.

Check	Conclusion
Test (ubuntu-latest, Node 22.x)	⏳ in progress
Lint & Static (ubuntu-latest, Node 22.x)	⏳ in progress
Integration Tests (no-AK, No Sandbox)	⏳ in progress
Real daemon E2E / Java 11	⏳ in progress
OpenTUI no-flicker gate	⏳ in progress
Capture web-shell visuals (ubuntu-latest, Node 22.x)	⏳ in progress
TUI parity snapshots (ink vs opentui)	⏳ in progress
triage (this run)	⏳ in progress
Install (ubuntu-latest)	✅ success
Install (macos-latest)	✅ success
Install (windows-latest)	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
SDK Java — ubuntu-latest / Java 11, 17, 21	✅ success
SDK Java — macos-latest / Java 21	✅ success
SDK Java — windows-latest / Java 21	✅ success
Classify PR · assign · label · authorize · delete-asset-branch · route	✅ success
review-pr · route · delay-automatic-review · fallback-comment	⚪ cancelled
Test (macos, windows) · Integration Tests (CLI) · verify · tmux-testing · build-cli	⚪ skipped

Two honest readings of that table, because the green part is less reassuring than it looks.

The four cancelled checks are bot orchestration lanes killed by the merge subject's [skip ci] and by their own concurrency groups once the PR merged — not PR-caused failures.

More importantly: not verified — no completed check has yet run npm ci against the regenerated lockfile. The three green Install (…) checks are tempting to read as lockfile proof and they are not; they belong to pnpm-worktree-smoke.yml and exercise the pnpm worktree bootstrap, not the npm lock. The jobs that do run npm ci on it — Test (ubuntu-latest, Node 22.x), Lint & Static, tui-parity, web-shell-visuals, sdk-java — were all still in flight when the PR merged at 15:03:36 UTC. So the 11 lightningcss peer-flag removals are reasoned-safe from the diff (identical versions and integrity hashes, optional/dev retained) but not yet install-verified. This is the one thing I would want green before calling the release fully clean, and no sandboxed lane would settle it either — /verify A/B-proves behaviour and this PR changes none. The in-flight npm ci jobs are the right oracle; the region markers above let the finalize job rewrite this table in place once they land.

中文说明

代码审查

在看 diff 之前我的独立方案是：release 回同步只有一种正确形态——提升版本序列上的每个清单、重新生成 lock、在顶部插入生成的 changelog、其余什么都不动。本 PR 就是这样，我也找不出更简单的版本。所以审查的问题不是"方案对不对"，而是"是否完整、有没有夹带东西"。这两点我都是按字节核对的，而不是只看文件列表。

提升完整性。 枚举合并前依赖树中的全部清单文件，恰好有 23 个带 0.23.x 版本号，而本 PR 改的正好是这 23 个——一一对应，既没有遗漏也没有多改。它有意跳过的清单都在各自的版本通道上，不是漏改：node-repl 0.1.3、live-host 0.0.5、desktop-shell 0.0.1、cua-sdk 0.20.5、plugin-example 的 extension 清单 0.1.0，以及那些 1.0.0 的示例、docs-site 和测试 fixture。

一致性。 全部 92 处版本行改动都是 0.23.2 → 0.23.3，无一例外。其中两处容易漏看：根目录 config.sandboxImageUri 已指向 ghcr.io/qwenlm/qwen-code:0.23.3；channel 与 CLI 清单里的 workspace 内部依赖版本也随各自的包一起移动了。

Lockfile。 行数账目完全对得上：32 处版本号替换加 11 处单行删除，正好是 43 行删除，对应 32 行新增。lock 中没有其他任何改动——resolved、integrity、依赖版本都没变。那 11 处删除全部是 lightningcss-* 平台二进制包上的 "peer": true（android-arm64、darwin-arm64/x64、freebsd-x64、linux-arm64-gnu/musl、linux-x64-gnu/musl、win32-arm64-msvc、win32-x64-msvc）。每个条目仍保留 "dev": true 与 "optional": true，版本号和 integrity 哈希完全相同，因此实际安装的依赖树没有变化，只是 npm 记录的"这些可选二进制是如何被引入的"这一元数据不同。值得知道，但不构成阻塞：这是重新生成 lock 带来的元数据漂移，不是依赖变更。

merge-base 漂移——即 #11400 那个隐患，已核对。 分叉点是 1961e974，合并前 main 已比它多出五个提交：#11571、#11570、#11581、#11533、#10188。我逐个读了这些提交的文件列表，而不是想当然。五个都没有触及任何 package.json、package-lock.json、qwen-extension.json 或 CHANGELOG.md，所以这次 squash 合并没有回退 main 上的任何内容，#11400 里那个值得多看一眼的 sdk-typescript lock 回退问题不会在此重演。

Changelog 准确性。 v0.23.2...v0.23.3 区间共 59 个提交（34 fix、13 feat、3 test、3 chore、2 refactor、2 docs、1 perf、1 ci）。新段落列出 56 条——13 feat、34 fix、3 test、2 refactor、2 docs、1 perf、1 ci——按类型完全吻合。被省略的三个提交正好是发布回同步类 chore（#11469、#11473，以及本次发布自己的版本提升提交），省略是正确的。区间里有六个 PR 号在 changelog 中没有链接，全部可以解释：两个是上述发布 chore，另外四个（#11088、#11346、#11525、#11529）是提交标题内部的引用，它们真正合并的 PR（#11094、#11362、#11530、#11537）都已在列表中。标题、日期与 compare 链接正确，@lorenzozanee 的首次贡献行对应 #11483，而该 PR 本身也在列表中；"No known breaking changes" 也是对的——区间内没有 ! 提交。main 上唯一那个破坏性变更 feat(channels)! #11571 是在发布切出之后才落地的，属于 v0.23.4，不在本次范围内。段落结构与 0.23.2 完全一致，包括占位的 Highlights。

没有正确性阻塞项，也没有违反 AGENTS.md 的地方。

测试证据

这是无人值守的 CI 运行，所以我没有构建或执行本 PR 的任何代码——下面的证据是通过 API 读取的、本 PR 自己在所审提交上的检查结果。共 176 项：18 项成功、8 项仍在进行、4 项取消、146 项跳过、0 项失败。表格同上（不重复）。

对这张表有两点需要如实说明，因为绿色的那部分没有看上去那么令人安心。

四项取消的检查是 bot 编排通道，被合并标题里的 [skip ci] 以及 PR 合并后各自的并发组终止，不是本 PR 造成的失败。

更重要的一点：未验证——目前还没有任何已完成的检查对重新生成的 lockfile 执行过 npm ci。 三个绿色的 Install (…) 很容易被当作 lockfile 的证明，但它们不是；它们属于 pnpm-worktree-smoke.yml，验证的是 pnpm worktree 引导流程，而不是 npm lock。真正会对它执行 npm ci 的 job——Test (ubuntu-latest, Node 22.x)、Lint & Static、tui-parity、web-shell-visuals、sdk-java——在本 PR 于 15:03:36 UTC 合并时全部仍在运行。因此那 11 处 lightningcss peer 标记删除，是从 diff 推理得出安全（版本与 integrity 完全相同，保留 optional/dev），但尚未经安装验证。这是我在称本次发布完全干净之前唯一希望看到变绿的一项；也没有任何沙箱通道能替代它——/verify 做的是行为的 A/B 证明，而本 PR 没有改变任何行为。正在运行的 npm ci job 才是正确的判定依据；上方的区域标记可以让 finalize job 在它们结束后就地重写这张表。

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

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

[qwen-code-ci-bot]

Confidence: 4/5 — a clean mechanical release sync-back whose completeness I could verify exactly; the missing point is evidence rather than the diff, because no completed check had run npm ci against the regenerated lockfile when this merged.

Going back to my independent proposal: what I said I would write is what is here, and I could not find a simpler version of it. A release sync-back has one correct shape and this matches it. The completeness question was the only one worth real effort, so I answered it by enumerating the manifests in the pre-merge tree instead of trusting the automation: exactly 23 sit on the 0.23.x train and exactly those 23 moved, while the ten it skips are all on their own version lanes. The changelog reconciles the same way — 59 commits in the tag range, 56 entries, an exact per-type match, with the three omissions being the release chores that should be omitted and every unlinked PR number explained.

The thing I would have gotten wrong on a first read is the lockfile, and it is why this is 4/5. Eleven lines are removed that are not version bumps, which on a release PR reads exactly like a differing npm resolution being pushed into main — the same shape as the sdk-typescript lock regression that made #11400 worth a second look. Two checks dissolved it. All eleven are "peer": true on lightningcss-* platform binaries with identical versions and integrity hashes and optional/dev retained, so the installed tree does not change; and the branch point 1961e974 is five commits behind where main merged, none of which touched a manifest, lockfile or changelog, so nothing on main is reverted. Both were verified per-commit and per-hunk, not inferred from the file list. What remains genuinely unproven is narrower than it sounds but real: the green Install (…) checks are the pnpm worktree smoke test, not npm ci on this lock, and every job that does run npm ci was still in flight at merge. So the lockfile is reasoned-safe and not yet install-verified. If one of those jobs lands red, main is already carrying the release commit — the table in Stage 2 gets rewritten in place once they settle, and that is where I would look.

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

• It is already merged — 15:03:36 UTC as 38513b59, eighteen seconds after the human approval landed. GitHub does not accept a review on a merged PR, so neither an approval nor a request-changes is available here, and this comment is a record rather than a gate.
• This bot's APPROVED review already stands on ee2bc9b2 anyway, posted by the release lane at 15:00:57 UTC ("Automated second approval for the release version bump."), the same second as qwen-code-dev-bot's. Triage approves once per commit and only its own approval counts as already cast; that slot was filled before this run began, so even on an open PR there would be nothing for me to add.
• reviewDecision is APPROVED on the strength of those two release-lane approvals plus the human one at 15:03:18 UTC. Nothing is waiting on review.
• So there is no deferred approval to schedule, and I have deliberately emitted no deferred-approval marker. Such a marker is an approval with a CI precondition attached; with the PR merged and the approval slot already filled on this exact commit, emitting one would only leave the finalize job trying to approve something that cannot be approved. The CI region markers in Stage 2 are still there and still useful — they let the table be updated when the pending jobs land, without any approval riding on them.

Nothing to fix in the diff. The one standing, non-blocking follow-up for whoever watches the release lane: the npm ci-based jobs were still running when --auto merge fired, which is branch protection behaving as configured for this lane and is how #11469 and #11400 shipped too — but it does mean a release can reach main before its regenerated lockfile has been install-verified once. Worth a glance at the Stage 2 table when it settles; not worth reopening a shipped patch release over.

中文说明

置信度：4/5 —— 一次干净的机械式发布回同步，其完整性可以被精确核对；扣掉的一分在于证据而非 diff 本身，因为合并时还没有任何已完成的检查对重新生成的 lockfile 执行过 npm ci。

回到我的独立方案：我说过会怎么写，这个 PR 就是怎么写，我也找不出更简单的版本。发布回同步只有一种正确形态，本 PR 与之吻合。完整性是唯一值得真正下功夫的问题，所以我通过枚举合并前依赖树中的清单文件来回答它，而不是默认自动化改全了：恰好 23 个位于 0.23.x 序列上，也恰好是这 23 个被改动，而它跳过的十个都在各自的版本通道上。changelog 以同样方式对得上——标签区间内 59 个提交、56 条记录、按类型完全吻合，被省略的三条正是应当省略的发布类 chore，每一个没有链接的 PR 号也都能解释。

第一遍阅读我会看错的地方是 lockfile，这也是给 4/5 的原因。有十一行删除不是版本提升，而这在发布 PR 上看起来完全像是把另一套 npm 解析结果推进了 main——与 #11400 里那个值得多看一眼的 sdk-typescript lock 回退是同一形状。两项核对化解了它。十一行全部是 lightningcss-* 平台二进制包上的 "peer": true，版本与 integrity 哈希完全相同且保留 optional/dev，因此安装的依赖树不变；分叉点 1961e974 比 main 合并时的位置落后五个提交，而这五个都没有触及任何清单、lockfile 或 changelog，所以 main 上没有内容被回退。两者都是逐提交、逐 hunk 核对的，不是从文件列表推断的。真正尚未被证明的部分比听起来要窄，但确实存在：绿色的 Install (…) 检查是 pnpm worktree 冒烟测试，而不是对本 lock 执行 npm ci；而所有真正会执行 npm ci 的 job 在合并时仍在运行。所以 lockfile 是"推理上安全、尚未经安装验证"。如果其中某个 job 变红，main 已经带上了这个发布提交——Stage 2 的表格会在它们结束后就地重写，那正是我会去看的地方。

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

• 它已经合并——15:03:36 UTC 合为 38513b59，比人工批准到位只晚十八秒。GitHub 不接受对已合并 PR 提交 review，所以这里既无法批准也无法要求修改，本条留言是记录，而不是门禁。
• 本 bot 的 APPROVED review 无论如何已经在 ee2bc9b2 上生效——由发布通道于 15:00:57 UTC 提交（"Automated second approval for the release version bump."），与 qwen-code-dev-bot 同一秒。triage 每个提交只批准一次，且只有它自己的批准才算已投出；该名额在本次运行开始前就已被占用，所以即便 PR 还开着，我也没有需要追加的东西。
• reviewDecision 为 APPROVED，凭两次发布通道批准加上 15:03:18 UTC 的人工批准。没有任何事项在等 review。
• 因此没有需要延后排期的批准，我也刻意没有写入任何延后批准标记。这类标记本质上是附带 CI 前置条件的批准；在 PR 已合并、且该提交上的批准名额已被占用的情况下写入它，只会让 finalize job 去尝试批准一个无法被批准的对象。Stage 2 中的 CI 区域标记仍然保留且仍然有用——它们让表格可以在 pending job 结束后更新，而不附带任何批准动作。

diff 中没有需要修改的地方。留给关注发布通道的人一条非阻塞的后续事项：--auto 合并触发时，基于 npm ci 的 job 仍在运行。这是该通道分支保护按配置运作的结果，#11469 和 #11400 也是这样发布的——但这确实意味着一个发布可能在它重新生成的 lockfile 被安装验证过一次之前就到了 main。等表格稳定后值得看一眼；但不值得为一个已发布的补丁版本重新打开。

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

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