Prevent Bonk from pushing commits.

[teamchong]

Bonk ignored the review prompt on #201 and pushed a commit. Prompt instructions are not a reliable security boundary.

This sets token_permissions: NO_PUSH for both automatic reviews and /bonk invocations. Bonk retains permission to post comments, reviews, and suggestions, but cannot push commits.

Documentation: https://github.com/Cloudflare-Studio/ask-bonk/blob/24832587005550860c8ad13fd96519e731ca632a/README.md#token-scoping

[changeset-bot]

⚠️ No Changeset found

Latest commit: d54144f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/cloudflare/capnweb@217

commit: d54144f

[teamchong]

/bonk review this

[ask-bonk]

Review: token_permissions: NO_PUSH

The change is correct and well-motivated. As the PR body notes, prompt instructions are not a security boundary, so enforcing NO_PUSH at the token level is the right approach. I confirmed against the ask-bonk docs that token_permissions is a supported input and that NO_PUSH sets contents: read while retaining issues: write and pull_requests: write — so Bonk can still comment, review, and suggest, but cannot push. The docs also note invalid values fail closed to NO_PUSH, which is the safe default.

Two things worth confirming before merge (non-blocking):

1. Different action SHAs across the two workflows. bonk-pr-review.yml pins 24832587... (the commit the docs link references), but bonk.yml pins c39e982d.... The token_permissions feature must exist in both pinned revisions to take effect. Please confirm c39e982d includes token scoping — if it predates the feature, the bonk.yml change would be silently ignored and Bonk would retain push access on /bonk invocations, which is exactly the case this PR is trying to close. Consider pinning both to the same known-good SHA.

2. Stale job-level contents: write in bonk.yml (line 27, outside the diff). Now that the installation token is scoped NO_PUSH, the job still declares contents: write for the default GITHUB_TOKEN. It is not the token that pushes here, but it is now misleading. For defense-in-depth and to match bonk-pr-review.yml (which uses contents: read), consider reducing it to read — unless another step relies on the default token for content writes.

Net: LGTM assuming point (1) checks out. This is a meaningful hardening.

[ask-bonk]

Review posted successfully: #217 (review)

Summary

I reviewed PR #217, which adds token_permissions: NO_PUSH to both Bonk workflows.

Verdict: LGTM — correct and well-motivated hardening. I verified against the ask-bonk docs that token_permissions: NO_PUSH is a supported input that sets contents: read while keeping issues: write / pull_requests: write, so Bonk retains commenting/review/suggestion abilities but loses push. Enforcing this at the token level (rather than via prompt) is the right call.

Two non-blocking follow-ups flagged:

1. Mismatched action SHAs — bonk-pr-review.yml pins 24832587... (the doc-referenced commit) but bonk.yml pins c39e982d.... The token_permissions feature must exist in both pinned revisions; if c39e982d predates it, the bonk.yml change is silently ignored and the push gap remains open on /bonk invocations. Recommended pinning both to the same verified SHA.

2. Stale contents: write — bonk.yml's job-level permissions still grant contents: write to the default GITHUB_TOKEN (line 27, outside the diff), which is now misleading. Suggested aligning it with bonk-pr-review.yml's contents: read for defense-in-depth.

github run

[kentonv]

It would be kind of nice if we could actually ask bonk to push changes when we explicitly want it to, maybe we could define a separate slash command for that or something.

(No need to action in this PR.)