chore(release): v0.23.2

[qwen-code-review-bot]

Automated release PR for v0.23.2. 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.2 release PR.

This is the repo's own release automation, not a contribution. v0.23.2 is tagged at f56de980 — the PR's first commit — and the release published 2026-09-09 10:51 UTC; this syncs that version bump and the regenerated changelog from release/v0.23.2 back into main. The body is the fixed one-liner finalize-release.yml writes for every release PR, the same shape as #11400, #10914, #10424 and #10166, 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.2 is already published while main still reads 0.23.1 in every manifest and has no 0.23.2 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 f56de980, which is the commit tagged v0.23.2, and the changelog sync 6c52f9a7 (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 non-mechanical thing I checked before moving on, because it is what made the last release worth a second look: main has moved two commits past the branch point (19ba03fb goal-checkpoint fix, 40c9506d reasoning presets), and the release branch was cut from 9600dfb4. Neither of those two commits touches a manifest, package-lock.json, or CHANGELOG.md, so this merge is clean and the sdk-typescript lock hazard from #11400 does not recur. I verified that at byte level rather than from the file lists — details in Stage 2.

Moving on to code review. 🔍

中文说明

v0.23.2 release PR 的入口检查。

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

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

进入代码审查前先核对了一件非机械的事，因为这正是上次发布值得多看一眼的地方：main 已比分叉点多出两个提交（19ba03fb goal-checkpoint 修复、40c9506d reasoning presets），而 release 分支是从 9600dfb4 切出的。这两个提交都没有触及任何清单、package-lock.json 或 CHANGELOG.md，所以本次合并是干净的，#11400 里那个 sdk-typescript lock 隐患不会重演。这一点我是按字节核对的，而不是只看文件列表——详见 Stage 2。

进入代码审查 🔍

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

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

[qwen-code-ci-bot]

🖼️ web-shell visual preview

Rendered against a mock daemon (no real backend): the PR base vs this PR head 6c52f9a. Only screenshots that changed are shown (flows below, if any, are head-only) — refreshes on every push.

Screenshots · before / after

✅ No screenshot changes against the PR base.

_{Full-resolution recordings (.webm) are attached to the workflow run.}

— Qwen Code · web-shell visuals

[qwen-code-ci-bot]

Code review

I wrote my independent proposal before opening the diff: for a post-tag sync-back I'd move every manifest on the 0.23.x train to 0.23.2 — including both config.sandboxImageUri entries and the pinned @qwen-code/channel-base dependencies — regenerate package-lock.json, leave pnpm-lock.yaml alone because no dependency changed, prepend the generated 0.23.2 changelog section, and touch nothing else, in two commits. That is exactly what this PR is, so the review became a completeness check rather than a design argument.

What I verified rather than assumed:

• Nothing on the train was left behind. The head tree holds 52 manifest files (package.json / qwen-extension.json, excluding node_modules). The PR moves 23 of them; I read the version of every one it leaves alone, and all are on their own release lanes — sdk-typescript 0.1.9, 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, docs-site 1.0.0, external-context/qwen-extension.json 1.0.0, plugin-example/qwen-extension.json 0.1.0, terminal-capture 0.1.0, plus a handful of version-less fixtures. No stragglers at 0.23.1.
• The stronger form of that check: I grepped the whole tree for 0.23.1 and subtracted what this PR changes. What remains is the historical ## [0.23.1] changelog section plus the new compare/v0.23.1...v0.23.2 link, a frozen verification record under docs/verification/ that cites a 0.23.1-preview.0 npm artifact, and three recast@0.23.11 lines in pnpm-lock.yaml — a substring false positive on an unrelated third-party package. Nothing that should have been bumped wasn't.
• The two things people forget are both here: config.sandboxImageUri → ghcr.io/qwenlm/qwen-code:0.23.2 in the root and CLI manifests, and the nine @qwen-code/channel-base pins (dingtalk, dws, feishu, github, gitlab, qqbot, telegram, wecom, weixin — plugin-example uses file:../base, so it correctly carries no pin).
• The lockfile is version strings and nothing else. 32 additions / 32 deletions: 2 root lines plus 21 workspace entries, 9 of which are the channel-base pins. Every bumped manifest has a matching lock entry. Diffing main's current package-lock.json against the head's, both files are 1,144,568 bytes and all 32 differing lines on each side are 0.23.1 → 0.23.2. packages/sdk-typescript reads 0.1.9 on both sides, so the mismatch that chore(release): v0.23.1 #11400 carried (branch cut two seconds before the sdk bump landed) does not recur here.
• pnpm-lock.yaml is untouched, correctly. A pnpm v9 lockfile doesn't record its own workspace packages' version fields, and no dependency spec changed, so there is nothing to regenerate. pnpm Worktree Smoke went green on this head, which runs the pinned pnpm with --frozen-lockfile — that is the check that would have caught it if I'm wrong.
• The changelog is a pure +67 prepend of the generated 0.23.2 section above the 0.23.1 one, with no existing entry rewritten — consistent with the file's "do not edit by hand" header. I also checked it against the tag range: v0.23.1...v0.23.2 carries 44 PR references, the new section lists 41, and the three it omits are ci: fail Lint & Static when the base moved the lint gate #11383 (skip-changelog-auto), chore(release): sdk-typescript v0.1.9 #11393 and chore(release): v0.23.1 #11400 (both skip-changelog). Deliberate omissions, and zero entries that aren't in the range. The published v0.23.2 release notes are the same text as the new section, modulo heading level.

