Skip to main content
RapidDev - Software Development Agency
lovable-issues

How to Use Lovable with Codex & Claude Code (Hybrid Workflow)

Adding Lovable to Codex means connecting the official Lovable MCP server (mcp.lovable.dev) so an external agent can create, prompt, and publish Lovable projects. Claude, Claude Code, Cursor, and VS Code can complete that OAuth setup today; Codex is listed in OpenAI's plugin ecosystem but full authentication is still rolling out, so the dependable fallback for Codex right now is a GitHub two-way sync hybrid workflow.

Book a free consultation
4.9Clutch rating
1,000+Happy partners
20+Countries served
200+Team members
Advanced10 min read~20 min setup, ongoing workflow discipline after thatLovable all plans (MCP server available Free through Enterprise); Claude, Claude Code, Cursor, and VS Code fully supported; Codex OAuth support rolling out as of September 2026Last updated September 2026RapidDev Engineering Team
TL;DR

Adding Lovable to Codex means connecting the official Lovable MCP server (mcp.lovable.dev) so an external agent can create, prompt, and publish Lovable projects. Claude, Claude Code, Cursor, and VS Code can complete that OAuth setup today; Codex is listed in OpenAI's plugin ecosystem but full authentication is still rolling out, so the dependable fallback for Codex right now is a GitHub two-way sync hybrid workflow.

Quick facts about this guide
FactValue
ToolLovable
DifficultyAdvanced
Time required~20 min setup, ongoing workflow discipline after that
CompatibilityLovable all plans (MCP server available Free through Enterprise); Claude, Claude Code, Cursor, and VS Code fully supported; Codex OAuth support rolling out as of September 2026
Last updatedSeptember 2026

Why combine Lovable with Codex or Claude Code

Lovable's builder agent is tuned for full-stack scaffolding, UI iteration, and wiring up Cloud services fast — but it is not the right tool for deep refactors, algorithm-heavy logic, or codebase-wide reasoning across dozens of files. That is exactly what dedicated coding agents like Codex and Claude Code are built for. In 2026, Lovable shipped its own MCP server so external agents can control a Lovable project directly, but the officially supported OAuth clients are currently Claude, Claude Code, Cursor, and VS Code. Codex shows up in OpenAI's plugin ecosystem listings, but its own authentication flow to the Lovable MCP server is not fully documented yet, which is why most Codex users fall back to a GitHub-based hybrid workflow instead. The two integration paths solve the same problem differently. The MCP server lets a supported agent act as a remote control for Lovable's builder — creating projects, sending prompts, inspecting diffs, running SQL against Lovable Cloud, and publishing, all without leaving the coding agent's own interface. The GitHub sync hybrid workflow is older and more universal: Lovable pushes every prompt-driven change to a connected repository, and any external agent with repo access — Codex included — can read, edit, and push back. Both paths work; which one you use depends entirely on which client your coding agent is.

  • Lovable's builder agent is tuned for UI and full-stack scaffolding, not deep refactors or algorithm-heavy logic across many files
  • The Lovable MCP server (mcp.lovable.dev) lets Claude, Claude Code, Cursor, and VS Code create, prompt, and publish Lovable projects directly
  • Codex's OAuth flow for the Lovable MCP server is not fully live yet, so it cannot complete that connection the same way today
  • GitHub two-way sync means any agent with repo access — including Codex — can push and pull changes without an MCP connection, as long as you follow pull-before-push discipline

Error messages you might see

Other MCP clients cannot complete the OAuth flow at this time

This is Lovable's own documented limitation for MCP clients outside the supported list (Claude, Claude Code, Cursor, VS Code). If Codex hits this, switch to the GitHub sync hybrid workflow instead of troubleshooting the MCP connection further.

GitHub sync broken after repository was moved or renamed

Moving a connected GitHub repo to a different organization, or renaming a GitLab repo, breaks two-way sync. Reconnect from Lovable's GitHub settings, which creates a fresh repository — export or note your latest commits first so nothing is lost.

Before you start

  • A Lovable project with GitHub (or GitLab) two-way sync connected
  • A Claude Code, Cursor, or VS Code setup if you plan to use the official Lovable MCP server (mcp.lovable.dev)
  • A Codex account with repository access for the GitHub sync hybrid workflow
  • An AGENTS.md file, or the willingness to create one, documenting which agent owns which part of the codebase

How to fix it

1

Understand the two integration paths before you pick one

Choosing the wrong path wastes setup time and can lead to conflicting edits

