I’ve set up my cloud agent to have its own environment, and everything around that works well. The agent spins up, makes the fixes, tests in the environment, and produces a testing video. However, it just fails at the step of creating the PR.
cd /workspace && gh pr create --draft --title "TOM-1522: Add site column to invoice table" --body "Fixes TOM-1522
Adds a **Site** column to the invoice table on the Invoice Page, positioned between Type and Matched PO. This helps users understand which site an invoice is associated with (e.g. to see why some invoices don't match rate cards for specific sites).
## Changes
- Updated \`SearchInvoices\` GraphQL query to fetch \`sites { id formattedName }\`
- Added \"Site\" column header between \"Type\" and \"Matched PO\"
- Display comma-separated site names per row (or \"-\" if none)
- Added empty summary row cell for proper column alignment
- Regenerated GraphQL types
## Screenshot
" 2>&1
Warning: 1 uncommitted change
pull request create failed: GraphQL: Resource not accessible by integration (createPullRequest)
Once I manually access that agent run, I think some trigger happens, and the hardcoded PR creation happens. But it’s missing the full message that was created + the artifact (this is what I really care about!).
How do I fix this?
Steps to Reproduce
I just kick off an agent run from Linear, don’t touch anything, and let it run. It consistently errors at this step.
Hey, this is a known issue. The installation token the agent gets in the sandbox doesn’t include write access for pull requests, even if the GitHub app permissions are set correctly. We’ve seen the same Resource not accessible by integration (createPullRequest) error for several users.
The team is aware and tracking it. We don’t have an ETA yet, but your report helps us prioritize this, especially since it’s consistent and reproducible.
Workaround for now: after the agent finishes, it should share a link so you can create the PR manually. The branch and commits will be there, you just need to open the PR yourself. I know it’s not ideal since you lose the full PR text and any artifacts the agent prepared.
I appreciate the prompt response and help! It’s quite frustrating to not have an ETA, especially since this exact thing is one of the largest features touted in the announcement of Cursor Agents. How did ya’ll get this to work internally?
I’ve just hit this issue (again) trying out Automations. Not being able to write to GitHub from Automations makes them pretty much useless. Curious to know how the Cursor team, or others, are resolving this.
If I kick off a cloud agent with the instruction “Work on GitHub Issue #5872” it fails to read it and starts hallucinating.
I see it ran:
gh issue view 5872 --repo MyOrg/Myrepo
But that fails with:
GraphQL: Could not resolve to an issue or pull request with the number of 5872. (repository.issue)
It then tried:
gh issue list --repo MyOrg/Myrepo --limit 20 2>&1 || true
Which fails with
GraphQL: Resource not accessible by integration (repository.issues)
After that it gives up and starts inventing things to work on.
Why isn’t it able to read GitHub? It has access to my repo obviously…
I tried reconnecting my GitHub integration but that didn’t help.
Steps to Reproduce
Setup a GitHub integration
Create a GitHub Issue
Ask Cursor’s cloud agent (via web) to work on that issue, “Work on Github Issue #1”
Expected Behavior
Cursor should load that issue via the GH CLI or API. Parse the contents of the issue title, body and comments – and use that to determine what to work on.
Upvote. Our organization has a strict naming convention for pull requests which Cursor’s default behavior does not respect (despite aggressive prompting).
This bug prevents Cursor from executing the shell script, wrapping gh pr create, that we built to enforce our convention.
I have been having a similar issue with lack of permissions for GitHub Actions inside the cloud agent. My workaround for now is to create a Personal Access Token on GitHub and add it to your cloud environment as:
GH_TOKEN=ghp_
So from there on, gh will use this access token to authenticate, so if you give the correct scope/permissions, it should work - it worked for me at least!
Same issue, here. Cannot read issues from our organization github even if the cursor app has “Read and write access to checks, code, discussions, issues, pull requests, and workflows”.
@deanrie Any updates from the team regarding this? Thanks!
@oelburk Unfortunately, there’s no news on this issue yet. The team is aware, but there’s no ETA, so I can’t promise any specific timeline.
In the meantime, @lucasmotta suggested a working workaround above: create a Personal Access Token on GitHub with the needed scopes issues and pull requests, then add it to your cloud environment as a variable:
GH_TOKEN=ghp_your_token
After that, the gh CLI will use this token instead of the limited installation token. Give it a try, it helped a few users.