Lovable GitHub Sync Broken? Complete Fix Guide

What causes Lovable GitHub sync to break?

Lovable pushes code directly to the default branch (usually main) in a connected GitHub repository whenever you make a change in the editor. Sync fails when the Lovable GitHub App loses access to that repository — most commonly because the repo was renamed, transferred to another organisation, deleted, or because the app installation was revoked. None of these are fixable by prompting Lovable to 'try again.'

Lovable documents four specific failure modes: (1) the connected repository was renamed or moved, which breaks the stored path permanently; (2) the app installation was revoked from the GitHub account or organisation settings; (3) the repository was deleted; and (4) the Lovable GitHub App was uninstalled at the organisation level. In each case the fix requires action in GitHub, not in the Lovable editor.

A fifth failure mode is permissions drift — the app was installed at the account level with access to 'selected repositories,' and the connected repo was later excluded from that list. This produces a 404 during the sync handshake without an explicit error in the Lovable UI.

Does renaming my GitHub repo break Lovable sync permanently?

Yes. Lovable stores the full repository path at the time of connection — including the owner name and repository name. If either changes, the sync endpoint becomes invalid. This is vendor-documented behaviour: Lovable has no automated recovery for a renamed or moved repository. The only self-service fix is to restore the exact original repository name.

This also applies to GitHub organisation renames and repository transfers. If you transfer a repository from your personal account to an organisation — or rename the organisation — the stored path no longer resolves, and Lovable will report it as inaccessible. Restoring the original name resolves it; leaving the new name requires a full disconnect and reconnect, which creates a new repository.

A common mistake is clicking the 'Reconnect' button in the Lovable editor without first fixing the repository name. The reconnect flow will attempt to connect to the current name, create a new repository if the original is gone, and begin pushing to a brand-new repo — leaving your history in the old one. Restore the name first, then reconnect.

How do I reinstall the Lovable GitHub App after a 404?

The 'it sends me to a 404' error during reconnect means the current app installation is invalid — either the app was uninstalled or its access token expired mid-flow. The fix is a clean reinstallation of the Lovable GitHub App, not a retry of the broken reconnect URL. Follow these steps in GitHub first, then return to Lovable.

1. Go to github.com/apps/lovable-dev and click 'Configure' (or 'Install' if no installation exists).
2. Select the account or organisation that owns the connected repository.
3. Under 'Repository access,' select 'All repositories' or explicitly add the connected repository.
4. Click Save and complete the OAuth authorisation if prompted.
5. Return to the Lovable editor and click 'Connect to GitHub' — the app installation should now resolve correctly.
6. Verify a new commit appears on the default branch (main) in your GitHub repository within a few minutes of making a change in the editor.

What are the lovable-sync-<timestamp> and lovable-fallback branches?

Lovable syncs editor changes directly to your repository's default branch (usually `main`) by default. Two special branches exist only as fallbacks: `lovable-sync-<timestamp>` is created when a push to main is rejected — for example by a branch-protection rule or a non-fast-forward conflict. `lovable-fallback` is created when the branch Lovable was synced to was deleted on GitHub. Neither is Lovable's normal push target.

When Lovable creates a `lovable-sync-<timestamp>` branch, the editor displays a message: 'To avoid losing your work, Lovable pushed it to a new lovable-sync-<timestamp> branch instead.' This means something on the default branch is blocking the push — resolve the branch-protection rule or merge conflict, then merge the timestamped branch into main to consolidate the work.

If `lovable-fallback` appears, the branch Lovable was previously synced to was deleted in GitHub. Lovable automatically switches to the new fallback branch to preserve changes. Merge lovable-fallback into your default branch and confirm the default branch is no longer deleted before your next session.

Can I import an existing GitHub repo into Lovable?

No. Lovable does not support importing an existing repository into a project — there is no 'bring your own repo' feature. Lovable only connects to a repository it creates itself. You cannot point Lovable at an existing codebase and continue editing it in the Lovable editor. This is explicitly documented by Lovable and is one of the most common misconceptions about GitHub integration.

The practical implication: if you want to continue Lovable-generated code outside the Lovable editor, you export or clone the Lovable-created repository and work in your own toolchain. You cannot then re-import that modified repository back into Lovable and expect the editor to pick up the changes unless those changes were made through the Lovable editor itself.

Some builders try to work around this by manually copying files from an external repo into the Lovable-connected repo. This sometimes works for simple file additions but breaks reliably when it touches files Lovable manages internally (config files, layout files, or the root index). There is no supported workflow for this pattern.

When should I disconnect and reconnect GitHub entirely?

Disconnect and reconnect is the correct path only when the original repository no longer exists and cannot be restored — for example, if the repo was deleted and cannot be recovered from GitHub's 30-day trash window. In every other case, restoring the original repo name is faster and preserves your push history. Reconnecting always creates a new repository and starts history fresh.

1. Confirm the original repository is unrecoverable: check GitHub → Your repositories (including trash) for deleted repos within the 30-day recovery window.
2. If recoverable, restore it — GitHub offers a restore option for recently deleted repos. Then re-run the GitHub App installation to re-grant access.
3. If not recoverable, go to the Lovable editor → Settings → GitHub → Disconnect.
4. Click 'Connect to GitHub' and complete the flow — Lovable will create a new repository.
5. Note: your commit history from the old repository is not transferred. Back up any commits you need before disconnecting.