Export Lovable project to GitHub and continue in Cursor

Lovable's GitHub export is a two-way sync, not a one-time download, and that changes how you should hand a project to Cursor. Lovable's GitHub integration docs describe the model in three lines: changes made in Lovable sync to GitHub, changes pushed to the active GitHub branch sync back into Lovable, and "Lovable only edits and syncs one branch at a time." Everything that goes wrong in a Lovable to Cursor handoff comes back to that last rule.

The Git sync overview adds the limit you hit first: the sync status card compares the 50 most recent commits on each side, so a large gap reads as 50+ rather than an exact count. The same page sets expectations about what a clone actually gives you: "A clone gives you the code, not the services the app calls." Keep both in mind and the rest of this guide is mechanics.

How do you connect a Lovable project to GitHub?

Connecting a Lovable project to GitHub takes two steps: only workspace admins and owners can do the first, and workspace or project admins and owners can do the second. First, a workspace connection installs the Lovable GitHub app on your GitHub account or organisation, from Workspace settings > Git > GitHub > Add connection. Second, a project repository link connects one Lovable project to one repository, from Project settings > Git > GitHub, where you click Connect next to the workspace connection you want.

Lovable's GitHub docs state that Lovable then "creates a new GitHub repository and starts two-way sync automatically." Three details from the same page matter before you click:

• The repository is new and private. Git sync cannot attach to a repository that already exists, and the repository it creates is private by default on every plan.
• Do not delete the repository. Deleting it stops the sync. Renaming the repository or your account keeps the sync running.
• Reconnecting creates another repository. If you disconnect and connect again, Lovable makes a fresh repository with the current code and leaves the old one unlinked.

If all you want is a copy of the code and you have no plan to keep building in Lovable, GitHub is optional. Lovable's docs point paid-plan users to Download codebase in Project settings > Git instead.

How do you open the Lovable repository in Cursor?

Opening the repository in Cursor starts from the clone URL Lovable shows in the project's GitHub settings, which offers HTTPS, SSH and GitHub CLI versions. Clone it to your computer with the Git client you already use, then open that folder in Cursor. Cursor's Quickstart describes the first run the same way: install Cursor, sign in, then pick a folder.

Before you change a line, wait for any Lovable edit in progress to finish and check that the sync status card reads "In sync with GitHub". Lovable's Git sync overview recommends this so your local copy starts from the latest Lovable changes. The README and package.json in the repository list what you need installed and the commands that install dependencies and start the app.

Your first Cursor prompt should be a read, not a write. The Cursor Quickstart suggests opening Agent with Cmd I and asking it to "Explain this codebase. Point me to the main entry points, key modules, and anything I should read before making changes." On a Lovable project this tells you where the pages, components and backend calls live before Agent touches any of them.

How do Cursor commits get back into Lovable?

Cursor commits reach Lovable when they land on the branch Lovable syncs, and only then. Lovable's Git sync overview says Lovable receives commits pushed to the synced branch regardless of which tool made them, so Cursor needs no special setup. Commit in Cursor's Source Control panel and push.

The safe pattern is the one Lovable's docs recommend: keep Lovable on the synced branch, usually main, and do your Cursor work on a feature branch. The feature branch stays out of the Lovable project until you merge it, so unreviewed work never reaches the preview. When you merge into main, Lovable pulls the result and the sync status card shows both sides in sync again.

Cursor adds two helpers on top of standard Git, per Cursor's Git help page. A sparkle icon in the commit message box writes a message from your staged diff, and a Resolve in Chat button in the merge conflict view has Agent propose a resolution. Cursor also adds a "Made with Cursor" trailer to commits and pull requests Agent creates, on by default and switchable in Cursor Settings.

Once your merge has synced, tell Lovable what you changed. The Git sync overview is blunt about why: "Lovable treats code you wrote the same as code it generated, and it can change either in a later request." Put any rule that must survive future prompts in project knowledge, which Lovable's knowledge base covers in detail, and keep tests for behaviour you depend on.

Which branch does Lovable sync, and can you change it?

Lovable syncs the repository's default branch, usually main, unless you pick another one in the branch picker in Project settings > Git > GitHub. Lovable's GitHub docs say it starts editing and syncing the new branch immediately, and that a branch you create from the picker forks from the currently active branch, not from main. Switch to main first if that is where the feature should start.

The most common complaint, commits that never show up in Lovable, has a plain cause. If you pushed from Cursor to a feature branch, Lovable ignores those commits until you either merge the branch into the synced one or switch Lovable's synced branch to it. If you pushed to the synced branch and the card still says GitHub is ahead, Lovable's docs explain that Lovable pulls only when GitHub notifies it of a push, and that when the notification never arrives the fix is to push any new commit, even an empty one.

Teams that protect main with required pull requests need one more setting. GitHub rejects Lovable's direct pushes to a protected branch, and Lovable then parks its work on a branch called lovable-sync. Lovable's docs suggest giving Lovable a feature branch of its own and merging its work through the same review process as everyone else's.

What happens when you edit in Lovable and Cursor at the same time?

Editing the synced branch from both tools at once produces a diverged history, and Lovable resolves it in a way that surprises people. Lovable's Git sync overview says that when the card reads "Lovable and GitHub have diverged", Lovable pushes its own changes to a separate lovable-sync branch, and "the next sync from GitHub replaces Lovable's version of the branch with the GitHub version."

