2026-06-18

Automate Figma with OpenClaw: Review the Diff Before It Writes

A safe Figma automation binds one file, node set, before-version, operation list, approval digest, and post-write check instead of trusting a broad prompt.

Figma can now expose design context to an agent and, in supported setups, let that agent write back to the canvas. That is a real capability. It is also where the comfortable phrase “automate Figma” stops being precise enough for production.

The safe version is narrower: let OpenClaw coordinate an exact design change, but make the Figma adapter prove what it will touch before any write occurs. A token-sync job, component cleanup, comment triage, and handoff export do not share one authority model. They use different Figma surfaces, different permissions, and different failure semantics. Treating them as four prompts hides the part that matters.

The operating rule: no canvas mutation should inherit approval from a conversational request. Approval belongs to a sealed change packet: one file, a bounded node set, a before-version, an operation allowlist, and a digest of the proposed delta.

The dangerous object is the unreviewed delta

Figma's current remote MCP server can provide design context and native writes. Its general-purpose use_figma tool runs JavaScript against a Figma file through the Plugin API. The documented examples cover frames, components, variants, variables, and auto layout. This is substantially more capable than exporting a screenshot or reading a node tree.

The same documentation calls write-to-canvas beta, requires the remote MCP server, and tells clients to inspect first, work in small increments, and validate the result. A Full seat and edit access are required for writes. A Dev seat is read-only. The tool response is limited to 20 KiB, image assets and custom fonts are not supported, and components still need manual publication before Code Connect. Those are not minor footnotes; they define the review boundary.

There is another compatibility boundary. Figma says only clients in its MCP Catalog can connect to the server. Its current support table names several clients, including Codex, but does not establish that every generic MCP host is accepted. An OpenClaw workflow therefore needs an adapter whose compatibility is actually verified. Protocol similarity is not authorization.

Three Figma surfaces, three contracts

A useful automation begins by choosing the smallest surface that can do the job.

Surface	Good first use	Authority that must be explicit	Verification
REST API	File and node reads, rendered exports, comments, webhooks, variable batches	OAuth or token identity, scopes, resource plan, file key, endpoint rate budget	Re-read metadata or target objects; retain response and version identifiers
Remote MCP	Selection-aware context and staged canvas edits through a supported client	Catalog/client compatibility, seat, edit permission, selected file and node set, exact operations	Call metadata or screenshot tools after each small write; compare to the approved delta
Plugin API	In-file variable and node operations under an installed plugin or the MCP write tool	Plugin execution context, current document, supported fonts/assets, local versus remote variable ownership	Inspect resulting nodes, bindings, modes, and collection state in the same file

REST is not merely the old read-only option. Figma exposes bulk create, update, and delete operations for local variables and collections, subject to plan and membership constraints. That endpoint is atomic: if one requested change fails, none of the changes are persisted. It also refuses updates to remote variables and documents a shared-font case that returns a 400. Atomicity helps, but it does not tell an operator whether the proposed batch was correct.

Webhooks are triggers, not proof of immediate state. A FILE_UPDATE event may arrive only after a period of editing inactivity. A library publication can be split across several events. A named version event is stronger for a release workflow because it carries a version identifier, yet the automation should still fetch the exact resource it intends to process. The passcode returned with webhook events verifies a configured secret; it does not make the payload's business meaning trustworthy.

Make the change packet boring

Before OpenClaw asks any adapter to write, it should produce a compact packet that another engineer can review without reading the conversation that created it.

A minimally useful packet binds:

the Figma file key and the exact node or variable identifiers;
the observed file version, named version, or other defensible before-state;
an allowlist such as “set these values” or “create these frames,” not arbitrary JavaScript;
the old and proposed values, including modes and bindings where variables are involved;
the delegated user or plan token, required scopes, seat capability, and edit permission;
a stable digest, idempotency key, and expected receipt;
the post-write reads and screenshots that will decide success.

That packet deliberately separates the agent's analysis from the adapter's authority. The agent may discover a stale component and recommend a fix. It does not gain permission to normalize an entire library because the recommendation sounded reasonable. If a reviewer approves one node in one file at one observed version, a later node selection or updated file invalidates the packet.

A sealed crystal packet holds a small set of approved design parts while larger mechanical tools remain outside a narrow brass boundary — Approval should fit around the proposed delta. Anything outside that file, node set, version, and operation list remains blocked.