There are two separate ways to connect an external coding agent to Lovable. Path one is the Lovable MCP server: a supported client (Claude, Claude Code, Cursor, or VS Code) connects via OAuth and can control the Lovable project directly from the agent's own chat. Path two is the GitHub sync hybrid workflow: Lovable pushes every change to a connected GitHub repository, and any agent with access to that repo — including Codex today — can read and write code independently, with changes flowing back into Lovable through the sync. If you use Claude Code or Cursor, start with path one. If you use Codex, use path two until Codex's own OAuth support ships.

Expected result: You know which path applies to your coding agent before you start configuring anything.

2

Set up the Lovable MCP server for Claude Code or Cursor

This is the officially supported way to control Lovable from a coding agent today

Open your coding agent's MCP server settings and add a new remote server pointing at https://mcp.lovable.dev, then complete the OAuth sign-in with your Lovable account when prompted. Once connected, tools appear for creating and listing projects, sending prompts to the builder, inspecting file diffs and edit history, running SQL against your Lovable Cloud database, and publishing the app to get a live URL. VS Code follows the same OAuth flow through its own MCP configuration screen. Note that a third-party guide claims a separate 'lov_' API key header works for headless auth outside the supported clients — that conflicts with Lovable's own documentation, which lists OAuth as the only supported method, so treat the API-key claim as unverified and stick with OAuth.

Expected result: Your coding agent can create and edit a Lovable project directly from chat, and every MCP action consumes your normal Lovable workspace credits, same as using the editor.

3

Set up the GitHub sync hybrid workflow for Codex

This is the reliable path for Codex until its own MCP OAuth flow is complete

In your Lovable project, click the GitHub icon in the top-right corner and connect a repository — this creates two-way sync, so every prompt-driven change in Lovable becomes a commit, and every commit pushed to the synced branch shows up in the Lovable editor. Give Codex access to that same repository (as a cloud agent or a local checkout, depending on how you run it) and let it work against the synced branch. Never rename or move the connected repository: GitHub renames auto-follow the sync, but moving the repo to a different organization or deleting it breaks the connection with no automated recovery — you would need to disconnect and reconnect, which creates a fresh repository.

Expected result: Codex-authored commits appear inside the Lovable editor, and Lovable-authored commits are visible to Codex, all through the same repository.

4

Divide the work between Lovable and the coding agent

Each tool has a different strength, and mixing responsibilities without a plan causes overwritten work

Use Lovable for UI scaffolding, page structure, Cloud and Supabase wiring, and fast iteration with Visual Edits. Hand off to Codex or Claude Code for complex business logic, algorithmic code, large refactors, and anything that benefits from a full codebase-aware reasoning pass across many files. Document this split in an AGENTS.md file in the repo root so every agent — Lovable's builder included — reads the same architecture notes, protected files, and conventions before making changes. This is also where a RapidDev engineer typically gets involved on client projects: reviewing the AGENTS.md split, tightening the handoff between the two agents, and taking ownership of the logic Codex or Claude Code should own so nothing falls into the gap between tools.

Expected result: A documented, repeatable split of responsibilities that both agents respect, instead of ad hoc decisions made prompt by prompt.

5

Avoid the common hybrid-workflow conflicts

Two agents editing the same repository without discipline will clobber each other's work

Always pull the latest commit before starting a new Codex or Claude Code session, and let any in-progress Lovable generation finish before pushing external changes to the synced branch. Lovable syncs one active branch at a time, so keep that branch as the single source of truth rather than juggling multiple synced branches. If you want to test a large Codex-authored change without risking the Lovable branch, work in a separate feature branch and merge it manually once you have reviewed the diff.

Expected result: No overwritten commits, no orphaned Lovable regenerations, and a commit history on GitHub that clearly shows which agent made which change.

Complete code example

