[qwen-code-dev-bot]

What this PR does

The release workflow's Publish Release job now fetches the release tree with the run-scoped GitHub token instead of the long-lived bot PAT. The bot PAT remains exported only to the steps that write: the release-branch force push, GitHub Release creation, and the downstream dispatch.

A workflow meta-test pins that split: the read-only checkout must not override the token, while the push and release-creation steps must keep receiving the PAT.

Why it's needed

On 2026-10-27 two release runs failed in Publish Release at Checkout with could not read Username for 'https://github.com': terminal prompts disabled and git exit 128, then passed the identical checkout on re-run, with run 40486976670 completing successfully on that attempt. That checkout was the only read-only fetch in the workflow authenticating with the long-lived PAT, and it already disables credential persistence, so the PAT added an auth dependency without adding access. The PAT was only needed where the job actually writes; moving the read-only fetch onto the run-scoped token removes the failing dependency and narrows credential exposure.

Reviewer Test Plan

How to verify

Read the publish job in the release workflow: its first checkout should have no token override and should keep persist-credentials: false; the release-branch push step should still receive CI_BOT_PAT, and "Create GitHub Release and Tag" should still use it as GITHUB_TOKEN.

Run the focused meta-tests:

npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.js

Expected: 103 tests pass. Re-adding token: '${{ secrets.CI_BOT_PAT }}' to the publish checkout should make the new test fail, which is the regression witness. A production dry-run release is the end-to-end check when credentials are available; this session could not dispatch one.

Evidence (Before & After)

Non-UI CI wiring change, so there are no screenshots. Before: the publish checkout passed token: secrets.CI_BOT_PAT, and two runs failed at that step with the git auth error above. After: the checkout uses the run-scoped token, the PAT stays on the write steps, and the new test pins both halves. Mutation probe: re-adding the token made the new test fail (1 failed | 102 skipped); restoring the change returned 103 passed.

Tested on

OS	Status
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

Environment (optional)

Linux workspace: npm run build, npm run typecheck, npm run lint, and focused Vitest suites. No production GitHub credentials were available, so the release run itself was not exercised.

Risk & Scope

• Main risk or tradeoff: The read-only fetch now depends on the job's GITHUB_TOKEN instead of the PAT. The token has contents: write on this job and can read a public repository, so the fetch is unchanged in capability; the PAT remains available for every write path.
• Not validated / out of scope: The transient GitHub-side PAT rejection itself; no checkout retry wrapper was added because the existing re-run path already recovers and the failing dependency is removed. A real dry-run release requires production credentials.
• Breaking changes / migration notes: None. The release workflow still receives secrets.CI_BOT_PAT at job level for the write steps.

Linked Issues

Fixes #15726

中文说明

本 PR 做了什么

发布工作流的 Publish Release 任务现在使用本次运行范围内的 GitHub 令牌拉取发布代码树，而不是长期有效的机器人 PAT。机器人 PAT 仍只导出给执行写入的步骤：发布分支强制推送、创建 GitHub Release，以及下游 dispatch。

新增的工作流元测试锁定了这一分工：只读检出不得覆盖令牌，而推送与创建 Release 的步骤必须继续接收 PAT。

为什么需要它

2026-10-27 有两次发布运行在 Publish Release 的 Checkout 步骤失败，报错为 could not read Username for 'https://github.com': terminal prompts disabled 以及 git 退出码 128，随后在重跑时相同的检出却通过了，且运行 40486976670 在该次尝试中完整成功。该检出是工作流中唯一使用长期 PAT 鉴权的只读拉取，而且它已经禁用了凭据持久化，因此 PAT 只增加了鉴权依赖，并没有增加访问能力。PAT 只在任务真正写入的地方才需要；把只读拉取改到运行范围令牌上，移除了失败的依赖并缩小了凭据暴露面。

审查者测试计划

如何验证

查看发布工作流中的 publish 任务：它的首次检出不应覆盖 token，并应保留 persist-credentials: false；发布分支推送步骤仍应收到 CI_BOT_PAT，“Create GitHub Release and Tag”仍应把它作为 GITHUB_TOKEN 使用。

运行聚焦的元测试：

npx vitest run --config ./scripts/tests/vitest.config.ts scripts/tests/release-workflow.test.js

预期：103 个测试通过。把 token: '${{ secrets.CI_BOT_PAT }}' 加回发布任务检出应使新测试失败，这就是回归证据。有凭据时，生产 dry-run 发布是端到端检查；本会话无法派发。

证据（前后对比）

这是非 UI 的 CI 接线改动，因此没有截图。修改前：发布任务检出传入 token: secrets.CI_BOT_PAT，两次运行在该步骤因上述 git 鉴权错误失败。修改后：检出使用运行范围令牌，PAT 保留在写入步骤上，新测试锁定了这两部分。变异探针：把 token 加回后新测试失败（1 failed | 102 skipped）；恢复改动后变为 103 passed。

测试平台

OS	状态
🍏 macOS	⚠️
🪟 Windows	⚠️
🐧 Linux	✅

环境（可选）

Linux 工作区：npm run build、npm run typecheck、npm run lint，以及聚焦的 Vitest 套件。没有生产 GitHub 凭据，因此未实际运行发布流程。

风险与范围

• 主要风险或取舍：只读拉取现在依赖任务的 GITHUB_TOKEN 而不是 PAT。该令牌在此任务上具有 contents: write，也能读取公开仓库，因此拉取能力不变；PAT 仍可用于所有写入路径。
• 未验证 / 超出范围：GitHub 侧的瞬时 PAT 拒绝本身；没有添加检出重试包装，因为现有重跑路径已经可以恢复，且失败的依赖已被移除。真实 dry-run 发布需要生产凭据。
• 破坏性变更 / 迁移说明：无。发布工作流在任务级别仍会收到 secrets.CI_BOT_PAT 供写入步骤使用。