The gate that belongs between proposal and write

A deterministic local fixture was used to exercise this boundary before touching a real design file. It evaluated 80 change packets across five surfaces: REST read audits, comment drafts, scratch-canvas writes, variable batches, and webhook-triggered work. The fixture included nine hard blockers and four hold conditions.

All 80 expected outcomes matched. Fifteen baseline packets were ready. Forty-five were blocked because the file, nodes, before-version, operation set, approval digest, identity, scopes, edit permission, or idempotency receipt was missing. Twenty were held for rate budget, unsupported assets, unverified client compatibility, or a stale selection. The fixture ran on Node.js v22.23.1. An OpenClaw CLI was present; a Figma CLI was not. No Figma account, file, credential, REST request, MCP call, plugin call, package installation, customer record, or external mutation was used.

This test does not prove that a Figma write will succeed. It proves something more modest and reusable: the orchestration layer can refuse ambiguous authority before a vendor call exists. The fixture's SHA-256 is 0283a7529e4b669d713c032be1d814bcf52011d60ba58ff0a86a4fb94ab73932, so the evidence can be tied to the exact cases that produced the result.

What to automate first

Start with a read-only component audit

Read the exact file or requested nodes, record the returned version metadata, and produce a report of component usage or variable bindings. Render only the relevant node subset when visual evidence is needed. Figma's rendered-image URLs expire, so store the result as an audit artifact if it must survive review; do not treat a temporary URL as durable evidence.

This is the safest first production workflow because a false positive creates a bad recommendation, not a damaged library. It also reveals the practical rate budget. Current REST limits vary by endpoint tier, seat, resource plan, user, token, and app. Figma recommends batching and caching, and 429 responses carry Retry-After. A job that repeatedly walks an entire file without caching is not merely inefficient; it can starve other workflows sharing the same personal token budget.

Draft comments before posting them

Comment summaries are useful, but direct autonomous posting creates social side effects. Generate a draft that links the exact file and node, quotes the source comment identifiers, and names the intended recipient. Post only after a person accepts that packet. Remember that the REST API lets only the comment author delete their own comment. “We can clean it up later” is therefore a weak control.

Write into a scratch page before the library

For a canvas write, prefer a new scratch page or dedicated test file. Bind the packet to that destination and allow a narrow construction operation. Then inspect metadata and a screenshot after each increment. Promotion into a shared component library should be a separate approval. This matches Figma's own guidance to work in small steps and manually review beta output.

Treat variable sync as a migration

Variable changes look like configuration, but they can propagate across modes, aliases, text bindings, and published libraries. Capture the current collection, proposed batch, remote/local ownership, and all affected modes. Prefer the atomic REST batch when its plan constraints fit; otherwise use the Plugin API with the same sealed packet. Do not silently update a remote variable from a consuming file, because Figma forbids that operation and the ownership model is wrong.

Amber and cyan transparent design frames are measured side by side while an unexpected fragment is diverted into a quarantine tray — A successful tool response is not the finish line. Re-read the file, compare the approved delta, and quarantine any extra change.

Verification is a second read, not a success message

After a mutation, fetch the same file or nodes again. Compare the resulting values, child structure, bindings, and version to the approved after-state. For canvas work, add a screenshot comparison because a structurally valid node tree can still be visually wrong. For variables, compare every requested mode and binding. For comments, retain the returned comment identifier. For webhooks, store the webhook identifier and request log rather than inferring delivery from creation alone.

The receipt must be exact enough to make retries safe. If the adapter timed out after Figma accepted a write, OpenClaw should reconcile the remote state before trying again. A fresh conversational turn with the same prose is not an idempotency key. The packet digest plus the observed before-state and returned identifiers form a much stronger retry contract.

Where automation should stop

Hold the packet when the selected nodes changed after review, the file version moved, client compatibility is unverified, the rate budget is unknown, or the operation requires unsupported assets or fonts. Block it when identity, scope, seat, edit permission, file key, node set, operation list, or approval digest is missing. Escalate publication of shared components and any change that widens from a scratch surface into a library.

This makes Figma automation less theatrical. It also makes it recoverable. OpenClaw can still collect triggers, compare source material, prepare the packet, route review, call the chosen adapter, and archive the receipt. The decisive improvement is that the automation can explain exactly what it was allowed to change—and prove that it changed only that.