AGENTS.md
1# AGENTS.md Lovable + Codex/Claude Code Hybrid Workflow
2
3## Division of Labor
4- Lovable: UI scaffolding, page routing, Supabase/Cloud wiring, Visual Edits polish
5- Claude Code / Codex: business logic, validation rules, complex refactors, algorithmic code
6
7## Sync Rules
8- One active synced branch only (check Lovable's GitHub settings before starting work)
9- Pull the latest commit before starting any Codex or Claude Code session
10- Never rename or move the connected repository to a different organization
11- Let in-progress Lovable generations finish before pushing external commits
12
13## Protected Files (do not regenerate from Lovable prompts)
14- src/lib/billing.ts logic implemented and owned by Claude Code
15- src/lib/pricing-engine.ts algorithmic code owned by Codex
16- supabase/migrations/ do not modify existing migration files from either agent
17
18## Conventions
19- Named exports only, @/ import alias
20- Document any new protected file here before starting the next session

Best practices to prevent this

  • Use the Lovable MCP server for Claude Code, Cursor, or VS Code today — it is the officially supported path with OAuth
  • Treat GitHub two-way sync as the dependable Codex integration until Codex's own OAuth flow to the Lovable MCP server ships
  • Document the division of labor in AGENTS.md so every agent, including Lovable's own builder, respects the same architecture rules
  • Never rename or relocate the connected GitHub repository — GitLab syncs break on rename entirely
  • Pull before every external-agent session and let Lovable finish generating before pushing new commits
  • Keep one active synced branch — Lovable does not support syncing multiple branches at once
  • Reserve Codex and Claude Code for logic-heavy work and let Lovable handle UI iteration, where it is fastest
  • Re-check external service connections, like Supabase and custom domains, after any workspace or repository move

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

I'm setting up a hybrid workflow between Lovable.dev and Codex (or Claude Code). Here's my project: [describe the app]. Help me: 1) Draft an AGENTS.md dividing work between Lovable's builder and the coding agent 2) List the GitHub sync checks I should run before every external-agent session 3) Flag any part of my app that's risky to hand to an AI agent without human review first.

Lovable Prompt

Create an AGENTS.md file in this project documenting a hybrid workflow with an external coding agent. List which files and features belong to Lovable's builder (UI, routing, Cloud wiring) versus the external agent (business logic, refactors, algorithmic code). Include a sync-rules section warning not to regenerate the files the external agent owns.

Frequently asked questions

How do I add Lovable to Codex?

There is no dedicated 'add' button yet. Lovable's MCP server is listed in OpenAI's Codex plugin ecosystem as of a July 2026 changelog update, but Codex's own OAuth flow to complete that connection is not fully documented. The reliable path today is connecting your Lovable project to GitHub with two-way sync and giving Codex access to that same repository.

What is the Lovable MCP server?

It is Lovable acting as an MCP server (at mcp.lovable.dev) so an external agent can create projects, send prompts to the builder, inspect file diffs and edit history, run SQL against Lovable Cloud, and publish apps — all without opening the Lovable editor. It launched as a research preview in 2026 and is available on every plan, including Free.

Can Claude Code control a Lovable project directly?

Yes. Claude Code is one of the officially supported OAuth clients for the Lovable MCP server, alongside Claude Desktop, claude.ai, Cursor, and VS Code. Once connected, it can create, prompt, inspect, and publish Lovable projects from its own chat interface.

Does using Codex or Claude Code with Lovable cost extra credits?

Actions performed through the MCP server, like prompting the builder or publishing, consume your normal Lovable workspace credits, the same as using the editor directly. The GitHub sync hybrid workflow itself does not cost credits — only the prompts you send to Lovable through it do.

What should Lovable build versus what should Codex or Claude Code build?

Let Lovable handle UI scaffolding, page structure, Cloud and Supabase wiring, and fast visual iteration. Hand complex business logic, large refactors, and algorithm-heavy code to Codex or Claude Code, since they can reason across the full codebase more reliably than a chat-to-app builder.

Will renaming my GitHub repository break the hybrid workflow?

GitHub renames auto-follow the sync, so that specific case is safe. Moving the repository to a different organization, deleting it, or renaming a GitLab repo will break the connection, and you would need to reconnect from Lovable, which creates a fresh repository.

What if I can't get the hybrid workflow running reliably?

Coordinating multiple AI agents on one codebase without conflicts takes discipline, and logic can fall through the gap between tools if the split isn't documented. RapidDev's engineers set up and maintain hybrid Lovable plus coding-agent workflows for teams that need both build speed and complex logic handled correctly.

RapidDev

Talk to an Expert

Our team has built 1,000+ apps. Get personalized help with your issue.

Book a free consultation
Matt Graham

Written by

Matt Graham · CEO & Founder, RapidDev

1,000+ client projects delivered. Columbia University & Harvard Business School alumnus, U.S. Navy veteran. About the author →

Stuck on this for days?

Paste-and-pray debugging burns credits and weekends. Get a free 30-minute project audit — a senior engineer looks at your actual your platform project and tells you what's wrong, no strings attached.

Get a free project audit

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.