chore(release): avoid persisted checkout credentials

[Wibias]

Summary

• disable credential persistence for the Release workflow checkout
• keep the workflow's write-capable GITHUB_TOKEN out of the checkout's Git authentication configuration
• leave explicit GitHub API authentication and npm OIDC publishing unchanged

Why

actions/checkout persists its authentication credentials by default.

The Release workflow has contents: write, so keeping those credentials in the checkout means later workflow steps can implicitly authenticate Git operations such as git push without explicitly requesting or configuring credentials.

The current Release workflow does not rely on that behavior:

• repository Git operations after checkout are read-only
• GitHub API and release operations use the explicitly provided GH_TOKEN
• npm publishing uses Trusted Publishing via OIDC
• the release helper performs its branch push before the Release workflow is dispatched

Setting persist-credentials: false therefore removes an unnecessary ambient write credential while preserving the existing release flow.

Impact

Normal release behavior is unchanged.

A future workflow step that intentionally needs an authenticated Git write will need to configure authentication explicitly rather than inheriting checkout credentials.

Review

Ready for review.

@lidge-jun @Ingwannu

Summary by CodeRabbit

• Chores
  • Improved release workflow security by preventing checkout credentials from being persisted.
  • Streamlined release publishing to create version tags more securely and reliably, helping ensure new releases are made available consistently.

[github-actions]

✅ Deterministic PR hygiene checks passed.

[coderabbitai]

Warning

Review limit reached

@Wibias, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 12 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 805cca60-03ef-4b9d-a90d-ded0a2006236

📥 Commits

Reviewing files that changed from the base of the PR and between 6c14e34 and 1965ddd.

📒 Files selected for processing (2)

• .github/workflows/release.yml
• tests/ci-workflows.test.ts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Ingwannu]

Approved on exact head 1965dddf76c2f6ca50f46fe8c9101922ec17a721. persist-credentials: false removes the checkout token from Git configuration, and tag creation now uses the explicitly scoped GH_TOKEN through the GitHub refs API only after release notes are rendered. The change preserves the existing exact-SHA and pre-existing-tag checks, targets dev, is mergeable, and exact-head CI is green.

[Ingwannu]

This remains approved and merge-ready at exact head 1965dddf76c2f6ca50f46fe8c9101922ec17a721; CI is fully green and the release credential boundary has been reviewed.

I attempted the merge again, but GitHub rejects this maintainer token because the PR modifies .github/workflows/release.yml and the OAuth token does not carry the workflow scope. I am not bypassing that guard with a direct push. @lidge-jun or another maintainer with the required workflow authority can merge this into dev without further changes.

[lidge-jun]

Reviewed during today's landing round and deliberately not merged — this needs a maintainer security review, not a routine merge.

The change looks correct on its face: persist-credentials: false on the Release checkout, and tag creation moved from git tag + git push to gh api --method POST .../git/refs. Both reduce the blast radius of the workflow's write-capable GITHUB_TOKEN.

But AGENTS.md puts release automation (.github/workflows/release.yml, scripts/release.ts) behind explicit security review, and that rule exists precisely so a plausible-looking workflow change cannot ride in on a bug-fix train. Everything else in today's round was product code with test coverage; this is the one PR where correctness is not the question — authority is.

Leaving it open and unmerged for a maintainer to review against MAINTAINERS.md. No changes requested; this is a routing decision.