[julianrubino]

What

Adds job-level permissions: to the node jobs that write with GITHUB_TOKEN:

Workflow / job	Scopes	Why (evidence in the job)
e2e.yml / build-zetanode	contents: read, packages: write	docker/login-action to ghcr.io with GITHUB_TOKEN, build-push-action push: true + registry cache-to
e2e.yml / e2e-ok	actions: read, pull-requests: write	actions.listJobsForWorkflowRunAttempt, issues.addLabels (MERGE_FAILED, already exists)
sast-linters.yml / nosec_alert	contents: read, pull-requests: write	mshick/add-pr-comment, issues.addLabels (nosec, already exists)
semgrep.yml / semgrep	contents: read, security-events: write	codeql-action/upload-sarif (repo is public, so actions: read isn't needed)
release-status-changer.yml / run-script	contents: write	check_and_update.py calls PyGithub release.update_release
publish-release-zetaclient.yml, publish-release-zetacore.yml / release	contents: write, id-token: write, attestations: write	the caller job has to grant what release-template.yml publish-release requests; a reusable workflow can't get more than its caller grants

Not changed: reusable-e2e.yml only pulls from ghcr (read). matrix-conditionals only reads PRs. generate-files, release-test-build and semantic-pr only read.

Evidence / testing

• Parsed every workflow and local composite action in the repo (PyYAML). Listed the jobs without permissions: and grepped their steps for token writes (git push, gh release/pr, github-script REST calls, ghcr push, SARIF upload, third-party actions that write with github.token).
• actionlint on the changed files: no new findings.

Why

INC-13809 hardening. The org default GITHUB_TOKEN permission is write on every scope. The plan is to switch the org default to read-only (default_workflow_permissions=read), so a leaked or hijacked job token can't push code, cut releases or edit PRs unless the job explicitly asks for it.

The jobs below write with GITHUB_TOKEN and have no permissions: block, so they rely on the write default and would break after the switch. This PR declares the minimal scopes each one uses. It doesn't change behavior today: the declared scopes are a subset of the current write default. Unlisted scopes become none for these jobs only, and I checked every step in each job, so none of them uses an unlisted scope.

Jobs and workflows not listed already declare permissions: or only read with the token.

Rollback

Revert this PR.

Merge order

Merge before the org-level flip (gh api -X PUT orgs/<org>/actions/permissions/workflow -f default_workflow_permissions=read). The flip happens after all PRs in this set are merged.

Confidence Score: 5/5

The PR appears safe to merge; the declared permissions cover the changed jobs’ existing token use.

Summary

This PR gives jobs explicit GITHUB_TOKEN permissions before the organization switches its default to read-only.

• The node image job can publish to GHCR with a limited token.
• The end-to-end status job can read run details and update pull-request labels.
• The nosec alert job can comment on pull requests with a limited token.
• The Semgrep job can upload security findings with a limited token.
• The release status updater can edit releases with a contents-only token.
• ZetaClient and ZetaCore release callers pass the needed permissions to the shared publisher.

No actionable issues were found.

_{Reviews (2) · Last reviewed commit: "ci: declare explicit GITHUB_TOKEN permis..." · Reviewed by Greptile}

[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-21T03:49:52.558173Z	bbb866b	PR opened

ℹ️ 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.

[julianrubino]

@greptileai review

[julianrubino]

@greptileai review