关联 Issue

Fixes #15726

[qwen-code-dev-bot]

Release failure v0.26.2-preview.1 — publish checkout auth

Root cause

The Publish Release job's first checkout authenticated with secrets.CI_BOT_PAT; every other checkout in the release workflow uses the run-scoped github.token. Run 40486976670 (attempt 2) and the concurrent run 40510643634 (attempt 1) both failed in that job at the Checkout step after about 31 seconds with:

• could not read Username for 'https://github.com': terminal prompts disabled
• The process '/usr/bin/git' failed with exit code 128

Both runs passed the identical checkout on re-run (attempt 3 of 40486976670 at 15:08:50Z and attempt 2 of 40510643634 at 15:16:27Z), and run 40486976670 completed successfully on that attempt. That points to a transient rejection of the long-lived PAT during a read-only fetch rather than a broken release ref. The PAT is not needed for that fetch: the checkout already sets persist-credentials: false, and the steps that actually write install the credential themselves — the release-branch force push runs gh auth setup-git with GH_TOKEN set from the PAT, and release creation plus the downstream dispatch pass the PAT explicitly as GITHUB_TOKEN. The read-only fetch now uses the default run-scoped token, removing the failing dependency and narrowing credential exposure.

Fix

• Removed the PAT token override from the publish job's initial checkout. The bot PAT remains exported exactly to the steps that push or write releases.
• Added a workflow meta-test pinning the read-only checkout to the run-scoped token and pinning the PAT to the push and release-creation steps, so a future edit cannot quietly reintroduce the failing wiring.

Verification

• npm run build — passed
• npm run typecheck — passed
• npm run lint — passed
• vitest on release-workflow, workflow-size, package-scripts, ai-release-notes-workflow, install-script, runtime-archive-cache — 6 files passed, 555 tests passed, 20 skipped
• bash .github/scripts/check-workflow-size.sh — passed (release.yml 40032 bytes, inside the 4096-byte growth allowance)
• Mutation probe: re-adding token: '${{ secrets.CI_BOT_PAT }}' to the publish checkout made the new test fail (1 failed | 102 skipped); restoring the change returned 103 passed
• The original failure was a GitHub-hosted authentication flake and cannot be reproduced locally; the workflow meta-test is the surrogate witness. A real dry-run release was not dispatched because this session has no production credentials.

中文说明

发布失败 v0.26.2-preview.1 —— 发布任务检出鉴权

根因

Publish Release 任务的首次检出使用 secrets.CI_BOT_PAT 鉴权，而发布工作流中的其他所有检出都使用本次运行范围内的 github.token。运行 40486976670（第 2 次尝试）与并发的运行 40510643634（第 1 次尝试）都在该任务的 Checkout 步骤失败，耗时约 31 秒，错误为：

• could not read Username for 'https://github.com': terminal prompts disabled
• The process '/usr/bin/git' failed with exit code 128

两次运行在重跑时都通过了完全相同的检出（40486976670 的第 3 次尝试于 15:08:50Z、40510643634 的第 2 次尝试于 15:16:27Z），并且 40486976670 在该次尝试中完整成功。这说明问题出在只读拉取时长期 PAT 被瞬时拒绝，而不是发布 ref 损坏。该拉取并不需要 PAT：检出本身已设置 persist-credentials: false，而真正执行写入的步骤会自行安装凭据——发布分支强制推送通过 gh auth setup-git 并使用 PAT 作为 GH_TOKEN，创建 Release 和下游 dispatch 也显式把 PAT 作为 GITHUB_TOKEN 传入。现在只读拉取改用默认的运行范围令牌，移除了失败的依赖并缩小了凭据暴露面。

修复

• 移除了发布任务首次检出的 PAT 令牌覆盖配置。机器人 PAT 仍只导出给执行推送或写入 Release 的步骤。
• 新增工作流元测试，锁定只读检出使用运行范围令牌，并锁定 PAT 继续用于推送与创建 Release 的步骤，防止后续改动悄悄恢复失败配置。

验证

• npm run build —— 通过
• npm run typecheck —— 通过
• npm run lint —— 通过
• vitest 运行 release-workflow、workflow-size、package-scripts、ai-release-notes-workflow、install-script、runtime-archive-cache —— 6 个文件通过，555 个测试通过，20 个跳过
• bash .github/scripts/check-workflow-size.sh —— 通过（release.yml 为 40032 字节，在 4096 字节增长额度内）
• 变异探针：把 token: '${{ secrets.CI_BOT_PAT }}' 加回发布任务检出后，新测试失败（1 failed | 102 skipped）；恢复改动后重新变为 103 passed
• 原始失败是 GitHub 托管环境的鉴权抖动，无法在本地复现；工作流元测试是替代性证据。由于本会话没有生产凭据，未实际派发 dry-run 发布。

--- 🧠 Handled by **Qwen Code** · model/模型 `deepseek-v4.1-flash-1017` · CLI `0.26.1`

[qwen-code-review-bot]

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

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

[qwen-code-review-bot]

Thanks for the PR — I dug into this one properly, because a change to release credential plumbing is exactly the kind of thing that should not be waved through. The diagnosis holds up, and I could confirm it from the failed run rather than taking the description's word for it. I'm escalating to a maintainer rather than approving, for the policy reason at the bottom — not because I found a defect.

Template looks good ✓ — every required heading is present, the Risk & Scope bullets are filled in rather than boilerplate, and the Chinese section is a real translation.

