Lovable GitHub Not Working: Where Your Code Actually Is

Lovable’s GitHub sync exists so your app’s code sits in two places at once. When the sync breaks, GitHub keeps everything pushed up to that moment, and only the work generated since exists in one place, the builder account, which may be the one whose access you do not control.

A broken Lovable GitHub sync is one of two faults. Workspace faults sit on the connection between Lovable and your GitHub account, and one workspace owner or admin repairs them once for every project on that connection. Project faults sit in one project’s branch or repository setting. Sort which you have before you touch anything.

This page skips the connect flow and the export routes. It covers the failure itself, the branches your work can land on when a push does not go through, and how to tell whether the repository holds a complete copy.

Where it says what a platform does, the wording comes off Lovable’s, Base44’s and Replit’s own Git documentation, read on 25 August 2026 and cited at the sentence it supports. Nothing here was run in a paid account, so a screen that does not match the wording below is more likely the docs having moved than your project being unusual.

Your code is in one place, and that is the actual problem

A healthy connection produces two copies of the same code: the one the builder generates into, and the one on GitHub that you can clone, read and give to someone else. A broken connection leaves GitHub with a copy that stops at the last push, and everything generated after that exists only behind a platform login, on a plan, inside a workspace whose permissions somebody else may hold.

A working GitHub connection means two copies of your app. A broken one leaves you the copy whose access you do not control.

The shape of it shows up clearest in a post from someone on a neighbouring builder, who had spent a fortnight working in the repository rather than in the app:

“I began building on my project on base44, then spent 2 weeks making changes on github. I checked to see why my base44 apk wasn’t changing, and it wasn’t linked… should I just try to sync the 2 repository and have the final project be the newly made repo?”

Two weeks of work in one place, an app build in another, and nothing joining them. That person is on Base44, and the platforms behave differently, but the failure is identical: the connection was never doing what its existence implied.

Which points at the thing every page on this search misses. The connection breaking and the work being lost are two separate events. An error in the project’s GitHub settings announces the first one. Nothing announces the second, and it can run for weeks. If the builder still opens and still generates, no screen tells you that commits stopped leaving the platform.

Before assuming the connection is the problem, rule out whether Lovable itself is down rather than just the GitHub link, because a platform-wide incident looks the same from outside. And if the app is misbehaving rather than the sync, when the fix loop itself has stopped working is the other half of that call.

How Lovable’s GitHub sync is meant to work

Read on 25 August 2026, Lovable’s GitHub integration documentation describes the sync running in both directions: work generated in the builder lands in the repository, and commits pushed to the branch the project is currently set to come back into the builder. The same page describes Lovable editing and syncing a single branch at a time.

That single-branch rule is the fact the rest of this page rests on, and it is why the Lovable GitHub integration can be connected, showing no error, and still not hold your last two weeks of work.

The connection itself has two layers, and the documentation defines them separately. A workspace connection “authorizes Lovable to access a GitHub account or organization through the Lovable GitHub app”. A project repository link “connects one Lovable project to one GitHub repository”. One workspace connection can carry many projects. One project points at one repository.

Roles follow that split. The docs state that “Workspace admins and owners can create workspace connections”, which is why a founder who invited a contractor into the workspace sometimes cannot clear an error the contractor clears on the first try, and why the reverse also happens.

Two absences matter here, because people assume the opposite. As of 25 August 2026 that documentation publishes no sync latency figure, so there is no “syncs within N seconds” behaviour to hold it to. It also does not list secrets, databases or environment values among what the sync leaves out; that boundary is established elsewhere, and the documented routes for getting Lovable’s code out covers the connect click path and the codebase download this page skips.

Every other connector a Lovable project carries has its own failure mode, and what else Lovable connects to, and where each join breaks, is a longer inventory than this page attempts.

Is it the workspace connection or the project’s repository link?

Two layers can fail, and the wording Lovable shows you tells you which. Workspace faults name the GitHub app or the account, and a workspace owner or admin clears them once for every project on that connection. Project faults name this repository, this branch, or one large file.

The documentation is explicit about where the fix lives: “When something goes wrong, Lovable shows a Reconnect prompt in the affected project’s GitHub settings.” For the workspace layer, one person clears it for everyone. “A workspace owner or admin only needs to perform the fix once from any affected project, and the other projects on the same connection resume automatically.”

Sorting a Lovable GitHub connection not working into the right layer is most of the diagnosis. The symptom wording below is Lovable’s own, from its troubleshooting sections read on 25 August 2026.

One workaround circulating in the community sits outside both lists. The top organic result for this search on 25 August 2026 is an r/lovable thread titled “2 way sync with github not working?”, and its Google snippet describes unpublishing and republishing the project. The thread is not readable to this page, so that is a reported workaround rather than a documented step, and the source is cited as reddit.com/r/lovable without a link for the same reason. If publishing is the step that will not complete, the diagnosis runs the other way and starts there.

