Skip to main content
Question

Figma Connector with Claude.ai and Slots Feature

  • April 11, 2026
  • 2 replies
  • 110 views

Nathan2

While using Claude.ai with the Figma connector Claude told me it wasn't able to programmatically insert the contents into the slot inside a component “because Figma protects slot nodes from plugin writes”. If this limitation is intentional, why? It serious limits the usefulness of the connector. Please allow the connector to write to slot nodes.

2 replies

Vinuti
  • New Member
  • June 21, 2026

There is an important distinction here that may help narrow the issue.

The Plugin API can now create and configure slots on the master component. Figma’s current API includes componentNode.createSlot(), SlotNode, and slot configuration through component properties.

The limitation is specifically about filling a slot inside an individual instance through code. Trying to append or move content into an instance-owned slot is blocked because Figma protects the structure of instances.

So the supported model is:

  • Create and configure the slot on the master component through the API.
  • Let that slot propagate to instances.
  • Fill a specific instance’s slot manually in the Figma editor.

I agree that programmatic instance-level slot filling would make connectors much more useful. But the current limitation is not that slots cannot be created or edited at all — it is that instance slots cannot be populated by script.


Nathan2
  • Author
  • New Participant
  • July 6, 2026

I was able to get it to work with Claude’s help. The actual constraint is different from what was described above.

Slot population on live instances does work via the Plugin API — you don't need to touch the master component or manually fill anything in the editor. The pattern is:

javascript

// Find the slot by type + parent name (not type alone — that grabs the wrong slot
// when a component has multiple slots)
const bodySlot = inst.findOne(n => n.type === "SLOT" && n.parent && n.parent.name === ".body");

// Build your content, set all text/properties on it first...
bodySlot.appendChild(formFrame); // then append

No detachInstance() required or recommended — in fact, detaching is actively harmful here: it converts the SLOT node into a plain FRAME, which breaks any future type === "SLOT" query and can corrupt node IDs. If you're reaching for detach to "get at" a slot, that's usually the sign something upstream is wrong, not a required step.

That said, there are real sharp edges that could easily produce an error that reads like "Figma protects slot nodes from writes":

  • All child instances need their properties/text set before they're appended into the slot — once appended, the instance becomes inaccessible for further mutation.
  • Only one text mutation is safe per slot subtree per script — the first characters write causes the slot to re-render with new node IDs, invalidating any other node references you grabbed earlier (including ones you haven't touched yet).
  • If you're building a complex tree, stage it at the page root first, then move the whole container into the slot in one appendChild — trying to build directly inside a slot (insertChild, etc.) throws "Parent not found."
  • Existing slot children can't be hidden (visible = false) or removed (.remove()) on a live instance — if the pre-built content doesn't match what you need, pick the variant/Type whose defaults are closest rather than trying to clear it.