How to Connect Claude Code to Figma

Claude Code can build UI fast. It cannot see your Figma file. Without access to the actual design — its structure, spacing, and token bindings — Claude writes plausible CSS that drifts from the source of truth on every property.

AI Bridge connects Claude Code to Figma through a local HTTP API. Claude reads component structure, extracts design token bindings, and writes CSS with var() references instead of magic numbers.

What you need

• A Figma file with design variables (tokens) bound to components.
• AI Bridge plugin.
• Claude Code (or any model that can make HTTP requests).

If your Figma file uses raw fills and hardcoded spacing instead of variables, the plugin still works — you just get raw values back. Variables are what make the output production-grade.

Setup

Two minutes, no config files.

1. Install the plugin in Figma. Plugins → Development → Import plugin from manifest. Point it at the manifest.json from the Bridge download.

2. Start the bridge server. Double-click start-bridge.command on macOS or start-bridge.bat on Windows. This starts a local server that relays commands between Claude and the Figma plugin.

3. Verify the connection.

curl http://localhost:8867/status

You should get {"connected": true}. If not, make sure the plugin is running inside Figma (not just installed).

4. Give Claude this context.

Paste this into your Claude Code session or project instructions:

Figma AI Bridge API: http://localhost:8867
1) GET /status — check connection
2) POST /command with {"command":"...","params":{...}}
3) Always use "params", not "args"

Claude now has a working channel to your Figma document.

Reading designs

The most common workflow: Claude reads a Figma component and generates matching React code.

Start by giving Claude a node ID (copy it from Figma's "Copy link" or the dev panel). Claude calls two commands:

{"command": "get-node-props", "params": {"nodeId": "1234:5678"}}

This returns the node's type, dimensions, layout mode, children, and component properties. Then:

{"command": "get-bound-variables", "params": {"nodeId": "1234:5678"}}

This is the part that matters. Instead of raw padding: 12px, Claude gets:

{
  "paddingLeft": "spacing/lg",
  "paddingRight": "spacing/lg",
  "paddingTop": "spacing/md",
  "paddingBottom": "spacing/md",
  "itemSpacing": "control/gutter/sm",
  "fills": "surface/secondary"
}

Claude maps these to your CSS custom properties and writes var(--spacing-lg) instead of 12px. The generated code respects your token system from the first draft.

Creating in Figma

The connection works both ways. Claude can create and modify nodes inside Figma:

{"command": "create-frame", "params": {
  "name": "card",
  "parentId": "1234:5678",
  "width": 320,
  "height": 200,
  "layoutMode": "VERTICAL",
  "paddingTop": 16,
  "paddingBottom": 16,
  "paddingLeft": 16,
  "paddingRight": 16,
  "itemSpacing": 12
}}

After creating a node, Claude binds it to design tokens:

{"command": "bind-variable", "params": {
  "nodeId": "5678:9012",
  "field": "paddingLeft",
  "variableId": "VariableID:6037:229949"
}}

This means Claude can prototype a component in Figma, bind every property to tokens, and then read those same bindings back to generate the React implementation. Design and code stay in sync because they reference the same token layer.

Why design tokens matter here

Without token access, Claude reads your Figma button and writes:

.button {
  background: #181818;
  padding: 0 16px;
  border-radius: 9999px;
  height: 32px;
}

This looks correct until someone switches to dark mode. Or changes the density scale. Or applies a different theme. Every value is a snapshot, not a reference.

With Bridge returning token bindings, the same button becomes:

.button {
  background: var(--color-background-primary-solid);
  padding: 0 var(--button-pill-gutter-md);
  border-radius: var(--radius-full);
  height: var(--control-size-md);
}

Dark mode, themes, density — all handled by the token layer. Claude writes CSS that adapts because it references intent, not pixels. This is the core argument from Design Tokens, Not Just Pixels applied to a concrete Claude Code workflow.

Real example

You ask Claude: "Build a notification card matching the Figma design at node 6430:12345."

Claude runs get-node-props to understand the structure — a vertical frame with an icon, title, description, and action button. Then get-bound-variables on each child to collect token bindings. Then find-children to walk nested instances.

The output:

.notificationCard {
  display: flex;
  flex-direction: column;
  gap: var(--spacing-md);
  padding: var(--spacing-lg) var(--spacing-xl);
  background: var(--color-surface-secondary);
  border-radius: var(--radius-lg);
}

.notificationCard__title {
  font-size: var(--text-sm);
  font-weight: var(--font-weight-medium);
  line-height: var(--line-text-sm);
  color: var(--color-text-primary);
}

.notificationCard__description {
  font-size: var(--text-sm);
  line-height: var(--line-text-sm);
  color: var(--color-text-secondary);
}

No hardcoded values. Every property traces back to a Figma variable. If the design team adjusts spacing/lg from 12px to 14px, both Figma and code update through the same token.

This is the workflow that keeps Claude Code output aligned with design intent — not through prompt engineering or manual review, but through shared infrastructure. The same approach works whether you are using Claude, Cursor, or Codex. The constraint is the token system, not the model.

For teams already using a design system with proper token architecture, Bridge is the missing connection layer. For those starting fresh, it is a reason to structure your Figma file with variables from day one.

Setup takes two minutes. The payoff compounds on every component Claude builds after that.

Get AI Bridge →