Scheduled Automations overnight token cannot addComment / close PRs despite GitHub App Issues + Pull requests Write (Draft PR Hygiene)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

Where does the bug appear?

Cursor Automations / scheduled overnight runs (Background Agent style GitHub token in automation sandbox). Product surface: scheduled Automation draft-pr-hygiene-sweep on repo beakerteeter/CP-Product-Advisory.

Describe the Bug

Our overnight Draft PR Hygiene sweep runs:

node scripts/draft-pr-hygiene-sweep.mjs

which calls:

gh pr close <N> --comment "…"

Every close fails first on GraphQL addComment with:

Resource not accessible by integration

Result: 0 closed, backlog ~40–42 stale app/cursor + cursor/* draft PRs accumulating nightly.

Confirmed NOT an install misconfig

Owner verified Cursor GitHub App install on beakerteeter/CP-Product-Advisory already shows Issues: write and Pull requests: write. We will not reinstall (known community anti-pattern / reinstall loop).

This matches Cursor staff/community reports that the runtime installation token handed to agents/automations is intentionally narrower than the App install permissions visible in GitHub settings so dashboard/install can show Write while gh pr comment / addComment still 403.

Related community threads (same class of gap):

Ask

Please make the scheduled Automation / overnight runtime token honor App-granted Issues:write + Pull requests:write, or expose an explicit PR Comment capability so gh pr close --comment works for close-only hygiene sweeps.

Alternatively document the supported path for Automations (e.g. secret named exactly GH_TOKEN / GITHUB_TOKEN for gh) if App-scoped tokens will stay conservative.

Steps to Reproduce

  1. Install Cursor GitHub App on a private repo with Issues write + Pull requests write.
  2. Schedule an Automation that runs gh pr close <open-cursor-draft> --comment "hygiene".
  3. Observe GraphQL addComment → Resource not accessible by integration; PR remains open.
  4. Confirm App install UI still shows Issues/PR write (no reinstall needed).

Expected

gh pr close --comment succeeds when App install grants Issues write + Pull requests write (or when PR Comment capability is enabled).

Actual

addComment 403 via integration token; 0 PRs closed overnight.

Evidence (our desk)

  • Overnight Proof Log · Draft PR Hygiene · Run Date 2026-09-26: FAILED — 42 failed closes, 0 closed (URL omitted due new-user link limit)
  • Policy/script: scripts/draft-pr-hygiene-sweep.mjs + docs/engineering/2026-09/hub-sync-auto-merge.md in the CP-Product-Advisory repository (URL omitted due new-user link limit)

Impact

Stale Cursor automation draft PRs accumulate; overnight hygiene Broken every night until runtime token includes comment/close scopes.

Workaround status

Not applying personal PAT into overnight automation yet (prefer platform fix). Willing to try documented GH_TOKEN secret path for Automations if that is the supported interim.

Steps to Reproduce

  1. Install Cursor GitHub App on a private repo with Issues write + Pull requests write.
  2. Schedule an Automation that runs gh pr close <open-cursor-draft> --comment "hygiene".
  3. Observe GraphQL addComment → Resource not accessible by integration; PR remains open.
  4. Confirm App install UI still shows Issues/PR write (no reinstall needed).

Operating System

Other

Version Information

Scheduled Automation runtime; no IDE version applicable.

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Hey @Clint_Pracher - you’ve got it exactly right, and this is expected rather than a misconfiguration. The token cloud agents and Automations run with is deliberately narrower than the App install: read-only on pull requests, no issues access. So gh pr close --comment can’t comment or close, and dropping --comment won’t help since the close itself needs pull-request write.

The supported fix is the GH_TOKEN route you guessed:

  1. Create a fine-grained GitHub PAT scoped to beakerteeter/CP-Product-Advisory with Pull requests: Read and write and Issues: Read and write.
  2. In the Cursor dashboard under Cloud Agents → Secrets, add it as a secret named exactly GH_TOKEN (use the Runtime Secret type to keep it out of logs/commits). Automations inherit these secrets, so your scheduled run picks it up, no script changes needed.

Two notes: the closes will show under the token owner’s account (use a bot account if you’d rather not attribute to a person), and keep the agent on the default “Allow all” network mode or the PAT can get overridden.

Making the runtime token honor the App’s granted permissions is feedback we’ve passed along, no timeline yet, but I’ll post here if that changes.

7

Adding GH_TOKEN (with repo scope) as a Cloud Agent secret doesn’t fix this on its own. The agent’s built-in instructions still say gh is read-only and that PR edits must go through Cursor’s PR tool. That tool can’t upload images as GitHub attachments, so screenshots either go to public cursor.com/artifacts links or I have to run the upload command myself and paste the URLs back. If I’ve supplied a token with write scope, the agent should be allowed to use it. But it will staunchly refuse. Some models like Grok can sometimes be convinced, but Opus and Sol will always refuse.