fix(ci): restrict workflow token permissions

[vincentkoc]

Summary

• restrict the CI workflow token to read-only repository contents
• remove reliance on GitHub's broader implicit token defaults

CodeQL

• resolves alert #1

Testing

• actionlint .github/workflows/ci.yml
• git diff --check origin/main...HEAD

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed August 25, 2026, 3:33 PM ET / 19:33 UTC.

ClawSweeper review

What this changes

This PR adds a read-only default GitHub Actions token permission to the CI workflow.

Merge readiness

✅ Ready for maintainer review

Keep this MEMBER-authored draft PR open for normal review. Current main still lacks an explicit workflow token policy, while this narrow least-privilege change is compatible with the CI job’s checkout and local build steps.

Priority: P2
Reviewed head: 62ef9c822d4a1db2a252ad0f37b54c75b126fe7e

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A narrow least-privilege change with successful checks and no identified correctness defect.
Proof confidence	🌊 off-meta tidepool	Not applicable: This MEMBER-authored CI hardening PR is exempt from the external-contributor real-behavior-proof gate; the reported actionlint check and successful GitHub checks remain useful supplemental validation.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Not applicable	Not applicable: This MEMBER-authored CI hardening PR is exempt from the external-contributor real-behavior-proof gate; the reported actionlint check and successful GitHub checks remain useful supplemental validation.
Evidence reviewed	4 items	Current main lacks the hardening: The current main workflow has no top-level permissions block before its build job, so the requested least-privilege default is not already implemented. Patch scope and CI compatibility: The PR adds only contents: read; the sole job checks out source with actions/checkout and then runs local Swift, shell, and release-harness commands. Workflow ownership history: Blame attributes the existing CI workflow lines, including its checkout and validation steps, to the v0.3.4 release commit by Peter Steinberger.
Findings	None	None.
Security	None	None.

Live Verification

Command: make help

Result: PASS (completed)

make format    - swift format in-place
make lint      - Swift, shell, and workflow lint
make test      - sync version + swift test (coverage enabled)
make check     - lint + test + coverage gate
make build     - release build into bin/ (codesigned)
make macos-artifact - build credential-free universal local candidate
make release-harness - test release scripts with credential-free mocks
make release-check TAG=vX.Y.Z - validate release preflight
make remindctl - clean rebuild + run debug binary (ARGS=...)
make docs-site - build GitHub Pages docs into dist/docs-site
make clean     - swift package clean
make format    - swift format in-place
make lint      - Swift, shell, and workflow lint
make test      - sync version + swift test (coverage enabled)
make check     - lint + test + coverage gate
make build     - release build into bin/ (codesigned)
make macos-artifact - build credential-free universal local candidate
make release-harness - test release scripts with credential-free mocks
make release-check TAG=vX.Y.Z - validate release preflight
make remindctl - clean rebuild + run debug binary (ARGS=...)
make docs-site - build GitHub Pages docs into dist/docs-site
make clean     - swift package clean

Assertions:

• PASS expect_output: make lint - Swift, shell, and workflow lint

How this fits together

The CI workflow builds and validates remindctl on pushes and pull requests. GitHub supplies the workflow token, which the workflow uses for source checkout before local validation commands run.

flowchart LR
  A[Push or pull request] --> B[CI workflow]
  B --> C[Read-only workflow token]
  C --> D[Source checkout]
  D --> E[Build and validation]
  E --> F[CI checks]

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Workflow permission delta	1 workflow changed; 3 lines added, 0 removed	A single top-level policy narrows the token available to the entire CI workflow.

Technical review

Best possible solution:

Merge the workflow-wide least-privilege default after normal maintainer review, retaining read access for checkout and avoiding unnecessary write scopes.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this is preventive workflow-token hardening, not a reported runtime failure.

Is this the best way to solve the issue?

Yes: a top-level read-only default is the narrowest maintainable solution because the current job only checks out source and runs local validation.

AGENTS.md: not found in the target repository.

Codex review notes: model internal, reasoning high; reviewed against bc9c2ed9e961.

Labels

Label changes:

• add P2: This is a bounded CI security-hardening change with limited user-facing blast radius.
• add rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This MEMBER-authored CI hardening PR is exempt from the external-contributor real-behavior-proof gate; the reported actionlint check and successful GitHub checks remain useful supplemental validation.

Label justifications:

• P2: This is a bounded CI security-hardening change with limited user-facing blast radius.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🌊 off-meta tidepool and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Not applicable: This MEMBER-authored CI hardening PR is exempt from the external-contributor real-behavior-proof gate; the reported actionlint check and successful GitHub checks remain useful supplemental validation.

Evidence

What I checked:

• Current main lacks the hardening: The current main workflow has no top-level permissions block before its build job, so the requested least-privilege default is not already implemented. (.github/workflows/ci.yml:8, bc9c2ed9e961)
• Patch scope and CI compatibility: The PR adds only contents: read; the sole job checks out source with actions/checkout and then runs local Swift, shell, and release-harness commands. (.github/workflows/ci.yml:8, 62ef9c822d4a)
• Workflow ownership history: Blame attributes the existing CI workflow lines, including its checkout and validation steps, to the v0.3.4 release commit by Peter Steinberger. (.github/workflows/ci.yml:12, 762ff39a6290)
• Release and main status: The latest released commit is v0.3.4 at 762ff39, which predates this open PR; current main is bc9c2ed and likewise lacks the permission block, so the fix is neither released nor on main. (.github/workflows/ci.yml:8, 762ff39a6290)

Likely related people:

• Peter Steinberger: Current-main blame assigns the CI workflow’s existing checkout and validation lines to the v0.3.4 release commit. (role: workflow origin author; confidence: high; commits: 762ff39a6290; files: .github/workflows/ci.yml)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.