Problem: observed, with hard evidence. #15726 is an open, machine-filed release failure. I pulled run 40486976670 attempt 2 and the Publish Release job did fail at the Checkout step with fatal: could not read Username for 'https://github.com': terminal prompts disabled and git exit 128 — three times in a row across the retry ladder (14:25:54, 14:26:14, 14:26:25). Attempt 3 then passed the identical step. So this is a real, reproduced transient failure, not theoretical hardening.

Direction: aligned, and I verified the mechanism independently rather than trusting the write-up.

• The publish job declares contents: 'write', so the run-scoped token can certainly read a public repo. The capability argument in the description checks out.
• The strongest evidence is inside the same failing run: six other jobs fetch the identical needs.prepare.outputs.release_sha through the checkout_release_validation anchor with no token override. On attempt 2, Quality Checks (Static) succeeded fetching SHA 39076719e221c096dd039ae5aa023d608ef397fb while the PAT-authenticated publish checkout failed beside it.
• I checked whether the difference might be the credential plumbing rather than the token — it isn't. Both jobs' logs show the byte-identical auth setup: credentials written to a temp file plus four git config --local includeIf.gitdir:... entries. Same mechanism, same SHA, same run; only the token differed. That rules out persist-credentials: false as the culprit and leaves the PAT as the differentiator.
• The specific symptom supports that reading too. A valid-but-unauthorized token yields 403; could not read Username means git was left with no usable credential and fell back to prompting, which is what a rejected PAT looks like under GIT_TERMINAL_PROMPT=0.
• The change also moves this checkout toward the workflow's own stated design: push-release-branch already says "Keep the write credential unavailable until the push step needs it" and exports GH_TOKEN="${CI_BOT_PAT}" only at write time. The read-only checkout carrying the PAT was the outlier.

CHANGELOG: no direct reference — the only hit for these keywords upstream is an unrelated footer-badge change. Expected, since this is internal CI plumbing; the area is clearly relevant regardless.

Size: not applicable — neither file is under a Stage 0 core path. 2 production lines (release.yml +1/−1) and 18 test lines (release-workflow.test.js +18/−0).

Approach: minimal and correctly scoped. One wiring line plus a meta-test that pins both halves of the split, which satisfies the AGENTS.md rule about updating workflow meta-tests when CI definitions change. I checked the change against every existing pin that could have caught it, and none break:

• uses shallow history only for validation jobs asserts publish fetch-depth: 0 — retained.
• The checkout.with.ref pin over eight jobs asserts release_sha — retained.
• package-scripts.test.js asserts the publish Checkout step contains persist-credentials: false — retained.
• The exact-equality scriptCheckout.with assertion targets the scripts checkout, not this one.

No existing test pinned the removed token, so the new test is genuinely additive rather than a rewrite of a failing expectation.

Three non-blocking notes, none of which I'd hold the PR for:

1. The description is wrong on one point, though the code is right. It states the workflow "still receives secrets.CI_BOT_PAT at job level for the write steps." There is no job-level PAT — it is passed per-step, and package-scripts.test.js explicitly forbids the PAT in the publish job header (publishJob.slice(0, indexOf('steps:')).not.toContain('CI_BOT_PAT')). Worth correcting so a future reader doesn't "restore" a job-level PAT and trip that pin.
2. release-workflow.test.js (~line 296) justifies the full workspace wipe with "release checkouts carry CI_BOT_PAT and the npm OIDC id-token". After this change no checkout in the workflow carries the PAT, so that half of the rationale goes stale — the OIDC half still holds, so the wipe stays correct.
3. The new test pins the push step and release creation, but not Trigger ECS runner qwen update, the third PAT consumer the description mentions.

Risk: no elevated Stage 1e signals — neither file matches the revert-correlated path set.

Why I'm escalating instead of approving. This is the gate's release/auth rule, not a judgement call about quality: changes touching the release pipeline or credential wiring go to a maintainer rather than being auto-approved. .github/CODEOWNERS agrees independently — /.github/workflows/release.yml sits under "Primary npm release workflows require core maintainer approval" and is owned by @pomelo-nwu and @wenshao. There's also a real verification ceiling here: the end-to-end proof is a production dry-run release, which neither the author nor this gate can run. The same-run evidence above is as far as static review can honestly go.

So: I think the change is correct and well-targeted, and I'd be comfortable with it — but the call belongs to the release owners. @pomelo-nwu (lower current load of the two owners; cc @wenshao), assigning to you. Two things would make this a quick yes: a dry-run release to confirm the publish checkout succeeds on the run-scoped token, and the one-line description fix in note 1.

Note on CI at the time of writing: nothing red, but the unit and integration suites (Test (ubuntu-latest), Integration Tests (no-AK, No Sandbox), web-shell E2E Smoke, TUI parity snapshots) were still running on 4bb937c9632e7c7226093d47b9793a70ddea4179, with the Installed npm matrix queued. Lint & Static and Managed Agent gate had passed. I have not waited on them and am not reporting a result that does not exist yet.

Stopping at the gate here — no code-review or verdict comment will follow from this run.

中文说明

感谢贡献！这个 PR 我认真看过了，因为发布流程的凭据接线正是不能随便放过的改动。诊断成立，而且我是从失败的 run 里直接确认的，不是只采信 PR 描述。我没有直接批准，而是转交维护者——原因是下面那条策略规则，不是因为发现了缺陷。

模板完整 ✓ —— 所有必需标题都在，Risk & Scope 三条是实填而非模板套话，中文部分是真正的翻译。

