[hassiebp]

What does this PR do?

Replaces the long-lived GH_ACCESS_TOKEN personal access token in the release workflow with a GitHub App installation token that is minted per run and expires after one hour. Same change as langfuse/langfuse-js#1049.

• The job's default GITHUB_TOKEN drops to contents: read; checkout no longer uses a PAT.
• The App token is minted only after the build and the wheel/sdist smoke tests, so build backends and test installs never see a write token.
• The token is scoped to permission-contents: write and is passed only to the tag push and gh release create steps.
• PyPI publishing is unchanged (Trusted Publishing via OIDC on the protected branches environment).
• CONTRIBUTING.md lists the PyPI trusted publisher and release App prerequisites.

Stays a draft until the release GitHub App exists, its RELEASE_APP_CLIENT_ID variable and RELEASE_APP_PRIVATE_KEY secret are on the protected branches environment, and the App is on the bypass lists for main and the v* tag rulesets. Until then, releases can't push to main either way, because main no longer allows bypassing branch protection.

Type of change

• Bug fix
• New feature
• Breaking change
• Refactor
• Documentation update
• Tooling, CI, or repo maintenance

Verification

uvx zizmor --offline .github/workflows/release.yml   # No findings (2 suppressed, down from 4 on main)
uvx --from actionlint-py actionlint .github/workflows/release.yml   # only the existing empty-option warning on line 22, unchanged from main

Not run: a release dry run. The workflow has no dry-run mode and needs the App to exist.

Checklist

• I self-reviewed the diff using code_review.md.
• I added or updated tests for behavior changes.
• I updated docs, examples, or .env.template if needed.
• I did not hand-edit generated files; if generated files changed, I used the upstream regeneration path.
• I did not commit secrets or credentials.

  

Confidence Score: 5/5

The code appears safe to merge once the App setup prerequisites acknowledged by hassiebp are complete.

Summary

Replaces the release workflow’s long-lived personal token with a short-lived GitHub App token.

• The release workflow uses a short-lived App token for GitHub writes.

hassiebp acknowledges that the App, environment settings, and bypass permissions must exist before this draft is ready.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Checkout with read access] --> B[Build and smoke tests]
  B --> C[Commit version locally]
  C --> D[Create GitHub App token]
  D --> E[Push version commit and tag]
  E --> F[Publish to PyPI with OIDC]
  F --> G[Create GitHub release with App token]

Loading

_{Reviews (1) · Last reviewed commit: "ci(release): push releases with a short-..." · Reviewed by Greptile}

[github-actions]

@claude review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-22T12:12:03.722216Z	8e669a8	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[claude]

Claude Code Review

No review was started: this request came from a bot account. Manual reviews can only be requested by someone with write access to this repository. Ask a maintainer to comment @claude review, or have your automation post the comment from a user account with write access.

_{Tip: disable this comment in your organization's Code Review settings.}

[hassiebp]

@claude review

[claude]

I reviewed this PR and didn't find any bugs. It changes the credentials the release workflow uses to push to main and to tags, and .github/ has a CODEOWNERS entry for maintainers, so a maintainer should still review it.

What was reviewed:

• Every step after the change for leftover uses of GH_ACCESS_TOKEN or gh. Only the tag push and gh release create need auth, and both now get the App token through GH_TOKEN.
• gh auth setup-git in the push step. The git credential helper runs in that same step's environment, so it picks up GH_TOKEN. Checkout still uses persist-credentials: false with the read-only default token.
• Where the token is minted: after the build, both smoke tests and the version commit, so nothing that runs package code sees a write token. The action is pinned by SHA, and the step order around the PyPI publish is the same as before.

Extended reasoning...

The change touches only .github/workflows/release.yml and CONTRIBUTING.md. It replaces a long-lived personal access token with a GitHub App token scoped to contents: write for the tag push and the GitHub release, and it lowers the workflow's default contents permission to read. The sensitive part is the release credentials and the branch/tag protection bypass, but nothing here touches application code. I deferred because .github/ is owned by the maintainers team in .github/CODEOWNERS and the change alters release credentials. Also, the workflow can't be fully checked until the App, its variable and secret, and the ruleset bypasses exist.

[claude]

Code review found no issues

No high-confidence issues detected in this change.