Renaming repo breaks Cloud Agent environment, making existing agents read-only

[ryanw]

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

I renamed my main repo today, moving it from my personal github to an org account. I connected Cursor to the new org and it can see the repo, no problem.

But apparently the cloud agent environments are bound to a particular repo? Which isn’t the end of the world, except now the 6-8 cloud agents I’ve been working on appear to be read-only, they won’t respond to any more follow-ups.

I did manage to regain the ability to talk to some of the agents by going to the terminal in cursor.com/agents for that cloud agent and running git remote set-url origin $URL, where $URL is the full repo address that I got from the terminal of the new cloud agent environment setup. Felt very hacky though, and didn’t work for all the agents.

Side note: I would kill for the ability to fork the history of one agent to a new one, ESPECIALLY if it could cross between local / worktree / cloud agent when you fork. I very frequently encounter issues with worktrees and cloud agents like this, where all my work and conversation with the agent is effectively lost, or where I’ve been working locally, but now I want to just pass this off to a remote agent so I can go home.

Steps to Reproduce

Start a cloud agent

Rename the repo the cloud agent is using

Try to continue the conversation with your cloud agent

Expected Behavior

Need some way to continue a cloud agent conversation in a new environment or something

Operating System

MacOS

Version Information

All cloud agents

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the report. This is a known issue. Cloud agent environments get bound to the repo URL when they’re created, and after a rename that binding breaks. We had a similar report before: Renaming GH Repository (and org?) breaks cloud agent GH access

Your workaround with git remote set-url origin is the best option right now, but like you noticed, it only fixes local git actions inside the VM, not the server-side binding.

Unfortunately, there’s no full fix yet to bring existing agents back to life after a rename. New agents should work fine with the new repo URL.

I’ve shared this with the team. No timeline yet, but your report helps with prioritization. About sharing agent history across local/worktree/cloud, that’s a good feature request. I’d suggest making a separate thread in Feature Requests so it can get votes.

Let me know if there’s anything else.