Introduction
Claude Code can edit a Framer project directly, without anyone opening the editor. It connects through Framer’s External Agent CLI, not through MCP, and it can reach pages, CMS collections, styles and code files across the whole project rather than one selected layer.
We run this site that way. Below is the setup we actually use, what it handles well, and the places where it still needs a human in the editor. If you want the wider picture of how this differs from the in-editor Agent, we covered that in Framer Agents Explained.
What You Need First
The setup is short, but it fails in confusing ways if one of these is missing.
Node installed and on your PATH; the CLI is run through npx
A Framer project you have edit rights on
Either a browser you can authorize in, or a per-project API key for headless runs
Claude Code, or another agent that can run shell commands
Connecting to a Project
Run the setup command once, then create a session against the project. The session ID it returns is the thing you reuse; every later command takes it, and that is what keeps state between calls.
Authorization has two paths. The browser prompt is fine when you are sitting there. For anything unattended, a per-project API key authorizes without opening anything, which is the only way a scheduled run completes. Keep the key out of the repo.
One session per conversation is the rule we follow. Creating a separate session halfway through can spawn a stray branch on projects where branching is enabled, and then you are reconciling two versions of the same edit.
What It Can Change and What It Cannot
The honest boundary matters more than the feature list, because the failures are quiet ones.
Handles well | Still needs the editor |
|---|---|
Bulk CMS edits across every item in a collection | Judging whether a layout actually looks right |
Adding fields and filtering collection lists | Anything depending on a plan feature you do not have |
Reading the real structure of a page before changing it | Fine visual spacing and optical alignment |
Repetitive work across breakpoints | Deciding what should ship |
Editing CMS items, fields and collection filters | Assigning overrides to nodes, reading analytics, changing project names or domains |
Where We Actually Use It
The wins are boring, which is the point; these are the jobs nobody wants to do by hand.
Adding a field to a collection and backfilling every existing item
Auditing what a page really contains, rather than what we remember building
Changing a value that appears in dozens of places at once
Reading CMS state without clicking through the editor
Where It Falls Short
Breakpoints are the big one. Setting a value on the primary node occassionally leaves the replicas untouched, so a change looks correct on desktop and silently is not applied on the others. Read all of them back after writing.
Plan limits are the other, and branching is the one that bites. Without it every edit lands on the live project, so drafts become the only isolation you actually have.
Before You Publish
Read the change back before trusting it. The CLI reports a clean apply for commands that parsed correctly, which is not the same as the result being what you meant. We verify by re-reading the node, not by reading the success message.
Then publish deliberately. Treat every agent edit as live on next publish, and keep new work drafted until someone has actually looked at it.
Agents are good at this kind of structural work and poor at judging a layout, which is the same split we cover in Where Vibecoded Sites Break.