问题：已观测，且有硬证据。 #15726 是一个开启状态的、机器提交的发布失败 issue。我拉取了 run 40486976670 的第 2 次尝试，Publish Release 任务确实在 Checkout 步骤失败，报错 fatal: could not read Username for 'https://github.com': terminal prompts disabled、git 退出码 128 —— 在重试阶梯上连续三次（14:25:54、14:26:14、14:26:25）。第 3 次尝试同一步骤通过了。所以这是真实且已复现的偶发失败，不是理论性加固。

方向：对齐，并且我独立验证了机制，没有直接采信描述。

• publish 任务声明了 contents: 'write'，因此运行范围令牌当然能读取公开仓库，描述里的能力论证成立。
• 最有力的证据在同一个失败 run 内部：另外六个任务通过 checkout_release_validation 锚点拉取完全相同的 needs.prepare.outputs.release_sha，且没有覆盖 token。在第 2 次尝试中，Quality Checks (Static) 成功拉取了 SHA 39076719e221c096dd039ae5aa023d608ef397fb，而旁边使用 PAT 鉴权的 publish 检出失败了。
• 我核查过差异是否出在凭据管道而非令牌本身 —— 不是。两个任务的日志显示完全相同的鉴权配置：凭据写入临时文件，加上四条 git config --local includeIf.gitdir:...。机制相同、SHA 相同、run 相同，只有令牌不同。这排除了 persist-credentials: false 是元凶，差异只能来自 PAT。
• 具体症状也支持这个判断。令牌有效但权限不足会报 403；而 could not read Username 意味着 git 手里没有可用凭据、退回到了交互式提示，这正是 PAT 被拒绝时在 GIT_TERMINAL_PROMPT=0 下的表现。
• 这个改动也让该检出更贴近工作流自身既定的设计：push-release-branch 已经写明"Keep the write credential unavailable until the push step needs it"，只在写入时才导出 GH_TOKEN="${CI_BOT_PAT}"。只读检出携带 PAT 才是那个例外。

CHANGELOG：无直接对应 —— 上游按这些关键词只命中一处无关的 footer badge 改动。这在意料之中，因为这是内部 CI 接线；无论如何该领域显然相关。

**规模：**不适用 —— 两个文件都不在 Stage 0 核心路径下。2 行生产代码（release.yml +1/−1），18 行测试代码（release-workflow.test.js +18/−0）。

方案：最小且范围准确。 一行接线改动，加一个锁定分工两端的元测试，符合 AGENTS.md 中"修改 CI 定义需同步更新工作流元测试"的要求。我把改动对照了所有可能拦住它的既有断言，都不会被破坏：

• uses shallow history only for validation jobs 断言 publish 的 fetch-depth: 0 —— 保留。
• 覆盖八个任务的 checkout.with.ref 断言 release_sha —— 保留。
• package-scripts.test.js 断言 publish 的 Checkout 步骤包含 persist-credentials: false —— 保留。
• 那条全等比较的 scriptCheckout.with 断言针对的是脚本检出，不是这个。

没有任何既有测试锁定被移除的 token，所以新测试是真正的增量，而不是改写一个原本失败的期望。

三条不阻塞的意见，我都不会为此卡住这个 PR：

1. 描述有一处不准确，但代码是对的。 描述称工作流"在任务级别仍会收到 secrets.CI_BOT_PAT 供写入步骤使用"。实际上并不存在任务级 PAT —— 它是逐步骤传入的，而且 package-scripts.test.js 明确禁止 publish 任务头部出现 PAT（publishJob.slice(0, indexOf('steps:')).not.toContain('CI_BOT_PAT')）。建议更正，以免后来者"恢复"一个任务级 PAT 而撞上这条断言。
2. release-workflow.test.js（约 296 行）用"release checkouts carry CI_BOT_PAT and the npm OIDC id-token"来论证整目录擦除的必要性。本改动之后工作流里已没有检出携带 PAT，因此这条理由的一半会失效 —— OIDC 那一半仍然成立，所以擦除逻辑本身依然正确。
3. 新测试锁定了推送步骤和创建 Release 步骤，但没有锁定 Trigger ECS runner qwen update，也就是描述中提到的第三个 PAT 消费方。

风险：无 Stage 1e 升级信号 —— 两个文件都不匹配与回滚相关的路径集合。

为什么选择上报而不是批准。 这是关卡的 release/auth 规则，不是对质量的主观判断：触及发布流程或凭据接线的改动应交由维护者决定，而非自动批准。.github/CODEOWNERS 也独立印证了这一点 —— /.github/workflows/release.yml 位于 "Primary npm release workflows require core maintainer approval" 之下，归属 @pomelo-nwu 和 @wenshao。这里还存在真实的验证上限：端到端证据是一次生产 dry-run 发布，作者和本关卡都无法执行。上面那份同 run 证据，已经是静态审查能诚实抵达的边界。

结论：我认为这个改动正确且目标精准，我个人是可以接受的 —— 但这个决定属于发布流程的 owner。@pomelo-nwu（两位 owner 中当前负载较低的一位；抄送 @wenshao），已把 PR 指派给你。有两件事能让它很快通过：一次 dry-run 发布以确认 publish 检出在运行范围令牌下成功，以及第 1 条那一行描述更正。

关于撰写时的 CI 状态：没有红色，但单元与集成测试套件（Test (ubuntu-latest)、Integration Tests (no-AK, No Sandbox)、web-shell E2E Smoke、TUI parity snapshots）在 4bb937c9632e7c7226093d47b9793a70ddea4179 上仍在运行，Installed npm 矩阵处于排队中。Lint & Static 与 Managed Agent gate 已通过。我没有等待它们，也不会去汇报一个尚不存在的结果。

本次运行到此为止 —— 不会再有代码审查或结论评论。

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

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

[wenshao]

