# Figma 126 broke the transport figma-use depends on, and two releases are about that break

> dannote/figma-use drives Figma from the terminal over a remote debugging port, or from JSX. The first line of its README is a warning that current Figma versions block that port, with a pipe mode and a different editor offered instead.

**dannote/figma-use** — Control Figma from the command line. Full read/write access for AI agents — create shapes, text, components, set styles, export images. 100+ commands.

- Repository: https://github.com/dannote/figma-use
- Website: https://www.npmjs.com/package/figma-use
- Stars: 607 · Forks: 44
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/dannote-figma-use

## The transport broke, and the newest releases are the repair log

The first thing the README says is that Figma 126 and newer block remote debugging, that figma-use still works through `figma-use daemon start --pipe`, and that you can skip Figma entirely with an open-source design editor that reads and writes the file format. That warning governs everything after it, including the installation section further down, which still tells you to relaunch Figma with a debugging port:
```bash
open -a Figma --args --remote-debugging-port=9222
```
The release history reads as a repair log for exactly that. v0.13.5, published 2026-07-03, adds custom CDP port support. v0.13.4, one day earlier, is titled Figma 126.6+ rspack support. v0.13.3, back in April, is a Figma 126 bootstrap fix. Three of the last three releases are about coping with a host application that changed underneath the tool, and the port-based path below the warning is the one being replaced rather than the one you should count on.

## The stdin renderer takes pure JSX, and a different file type takes the rest

The declarative mode has two tiers, and the boundary is a filename. Piping JSX on standard input accepts pure JSX only, with no variables and no logic. Components, variants and conditions require a file with a different extension, one written for the project. The elements available are Frame, Rectangle, Ellipse, Text, Line, Star, Polygon, Vector, Group, Icon and Image, and the style objects borrow CSS vocabulary, with grid layout supporting fixed, fractional and automatic sizing and separate column and row gaps. What that means for an agent is concrete: the compact form that fits in a shell pipeline cannot express a conditional, and the form that can is a file you have to write out first. The variants example, which builds a real component set from two variant axes and four combinations, is cut off partway through its own JSX in the documentation.

## Two of the three export paths hand out TypeScript source

The published package maps three entry points, and only one of them points at build output. The bare package resolves to a bundled file under dist, while the render and components subpaths resolve to TypeScript and TSX files inside the source tree. The file list confirms the intent: alongside the bundle, the manifest ships a plugin source directory, one source file for colour handling, and the render source directory. The bundle itself is produced by Bun, minified for a node target, with several packages marked external so they are resolved at run time instead of being inlined. A consumer who imports the render subpath therefore receives raw TypeScript from inside the tarball, and their own toolchain has to cope with that, which is a deliberate trade for letting the render layer be edited without a build step.

## The build marks three packages external, and one of them has install instructions

The build command lists its externals by name: a bundler, the TypeScript compiler, the model context protocol SDK, a formatter, and three others that are harder to place. One of those three is whaticon, and the documentation tells you to install it yourself when you want icon matching:
```bash
npm install whaticon
```
The other two are a PNG library and an image comparison library. Nothing in the documentation asks you to install either of them, and neither appears in the visible dependency list of the manifest, yet both are excluded from the bundle and so have to be present at run time for whatever feature uses them. It is the kind of gap that shows up as a missing module error rather than as a sentence in a guide. Icon matching itself is an export-time option, and the example pairs it with a preference for one icon family, so the optional dependency is scoped to one flag rather than to the tool as a whole.

## A colour takes two prefixes for the same variable reference

Binding colours to Figma variables works by naming the variable and supplying a hex value as the fallback, so a missing binding degrades to a literal colour rather than to nothing. On the command line the same binding is referenced in any colour option with one of two prefixes, either a spelled-out form or a dollar sign. Two prefixes for one concept is a small thing with a real edge: a dollar prefix will collide with any literal value that happens to start the same way, and nothing in the documentation says which form wins if both appear in the same option. The export path is the reverse of the import path, which is the more interesting asymmetry here. A node can be turned back into JSX, optionally prettified, and two nodes can be compared as a JSX diff, so the loop from model output to file and back to text is closed.

## Icons claim no downloading, and images are pulled from a URL

Icon insertion is presented as the cheapest win in the tool: give a name from a public icon set and the shape appears, with no downloading, no importing and no cleanup from the user's side, and the catalogue to browse holds over 150,000 icons. The same document shows images handled the opposite way, from an element whose source is an arbitrary URL with a width and a height, which means a remote asset has to be fetched to end up in the document. So the two asset types have different shapes of cost. Icons are addressed by name and resolved by the tool; images are addressed by location and resolved over the network, and the documentation gives no timeout, no size limit and no statement about what happens when the URL fails.

## Storybook export is marked experimental, and the diff sample stops mid-line

The storybook exporter is labelled experimental in its own heading, takes an output directory, and accepts the same icon-matching flags as the JSX exporter. What it produces is a stories file with typed props derived from the component's properties, which is a translation step rather than a copy, and that is where the risk sits if the property types are anything other than plain values. The diff example is the one that ends badly: the documented patch output shows the two node paths and their identifiers, a hunk header, and then a single type line before the document stops. Nothing tells you what the remaining lines look like, or what a diff between two nodes of different types is supposed to produce. The repository itself is organized around the agent surface, with a reference document, an MCP document, a skill file and a single example file, and the package version matches the newest tag.

## Conclusion

Treat it as a tool whose transport is hostage to the Figma version, not as a stable interface, because the two newest releases exist to cope with a change that disabled remote debugging. Before you plan an agent workflow on it, confirm your Figma build still accepts a debugging port or that the daemon pipe mode covers you. If you only need to generate design files rather than drive a running editor, the open-source editor the warning points at reads and writes the file format directly and does not depend on that port at all.

## FAQ

### how to use figma use

Install it with npm or run it through npx, start Figma with a remote debugging port, then check the connection with `figma-use status`. Because Figma 126 and newer block remote debugging, the README points at `figma-use daemon start --pipe` instead, or at an open-source editor that reads and writes the file format directly.

### figma use alternate zoom handling

None of the documented commands or flags covers zoom. The command surface shown covers creating nodes, setting layout, inserting icons and images, exporting to JSX or Storybook, and diffing, while the only viewport-adjacent setting in the documentation is the remote debugging port used to reach Figma itself.

### Does figma-use require a Figma plugin to be installed?

No. The installation section states that no plugins are needed, because the tool drives Figma through the application's remote debugging port. The README notes that Figma 126 and newer block that route, which is why a daemon pipe mode is offered as the way around it.

### What can figma-use render from JSX, and what does it refuse?

Piping JSX on standard input accepts pure JSX only, with no variables and no logic. Components, variants and conditions need a .figma.tsx file instead. The available elements are Frame, Rectangle, Ellipse, Text, Line, Star, Polygon, Vector, Group, Icon and Image.

### What does the figma-use npm package expose as its entry points?

Three: the bare package resolves to bundled output under dist, while the render and components subpaths resolve to TypeScript and TSX files inside the source tree. Consumers of those two subpaths receive raw source from the tarball rather than compiled files.

## Sources

- [dannote/figma-use on GitHub](https://github.com/dannote/figma-use)
- [License: MIT](https://github.com/dannote/figma-use/blob/master/LICENSE)
- [Project website](https://www.npmjs.com/package/figma-use)
- [README](https://github.com/dannote/figma-use/blob/master/README.md)
- [Releases](https://github.com/dannote/figma-use/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dannote-figma-use