No critical blockers, no AGENTS.md violations. One thing to have on the record rather than fix: main has moved two commits past the branch point since the tag was cut — 19ba03fb (#11365) and 40c9506d (#11349). Neither is in this changelog, because the release was cut before they landed, and both will roll into the next release. That's correct behaviour for a tag-range changelog, but it does mean the 0.23.2 section is not "everything now on main", and I'd rather a reader know that than discover it.

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 6c52f9a7, read through the API. CI has not finished at the time of writing: 23 checks success, 111 skipped, 1 cancelled, 3 in progress, 0 failures.

Final CI results for 6c52f9a (auto-updated by the triage finalize job after CI completed):

Check	Conclusion
Capture web-shell visuals (ubuntu-latest, Node 22.x)	✅ success
Classify PR	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
Install (macos-latest)	✅ success
Install (ubuntu-latest)	✅ success
Install (windows-latest)	✅ success
Integration Tests (no-AK, No Sandbox)	✅ success
Lint & Static (ubuntu-latest, Node 22.x)	✅ success
macos-latest / Java 21	✅ success
OpenTUI no-flicker gate	✅ success
Real daemon E2E / Java 11	✅ success
Test (ubuntu-latest, Node 22.x)	✅ success
TUI parity snapshots (ink vs opentui)	✅ success
ubuntu-latest / Java 11	✅ success
ubuntu-latest / Java 17	✅ success
ubuntu-latest / Java 21	✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	✅ success
windows-latest / Java 21	✅ success

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

One pull_request workflow run is still open on this commit — Qwen Code CI, which is where Test (ubuntu-latest, Node 22.x) lives; Web-shell Visuals finished green while I was writing this. Reading the signal honestly rather than as "CI is green":

• The one job that directly substantiates this diff has not landed yet. Test (ubuntu-latest, Node 22.x) is the ci.yml job that runs npm ci before the suite, so it is what proves the regenerated package-lock.json resolves against the bumped manifests and installs cleanly. It is still in progress. My lockfile conclusion above rests on the byte-level diff (version strings only, identical file size), which is strong but is not the same thing as a green install.
• The three green Install (...) checks are not npm evidence. They belong to pnpm-worktree-smoke.yml and exercise the pnpm layout. They are real evidence for the untouched pnpm-lock.yaml claim, and citing them for package-lock.json would be exactly the wrong read — they finished green long before the npm job did.
• Lint & Static being green is worth more here than it usually is on a release PR, because the reduced CI profile this diff gets is the reason the macOS and Windows suites are skipped: lint plus the ubuntu unit job are the whole substantive gate.
• 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. Same shape as chore(release): v0.23.1 #11400.
• The cancelled route check is bot orchestration superseded by its concurrency group, not PR CI.

Not verified: that the merged tree installs, and that the head's own npm ci passes — both wait on Test (ubuntu-latest, Node 22.x). I'm naming that job 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, so a suite that passes identically with and without it is the expected outcome rather than a gap.

中文说明

代码审查

在看 diff 之前我先写下了自己的独立方案：标签发布后的回同步，应当把 0.23.x 发布序列上的每个清单提升到 0.23.2（包括两处 config.sandboxImageUri 和固定版本的 @qwen-code/channel-base 依赖）、重新生成 package-lock.json、因为没有依赖变化而完全不动 pnpm-lock.yaml、在顶部插入生成的 0.23.2 changelog 段落，此外什么都不动，共两个提交。这个 PR 正是如此，所以审查变成了完整性核对，而不是方案之争。

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

• 序列上没有遗漏。 head 树中共有 52 个清单文件（package.json / qwen-extension.json，不含 node_modules）。PR 改动其中 23 个；我逐个读取了它未触碰的那些的版本号，全部在各自的发布通道上——sdk-typescript 0.1.9、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、docs-site 1.0.0、external-context/qwen-extension.json 1.0.0、plugin-example/qwen-extension.json 0.1.0、terminal-capture 0.1.0，以及若干无 version 字段的 fixture。没有滞留在 0.23.1 的。
• 更严格的一种核对方式： 我在全树 grep 0.23.1，再减去本 PR 改动的部分。剩下的是历史 ## [0.23.1] changelog 段落与新增的 compare/v0.23.1...v0.23.2 链接、docs/verification/ 下一份引用 0.23.1-preview.0 npm 产物的冻结验证记录，以及 pnpm-lock.yaml 中三行 recast@0.23.11——那是一个无关第三方包造成的子串误命中。该提升而没有提升的地方，一个都没有。
• 最容易被忘记的两处都在： 根清单与 CLI 清单里的 config.sandboxImageUri 已改为 ghcr.io/qwenlm/qwen-code:0.23.2，以及 9 处 @qwen-code/channel-base 依赖固定版本（dingtalk、dws、feishu、github、gitlab、qqbot、telegram、wecom、weixin——plugin-example 用的是 file:../base，因此正确地不带固定版本）。
• lockfile 只有版本号字符串，别无其他。 32 增 / 32 删：2 行根条目加 21 个 workspace 条目，其中 9 处是 channel-base 固定版本。每个被提升的清单都有对应的 lock 条目。把 main 当前的 package-lock.json 与 head 的对比，两个文件都是 1,144,568 字节，双方各 32 行差异全部是 0.23.1 → 0.23.2。packages/sdk-typescript 两侧都是 0.1.9，所以 chore(release): v0.23.1 #11400 携带的那个不一致（分支比 sdk 版本提升早两秒切出）这次没有重演。
• pnpm-lock.yaml 未被改动，这是对的。 pnpm v9 lockfile 不记录自身 workspace 包的 version 字段，而依赖声明也没有变化，所以没有需要重新生成的内容。pnpm Worktree Smoke 在该 head 上已变绿，它会用固定版本的 pnpm 执行 --frozen-lockfile 安装——如果我判断错了，能被这项检查抓到。
• changelog 是纯新增 67 行，把生成的 0.23.2 段落插到 0.23.1 段落之上，没有改写任何既有条目——与该文件"请勿手工编辑"的说明一致。我还把它与标签区间做了核对：v0.23.1...v0.23.2 含 44 个 PR 引用，新段落列出 41 个，未列出的三个是 ci: fail Lint & Static when the base moved the lint gate #11383（skip-changelog-auto）、chore(release): sdk-typescript v0.1.9 #11393 与 chore(release): v0.23.1 #11400（均为 skip-changelog）。都是有意的省略，且没有任何条目不在该区间内。已发布的 v0.23.2 release notes 与新段落文本一致，仅标题层级不同。

无阻塞性问题，也没有违反 AGENTS.md 之处。 有一点需要记录在案（而不是需要修改）：自打标签以来 main 已比分叉点多出两个提交——19ba03fb（#11365）与 40c9506d（#11349）。两者都不在本 changelog 中，因为发布是在它们落地之前切出的，它们会进入下一个发布。对于按标签区间生成的 changelog 来说这是正确行为，但这确实意味着 0.23.2 段落并不等于"当前 main 上的全部内容"，我希望读者是先知道这一点，而不是事后发现。

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

测试证据

本次为无人值守 CI 运行，按 gate 规则我没有从该分支构建、安装或执行任何东西——以下全部是通过 API 读取的、该 PR 自身在 6c52f9a7 上的 CI 结果。撰写时 CI 尚未跑完：23 项成功、111 项跳过、1 项取消、3 项进行中，0 项失败。

该提交上仍有一个 pull_request workflow 运行未结束——Qwen Code CI，也就是 Test (ubuntu-latest, Node 22.x) 所在的 workflow；Web-shell Visuals 在我撰写期间已跑绿。诚实地解读这些信号，而不是笼统说"CI 绿了"：

• 唯一能直接证实本次 diff 的 job 还没有结果。 Test (ubuntu-latest, Node 22.x) 是 ci.yml 中先执行 npm ci 再跑测试套件的 job，因此它才能证明重新生成的 package-lock.json 能与提升后的清单正确解析并干净安装。它仍在进行中。我上面对 lockfile 的结论依赖的是按字节的 diff（只有版本号字符串、文件大小完全相同），这很有力，但与"安装已通过"不是一回事。
• 三个绿色的 Install (...) 检查不是 npm 证据。 它们属于 pnpm-worktree-smoke.yml，验证的是 pnpm 布局。它们对"未改动 pnpm-lock.yaml"这一主张是真实证据，但拿它们去证明 package-lock.json 就完全是误读——它们比 npm job 早很多就变绿了。
• Lint & Static 变绿在这里比平时更有分量，因为本次 diff 走的精简 CI 档正是 macOS 与 Windows 测试被跳过的原因：lint 加 ubuntu 单元测试 job 就是全部的实质门禁。
• macOS/Windows 的 Test job 是跳过，不是失败： Classify PR 已成功，而本次 diff 只涉及清单、changelog 和 lockfile，因此走了精简档。与 chore(release): v0.23.1 #11400 形状相同。
• 被取消的 route 检查是 bot 编排通道，被自己的并发组取代，不是 PR CI。

未验证：合并后的树能否安装，以及 head 自身的 npm ci 是否通过——两者都取决于 Test (ubuntu-latest, Node 22.x)。我指名这项 job 而不是沙箱通道，是因为这里没有可供 @qwen-code /verify 或 @qwen-code /tmux 验证的行为性主张：本次 diff 只改动版本号字符串和生成的 changelog 文本，不涉及任何运行时行为，所以"有无本次改动测试套件结果都一样"在这里是预期结果，而不是缺口。

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

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

[qwen-code-ci-bot]

Confidence: 4/5 — a clean mechanical release sync-back whose completeness I could prove rather than eyeball; the only thing missing at review time is the one CI job that would confirm the lockfile installs.

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 npm lock, leave the pnpm lock alone, prepend the generated changelog, touch nothing else — and this matches it. So the effort went into completeness, and I answered that three ways instead of one: enumerating all 52 manifests in the head tree and reading the version of every one the PR skips, grepping the whole tree for 0.23.1 and confirming the only survivors are the historical changelog section, a frozen verification doc, and three recast@0.23.11 substring false positives, and diffing main's package-lock.json against the head's byte for byte — identical file size, 32 differing lines each way, every one a version string. The changelog also checks out against its own tag range: 44 PR references in v0.23.1...v0.23.2, 41 listed, and all three omissions carry skip-changelog labels. Nothing phantom, nothing stranded.

The reason this is 4/5 and not 5/5 is evidence, not the diff. Test (ubuntu-latest, Node 22.x) — the job that runs npm ci before the suite, and therefore the only check that actually substantiates a regenerated lockfile — was still in progress when I wrote this, the last substantive job left in Qwen Code CI; Lint & Static and the web-shell visuals capture landed green while I was working. Everything that has finished is green, zero failures, but a green install on this head is the one signal I'd want before calling it done. The static evidence is about as strong as static evidence gets here, and I'd still rather report the gap than paper over it with the pnpm Install (...) checks, which cover a different lockfile.

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

• This bot's APPROVED review already stands on 6c52f9a7 — submitted by the release lane at 10:54:26Z ("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 there is nothing for me to add and a second review from the same account would be noise. For the same reason I'm not scheduling a deferred approval: nothing is waiting on CI to become approvable, because the approval already exists on this exact commit. If Test (ubuntu-latest, Node 22.x) lands red, the two standing automated approvals should not be read as a green light — the checks gate the merge, not the reviews.
• A human approval is still required. reviewDecision reads REVIEW_REQUIRED despite the two bot approvals, and mergeable is MERGEABLE. This is the same shape chore(release): v0.23.1 #11400 sat in until @yiliang114 approved it. I can't read the branch-protection settings with this token (404), so treat this as inference rather than fact: the diff touches packages/core/package.json, which .github/CODEOWNERS assigns to @wenshao @tanzhenxin @yiliang114 @LaZzyMan @doudouOUC @qqqys, and a required code-owner review would not be satisfied by bot approvals. Naming it because nothing else in the pipeline reports it, not because I think something is wrong.
• No merge-hygiene warning this time. The thing worth flagging on chore(release): v0.23.1 #11400 — a lockfile that disagreed with main about sdk-typescript because the branch was cut seconds too early — I checked specifically and it does not recur: both sides read 0.1.9, and main's two commits since the branch point touch no manifest, no lockfile, and no changelog. A normal merge is clean.

So: nothing to fix in the diff, no changes requested. Once Qwen Code CI finishes green and a code owner signs off, this is ready to land.

中文说明

置信度：4/5 —— 一次干净的机械式发布回同步，其完整性我是证明出来的而不是靠目测；审查时唯一缺的，是那个能确认 lockfile 可安装的 CI job。

回到我的独立方案：我说过会怎么写，这个 PR 就是怎么写，我也找不出更简单的版本。发布回同步只有一种正确形态——提升序列上的每个清单、重新生成 npm lock、不动 pnpm lock、在顶部插入生成的 changelog、其余什么都不动——本 PR 与之吻合。所以功夫都花在完整性上，而我用了三种方式而不是一种来回答它：列举 head 树中全部 52 个清单文件并逐个读取 PR 跳过的那些的版本号；在全树 grep 0.23.1，确认剩下的只有历史 changelog 段落、一份冻结的验证文档，以及三行 recast@0.23.11 子串误命中；把 main 的 package-lock.json 与 head 的按字节对比——文件大小完全相同，双方各 32 行差异，每一行都是版本号字符串。changelog 与其标签区间也核对得上：v0.23.1...v0.23.2 含 44 个 PR 引用，列出 41 个，三个未列出的都带 skip-changelog 标签。没有凭空多出的条目，也没有被落下的清单。

给 4/5 而不是 5/5 的原因是证据，不是 diff。Test (ubuntu-latest, Node 22.x)——那个先跑 npm ci 再跑测试套件、因此也是唯一能真正证实重新生成的 lockfile 的检查——在我撰写时仍在进行中，是 Qwen Code CI 里最后一个实质 job；Lint & Static 与 web-shell visuals 采集在我工作期间已跑绿。已结束的检查全绿、零失败，但"该 head 上安装通过"是我在收工之前想看到的那一个信号。这里的静态证据已经强到静态证据所能达到的程度，而我仍然宁愿把这个缺口报出来，也不愿用 pnpm 的 Install (...) 检查去糊上——它们覆盖的是另一个 lockfile。

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

• 本 bot 的 APPROVED review 已经在 6c52f9a7 上生效——由发布通道于 10:54:26Z 提交（"Automated second approval for the release version bump."），比 qwen-code-dev-bot 晚一秒。triage 每个提交只批准一次，且只有它自己的批准才算已投出；该名额已被占用，所以我没有需要追加的东西，同一账号再提交一次 review 只是噪音。同理，我不安排延后批准：没有任何东西在等 CI 之后才变得可批准，因为该提交上的批准已经存在。如果 Test (ubuntu-latest, Node 22.x) 最终变红，那两次已生效的自动批准不应被当作放行信号——拦住合并的是状态检查，不是 review。
• 仍然需要人工批准。 尽管已有两次 bot 批准，reviewDecision 仍是 REVIEW_REQUIRED，mergeable 为 MERGEABLE。这与 chore(release): v0.23.1 #11400 在 @yiliang114 批准之前的状态形状相同。用当前 token 读不到分支保护设置（404），所以请把下面当作推断而非事实：本次 diff 触及 packages/core/package.json，而 .github/CODEOWNERS 把它分配给 @wenshao @tanzhenxin @yiliang114 @LaZzyMan @doudouOUC @qqqys，若要求 code-owner review，则 bot 批准无法满足。之所以点出来，是因为流水线里没有别的地方会报告这件事，而不是我认为有什么问题。
• 这次没有合并注意事项。 chore(release): v0.23.1 #11400 上值得提醒的那件事——lockfile 与 main 在 sdk-typescript 上不一致，因为分支早切了几秒——我专门核对过，这次没有重演：两侧都是 0.1.9，且自分叉点以来 main 的两个提交都没有触及任何清单、lockfile 或 changelog。正常合并是干净的。

结论：diff 中没有需要修改的地方，不请求变更。等 Qwen Code CI 跑绿、并由 code owner 签署批准后，即可合并。

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

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

[qwen-code-ci-bot]

Released in v0.23.3.