Verdict: merge-ready — 47/47 scripted assertions passed at head 4bb937c9632e7c7226093d47b9793a70ddea4179.

中文摘要

结论：merge-ready（47/47 脚本化断言通过），验证对象为 head 4bb937c9（轮次开始与发布前两次读取一致）。这是本地维护者轮，不是 CI verify 产物。

中心主张成立：Publish Release 的只读检出不再使用长期 bot PAT，改用 actions/checkout 的默认 github.token；PAT 只保留在三个写入步骤（push release branch、Create GitHub Release、下游 dispatch）。

• A/B：base 工作流 + PR 自带的新测试 → 红，失败信息正是 expected '${{ secrets.CI_BOT_PAT }}' to be undefined；head 工作流 → 102 passed / 1 skipped。trial merge 到当前 main（6f53133）后同样 102/1 skipped。
• 变异矩阵 8/8：M1–M4（把 PAT 加回检出、persist-credentials 改 true、推送步去掉 PAT、Release 创建改用 github.token）全部被杀；同文件正控（改 concurrency group）也被杀。M5 存活——把下游 dispatch 改用 github.token，套件仍全绿（见建议 1）。M6（显式 token: ${{ github.token }}）会被判红，这是测试对"不得覆盖 token"的刻意收紧。
• 真实环境：取回被 pin 的 actions/checkout@df4cb1c（= v6.0.3，dist/index.js blob SHA 校验一致）实际执行三臂：无效 PAT → 事故同款 could not read Username ... terminal prompts disabled + git 128 + 2 次重试；空 token（secret 未配置时的形态）→ 直接拒检；匿名 ls-remote → 成功。生产 run 40486976670：attempt 2 只失败在 Checkout，attempt 3 同一 job 里 7 次默认 token 检出全部成功。
• 不阻塞的建议：1）新测试没钉住第三个 PAT 消费点 Trigger ECS runner qwen update；2）finalize-release.yml 仍有同款「只读检出 + 长期 PAT」，全仓 131 个 checkout 里只剩这 1 个；3）测试文件 ~296 行注释已过时；4）PR 描述写 PAT 是 "job level" 下发，实际是逐 step 的 env。
• 未覆盖：没有派发真实 dry-run 发布；本机无法铸造 runner 的 github.token（head 侧靠 action 自身默认值 + 生产默认 token 检出取证）；套件只在 macOS 跑（GNU-realpath 用例跳过）；未执行 release 工作流端到端。

Central claim and A/B

The PR's central claim is narrow: the publish job's first checkout is a read-only fetch, it already disables credential persistence, and it is the last read-only fetch in release.yml authenticated with the long-lived bot PAT. Removing that token: override should leave the fetch on the run-scoped github.token without changing what the fetch can reach, while every writing step keeps the PAT.

Two structural facts make the claim testable rather than rhetorical, both scripted:

• actions/checkout@df4cb1c069e1 is exactly the v6.0.3 tag commit, and its own action.yml declares token with default: ${{ github.token }} — so an absent with.token is the run-scoped token, not an empty credential.
• On base, release.yml had exactly one PAT checkout (this one); after the change it has zero, and the three write steps still receive the PAT. The publish job has no job-level env block in either revision.

Cell	Oracle	Base 32f6713ce6	Head 4bb937c963
A1	PR's new meta-test, run against each workflow	expected '${{ secrets.CI_BOT_PAT }}' to be undefined → 1 failed	pass
A2	full focused suite (scripts/tests/release-workflow.test.js)	101 passed, 1 skipped (102)	102 passed, 1 skipped (103)
A3	trial merge: git diff base..head applied to current origin/main 6f53133d6d	—	102 passed, 1 skipped (103)
A4	YAML assertions (token placement, ref/depth unchanged, census)	—	16/16

Witness for A1–A3: 04-suite-counts.png; the A1 failure text and the matrix in 03-mutation-matrix.png.

Mutation matrix

Each row applies exactly one literal edit to the head workflow, runs the selected test through the repo's own vitest config, then restores with git checkout HEAD -- and asserts a clean tree. The selected-test status comes from the JSON reporter, and every row reports matched=1 (no zero-collection false green).

Row	Mutation	Expected	Observed
BASE-YAML	base workflow + head test	test fails	failed ✔
M1	re-add token: secrets.CI_BOT_PAT to the publish checkout	fails	failed ✔
M2	persist-credentials: true on the publish checkout	fails	failed ✔
M3	drop CI_BOT_PAT from push_release_branch	fails	failed ✔
M4	Create GitHub Release uses github.token	fails	failed ✔
M5	downstream dispatch uses github.token	passes	passed — coverage gap
M6	explicit token: ${{ github.token }} on the checkout	fails	failed (strict-by-design)
CTRL	drop is_dry_run from the publish concurrency group (different test, same file)	fails	failed ✔

M5 is the one survivor, and it is the same point the triage comment raised: the PR body says the PAT stays for the downstream dispatch, but the new test only pins the push step and release creation.

Witness: 03-mutation-matrix.png.

Real-action arms and production evidence

The pinned action was downloaded at its exact SHA and executed with a scrubbed HOME and no host credentials. dist/index.js hashes to 906b59aff44f1df11c154e1e25397c7fafc12da5, the same blob the SHA serves.

Arm	Input	Result
A	no credential, anonymous git ls-remote	exit 0, refs/heads/main returned
B	empty token (what an unset CI_BOT_PAT secret renders to)	exit 1, ::error::Input required and not supplied: token
C	rejected PAT through the real action	exit 1, fatal: could not read Username for 'https://github.com': terminal prompts disabled, git 128, 2 retries

Arm C is the incident mechanism reproduced locally; the retry cadence (18 s, 16 s) matches the production log (20 s, 11 s).

