# Work on a Lovable app locally in Canopy without losing Git sync

> A branch, environment, preview, and publishing checklist for using local coding agents on a Lovable project connected to GitHub.

Canonical HTML: https://canopyide.dev/guides/lovable-to-canopy-local-coding-agent-workflow
Article date: 2026-09-28

You can keep building a Lovable app in Lovable and use a local coding agent on the same repository. Lovable's Git sync is two-way, but it follows one active branch at a time. The safe handoff is to finish the Lovable edit, confirm sync, work locally on a feature branch, review a pull request, merge to the synced branch, then check Lovable Preview and publish separately. The harder part is often the environment: a local clone can still call the real Lovable Cloud backend.

## First, know what each product owns

Lovable already provides an AI app-building workflow, GitHub sync, project drafts, preview testing, Cloud services, and a separate publishing action. Its Git sync guide explicitly supports cloning the project and editing it with an IDE or coding assistant. Canopy adds a local project workspace around an installed coding CLI, the project's own run commands, a local Preview, files, diff, and PR review. Canopy does not supply a replacement Lovable Cloud backend or publish the app to Lovable. You need Git access, the project's runtime, and a supported CLI signed in to its own provider account. Check the Canopy release you installed: its main-branch README can describe features newer than the latest download.

*A handoff map, not an automatic migration.*

| Surface | What to check before editing | What happens next |
| --- | --- | --- |
| Lovable | Git sync status and active synced branch | Merges to that branch return to the project |
| GitHub | Repository access, feature branch, PR checks | Reviewed commits enter the synced branch |
| Canopy | Correct local checkout, installed CLI, run commands | Agent edits and local Preview stay inspectable |
| Cloud and live app | Backend target, test data, publish permission | Preview and published URL need separate checks |

## Connect GitHub and establish a clean starting point

In Lovable, connect the project under Project settings → Git and note the repository URL, the branch in the picker, and the sync status. Lovable creates a repository when you link a project; its docs say the new repository is private by default. Let any Lovable edit finish. Wait until the status says the project and GitHub are in sync before cloning, because otherwise the local checkout may start behind an edit still held in Lovable. The status card's Re-check compares histories; it does not perform a sync. If you lack repository write access, ask the owner to set up a reviewed contribution route before expecting your local commits to return to Lovable.

- Copy the HTTPS, SSH, or GitHub CLI clone URL from Lovable's Git settings.
- Record the active synced branch; a local feature branch does not appear in Lovable until merged or selected there.
- Do not rewrite history on the synced branch with a force push, rebase, or squash after Lovable has seen those commits.

## Clone and identify the environment before running anything

Clone the repository, open its folder in Canopy, and check `git status --short --branch` before starting an agent. Read the repository README and package scripts for the actual install and run commands. Save the verified command in Canopy Servers and open its detected local URL in Preview. Do not infer the command from the framework logo. Lovable's local-work guide says a clone contains code but may still use its Lovable Cloud backend. A committed `.env` can contain the backend URL and a publishable browser key; with that configuration, local creates, edits, and deletes can affect the same data as the published app. Use test accounts and records, inspect auth redirect settings, and keep secrets out of browser-prefixed variables and Git commits. A Git branch is not a separate database.

- Before a write test, identify which backend, database, and external services the local page calls.
- If a local AI or connector call fails, check whether that service only works in Lovable Preview for this project's framework and creation date.
- A synced migration file or Edge Function change is code only; Lovable does not automatically run the migration or deploy the function from a Git commit.

## Give one agent a bounded branch and review its result

Create a feature branch from the synced branch, then give the installed CLI one request with a visible success and failure state. For example: fix the sign-up form's duplicate-submit behavior without changing the database schema; show the form working locally, report the test command and result, and list any backend calls. In Canopy, verify the agent's working directory and branch, inspect its terminal and the local page, then read the final diff. If another agent is editing in parallel, give it an isolated worktree and a separate outcome. Open a GitHub pull request for human review and let required checks finish. A passing local build is useful evidence; it is not proof that Lovable Preview, Cloud behavior, or the published site is correct.

- Review changed dependencies, auth rules, migrations, and secrets before merging.
- Keep the branch and PR link in a short handoff so a new CLI session can continue from current files.
- If the agent edited the wrong checkout, preserve the work and move only reviewed changes to the intended branch.

## Merge into Lovable's synced branch, then verify three states

Merge the reviewed PR to the branch Lovable currently syncs. Wait for the Git status card to return to in sync; if your organization protects that branch, coordinate the review path with the owner. Open the changed files and test the behavior in Lovable Preview. Tell Lovable what changed outside its chat so its next edit has the right context, and put durable constraints in project knowledge and tests. Finally, publish or publish changes when the owner decides the feature is ready, then open the live URL. Git merge, Lovable Preview, and the published snapshot are three separate states. Accepting a Lovable draft is also separate from publishing; drafts do not sync as Git branches until accepted.

