Cloud Agent gh/git token missing issues:write despite GitHub App being granted Issues: Read & write

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

In a Cloud Agent run, the injected GitHub App installation token can read the repo and push commits (contents:write), but every Issues API call fails with 403 Resource not accessible by integration. Our org’s Cursor GitHub App is granted Issues: Read and write, so the agent token appears to be minted with a narrower permission set than the installation actually holds. This blocks automations that file GitHub issues (e.g. a code-audit agent that opens triaged issues for findings).

Environment

  • Cursor Cloud Agent (background automation, cron-triggered)
  • Repo: GitHub organization, private
  • GitHub App: Cursor — confirmed granted Issues: Read and write at the org installation
  • Token type observed on VM: GitHub App installation token (x-access-token:… git remote)

Questions for Cursor

  • Is issues intentionally excluded from the Cloud Agent installation token? If so, can it be opt-in (e.g. per-repo or per-automation setting)?
  • Is there a setting that makes the agent token inherit the full granted permission set of the installed GitHub App?

Steps to Reproduce

  • Run a Cloud Agent on a repo whose Cursor GitHub App has Issues: write granted.
  • From the agent, run gh issue create … (or gh api -X POST /repos/{owner}/{repo}/issues).

Expected Behavior

Issue is created, since the installation has Issues: Read and write.

Actual

HTTP/2.0 403 Forbidden
X-Accepted-Github-Permissions: issues=write
{"message":"Resource not accessible by integration","status":"403"}

Evidence / diagnosis (run from inside the agent VM)

Operation	                         Result	       Required perm

`GET /repos/{owner}/{repo}`          200           metadata=read ✅
`git push` (new branch)              success       contents=write ✅
`POST /repos/{owner}/{repo}/issues`  403           issues=write ❌
`POST /…/issues/{n}/comments`        403           issues=write; pull_requests=write ❌

The token is clearly not blanket read-only (it has contents:write); it is specifically missing issues. Since the org installation grants Issues: write, this points to the per-run agent token being down-scoped to a subset of the app’s permissions, rather than an org-side configuration gap.

Operating System

MacOS

Version Information

No updates available
Version: 3.7.36
VS Code Extension API: 1.105.1
Commit: 776d1f9d76df50a4e0aeca61819a88e7c1b861e0
Date: 2026-06-13T00:31:56.287Z (3 days ago)
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

For AI issues: which model did you use?

Opus 4.8

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

Hey @MishaTheMisha

Thanks for raising this! This is a known limitation we are working on resolving.

In the meantime, some users have found a workaround by adding a GH_TOKEN with the repo scope in their Cloud Agent settings.

We are experiencing the same thing at my org

Still having the issue after a month.

New (paying) customer here. I immediately ran into this bug as I started to explore Cursor. Surprising, and creating a very poor initial impression. Shouldn’t this be pretty simple to fix?

I’m still running into this issue as well.

The strange thing is, we had one automation working about six weeks ago where it would automatically create Pull Requests for us based on a schedule. I tried creating a different PR today where it triggers on new commits in main. It was able to see the commits and even push new ones, but was not able to create a pull request. Same tools/skills as the original automation.

From the agent session, it appears that the original automation connects via MCP and this new one was (unsuccessfully) trying to add a GitHub action.

Need this fixed.. cloud is kinda useless without it really as issues can’t get updated etc.

The automation we had working has now broken as well. This is so sloppy and inconsistent.

Given the way this has been handled, Cursor’s new Codebase feature is going to be a hard pass from us.

This is a dealbreaker. do you have ETA for fixing it?