Reconnecting is also not always enough, and it is better to know that before you spend a morning on it. A GitHub community discussion opened on 22 March 2025 records a Lovable project that lost access to its repository after a GitHub organization rename. The poster reinstalled the app, granted it access to the new organization and repository, synced from inside Lovable, and signed out of both services. None of it worked. The thread ran to a dozen comments with activity into April 2026 and closed unanswered.

Where the work hides when a push fails

Lovable creates two branch names of its own, and each one is a receipt for a specific failure. Neither is a bug.

lovable-fallback appears when the branch you were synced to stopped existing. The documentation is plain about the cause: “The branch your project was synced to was deleted on GitHub. Lovable automatically switched the project to a new branch called lovable-fallback so you can keep editing without errors. Your repository is otherwise untouched.” The documented move is to pick another branch or recreate the original, then leave or delete the fallback branch once you have moved on.

lovable-sync-<timestamp> appears when the push was refused. Lovable’s own explanation names both usual reasons: your synced branch rejected the push, “most often because of branch protection rules or because someone pushed a conflicting change you couldn’t be rebased onto”, so it pushed the work to a new timestamped branch instead. Open that branch on GitHub, read the changes, and merge them through whatever review your protected branch requires. The work survives. It sits on a branch nobody told you about.

Then there is the size ceiling, which has two owners and gets blamed on the wrong one constantly. GitHub is the side that refuses a push containing any file over 100 MB. Lovable is the side that cannot save a file over 10 MB into the project in the first place. Both numbers come off the integration page linked above, under the read date this page opened with, and both produce the same outward symptom: a designer drops a video into the project, every later commit stops leaving the platform, and GitHub simply looks stale. A project that stops moving inside the editor for other reasons is a broader question than the sync.

None of this is the same job as getting back to the last version that worked in the builder’s own history, which is a separate mechanism with separate consequences.

Does the repository hold a complete copy?

A repository that is connected can still be missing your last two weeks. Six checks settle it: the branch the project is set to, any Lovable-created branch in the picker, the newest commit date, who authored the newest commits, whether a large file was rejected, and the parts that never travel at all.

Every check below runs in the GitHub web interface and the project’s own settings screen. None of it needs a terminal.

1. 01 Read which branch the project is set to in its GitHub settings, then open that exact branch on GitHub. It is the only branch Lovable is syncing, so the default branch you land on by habit may not hold your work.
2. 02 Look at the branch picker for a lovable-fallback branch or anything starting with lovable-sync-. Either name means a push was diverted, and says which failure happened.
3. 03 Compare the newest commit date on the synced branch against the last change you remember making in the builder. The gap is the length of the silent period.
4. 04 Check who authored the newest commits. Lovable states that commits it makes carry its GitHub app identity, lovable-dev[bot] on github.com and GitHub Enterprise Cloud, so generated commits are distinguishable from yours at a glance.
5. 05 Look for a missing large asset, and read the project GitHub settings for a file-size error. One file over the limit stops everything behind it, and the repository just looks a few commits short.
6. 06 Accept that the database, the uploaded files and the secret values were never in the repository at all. A complete code copy is still not a complete app.

That last item is the one people discover too late, usually while trying to restore something. The repository holds the code and the configuration files that describe the backend. It does not hold the rows. Getting the database itself out of Lovable is a separate procedure, run separately from anything on this page.

You have two repositories and no idea which is real

This is the situation the top of this page opened with, and Lovable’s own limitations list explains how it happens. Among the things the Git sync integration does not support: “Reconnecting to the same repository after disconnecting. A new repository is created on reconnect.” Disconnect a project to clear an error, connect it again, and you own two repositories. The original stays on GitHub with its full history, unchanged, attached to nothing.

The safe order matters more than speed here.

Do not merge anything yet. Clone or download both repositories so you can read them side by side without either platform in the loop. Compare the newest commit date, the total file count, and the two or three features you built most recently. Decide which one is the trunk before you touch either. Only then reconcile, and keep the loser as an archive rather than deleting it.

A single broken connection is usually one specific problem with one specific repair. Reconciling two repositories that both hold real work is a different size of job, decided after someone has read both, and it should never be quoted as though it were the small one.

If the second repository appeared because you moved the repository yourself during a migration, the cause and the fix are different: what breaks when you move the repository during a migration covers the rename, transfer and delete cases and the ordering rule around them. This page is about the sync that broke without anyone moving anything.

Two repositories is also the state that makes it impossible to bring anyone in, because the first question a developer asks is which one to work from. What a developer needs handed over before they can help belongs in that conversation, and handing the whole project to someone else has its own prerequisites beyond a working repository.

