Lovable GitHub not working comes down to one of two layers. A workspace fault involves the Lovable GitHub app or its access, and one workspace owner or admin usually clears it once for every project. A project fault sits in one repository, one branch or one large file. Open the project’s GitHub settings first: Lovable shows its Reconnect prompt there.
Lovable GitHub not working: the workspace connection or the project link?
A Lovable GitHub sync failure is a workspace fault when the message is about the Lovable GitHub app: suspended, uninstalled, missing for that owner, or denied the repository. It is a project fault when the repository is gone or the trouble sits on one branch or file. Workspace owners and admins usually fix workspace faults once, for every linked project.
Before you decide the Lovable GitHub connection is not working, check whether Lovable itself is down. A platform incident looks the same from inside a project, and no amount of reconnecting fixes it.
When the Lovable GitHub sync is not working, the first job is to read the exact message in Project settings → Git → GitHub and match it to a row below. The messages are quoted from Lovable’s GitHub sync documentation, read on 21 October 2026; we did not trigger these errors ourselves.
| What you see | Layer | Who can clear it | Is recent work at risk |
|---|---|---|---|
| ”The Lovable GitHub App is suspended. Reconnect and unsuspend it to resume syncing.” | Workspace | Workspace owner or admin | Yes, until the app is unsuspended |
| ”The Lovable GitHub App has been uninstalled. Reconnect to reinstall it and restore access.” | Workspace | Workspace owner or admin | Yes: every project on that connection was disconnected, and each reconnect creates a new repository |
| ”Lovable no longer has access to this repository. Reconnect and grant access to it.” | Workspace | Workspace owner or admin, granting the repository on GitHub | Yes, until access is restored |
| ”Install the GitHub App for <owner> to enable gitsync.” | Workspace | Workspace owner or admin | Yes, until the app is reinstalled on that owner |
| ”Clicking ‘Add account’ or ‘Connect GitHub’ does nothing.” | Workspace (a blocked popup in your browser) | Workspace owner or admin, after allowing popups for Lovable | No: the connection was never made |
| ”(Enterprise) My GitHub organization uses an IP allow list and the connection fails.” | Workspace | Whoever manages the organization’s IP allow list on GitHub | No: the connection was never made |
| ”(Enterprise Server) The setup popup can’t reach my instance.” | Workspace | Whoever runs the GitHub Enterprise Server instance | No: the connection was never made |
| ”This repository is no longer accessible. Try reconnecting, or contact support if the issue persists.” | Project | Workspace or project owner or admin | It depends: restoring the repository resumes sync; reconnecting creates a new repository |
| ”My commits and pushes from GitHub aren’t showing up in Lovable.” | Project | Editor or higher, by switching the branch | No: the commits are on GitHub, on another branch |
| ”I pushed to the synced branch, but the commits don’t appear in Lovable and the sync status says GitHub is ahead.” | Project | Anyone who can push to the synced branch | No: the commits are on GitHub |
| ”I see a ‘lovable-fallback’ branch in the branch picker.” | Project | Editor or higher, by switching the branch | No: the repository is otherwise unchanged |
| ”Sync stopped working after I added a large file.” | Project | Workspace or project owner or admin | Yes: nothing pushes until the listed files are gone |
| ”My push from Lovable ended up on a ‘lovable-sync’ branch instead of the synced branch.” | Project | Whoever can merge into the synced branch | No: the work is on that branch |
The last column is our reading of each entry, not Lovable’s wording. The quick reset is the Reconnect button in the affected project’s GitHub settings, and on a workspace fault one owner or admin only needs to do it once: Lovable’s page says the other projects on the same connection then resume automatically. If a screen tells you that you need workspace Git access to add a connection, read it as a role question: adding, updating or reconnecting a workspace connection is reserved for workspace owners and admins, while a project owner or admin can connect, disconnect or reconnect one project.
One reported workaround sits outside Lovable’s list. A thread on the r/lovable forum reports that unpublishing the project and publishing it again got it updated; that is a forum report, not a documented step. One likelier reason is a line in Lovable’s own Git sync overview: “A merge does not change your published app. When the change is ready for your users, publish again.” If the code is current in Lovable but the live site is not, the fault is on the publishing side, and the diagnosis starts with when a Lovable publish will not go through.
When reconnecting does not clear it
When Reconnect keeps failing, look at where the Lovable GitHub app is installed. The app can be installed only once on the same account or organization, so a second install attempt on that owner is not the fix. Lovable’s documented order starts in the project: press Reconnect, then in the GitHub window it opens, install the Lovable GitHub app on the account or organization shown, or grant it the repository under Repository access.
Renames and moves have their own entries in Lovable’s FAQ. Renaming the repository, your GitHub username or your organization keeps the sync running, and a transfer to another owner keeps it running only when your workspace also has a GitHub connection for the new owner. An earlier case went differently. A GitHub community discussion opened on 22 March 2025, “Third-party app (Lovable) can’t access repository after GitHub organization rename”, records a project that kept failing after the poster reinstalled the app, granted it the new organization and repository, synced from Lovable, and signed out and back in to both services; the thread is marked closed and unanswered. If you are in that state today, Lovable’s page points the “no longer accessible” case to its support once reconnecting has not worked.
When the fault is on Lovable’s or GitHub’s side
Sometimes neither layer is yours. Lovable’s own write-up of its 2 January 2025 incident, published on 6 January 2025, says the platform was partially or fully down for about 19 hours after GitHub disabled Lovable’s GitHub app over the rapid creation of new repositories. The same post says no projects were lost, but some edits made during the outage were never applied. Our take on that incident: an outage on either side can drop edits without leaving an error, so the repository, not a status light, is where you find out what was saved.
GitHub’s status page at githubstatus.com lists Git Operations, API Requests and Webhooks among its components, and those are the ones a sync leans on. Lovable pulls your commits when GitHub notifies it about a push, so a webhook problem on GitHub’s side can show up in Lovable as pushed commits that do not appear. Read the status page live when you need it; any status written into an article is out of date by the time you read it.
Is your code safe? Check the repository holds a complete copy
A connected repository is a complete copy only when its synced branch holds your newest change from the builder, no lovable-sync or lovable-fallback branch is waiting, and no oversized file has stopped the pushes. Even then it holds the code, not the database rows, the uploaded files or the secret values.
Every check below runs in GitHub’s web pages and in the project’s GitHub settings; none needs a terminal. Each one comes from Lovable’s GitHub and Git sync pages as read on 21 October 2026.
- 01 Open Project settings, then Git, then GitHub, and note the branch the branch picker shows. Open that exact branch on GitHub, not the default branch you land on by habit: Lovable syncs one branch at a time.
- 02 Open the branch list on GitHub and look for lovable-fallback or any branch whose name starts with lovable-sync. A lovable-sync branch holds work GitHub refused on the synced branch; lovable-fallback means someone deleted the synced branch and Lovable moved editing to a new one.
- 03 Read the sync status card in the same settings. In sync with GitHub means both sides are on the same commit; Lovable is N commits ahead means work still waits to be pushed; diverged means each side has commits the other lacks. The card also shows when Lovable last synced.
- 04 Open the newest commits on the synced branch and check who authored them. Lovable's commits come from lovable-dev[bot] on github.com, and raw git log output can show the older name gpt-engineer-app[bot] for the same account.
- 05 Look in the project's GitHub settings for a file-size error. Lovable lists the files over 100 MB that stopped the push, and nothing newer reaches GitHub until they are gone.
- 06 Accept what the sync never carries. Secrets stay out of the repository, and the database records and the files in storage come out through Lovable Cloud's own export and storage screens, not through Git sync.
On a project that uses Lovable Cloud, the repository should also hold the backend code: Edge Functions under supabase/functions/ and the migration files that record the database structure under supabase/migrations/ and drizzle/migrations/. Those files let anyone read the structure without opening the dashboard. In a sports-analytics app, one of the 21 third-party apps we audited in June and July 2026, every table, constraint and row-level security policy lived only in the hosted dashboard, and the repository held TypeScript interfaces that no database enforces, so the app’s access rules could not be reviewed, diffed or rebuilt from the code. We chose those 21 apps for audit rather than drawing them at random, so this is one case, not a rate; the full account sits with the two-minute Supabase data test.
If the checks show weeks of work that exist only inside Lovable, or a repository and provider accounts that sit in someone else’s name, and a launch, a client handover or an investor’s questions are close, that is the point to bring someone in: in a free audit, we weigh up with you whether the repository and the accounts behind the app are in your name. In the sprint, our engineers keep the application in a version-controlled repository and on a hosting account the founder controls, deployable through a documented pipeline, independent of the tool that generated it, and move every service the product depends on into an account the founder owns; those are two of the 123 deliverables.
The standard to aim for is an app that runs without the builder: a clone that deploys with no step that needs Lovable. The release path around that repository is covered in the release path a small app needs. The data, files and secrets travel separately, and what comes across from Lovable Cloud lists each route. If the goal is to keep building outside Lovable, start with running the Lovable code in Cursor.
Where your work goes when a push fails
When a push fails, Lovable leaves a trace, and each kind of trace says where the work went. The four cases below come from Lovable’s GitHub page as read on 21 October 2026; they describe documented behavior, and we did not reproduce them.
A lovable-sync branch: your push was refused
When GitHub rejects Lovable’s push to the synced branch, most often because of branch protection rules or because someone pushed a conflicting change Lovable could not apply its work on top of, Lovable pushes the work to a branch named lovable-sync instead. The project’s GitHub settings then say the changes “were pushed to the branch lovable-sync instead”, and later rejected pushes are added to the same branch. If you have added your own commits to lovable-sync, Lovable leaves them alone and uses a new branch named lovable-sync-<timestamp>. The move: open that branch on GitHub, review the changes and merge them through the review your protected branch requires. If the rule that refused the push is yours, branch protection rules for main covers how those rules work.
A lovable-fallback branch: the synced branch was deleted
Someone deleted the synced branch on GitHub, and Lovable switched the project to a new branch called lovable-fallback so editing could continue. The rest of the repository is unchanged. The move: pick another branch or recreate the original one, then leave or delete lovable-fallback once you have switched away.
GitHub is ahead: commits that never arrive in Lovable
Commits pushed to a branch the project is not set to stay on GitHub and never show up in Lovable. Lovable documents two fixes: merge them into the synced branch, for example through a pull request into main, or switch the synced branch to the one your commits are on. Lovable GitHub branch switching happens in the branch picker in the project’s GitHub settings, and it has two limits: you cannot switch or create branches while Lovable is editing, and a new branch forks from the active branch, not from the default.
The harder case is commits pushed to the synced branch itself while the status card says “GitHub is ahead”. Lovable pulls when GitHub notifies it about a push, and if that notification never arrives, the commits stay missing until a new push comes in; Reconnect does not fix it, and Re-check only compares the branches. Lovable’s documented fix is any new push to the synced branch, including an empty commit:
git commit --allow-empty -m "Trigger Lovable sync"
git pushBefore you push, confirm the card does not say the two sides have diverged. In that state the push replaces Lovable’s version of the branch with GitHub’s, and edits made only in Lovable are no longer in the project; Lovable saves a backup first, and the project owner can restore it.
A file over the size limit
Two limits apply, set by two different companies. GitHub blocks files larger than 100 MiB, as GitHub’s limit on large files states, and Git warns about files larger than 50 MiB. Lovable cannot save a file larger than 10 MB into a project at all; a bigger file pushed from your own computer syncs in, but Lovable cannot edit it afterwards. After a few failed attempts, the project’s GitHub settings show “Your project contains files that exceed the maximum file size limit (100 MB)” with the files listed, and until then the repository simply looks a few commits short. The move: delete the listed files from the project, or ask Lovable to remove them, and let the sync retry; if the push still fails, the file is stuck in the repository’s history, and Lovable’s page says cleaning that up needs Lovable Support.
How the Lovable GitHub integration is meant to sync
The Lovable GitHub integration is a two-way sync on one branch at a time: work generated in Lovable is pushed to that branch, and commits pushed to that branch come back into Lovable. A workspace connection authorizes the Lovable GitHub app, and each project links to exactly one repository.
Lovable’s page names the two layers in plain terms. A workspace connection “authorizes Lovable to access a GitHub account or organization through the Lovable GitHub app”, and every project in the workspace can use it. A project repository link “connects one Lovable project to one GitHub repository”. Connecting a project makes Lovable create a new repository, private by default, and the synced branch is the repository’s default branch, usually main, until someone switches it.
The roles split the same way. Only workspace owners and admins install the app on a new account or organization and add, update, reconnect or delete a workspace connection; workspace or project owners and admins connect, disconnect and reconnect a project; editors and above see the sync status and switch or create branches. The github.com connection is available on all plans, while GitHub Enterprise Cloud with data residency and GitHub Enterprise Server need the Enterprise plan.
GitHub is no longer the only provider. Lovable’s docs now cover a Lovable GitLab integration and a Bitbucket one beside it, with GitLab.com and Bitbucket Cloud on all plans, and each project can connect to one repository on one provider at a time.
The repository is the copy you can clone, read and hand to another engineer. If the GitHub account or organization that holds it is not yours, that copy is not yours either, and the same goes for the hosting, database and email accounts around it; moving every provider into accounts you own walks through the transfer.
You reconnected and now have two repositories
A reconnect after a Lovable disconnect creates a new repository instead of relinking the old one, so a quick disconnect and reconnect leaves two repositories. Compare both before merging anything, choose one as the trunk, and keep the other as an archive.
Reconnecting to the same repository after a disconnect is on Lovable’s list of things Git sync does not support. So a Lovable disconnect from GitHub, used to clear an error, leaves the old repository on GitHub with all its history and files, attached to nothing, while every change made after the disconnect is stored only inside Lovable until the new repository exists. The same split happens when someone uninstalls the Lovable GitHub app, when you switch a project to another GitHub account, and when you move a project to another workspace: each reconnect creates a new repository. Lovable’s own advice for the uninstall case is to copy or merge any history you need from the old repository into the new one yourself.
- 01 Merge nothing yet, and change neither repository.
- 02 Clone or download both repositories so you can read them without Lovable or GitHub in the way.
- 03 Compare the newest commit date, the file count and the two or three features you built most recently.
- 04 Choose the trunk: the repository that holds the newest work you want to keep, or the new one if you keep building in Lovable, which cannot reconnect to the old one.
- 05 Bring the missing work into the trunk, then archive the other repository on GitHub. Do not delete it.
Reconciling two repositories that both hold real work is a bigger job than repairing one broken connection, and it needs its own plan. A repository renamed, transferred or deleted on purpose during a move is a different cause, covered in what breaks when a repository moves. Two repositories also stall any handover, because the first thing a new developer asks is which one is real; the rest of that conversation is in the takeover checklist for an inherited app.
Replit GitHub and Base44: the same symptom, different rules
A repository that stopped moving means a different thing on each builder. On Replit, the Git pane is a manual client: you commit, push and pull yourself, and Git commands you run in the Shell show up in the pane. So on Replit a stale repository usually means nobody pushed: the Replit GitHub integration moves code only when someone commits and pushes from the Git pane or the Shell. Replit’s Git pane documentation lists each action. Replit’s import docs also describe bringing in a Lovable project by exporting it to GitHub first, and they say Supabase data and secrets are not imported with it.
On Base44, two-way GitHub sync needs the Builder plan or higher, changes sync automatically, and there is no manual push from the Base44 app to GitHub. The synced branch must be named main, and a merge to main reaches your users only after you click Publish in Base44. Base44’s GitHub documentation adds one more catch: once GitHub is connected, Version History cannot restore versions from before the connection.
| Platform | How sync works | Import from an existing repository | Branch rule |
|---|---|---|---|
| Lovable | Two-way and automatic, one branch at a time | Not through Git sync: download the repository as a ZIP and import it with Upload code | One synced branch, the repository’s default unless switched |
| Replit | Manual commit, push and pull in the Git pane; Shell Git commands show in the pane | Yes, at replit.com/import, including a repository exported from Lovable; Supabase data and secrets are not imported | Any branch: create, switch and merge branches in the Git pane |
| Base44 | Automatic once connected, on the Builder plan or higher; no manual push | An app created with the Base44 CLI can link its repository from the app’s Overview page | The synced branch must be named main |
Docs checked 21 October 2026. Getting off either builder entirely is a separate job, with its own steps for getting a Replit app fully out and every documented way out of Base44.
Common questions about a broken Lovable GitHub sync
How to import GitHub project into Lovable?
Download the repository from GitHub as a ZIP (Code, then Download ZIP) and import it in Lovable with Upload code; Git sync itself cannot connect to a repository that already exists. The import copies the code into a new project, uses credits, and leaves out database records and user accounts, which Lovable asks for afterwards; Lovable is rolling the import out gradually, so not every account has it yet. A Lovable import from GitHub therefore ends with a new project, and you connect Git sync to it afterwards if you want a repository that stays in step. After that, Lovable does pull from GitHub, but only commits pushed to the synced branch of the repository it created.
Is GitHub having issues today?
GitHub’s status page at githubstatus.com answers that live, component by component. For a Lovable sync, the components to read are Git Operations, API Requests and Webhooks, because Lovable pulls commits when GitHub notifies it about a push.
How to get Lovable code on GitHub?
Connect the project from Project settings → Git → GitHub; Lovable creates a new private repository under the GitHub account or organization you pick and starts two-way sync on its default branch. If you only want a one-off copy, paid plans can download the codebase from the same Git settings or from the bottom of the Code editor’s file tree.
Does Lovable work with GitHub?
Yes. Lovable syncs a project with GitHub through the Lovable GitHub app, two ways on one branch at a time, and the github.com connection is available on all plans. The two self-hosted and regional GitHub options are Enterprise-plan features.
How do I disconnect GitHub from Lovable AI?
Open the project’s GitHub settings, open the dropdown on the active repository connection, select Disconnect, type the confirmation and click Disconnect; workspace or project owners and admins can do it. The repository stays on GitHub with its history, sync stops, and later changes are stored only inside Lovable. If you reconnect, Lovable creates a new repository instead of relinking the old one.
When is a broken Lovable GitHub sync worth getting help with?
It is worth outside help when GitHub is missing work that exists only in Lovable, or the repository or provider accounts are not in your name, and a customer, buyer or new developer will soon rely on the code. AxonBuild offers a free audit, where we go over with you which copy of the code is current and whose accounts hold it.
Not sure GitHub holds all of your app's code?
When the sync breaks quietly, recent work lives in one place only, and a lost account could take it with it. During the audit, we talk through where your code and changes sit today. Then we tell you what to secure first so one outage cannot cost you the app.
Book a free audit →
Free · 30 minutes · No code access needed