*Stop at the first failed boundary instead of assuming a push shipped the app.*

| Boundary | Evidence | Next action if missing |
| --- | --- | --- |
| GitHub to Lovable | Sync card says in sync; changed file visible | Check active branch and sync error |
| Lovable project | Expected behavior in Lovable Preview | Inspect build, auth, Cloud call, and backend deployment |
| Published app | New behavior at live URL after publish | Publish changes and verify the deployed version |

## Recover from a diverged or blocked sync

If Lovable and GitHub both contain unmatched commits, stop new edits and inspect both histories. Lovable's docs say it may save Lovable-only work to `lovable-sync` when a push is rejected by a protected branch or conflict. Review that branch as a PR and merge intentionally; do not delete it or force-push the synced branch simply to clear a warning. The docs also warn that a later GitHub sync can replace Lovable's copy of the branch. If the status remains ambiguous or Lovable-only edits are missing from GitHub, preserve the status and commit IDs and follow Lovable's troubleshooting guidance before another push. For costs, local edits and commits do not spend Lovable build credits, but Cloud or AI calls from the local app can still count as Lovable usage; the installed CLI has its own provider billing or plan limits.

- Check whether the PR targeted Lovable's active branch, not merely a similarly named default branch.
- Inspect the contents of `lovable-sync` before merging it; a branch name alone does not certify the patch.
- If a backend migration or function is part of the change, assign its deployment and data verification explicitly.

## Copyable resources

### Lovable ↔ local agent handoff card

Copy into a project issue or PR. Record identifiers and results, never secret values or customer data.

````text
Lovable project and GitHub repo: [ ]
Active synced branch and last in-sync time: [ ]
Starting commit and feature branch: [ ]
Local runtime/install/run commands: [ ]
Canopy release, installed CLI, working directory: [ ]
Local backend target and test-data plan: [ ]
One requested behavior and failure check: [ ]
Agent diff, test result, and PR URL: [ ]
Backend migrations/functions and owner: [ ]
After merge: Lovable in-sync status [ ]; Preview behavior [ ]
After owner publishes: live URL and behavior [ ]
Next task, constraints for project knowledge, and reviewer: [ ]
````

## Frequently asked questions

### Can I keep using Lovable after an agent edits the repo in Canopy?

Yes. Merge the reviewed local branch into Lovable's active synced branch, wait for sync, and test in Lovable Preview. Tell Lovable what changed so the next request builds on the right code.

### Will my local feature branch or Lovable draft appear on the other side automatically?

No. Lovable follows one active synced Git branch; a local feature branch reaches it after merge or a deliberate branch switch. A Lovable draft is not a Git branch in the connected repository until accepted.

### Does running the clone locally make a safe test database?

No. A local app can call the same Lovable Cloud backend and change real records. Check the environment, use test data, and arrange separate backend isolation when the work requires it.

### Does merging a PR publish the Lovable site?

No. Merge and sync update the Lovable project and Preview. The live site changes only after a separate publish action.

### Does this avoid all Lovable charges?

No. Local code edits do not use Lovable build credits, but calls from the local app to Cloud or Lovable AI may consume usage. The coding CLI and other services have their own accounts and costs.

## Sources and further reading

- [Lovable Git sync: local IDE workflow, branch handoff, environment, and backend limits](https://docs.lovable.dev/integrations/git-sync-overview)
- [Lovable GitHub integration and sync troubleshooting](https://docs.lovable.dev/integrations/github)
- [Lovable drafts and Git sync limitation](https://docs.lovable.dev/features/drafts)
- [Lovable publishing and live snapshot](https://docs.lovable.dev/features/publish)
- [Canopy README: local agents, Servers, Preview, and Git review](https://github.com/FluidWorksApp/canopy-ide/blob/main/README.md)
- [Public question about continuing local work alongside Lovable](https://www.reddit.com/r/lovable/comments/1uum2ug/github_repo_work_alongside_continued_lovable_use/)

## Related Canopy pages

- [Can a noncoder build software with AI coding agents?](https://canopyide.dev/guides/can-noncoders-build-software-with-ai-agents.md)
- [Canopy vs Replit Agent for building an app](https://canopyide.dev/use-cases/canopy-vs-replit-agent-for-building-apps.md)
- [My coding agent edited the wrong branch or worktree. What now?](https://canopyide.dev/guides/coding-agent-edited-wrong-branch-or-worktree.md)
- [How do I start my website, API, and worker with one click?](https://canopyide.dev/use-cases/one-click-local-dev-stack.md)
- [How to review an AI-generated pull request](https://canopyide.dev/guides/review-ai-generated-pull-requests.md)

Canopy runs installed coding CLIs; CLI accounts, model selection, and provider billing remain separate. Check the installed release before relying on version-specific behavior.