Production run 40486976670:

• attempt 2's Publish Release failed only at Checkout, three times with the same message and exit 128;
• attempt 3 completed the same step and ran seven Checkout release workflow scripts steps — the workflow's other checkout, which has no token override and therefore already used the default token — all green. That is the run-scoped token fetching this repository inside the same job, on the same commit range.

Witness: 01-actions-checkout-arms.png and 02-production-run-logs.png.

Corrections

These correct descriptions, not code. The triage stage-1 comment raised the first three; this round confirms each independently and adds the measurement.

1. "Still receives secrets.CI_BOT_PAT at job level" is inaccurate. The publish job has no job-level env block in base or head; the PAT is per-step env on the three write steps only. package-scripts.test.js already forbids a job-level PAT in the publish header, so a future "restore" based on the sentence would trip that pin.
2. The rationale comment above canonicalWipe in the test file (~line 296) is now half stale. It says "release checkouts carry CI_BOT_PAT and the npm OIDC id-token". After this PR, zero checkouts in release.yml carry the PAT (census). The OIDC half still holds, so the full wipe remains correct — only the rationale needs a word.
3. The test does not pin the third PAT consumer. See M5 above.

One measurement note: the PR body's "103 tests pass" is the Linux figure. On this macOS host the same file is 102 passed + 1 skipped, because one case is gated on GNU realpath (test.skipIf(!hasGnuRealpath ...)). Nothing is wrong with the count; the platform differs.

Findings

All findings are non-blocking; none argues against merging.

S1 — the new test leaves the downstream dispatch unpinned. Trigger ECS runner qwen update still carries GITHUB_TOKEN: secrets.CI_BOT_PAT, and the PR body says the PAT remains for it, but the test asserts only push_release_branch and Create GitHub Release and Tag. Mutation M5 (switching that step to github.token) keeps the suite green, so a future edit could silently drop the PAT there and stop the downstream release-event workflows from firing.

Suggested addition (one assertion, same shape as the existing two):

expect(
  steps.find((step) => step.name === 'Trigger ECS runner qwen update').env
    .GITHUB_TOKEN,
).toBe('${{ secrets.CI_BOT_PAT }}');

S2 — the same read-only-PAT pattern survives in finalize-release.yml. A census over all 131 actions/checkout steps leaves exactly one PAT checkout: finalize-release.yml → finalize → Checkout release branch, with persist-credentials: false. Its later write re-authenticates independently (export GH_TOKEN="${CI_BOT_PAT}"; gh auth setup-git before the changelog push), so the PAT on that checkout is fetch-only — the same "auth dependency without added access" the issue describes. A transient PAT rejection would fail finalization the same way. This is a follow-up, not a defect in this PR.

N1 (note, not a request). M6 shows the test fails on any explicit token, including token: ${{ github.token }}. That matches the stated contract ("must not override the token"), so it looks deliberate; flagging it only so the next author is not surprised.

Not covered

• No production dry-run release was dispatched (needs release credentials; a local round should not mint them).
• The runner-minted github.token cannot be reproduced locally. The head side rests on the action's own default (${{ github.token }}) plus the production default-token checkouts above, not on executing with a real run-scoped token.
• The release workflow was not executed end to end; only the checkout credential path was driven.
• Suite runs are macOS/arm64 (Node 24.18.1) only; the GNU-realpath case is skipped there, and Windows/Linux counts are not measured.
• finalize-release.yml was inspected, not modified or run.
• Everything in A4 is YAML/AST-level; no GitHub-side permission evaluation was performed beyond the production observations.

Methodology

Three detached worktrees in a shallow clone: base 32f6713ce6 (gh pr view baseRefOid), head 4bb937c963, and a trial tree at origin/main 6f53133d6d with git diff base..head applied (git apply --check clean; main had not touched either changed file since base, verified by an empty git diff --stat). No dependency changes, so the root node_modules was reused and each tree resolved upward. The workflow meta-test was run with the repo's own scripts/tests/vitest.config.ts and JSON reporter; mutation rows apply one literal replacement with an exactly-one-match guard and restore via git checkout HEAD -- with a clean-tree assertion. Gates are actionlint, prettier --check, and eslint on the changed files, each paired with a planted violation. The prettier liveness check caught a real vacuity trap worth recording: running it from the repository root on an absolute path under tmp/ matches .gitignore's tmp/ and checks zero files, so the gate is run from inside the arm tree. Raw logs, harnesses, and the mutation/suite JSON are in this round's artifact directory; the four figures are hosted on wenshao/qwen-code branch assets/pr15728-verify, path r1-4bb937c/.

Figures

[qwen-code-dev-bot]

✅ AutoFix round 1 finished — view run. See this round's report below.

中文说明

✅ AutoFix 第 1 轮已完成 —— 查看运行。本轮报告见下方。

[qwen-code-dev-bot]

🤖 Addressed the latest review feedback (round 1/10). What changed, and what I pushed back on: · 已处理最新评审反馈（第 1/10 轮）。改动内容与我反驳保留之处如下：

Round summary — PR #15728 (head 4bb937c963)

Feedback in this window is one issue-level comment from @wenshao (verdict merge-ready). There were no review bodies and no inline comments, so nothing was resolved or replied to on a thread; every point is answered here.

I re-verified each point at head 4bb937c963 before acting on it.

S1 — downstream dispatch unpinned: refuted by a mutation probe, escalated as an open question

The finding says mutation M5 (switching Trigger ECS runner qwen update to github.token) "keeps the suite green", so a future edit could silently drop the PAT there. That premise does not hold for the full suite at this head.

