/in-cloud fails while cloud agents work fine, on the same respository

Support Bug Reports
, ,
1

Just as the title says. The important note here is that I am attempting this with repositories that I am shared on. I have the cursor integration enabled on both GitHub accounts, and I know that there is not a problem with permissions because when I go to cursor.com/agents, I can spin up an agent on that same repository that I’m shared on with no issues. The problem just appears to be isolated to using /in-cloud in the IDE, which is a bummer because I really want to pass tasks off from the IDE to iOS, which I have no way to do right now.

The error I get in the IDE is:

"The cloud subagent couldn’t start. Cursor returned a permissions error:

Organization <org-name>could not be accessed. Unable to determine Git provider.

This means your repo isn’t fully linked to Cursor’s cloud agents (the Git provider/organization connection isn’t set up), so I can’t spawn a cloud agent.

To enable cloud agents for this repo, link it to Cursor at cursor.com/dashboard. Once the repo/org is connected, re-run /in-cloud."

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Editor, Tab & Chat (autocomplete, Composer, in-editor agent)
  • Terminal & commands
  • Models, pricing & API keys (availability, Auto/Max, BYOK/Bedrock)
  • MCP & tools
  • Cloud Agents & Automations (cursor.com/agents, scheduled/event)
  • BugBot & Code Review
  • Cursor CLI
  • Cursor Mobile
  • Remote (SSH / Dev Containers / WSL)
  • Account, billing & login
  • Something else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

8

Hey @jayskerdoo.
Thanks for the clear writeup, and you’re right that it isn’t a permissions problem on your end. The web launcher works because it pulls the repo from your GitHub connection as a canonical github.com URL. /in-cloud instead reads your local git remote, and yours uses a custom SSH host alias (the github.com-… host from your multi-account ~/.ssh/config), which it doesn’t yet recognize as github.com, so it can’t match the repo and errors out.

Quickest way to unblock yourself is to point the remote at the canonical host while keeping your per-account key:

git remote set-url origin [email protected]:<org>/<repo>.git
git config --local core.sshCommand "ssh -i ~/.ssh/<your-key-for-this-account> -o IdentitiesOnly=yes"

git remote -v should then show [email protected]``:…, and /in-cloud will resolve it. An HTTPS remote (https://github.com/``<org>/<repo>.git) works too. Reconnecting the GitHub org (as suggested above) won’t change this, since the org connection itself is fine; it’s just the alias in the remote URL.

This is a known limitation we’ve seen reported before, and I’ve flagged it with the team. Let me know if that gets /in-cloud working for you!