Connect a GitHub repository to Cursor using the official GitHub integration.
Start a Cursor Cloud Agent for that repository.
Ask the agent to inspect/read the repository’s GitHub Issues.
The agent reports that it does not have permission to read Issues.
Create a separate GitHub token with permission to read Issues.
Add this token to the Cloud Agent’s environment/secrets.
Ask the agent again to inspect GitHub Issues.
Expected Behavior
There are two issues here:
The GitHub integration should provide the Cloud Agent with the permissions granted to the Cursor GitHub App, including read access to Issues.
If a user explicitly provides a GitHub token through the Cloud Agent’s environment/secrets, there should be a reliable way to make that token the authentication method used for GitHub operations, rather than silently falling back to the Cursor GitHub App credentials.
Hey, thanks for the detailed report. This is actually working as intended, not a bug in your setup.
Even though the Cursor GitHub App has broad permissions at the install level, each Cloud Agent run gets an intentionally restricted, security-scoped token. That token does not include Issues access, so the agent can’t read them and GitHub returns 403.
On the second point, your token is actually fine, but the secret name matters. You need to:
Create a fine-grained GitHub PAT scoped to the repo you need, with Issues permission read or read/write.
Add it to your Cloud Agent environment secrets with the exact name GH_TOKEN (or GITHUB_TOKEN).
The gh CLI inside the agent will pick up that token instead of the built-in credentials. If the secret is named something else like GITHUB_PAT, gh won’t see it and it’ll look like a silent fallback to App auth, which is probably what happened. Note that git push and pull still use the built-in auth. The PAT only applies to gh and API requests.
More flexible permission controls are on our radar. Let me know if it still doesn’t work with GH_TOKEN.
Fair point. It’s not that reading Issues is considered “dangerous”. This is just least-privilege in action. The token we issue for each agent run only requests the scopes needed for the main workflow by default, working with code and PRs. Issues aren’t in that default set, so you get a 403. This is about minimizing what the token can touch at all, not about Issues being especially sensitive.
I get your point, and more flexible permission controls are something we’re working on. For now, the practical workaround is to use a PAT with Issues access, add it to the agent’s secrets exactly as GH_TOKEN (or GITHUB_TOKEN). Let me know if it still doesn’t get picked up with that name.
We need a way to permit this reading and working with issues is key to workflow and Cloud becomes pretty useless if it can’t read and work with issues etc. PAT is a pain in the but to do (partially due to GitHub’s horrible UI and menus), especially per repo
Hey, thanks for the feedback. I get the pain, and I’ve logged the request for native Issues support. More flexible permission controls for Cloud Agents are also on the team’s radar. I can’t share an ETA yet.
On PATs being painful, especially per repo, you can simplify this a lot. You don’t need to create a fine-grained GitHub PAT for each repo. When you create the token, you can select multiple repos at once or choose All repositories, then grant it Issues read or read/write. One token can cover all the repos you need. Then add it to your Cloud Agent secrets with the exact name GH_TOKEN or GITHUB_TOKEN. The gh CLI inside the agent will pick it up instead of the built-in credentials.
Let me know if it doesn’t get picked up with that token.