Probe: in .github/workflows/release.yml, replace only that step's GITHUB_TOKEN: '${{ secrets.CI_BOT_PAT }}' with '${{ github.token }}', then run the whole scripts/tests/release-workflow.test.js (not just the new test). Result: 1 failed / 108 passed — release workflow > keeps a dispatch failure from failing an already-published release fails at release-workflow.test.js:3682, because it pins the exact continue-on-error: true + env: + GITHUB_TOKEN: '${{ secrets.CI_BOT_PAT }}' triplet. Deleting that GITHUB_TOKEN line outright fails the same test the same way (1 failed / 108 passed), so both a swap and a drop are caught. The tree was restored with git checkout -- .github/workflows/release.yml, and git status is clean.

So the new test is deliberately narrow, but the third PAT consumer is not unpinned: the existing test already kills M5. I did not add the suggested assertion because it would only duplicate that coverage. Open question for the author: was the intent to make the new test self-contained, or to close a real suite-level gap? If it is the former, I will add the five-line assertion next round; if the latter, no change is needed.

S2 — same read-only-PAT pattern in finalize-release.yml: verified, deferred

Confirmed at line 53: the finalize job's Checkout release branch passes CI_BOT_PAT to a persist-credentials: false fetch, and its Regenerate CHANGELOG.md step re-authenticates with gh auth setup-git before pushing, so the PAT on the checkout is fetch-only. A census over the 131 actions/checkout steps in .github/workflows finds exactly one CI_BOT_PAT override: this one. It is outside this PR's footprint, so it is recorded in deferred-findings.json for the follow-up queue rather than changed here.

N1 — explicit token: ${{ github.token }} fails: acknowledged

That is the intended contract ("must not override the token"), so no change.

Corrections

1. PR body: "job level" is wrong. The publish job has no job-level PAT; it is per-step env on push_release_branch, Create GitHub Release and Tag, and Trigger ECS runner qwen update. I cannot edit the PR body from this run (no GitHub credentials); the corrected sentence is: "The PAT stays exported per step to the three steps that write: push release branch, Create GitHub Release, and the downstream dispatch."
2. Stale canonicalWipe rationale: fixed. The comment now says release checkouts persist credentials and the publish job can mint the npm OIDC id-token, so the full wipe stays justified without claiming a checkout carries the PAT. This is the round's only code change.
3. Third PAT consumer: same as S1 (escalated above).

Net diff for the round: 0 added/removed lines (a 6-line comment reflow in a test file the PR already modifies).

Verification