Can Lovable pull from GitHub?

Lovable does not import an existing GitHub repository. Its GitHub integration page, read on 25 August 2026, answers the question with a flat no in both the limitations list and the FAQ. The sync is two-way on the branch it is set to, and the initial direction is Lovable outward only.

The limitations list names it outright, among the things the Git sync integration does not support: “Importing existing GitHub repositories into Lovable”. The FAQ answers the same question the same way.

For someone staring at a broken sync, that is the fact that reorders the priorities. There is no route back in. If the builder’s copy of your project is the damaged one, the repository cannot be used to restore it, which is the reverse of what most people assume a two-way sync means. The repository is a destination, and a destination is only useful if what arrives there is complete, which is why the checks above come before any attempt to reconnect.

The exit is one-directional by design. Which builders let you take the code with you sets Lovable against the ones that read from a repository as well as write to it, and that difference shows up the day you want to work outside the builder.

The same failure on Replit, and what is different

A stale GitHub repository means something different on Replit, and mistaking one cause for the other wastes an afternoon. Replit’s Git pane documentation, read on 25 August 2026, describes a manual client. Commit changes: “Save your changes with descriptive messages”. Push updates: “Send your commits to your remote repository with a single click”. Pull changes: “Sync with remote updates from collaborators”. It also states that “Any Git commands executed in the Shell will automatically sync with the Git pane”, so the terminal and the visual pane are two views of the same repository.

As of 25 August 2026 that page documents no automatic two-way mirror. So on Replit a stale repository usually means nobody clicked push, and the Replit GitHub integration has no connection to repair. Self-hosted providers are the one place the plan matters: Replit “supports GitHub Enterprise Server, GitLab Self-Managed, and Bitbucket Data Center on the Enterprise plan”.

The import direction is where the two platforms genuinely diverge. Replit documents importing from a provider at replit.com/import, and names Lovable specifically: “Import a Lovable project into Replit by exporting it to GitHub, then importing that repository.” The same page is honest about the ceiling, listing under what is not imported “Supabase data: Existing database records are not migrated” and “Secrets: Environment variables and API keys must be added separately”. That is the completeness check arriving from the other end: a repository moves the code, and the app is more than the code.

For the Replit push procedure itself, including the token handling that trips people up, getting a Replit app, its database, files and secrets out has the sequence, and this page deliberately does not repeat it.

Common questions about a broken Lovable GitHub sync

Does Lovable work with GitHub?

Yes. Lovable’s GitHub integration documentation, read on 25 August 2026, describes a two-way Git sync built on a Lovable GitHub app: a workspace connection authorizes the app against a GitHub account or organization, and each project links to one repository. The sync covers one branch at a time, in both directions on that branch.

How to get Lovable code on GitHub?

Connecting the project to GitHub is the documented route, and Lovable also documents a codebase download on paid plans. Both click paths live on the documented routes for getting Lovable’s code out, with the warnings attached to each. This page assumes the connection already existed and stopped working.

Is Lovable down?

Check that before anything else, because a platform incident and a broken GitHub connection look identical from inside your project. Whether Lovable itself is down rather than just the GitHub link is a separate check with its own signals.

Why is GitHub not working?

GitHub publishes its own component status at www.githubstatus.com, and three of those components bear on sync: Git Operations, API Requests and Webhooks. Read that page live rather than trusting any status quoted here, because a status is only true for the minute it was read.

Why did my GitHub commits not show up in Lovable?

Almost always because the commits went to a branch the project is not synced to. Lovable syncs the branch selected in the project’s GitHub repository connection settings, which defaults to the repository’s default branch. The documentation gives two fixes: merge your branch into the synced branch, for example through a pull request into main, or switch the synced branch in the project’s GitHub settings to the branch your commits are on.

My Base44 app stopped updating from GitHub. Same problem?

Different platform, different rule. Base44’s GitHub documentation requires the synced branch to be named main, and says so without hedging: “Other default branch names, such as master, currently aren’t supported.” Base44 also pushes automatically once connected and gives you no manual push button, so a stalled Base44 sync is usually a branch-name or plan-tier question. Every documented way out of Base44 has that page’s full terms.

Has this ever been Lovable’s fault rather than mine?

Once, on the record. Lovable’s own incident write-up, published 6 January 2025, says the platform was “partially or fully down for about 19 hours” on 2 January 2025 after GitHub disabled Lovable’s GitHub app, because the rate of repository creations breached GitHub’s terms and “significantly burdened their servers”. The outcome is the part to keep: “No projects were lost in the incident but some edits made during the outage were never applied.” An edit that was never applied leaves no error behind, which is the same silence the checks above are built to break.