What Changed, and Why It Matters for Agents
The canvas is becoming a repository client, not just a drawing surface: an agent can work with cloned code, branches, and pull requests while using connections between prototype frames as generation context. That changes what it can perceive and what a team can review. It also raises a governance question: who can see code once it is inside a design file?
- Nov 3: Figma announced that the agent reads prototype connections and interactions when it creates a code layer, and that repository cloning would be enabled by default for new GitHub connections, with an admin opt-out. Style Dictionary v5.8.0 shipped at 21:10, commit
795233d. - Nov 4: Figma published a code-layer workflow and a description of Nimbus, its sandbox infrastructure.
- Cutover dated November 2026: zeroheight’s guidance ends support for previous token export formats “at the beginning of November 2026”, in favor of DTCG 2025.10 and Style Dictionary v5.
- Observed Nov 5: Penpot’s hosted release notes and public GitHub tags do not agree on the latest release description.
These changes bear on what agents can perceive, validate, and hand off. Figma’s shader export, Weave tools, and Google’s A2UI were covered in the November 2 digest and are outside this one.
The Canvas Reads Your Flow: Code Layers Hit 100% Open Beta
The agent can now use the links between frames as context: the flow topology, including interactions, is part of what it reads. Figma’s release note says, “When you create a code layer from design frames, the agent now reads the prototype connections and interactions between them. That way, you spend less time prompting the complex parts of your flow and more time refining your prototype and finding edge cases.” (Figma release notes)
The availability statement is explicit: “Code layers is now in open beta for 100% of users.” (Workflow Lab) The help documentation defines the object this way: “A code layer is an interactive prototype backed by running code that sits directly on the canvas.” (Figma Help: Code layers)
Our reading: for an agent, the shift is from isolated frames to an interaction graph—flow behavior becomes generation context instead of something a person must dictate. It does not establish that the agent infers every requirement correctly; the capability described is access to connections and interactions.
Nov 5: Vector Hygiene as Agent Context
A Nov 5 vector update covers style references and layer grouping — on this blog’s reading, that is editable layer structure an agent can iterate on without redrawing. The release notes do not establish that this update touches version-control surfaces. (Figma release notes)
A Repository Client Inside the Design Tool
The Git help documentation describes a repository workflow in one sentence: “After connecting Figma to one or more GitHub organizations or accounts, you can select a repository to clone for your code layer or Make. Figma stores the clone of your repository so you can make changes, utilize multiple branches so you can experiment, and then create pull requests to merge your improvements back into the original repository.” (Figma Help: Git with Figma Make and code layers)
A Nov 3 release note says: “Cloning will be enabled by default for new GitHub repository connections, so teams can import code into Figma without an additional admin approval step. Admins can disable cloning for individual repositories at any time and settings for existing repository connections will stay the same.” The rollout note is “Rolling out to all plans.” The note gives no completion date. (Figma release notes)
What a Repository Must Look Like
The supported project has to meet five requirements: it must be a web app (any web framework); it must be installable and runnable; it must have an entry point, such as a start script or index.html; it must have a build script, usually build in package.json; and it must be under 3GB. (Figma Help: Git requirements)
Three kinds of projects are not supported: repositories requiring private network access through a VPN, firewall, or IP allowlist; private npm packages; and native mobile or desktop apps. A local folder upload is limited to 1 GB and has no live GitHub connection, so it cannot push, pull, or create PRs. Cloning a public repository by URL also does not support pushing changes or creating PRs. (Figma Help: Git with Figma Make and code layers)
Branches, Pull Requests, and the Edges
The help doc gives three example prompts: “Create a branch called login-flow/new-sign-up-modal”; “Push my changes to login-flow/new-sign-up-modal”; and “Create a pull request for my changes”. A push can fail if you lack permission, or if “the code in the corresponding branch of the original repository has changed since you cloned it”; in that case the agent can pull those changes and resolve conflicts. The Create PR button appears only when working in a branch different from the cloned one. (Figma Help: Git with Figma Make and code layers)
The Visibility Rule
The same documentation sets out the access boundary: “When you clone a repository for a code layer or Make file, the source code you clone becomes visible to other users of the file. Anyone with permission to view a Figma Design file that contains a code layer can see the preview of that code layer and the preview’s source code. Anyone with permissions to edit the Figma Design file that contains a code layer or a Make file can see the underlying git-level source code, even if they don’t have permissions in GitHub to do so.” (Figma Help: Git with Figma Make and code layers)
That makes the clone a file-scoped disclosure, not merely a repository-scoped one: canvas permissions can expose source beyond the permissions assigned in GitHub. Teams should account for the design file’s audience when deciding what to clone.
The .figma/make Contract and the Web-App Ceiling
On first clone, .figma/make can include eight configuration items: setup installs optional system dependencies; install installs project dependencies; dev starts the live-preview server and must listen on $PORT; deploy builds and publishes to a Figma-hosted URL; deploy-preview builds a cached preview; dev.json configures the dev server, including the port and which file changes trigger install or restart; site.json holds title, description, favicon, social image, and analytics; and root-level .mise.toml can specify runtime versions such as Node.js and pnpm. (Figma Help: Git with Figma Make and code layers)
These files, in the help doc’s words, “aren’t automatically pushed back to the original repository.” Whether they are git-versioned or diffed in PRs is not established. The design target is therefore a web app with a dev server, a publish target on a Figma-hosted URL, and a cached preview build—not a static frame.
Seven Doors In, Five in the Manual
The Workflow Lab describes seven ways to create or bring code to the canvas: capture webpage code with the Figma Chrome extension; turn an existing design frame into a code layer; create an empty code layer and prompt from scratch; clone a connected GitHub repository; upload a local folder; ask an external coding agent to import a project through MCP; or create an empty code layer from a description or PRD. For the PRD route, the post says: “If your PRD lives in Notion, use the Notion connector to share it with the Figma agent”. (Workflow Lab)
The help doc lists five routes: start from scratch; start with designs by selecting a frame and choosing Code → Build selection; capture code with the Chrome extension; connect a GitHub repository; or upload a local folder. It also names the benefit “Start from your team’s codebase instead of a blank prompt.” (Figma Help: Code layers) Seven in the blog and five in the manual is documentation drift, not evidence that one list supersedes the other.
The Pickup Walkthrough: A Reviewable Agent Loop
In Figma’s Pickup example, a designer clones a repository and asks: “Make three variations of this and add a new delivery button to the map page… The first one should be an omnisearch address field, but surprise me with the other two.” The agent produces three code layers: address search, map-based selection, and address shortcuts. Option-drag duplicates a layer; the editor shows agent chat, a live preview, and “Files” for the underlying code. (Workflow Lab)
“Extract designs” turns a screen, element, or recorded flow into editable design layers; “Record flow” captures screens as editable frames; “Update code layer” sends edits back. For combining ideas, the example prompt is: “Create a new code layer combining the grid clustering from the grid layer and the delivery feature from the delivery code layer”.
Before pushing, the designer asks the agent to compare the result with the original and document changes in a Figma Spec. The prompt says: “Describe the changes in the combined code layer and how they differ from the original code layer. Flag upfront any changes that have technical implementation implications that should be reviewed with a developer, such as backend work or API calls.” That makes the loop compare, document, then hand a branch or PR for review—not treat generated code as self-reviewing. The post closes: “The updated code can then go back to the team’s branch or into a pull request for review and testing before release. The explorations, comments, and spec remain together on the canvas, giving reviewers a place to revisit the options and understand how the team arrived at this direction.” (Workflow Lab)
Nimbus: Provenance and Feedback Under the Canvas
Nimbus describes the infrastructure behind Figma’s sandboxes: “Figma’s AI products require tens of thousands of sandboxes to run untrusted code safely. That’s why we built Nimbus”. A namespace is a config file a product provides; the control plane picks a provider, allocates resources, applies policies, and manages lifecycle. The sandboxd daemon inside each sandbox supervises workload processes, network listeners, authentication, health checks, metrics, and shutdown, and owns the process tree. (How Figma manages sandboxes at scale)
The three APIs are GetOrCreate, Get, and Delete. GetOrCreate takes a namespace and custom key and “returns the same sandbox for repeated requests with that key”. The documented namespace keys include name, imageRepository, services{ninja{command,port}}, healthCheck{http{portName,path:"/healthz"}}, resources{cpu:"2",memory:"1Gi"}, warmPool{minSize:10,maxSize:100}, envVars{logLevel}, and allowedHosts["*.figma.com"]. (How Figma manages sandboxes at scale)
The egress rule distinguishes allowlisted hosts, which are fully trusted, from other destinations: Nimbus permits “only read requests—GET, HEAD, or OPTIONS—with no request body”; POST, PUT, and requests with a body to arbitrary endpoints remain blocked. Credentials follow a separate safeguard: “Nimbus encrypts credentials before they enter the sandbox, and swaps the encrypted value for the real credential immediately before the request leaves the sandbox—and only when it’s being sent to its intended destination.” (How Figma manages sandboxes at scale)
Feedback is an operational signal too: “Slow provisioning requests now reduce a provider’s effective weight even when they eventually succeed”. Warm pools cut provisioning latency by 90%, and warm pools plus automated provider selection raised provisioning availability from 99% to 99.95%; the stated goal is a provisioned sandbox in under one second. Claim handling is transactional: “Each claim is a single transaction: Select the oldest matching sandbox, skip any row another request is already claiming, remove the chosen row from the pool, and return its connection details.” Nimbus has been internal since November 2025; whether namespaces are user-configurable or exposed externally is not established. (How Figma manages sandboxes at scale)
The Token Contract Hardens
Tokens become something an agent or pipeline can diff, validate and lint, not just read as strings. The shift is a structured, machine-readable contract—but migrations can change how overrides and aliases resolve.
Style Dictionary v5.8.0: Small Version, Sharp Edges
Style Dictionary v5.8.0 was released Nov 3 at 21:10, commit 795233d. The release exposes utilities: “Expose stripMetaProps, formatJS and isColor utilities through the style-dictionary/utils entrypoint, so that custom formats and transforms can reuse the same helpers as the built-in ones.” It also adds: “Add StopTransformError to style-dictionary/utils. A transform can throw it to skip the remaining transforms for that token, which keeps the changes made by the transforms that ran before. It is still reported as a transform error.” (Style Dictionary releases)
The release fixes copy_assets cleaning on Node.js 25 and later: the method removed the assets directory with fs.rmdir() and its recursive option, which Node.js 25 removed, so cleaning now uses fs.rm. Its override behavior changes from merging to replacement: “When a token in source overrides a token from include (or from the inline tokens option), it now replaces that token instead of being merged into it… Properties that only the overridden token had, such as $extensions or comment, are no longer carried over.” Alpha rounding is corrected so #00000014 becomes rgba(0, 0, 0, 0.08) again instead of rgba(0, 0, 0, 0.0784313725490196). (Style Dictionary releases)
There is also a breaking name change: sketch/palette is restored under its documented name; the accidental sketchPalette name had been used since v4.3.0 and is no longer accepted. The release improves the “Token name must be a string” error with token path and filePath. The prior v5.7.1 release, dated Oct 24, summarized a fix as “Protect convertTokenData to output ‘object’ from another prototype pollution vulnerability (GHSA-m4pr-rgwp)” — the advisory is GHSA-m4pr-rgwp-x36r, and its contents beyond that summary are not established. (Style Dictionary releases)
zeroheight’s One-Way Door to DTCG 2025.10
zeroheight says, “Support for the previous export formats will end at the beginning of November 2026.” Its token manager now uses Style Dictionary v5 and DTCG 2025.10. DTCG JSON becomes the default; CSS, SCSS, iOS, iOS Swift, Android, Compose, Flutter, LESS, JS, and Web exports are generated through Style Dictionary v5. New token-set outputs and URL exports no longer offer legacy formats, though existing outputs keep working. Files change from .json to .tokens.json. (zeroheight: Migrating to Style Dictionary v5)
The key changes are value → $value, type → $type, and description → $description. Dimension and duration values become structured objects such as { "value": 16, "unit": "px" }; colors carry colorSpace, a components array, alpha, and a hex fallback. Every token, group, and set includes $extensions under com.zeroheight. (zeroheight: Migrating to Style Dictionary v5)
The constraint is explicit: “Once you’ve switched a token set output to DTCG 2025.10, there’s no in-product way to move it back to the legacy DTCG JSON or Style Dictionary format.” There is also drift risk: “A small number of tokens that used mode inheritance or alias chains may resolve slightly differently under v5.” Make the documentation’s advice a checklist step: download the new export, diff it against the existing output, inspect affected aliases and modes, then decide whether to switch. The exact resolution differences are not established. (zeroheight: Migrating to Style Dictionary v5)
Penpot: When Release Notes and Tags Disagree
Penpot’s hosted page lists “2.19 - Is this it”, dated Oct 28—outside this digest window. Its public GitHub releases page instead lists 2.18.6 as the latest tag, “released this 04 Nov 17:11”, commit c7fee6a, fixing upload endpoints storing files outside the temp directory, issue #12771. The hosted page’s own changelog link points to CHANGES.md#2190-unreleased. This is a described-but-not-tagged discrepancy, observed and unresolved; it does not establish whether 2.19 is generally available or when a 2.19.0 tag will appear. (Penpot release notes; Penpot GitHub releases)
The hosted notes describe shared token libraries—one library file, with tokens synced to connected files on updates “just like components and colors”—plus per-side strokes that work with tokens, a revamped path editor, remappable keyboard shortcuts, and opt-in WebGL rendering. No machine-readable token format is named in these sources. For release integrity, “diff the release notes against the tags” is a concrete check, not a verdict on why the records differ. (Penpot release notes; Penpot GitHub releases)
Four Lineage Surfaces, Side by Side
| Surface | What lineage artifact exists | Who can inspect it | Machine-readable? |
|---|---|---|---|
| Figma code layers + Git | Stored repository clone, multiple branches, and pull requests back to the original repo; Figma Specs, explorations, and comments remain on canvas | File viewers see preview and preview source; editors can see underlying Git-level source even without GitHub permissions (Figma Help) | Yes: Git source, .figma/make files, and branch/PR semantics (Figma Help) |
| Penpot shared token library | One library file; tokens sync to connected files on library updates | Users of every file connected to the library (Penpot release notes) | Not established by these sources; no token file format is named (Penpot release notes) |
| Style Dictionary v5.8.0 + zeroheight DTCG 2025.10 | .tokens.json exports, $extensions under com.zeroheight, and replace-not-merge override semantics (zeroheight) |
Consumers of a token-set output or the Style Dictionary URL export — downstream pipelines (zeroheight) | Yes: DTCG 2025.10 JSON, $value/$type/$description, and structured dimension/duration values (zeroheight) |
| Figma generative-plugin version history (Oct 27, context) | A new version per edit and an agent-generated change log (Figma Help) | Creators can revisit and restore; consumers get only the latest version and cannot revert (Figma Help) | Partly: versions and generated descriptions exist; no file format or export is stated (Figma release notes) |
Machine-readability is arriving from three directions at once, with asymmetric human access.
FAQ
Do I still need admin approval to clone a GitHub repository into Figma?
Not for new repository connections when cloning is enabled by default; an admin can disable it for an individual repository. No rollout completion date is given. (Figma release notes)
Who can see my source code once it’s cloned into a file?
File viewers can see a code layer’s preview and preview source; editors can see underlying Git-level source, even without GitHub permissions. (Figma Help: Git with Figma Make and code layers)
What happens if our repository is 3GB or larger?
It does not meet the documented requirement, which is “under 3GB”. The help doc suggests trying a smaller repository containing only the components needed for prototyping. (Figma Help: Git with Figma Make and code layers)
Can the Figma agent push .figma/make files back to my repository?
They are not automatically pushed back to the original repository. The doc does not say whether they are git-versioned or appear in PR diffs. (Figma Help: Git with Figma Make and code layers)
Is Style Dictionary v5.8.0 safe to upgrade?
That depends on your use of its changed override semantics and the breaking sketch/palette name restoration; the release also includes fixes and improved errors. Review those changes against your pipeline before upgrading; the sources do not establish a universal safety verdict. (Style Dictionary releases)
Can we switch a zeroheight token set back to legacy export after moving to DTCG 2025.10?
No in-product way back is documented once a token set output has switched. Download and diff the new export before changing a production pipeline. (zeroheight: Migrating to Style Dictionary v5)
Which Penpot version should we pin — 2.19 or 2.18.6?
The sources show 2.19 described in hosted notes but no corresponding tag, while 2.18.6 is the latest tagged release. Pinning guidance beyond verifying the release notes against the tags is not established; treat 2.19 as described-but-not-tagged. (Penpot release notes; Penpot GitHub releases)
The Bottom Line
On this blog’s reading, the canvas became a repository client, and that is a genuinely new capability for agents: Git lineage, prototype-flow topology, and a diffable DTCG 2025.10 contract are now perceivable and checkable. But provenance is asymmetric and partly one-way. Figma file permissions can expose code beyond GitHub permissions; zeroheight’s cutover has no in-product reversal; plugin consumers cannot revert; and Penpot’s release metadata disagrees with its tags.
Adopt the Git semantics without making the canvas the archive. Keep the source of truth in your repository and tokens in DTCG JSON exports that can be diffed. Treat the design canvas as a client—with its own permissions and migration boundaries—not as the durable record.
How This Guide Was Built
This digest covers 2026-11-03 → 2026-11-05 and draws on ten sources: Figma release notes, the Workflow Lab and Nimbus posts, three Figma help documents (Git, code layers, generative plugins), Style Dictionary releases, zeroheight guidance, and Penpot’s release notes and GitHub releases. All captured 2026-11-05 unless dated otherwise.
Quotes are reproduced verbatim. This is a source-based digest, not a hands-on review: there was no hands-on testing, vendor briefing, or preview access. The Oct 27 version-history item and Oct 28 Penpot notes are flagged as context outside the digest window; the version-history item is used only for its provenance mechanic and consumer/creator asymmetry, not shader functionality. Pricing, enterprise terms, the cloning rollout completion date, Penpot’s token format, .figma/make git-versioning, and Nimbus’s external availability are not established by these sources. See the November 2 digest for shaders, Weave tools, and A2UI.