Lovable saves a backup before that replacement. Lovable shows a notice in the editor and in Project settings > Git reading "A repository push replaced your Lovable work", and only the project owner can restore the saved commits or keep the repository version. Other members see the notice but must ask the owner to restore. The notice shows for 24 hours after the push; after that, the owner finds it under Check for saved Lovable work in Project settings > Git.

Rewriting history makes the same thing happen. Lovable's Git sync overview says: "Do not force-push, rebase, or squash commits that are already on the synced branch." To undo a change, add a commit that reverts it. If you take one rule from this page into Cursor, take that one, and tell Agent too, because an agent asked to tidy up the history will reach for exactly those commands.

What breaks when you run a Lovable app locally in Cursor?

Environment and backend configuration break first, because the repository does not carry everything the running app needs. The numbers below come from Lovable's Git sync overview and GitHub docs:

Limit or behaviour	Value	What it means for a Cursor handoff
Commits compared by the sync status card	50 most recent on each side	A large gap reads as 50+, not an exact count
Largest file GitHub accepts in a push	100 MB	A bigger file stops the sync until you remove it
Largest file Lovable can save	10 MB	Files you push that are larger sync in, but Lovable cannot edit them
Restore notice after a push replaces Lovable work	24 hours	After that the owner restores from Project settings > Git
Apps that run server code on your machine	Created from May 13, 2026 (TanStack Start)	Connector and Lovable AI calls fail locally

The database is the trap with the highest cost. In a Lovable Cloud project, the committed .env file carries the backend URL and publishable key as VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY, so your local app reads and writes the same backend as the published app. Lovable's Git sync overview puts it in one line: "A Git branch does not give you a separate database." Use test accounts and test records whenever you try a write locally.

Secrets do not travel at all. Lovable's Secrets docs say secrets are write-only, injected into Edge Functions, and never reach the browser, so server-side code that reads them needs those values wherever it runs. The same page warns against a habit Cursor users bring with them: do not add .env to .gitignore in a Lovable project, because Lovable needs it committed for previews and published builds. The flip side is that .env must never hold a secret, since every VITE_ value is bundled into browser code. The vibe coding security checklist shows how to search the deployed JavaScript for a leaked key.

Sign-in and backend files need two more checks:

• Auth redirects. An authentication provider redirects only to URLs it knows, so add your local URL to the provider's redirect list before you test login.
• Edge Functions. Lovable does not deploy a changed function under supabase/functions/ when your commit syncs. Ask Lovable in the project chat to deploy it.
• Migrations. Lovable does not run a migration file you add through Git. Ask Lovable for the schema change, or run the SQL yourself in the SQL editor.

If the project uses your own Supabase project rather than Lovable Cloud, the Secrets docs say its secrets are managed in the Supabase dashboard, and Lovable's Supabase docs say there is no automatic migration between Lovable Cloud and your own Supabase project in either direction. Decide which backend you want before the handoff, not after.

How do you keep Cursor's agent from undoing Lovable's structure?

Cursor's agent starts every session with no memory of how Lovable built the project, so give it written rules in the repository. Cursor's Rules docs explain the reason directly: "Large language models don't retain memory between completions." Project rules live in .cursor/rules as .mdc files and are version-controlled, and a plain AGENTS.md file is the simpler alternative.

A useful first rule file for a Lovable repository says four things: do not edit .env or add it to .gitignore, never rewrite history on the synced branch, create new schema changes through Lovable rather than new migration files, and keep secrets out of any VITE_ variable. Cursor rules for product managers covers how to write and scope rules like these.

For anything larger than a copy fix, use Plan Mode. The Cursor Quickstart says Shift+Tab in the agent input toggles it, and Cursor then researches the codebase, asks clarifying questions, writes a plan and waits for approval before building. On an app another tool generated, reading the plan is how you catch Agent deciding to rewrite a Lovable component instead of extending it.

When should you graduate from Lovable to Cursor for good?

Most projects should not leave Lovable completely, and Lovable's own GitHub docs say so plainly: "You don't need GitHub to use Lovable. Many users build and launch entirely within Lovable." The handoff described above keeps both tools, and Lovable's ownership docs list "use your own IDE or coding tools" as a case where you keep Git sync connected and carry on building in Lovable.

Move to Cursor full time when one of these is true: an engineer now owns the code and reviews every change, the work is mostly logic and tests rather than screens, or Lovable keeps rewriting code you changed by hand. Stay in Lovable when the work is still mostly UI iteration, when nobody on the team can review a diff, or when the app depends on Lovable connectors and Lovable AI, whose credentials Lovable manages and which cannot be copied out.

The cost of leaving is concrete. The same ownership page lists what you take on if you stop using Lovable entirely, including CI/CD pipelines and release processes, production infrastructure and SSL, databases and backups, authentication and data isolation, secrets and API integrations, and security audits and monitoring. If that list reads like a job description nobody on your team has, keep the two-way sync and use Cursor for the parts Lovable handles badly. Deploying an AI-built app for the first time shows what running your own hosting involves.

Building with Lovable is a two-week Builders Camp bootcamp with 3 live sessions and 9 self-paced microlessons, led by programme director Ricardo Luiz, and it takes you from idea to an interactive full-stack prototype using Lovable, Supabase and GitHub, with no code required. If you write code already and want the Cursor side, Building with Cursor is a one-week bootcamp for developers on using Cursor as a development partner through Ask, Plan and Agent workflows. Both sit in the Vibe Coding Expert Track.