Your Cursor cloud agent can’t read GitHub issues. Here are the two fixes that work.

The symptom

You point a cloud agent at a GitHub issue — a URL, a number, “fix #482” — and one of three things happens:

• The agent says it doesn’t have permission to read the issue.
• It tries, gets a 404 or 403 from the API, and stalls. The ticket sits.
• Worst: it doesn’t complain at all. It works from the issue title and its own assumptions, and opens a confident PR against a spec nobody wrote.

That third mode is the expensive one. The acceptance criteria — usually in the issue body and the comment thread — never made it into the run. The PR looks plausible, your reviewer spends real time on it, and the ticket still isn’t done.

Why it happens

When a cloud agent boots, its VM is handed a short-lived GitHub App installation token for your repo. As of this writing, that token often does not carry the issues scope — even though the GitHub App’s settings page shows Issues: read and write. What the app is allowed and what the VM’s token actually contains are two different things. Repo contents and pull requests work, which is exactly why the agent can branch and open PRs but can’t read the ticket those PRs are supposed to close.

This is not your misconfiguration, and reinstalling the app won’t change it. It’s a known gap — Cursor staff have acknowledged it on the public forum thread, with a token workaround as the recommended path and no shipped fix at the time we last checked.

Fix 1 — paste the ticket into the prompt

Zero setup, works today, needs nobody’s approval. When you start the agent, give it the ticket itself, not a pointer to it:

• the title and the full body, not a summary,
• acceptance criteria, expected vs. actual,
• the comments that changed the spec (“we agreed to gate this behind a flag”),
• links to related PRs and files.

Fix the ticket below. Do not guess at scope — if anything is
ambiguous, say so in the PR description instead of deciding.

--- TICKET #482: Export fails for orgs with more than 1,000 members ---
[full issue body pasted here]

--- COMMENTS THAT CHANGED THE SPEC ---
[the two comments that matter, pasted here]

Right choice when: it’s a one-off, you’re still evaluating cloud agents, or a token would need a security review you don’t want to run this week.

The cost: it’s manual. The agent never sees comments added after you pasted. And every teammate has to remember to do it, every time — the day someone forgets, you’re back to confident guessing.

Fix 2 — one team token in secrets (the durable fix)

The workaround recommended on the forum is a personal access token. Done naively, that means every engineer mints their own — which is the actual complaint in that thread: asking a whole team to create and babysit personal tokens is a lot. Do it once instead: one scoped, read-only token, held as a team secret, injected into every agent VM.

Step 1 — create a fine-grained token

Use a service account if you have one — offboarding a person shouldn’t break the crew. Then: GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens → Generate new token.

• Resource owner: your organization.
• Repository access: only the repo(s) the agents work in.
• Permissions: Issues — read-only. Metadata — read-only (GitHub adds it automatically). Add Pull requests — read-only if the agent should read PR threads too.

Leave write scopes off — reading a ticket doesn’t need them, and a leaked read-only token is a much smaller day. Set an expiry (90 days is sane) and put rotation on a calendar now, not when it breaks.

Step 2 — add it as a Cursor secret

In the Cursor dashboard: Cloud Agents → Secrets → add a secret named GH_TOKEN with the token as its value. Secrets are injected as environment variables into agent VMs, and a team-scoped secret means one token covers everyone — nobody else touches GitHub settings.

Two things people trip on:

• The secret lands in agents started after you save it. A run that’s already going won’t pick it up — start a fresh one.
• Never paste the token itself into a prompt, a ticket, or an email. Prompts get logged and quoted; the secret store exists so credentials don’t travel with the words.

Step 3 — verify before you trust it

Start a new agent and ask it, before any code:

Run: gh issue view 482 --repo acme/api --comments
Quote the acceptance criteria back to me before you write anything.

The gh CLI picks up GH_TOKEN from the environment on its own. If the VM’s gh is pinned to other credentials, go around it with the REST API:

curl -s -H "Authorization: Bearer $GH_TOKEN" \
  https://api.github.com/repos/acme/api/issues/482

If the agent quotes the real body and comments, ingestion works. If it still can’t read the issue, the usual suspects: the secret was added after the agent started (start another), the token’s repository access doesn’t cover this repo, or Issues read-only didn’t get ticked.

Which fix to pick

• Paste the ticket if cloud agents are still an experiment, or the task is a one-off.
• The team token if agents are becoming part of how you ship. One secret beats a drawer of personal tokens for scoping, rotation, and revocation — and nobody has to remember anything at prompt time.

Reading the ticket is step one, not the whole job

Everything above gets the ticket into the agent. It doesn’t decide which tickets are safe to hand over, what the tests must prove, or what a mergeable PR looks like in your repo. That part is what Crew Install does: a seven-day setup that wires one ticket type on one repo into branches, tests, and PRs — ingestion included. A human on your team still merges every PR. We never touch main.