• HOME=/tmp/fakehome npm run build — passed. (The sandbox HOME is read-only, so corepack's cache was redirected to a writable directory.)
• HOME=/tmp/fakehome npm run typecheck — passed.
• HOME=/tmp/fakehome npm run lint — passed.
• HOME=/tmp/fakehome npx vitest run --config ./scripts/tests/vitest.config.ts release-workflow — 2 files / 109 tests passed (release-workflow.test.js: 103).
• HOME=/tmp/fakehome npx prettier --check scripts/tests/release-workflow.test.js — passed.
• Mutation probes described above (swap and drop) — 1 failed / 108 passed each, then reverted; the final focused run above is green.
• Checkout census (Node + YAML parse over .github/workflows) — 131 actions/checkout steps, 1 CI_BOT_PAT override (finalize-release.yml), 1 explicit github.token override (qwen-triage.yml).

中文说明

本轮总结 —— PR #15728（head 4bb937c963）

本窗口的反馈只有 @wenshao 的一条 issue 级评论（结论 merge-ready）。没有 review body，也没有 inline comment，因此没有线程需要解决或回复；每个点都在这里作答。

动工前我在 head 4bb937c963 上逐条复核了每个点。

S1 —— 下游 dispatch 未被锁定：变异探针证伪，转为公开问题上报

该发现称变异 M5（把 Trigger ECS runner qwen update 改用 github.token）"整套测试仍然全绿"，因此未来某次修改可能悄悄丢掉 PAT。这个前提在当前 head 的完整套件上不成立。

探针：只把 .github/workflows/release.yml 中该步骤的 GITHUB_TOKEN: '${{ secrets.CI_BOT_PAT }}' 改成 '${{ github.token }}'，然后运行整个 scripts/tests/release-workflow.test.js（不是只跑新测试）。结果：1 失败 / 108 通过 —— release workflow > keeps a dispatch failure from failing an already-published release 在 release-workflow.test.js:3682 失败，因为它钉住了 continue-on-error: true + env: + GITHUB_TOKEN: '${{ secrets.CI_BOT_PAT }}' 这组原文。直接删掉该 GITHUB_TOKEN 行也会让同一个测试以同样方式失败（1 失败 / 108 通过），所以无论是替换还是删除都会被拦住。随后已用 git checkout -- .github/workflows/release.yml 还原，git status 干净。

所以新测试确实只覆盖两个写入步骤，但第三个 PAT 消费方并不是无人锁定 —— 既有测试已经能杀掉 M5。我没有添加建议里的断言，因为它只会重复那份覆盖。留给作者的问题是：意图是让新测试自身完整，还是补一个真实的套件缺口？如果是前者，下一轮我补上那五行断言；如果是后者，则无需改动。

S2 —— finalize-release.yml 里同样的只读 PAT 模式：已核实，转为后续项

已在第 53 行确认：finalize 任务的 Checkout release branch 仍把 CI_BOT_PAT 传给一个 persist-credentials: false 的只读拉取，而它的 Regenerate CHANGELOG.md 步骤会在推送前用 gh auth setup-git 重新鉴权，因此检出上的 PAT 只用于拉取。对 .github/workflows 中 131 个 actions/checkout 步骤做普查，只找到一处 CI_BOT_PAT 覆盖：就是这一处。它不在本 PR 的改动范围内，因此记录到 deferred-findings.json 交给后续队列，本轮不改。

N1 —— 显式 token: ${{ github.token }} 会红：已知悉

这正是刻意收紧的契约（"不得覆盖 token"），无需改动。

更正项

1. PR 描述里的"job level"不准确。 publish 任务没有任务级 PAT；它是逐步骤 env，只出现在 push_release_branch、Create GitHub Release and Tag 和 Trigger ECS runner qwen update 三步。本轮没有 GitHub 凭据，无法编辑 PR 描述；更正后的句子是："The PAT stays exported per step to the three steps that write: push release branch, Create GitHub Release, and the downstream dispatch."
2. canonicalWipe 的过时理由：已修正。 注释现在写的是 release 检出会持久化凭据、publish 任务可以铸造 npm OIDC id-token，因此整目录擦除依然成立，同时不再声称检出携带 PAT。这是本轮唯一的代码改动。
3. 第三个 PAT 消费方：同 S1（已在上文上报）。

本轮净 diff：新增/删除 0 行（只是在 PR 已经修改的测试文件里重排了 6 行注释）。

验证

• HOME=/tmp/fakehome npm run build —— 通过。（沙箱里的 HOME 只读，因此把 corepack 缓存指向了可写目录。）
• HOME=/tmp/fakehome npm run typecheck —— 通过。
• HOME=/tmp/fakehome npm run lint —— 通过。
• HOME=/tmp/fakehome npx vitest run --config ./scripts/tests/vitest.config.ts release-workflow —— 2 个文件 / 109 个测试通过（release-workflow.test.js：103）。
• HOME=/tmp/fakehome npx prettier --check scripts/tests/release-workflow.test.js —— 通过。
• 上述变异探针（替换与删除两臂）—— 各为 1 失败 / 108 通过，随后还原；上面最后一次聚焦运行全绿。
• 检出普查（Node + YAML 解析 .github/workflows）—— 131 个 actions/checkout 步骤，1 处 CI_BOT_PAT 覆盖（finalize-release.yml），1 处显式 github.token 覆盖（qwen-triage.yml）。

Base-conflict check · 基分支冲突检查: no conflict with main. · 与 main 无冲突。

Re-review when you have a moment. After round 10 this bot stops and leaves the PR for a human. · 有空请复审；第 10 轮后本 bot 停止并将 PR 交给人工。

---

🧠 Handled by Qwen Code · model/模型 deepseek-v4.1-flash-1017 · CLI 0.26.2

[qqqys]

Critical-only scan at head d1632c1a. Verdict: APPROVE — no prior blocking findings exist on this PR, and the current scan found no provable blocking defect.

What the change does

One production line: the publish job's read-only Checkout in .github/workflows/release.yml:656-662 drops token: '${{ secrets.CI_BOT_PAT }}' and falls back to the run-scoped GITHUB_TOKEN, keeping ref, fetch-depth: 0 and persist-credentials: false unchanged.

Why the run-scoped token is sufficient here

• The publish job declares permissions: contents: 'write' (:646-647), so the default token can read this repository; the checkout names no repository: override, so it fetches from the same repo the token is scoped to.
• ref is needs.prepare.outputs.release_sha, a commit of this repository — the same value, fetch-depth and persistence behaviour as before, so only the authenticating identity changed.
• The workflow already proves the default token can fetch here: the checkout_release_workflow_scripts anchor (:161-180) has no token override and is reused seven times inside publish itself (:693, :703, :725, :733, :744, :756, :764), and prepare's own full-depth checkout (:156-160) uses it too. Those paths are exercised on every release.
• Triggers are schedule and workflow_dispatch (:3-10), never pull_request, so there is no restricted fork-token context in which the default token would be read-only.

No write path lost its credential

CI_BOT_PAT appears exactly three times after the change, and all three are writes:

• :713 — Conditionally push release branch (push_release_branch), which also receives GITHUB_TOKEN: github.token;
• :780 — Create GitHub Release and Tag, with the in-file reason that a GITHUB_TOKEN event cannot trigger downstream release-event workflows;
• :795 — Trigger ECS runner qwen update (repository_dispatch).

No step's env block was touched, and the removed token was never persisted (persist-credentials: false predates this PR), so nothing downstream could have inherited git credentials from that checkout.

Test

scripts/tests/release-workflow.test.js:3479-3495 pins both halves of the split: the publish checkout has no token and keeps persist-credentials: false, while push_release_branch still gets CI_BOT_PAT and Create GitHub Release and Tag still gets it as GITHUB_TOKEN. The lookups fail loudly rather than passing vacuously — a missing step makes .with / .env throw. The reworded canonicalWipe rationale at :295-301 leaves the pinned body byte-identical, so the equality pin still holds.

CI at this head

Everything reported is green — Test (ubuntu-latest, Node 22.x) (35m37s), Lint & Static, Integration Tests (no-AK), web-shell E2E Smoke, the TUI gates and all four Installed npm global and npx lanes. Nothing red or pending is attributable to this change.

One non-blocking number worth knowing, since it bears on the next PR that touches this file: release.yml is 40032 bytes at this head against a recorded .size-baseline:58 of 35955 — an overage of 4077 bytes, inside the growth allowance of 4096 that check-workflow-size.sh:33 sets and the workflow-size.test.js "is within its baseline allowance" case reads back from it, with 19 bytes of headroom left. The ratchet's stale-baseline leniency would not cover this file, because it only applies when the file is byte-identical to the PR's base and this PR edits it; the allowance is what keeps the gate green here.

[qwen-code-review-bot]

Released in v0.26.3.