Lovable GitHub Reconnect Not Working

Why does the Lovable GitHub reconnect show a 404?

The 404 appears when Lovable's OAuth flow tries to validate an app installation that no longer exists — either because the Lovable GitHub App was uninstalled, the authorisation token expired, or the user who originally installed the app no longer has admin access to the organisation. The reconnect button in Lovable cannot fix this because it relies on the same broken installation to complete the handshake.

The error 'we couldn't find the Lovable GitHub app installation' is a variant of the same problem: the app is not installed on the GitHub account or organisation that owns the repository Lovable is trying to reach. This often happens after an organisation rename, after a team member who installed the app leaves, or after the app is manually uninstalled from GitHub's Applications settings.

A subtler trigger: if the app was installed with 'selected repositories' access and the Lovable-connected repo was later removed from that list, the installation technically still exists but has no permission to the relevant repo — producing the same 404 symptom during reconnect.

How do I fix a broken Lovable GitHub reconnect?

The correct sequence is: fix the GitHub App installation first, then return to Lovable and reconnect. Do not start in Lovable. Starting in Lovable without fixing the installation first will loop you back to the same 404 because the underlying app access has not changed. Follow these steps in order.

1. Go to github.com/settings/applications (personal) or github.com/organizations/YOUR-ORG/settings/installations (org).
2. Look for 'Lovable' in the installed apps list. If it is there, click Configure.
3. Under 'Repository access,' verify the connected repo is included. If not, add it.
4. If Lovable is not in the list, go to github.com/apps/lovable-dev and click Install.
5. Select the account or organisation that owns the repository and grant access.
6. Complete the installation and return to the Lovable editor.
7. Click 'Connect to GitHub' (not Reconnect) and complete the fresh OAuth flow.
8. Verify a new commit appears on the default branch (main) in your repository after the next editor change.

What if reconnect creates a new repo instead of restoring the old one?

If the reconnect flow creates a new repository instead of restoring access to the existing one, it means Lovable could not find the original repository — usually because it was renamed, transferred, or deleted. Lovable's default behaviour when the original path is unavailable is to create a new repository and start pushing there. Your previous push history stays in the old repository.

To avoid this: before reconnecting, confirm the original repository exists at the exact same path — same owner name, same repository name — that was connected when you first set up GitHub sync. If the repo was renamed, restore the original name first. If it was transferred, either transfer it back or accept that reconnect will create a new repo.

If you have already landed in the 'new repo created' state and your history is split across two repositories, a senior engineer can consolidate the history using git rebase or cherry-pick without losing either set of changes. This is not something to attempt blind — an incorrect rebase on the Lovable-connected branch can cause Lovable to fail all future pushes.

How do I tell if my GitHub App installation is valid right now?

You can verify the Lovable GitHub App installation status directly in GitHub without waiting for a sync error in the editor. Check both the installation status and the repository access list — a valid installation with the wrong repository scope is as broken as no installation at all.

1. Go to GitHub → Settings → Applications → Installed GitHub Apps.
2. Find 'Lovable' in the list. If missing, the app is not installed — proceed to github.com/apps/lovable-dev.
3. Click Configure on the Lovable entry.
4. Under 'Repository access,' confirm your connected repo is listed — or that 'All repositories' is selected.
5. If the repo is missing from the access list, add it and click Save.
6. Return to the Lovable editor and confirm the next prompt push appears in GitHub.

Can reconnecting to GitHub break my existing code?

Reconnecting to an existing, accessible repository is safe — it restores the push path without touching the code in the repository or in the Lovable editor. The risk is creating a new repository by accident: if the original repo is not accessible at connection time, Lovable creates a new one and pushes current editor state there, effectively splitting history. Confirm original repo access before clicking reconnect.

Nothing in the Lovable editor changes during a reconnect — your prompts, version history, and editor state are not affected by the GitHub connection status. The reconnect only determines where future pushes land. Past pushes to the old repository are not transferred automatically.

When should I ask a senior engineer to handle the reconnect?

If you have completed a fresh app installation and the reconnect still fails, or if reconnect created a new repository and you need to consolidate diverged history, the situation requires git-level intervention that is easy to get wrong. A senior engineer can diagnose the exact handshake failure, identify whether the issue is at the app installation level or the repository permissions level, and resolve it without losing history.

Common escalation triggers: the 404 persists after a reinstall; the Lovable editor shows a sync error even when GitHub shows the app as installed; or you have ended up with two repositories containing different versions of your app code.