Repo Rename Broke My Lovable Sync

Why does renaming a GitHub repo break Lovable sync?

Lovable stores the full repository path — owner name plus repository name — at the time you first connect to GitHub. When you rename the repository, that stored path no longer resolves to a valid endpoint. Lovable has no webhook or polling mechanism to detect renames, so sync fails silently or with a generic access error. No automatic recovery path exists because Lovable cannot know what the repo was renamed to.

The same failure applies to three related operations: transferring a repository from a personal account to an organisation (changes the owner segment of the path), renaming the GitHub organisation that owns the repository (changes the owner segment), and archiving the repository (makes it read-only and breaks write access). All four produce the same symptom — sync fails — for the same underlying reason: the stored path is no longer valid.

This is not a Lovable bug; it is a consequence of how Lovable stores and scopes repository access. Lovable stores the owner/repo path at connection time and its GitHub App installation is scoped to that path. After a rename, Lovable does not re-resolve to the new path — it continues targeting the original stored path, which no longer matches the renamed repository, causing sync to fail.

What is the correct fix after a repo rename?

Yes — the fix is to restore the original repository name. GitHub allows you to rename a repository back to its previous name as long as no other repository in the same account is using that name. Once restored, the stored Lovable path resolves again and sync resumes on the next editor change. No reconnect action in Lovable is needed if the name is restored correctly.

1. Go to the renamed repository in GitHub → Settings → Repository name.
2. Enter the exact original name (case-sensitive) and click Rename.
3. Wait for the rename to propagate — usually a few seconds.
4. Return to the Lovable editor and make a small change (add a space to a comment).
5. Check the GitHub repository's default branch (main) for a new commit to confirm push resumed.
6. If no commit appears within 30 seconds, check the GitHub App installation still has access to the repository.

What if I cannot restore the original name?

If the original repository name is taken — for example, you renamed to something else and then another repository took the old name — you cannot restore it directly. In this case, the only path is to disconnect GitHub in Lovable and reconnect. Reconnecting when the original repo is gone creates a new repository. Your push history from the original repository is not transferred.

Before disconnecting: make sure your Lovable editor state reflects the code you want to keep. Lovable's editor is the source of truth for what it will push to the new repository. If the editor state diverges from your last known-good GitHub version, resolve that divergence first.

After reconnecting to a new repository: you will have two repositories — the renamed one and the newly created one. The renamed repository still contains your full previous push history. Keep it archived rather than deleting it, at least until you have confirmed the new repository is stable and your deployment pipeline is updated to point at the new repo.

Does transferring a repo to another org also break sync?

Yes. Transferring a repository to a different organisation changes the owner segment of the path — for example, from `personal-account/my-app` to `my-org/my-app`. This breaks sync in the same way a rename does. Additionally, the Lovable GitHub App installation may need to be re-added to the destination organisation because app installations are per-account, not per-repository.

1. If you must transfer the repo, do it during a planned maintenance window — sync will be broken until restored.
2. After the transfer, go to the destination organisation's GitHub Settings → Applications and confirm the Lovable app is installed there.
3. If not installed, go to github.com/apps/lovable-dev and install it for the destination org.
4. Then transfer the repository back to the original account (if that is the connected account) or accept that you need to disconnect and reconnect Lovable.

How do I verify sync is restored after fixing the repo name?

After restoring the original repository name, confirm sync is working by triggering a push and checking the repository — do not rely on the Lovable editor status indicator alone. The editor can show a connected state even when the last push failed. Verify at the GitHub level.

1. Make a trivial change in the Lovable editor — add a comment, adjust a label — to trigger a push.
2. Go to the GitHub repository → Code tab and check the default branch (main) for a new commit.
3. The commit timestamp should be within the last minute.
4. If no new commit appears, open the Lovable editor and look for a sync error indicator in the toolbar.
5. If an error indicator appears, go through the GitHub App installation check: GitHub Settings → Applications → Lovable → Configure → verify repo access.

When should I involve a senior engineer?

If restoring the original repository name does not restore sync, or if you have ended up with diverged history across two repositories, you need git-level intervention. Merging or rebasing Lovable-managed branches incorrectly can corrupt the branch history Lovable relies on for incremental pushes — and that is harder to recover from than the original rename.

A senior engineer can also safely consolidate the history from the original and new repositories, update your deployment pipeline to the correct repository, and confirm the Lovable push path is clean before your next session.