The symptom
You add the Figma MCP server to opencode.json and run opencode mcp auth figma. No browser opens. OpenCode prints Authentication failed and exits with status 0, so a script that checks the exit code thinks it worked. The agent then starts without Figma.
Reinstalling OpenCode does not change it, and neither does a new Figma token. The failure happens before any token exists.
Why it fails
MCP servers that use OAuth let a client register itself on the fly, with dynamic client registration. Figma's registration endpoint, https://api.figma.com/v1/oauth/mcp/register, only accepts a short allowlist of client names. OpenCode registers under its own name, which is not on the list, so Figma refuses the registration and OpenCode never gets as far as the browser.
Figma's documentation describes the workaround: register a client ahead of time under a name the allowlist accepts, then run the authorization flow with that client. Doing it by hand means a curl to the registration endpoint, a PKCE flow with a local redirect, and writing the tokens where OpenCode reads them.
The fix in four commands
ivar does those steps for you. Install it, create a hall in an empty directory, declare Figma and authenticate:
curl -fsSL 'https://ivar.run/install?ref=figma-mcp-opencode' | sh
mkdir design-hall && cd design-hall
ivar init --provider opencode
ivar mcp add figma
ivar mcp auth figma --provider opencode
ivar mcp add figma writes the server into the hall's ivar.json and into the opencode.json next to it:
ivar.json
{
"mcp": [
{ "name": "figma", "type": "http", "url": "https://mcp.figma.com/mcp" }
]
}
ivar mcp auth then pre-registers a client for OpenCode under a name Figma accepts, opens the browser for the authorization, listens for the redirect on 127.0.0.1:19876, and writes the tokens into OpenCode's MCP auth store. It reads the store back afterwards, so a run that leaves no tokens is reported as a failure instead of a silent exit 0. Start opencode from the hall directory and the Figma tools are there.
The client secret goes to .ivar/secrets/mcp.env, which stays out of git. Tokens never go into ivar.json, so the file is safe to commit and share.
If Figma changes its allowlist, the registration step answers 403. That is the one place to look, and the error says so.
The next server, the next harness
The same two commands work for other servers. ivar mcp add linear declares Linear's MCP server; OpenCode's own login works for Linear, so ivar mcp auth linear --provider opencode hands the browser step to opencode mcp auth.
Other harnesses read the same declaration. Add Claude Code or OMP to the hall and authenticate every provider it lists, one at a time:
ivar provider add claude-code
ivar sync
ivar mcp auth figma --all-providers
ivar mcp status
ivar provider add only records the harness; ivar sync writes its MCP file from the same ivar.json. Claude Code's own claude mcp login works with Figma, so ivar delegates to it. OMP has no MCP login command, so ivar runs the flow itself and imports the token with omp auth-broker import. ivar mcp status shows which server has credentials on which provider. One MCP config for Claude Code, OpenCode and OMP walks through all three harnesses side by side.
Then mount your repos
The hall you created is the same hall ivar uses to run agents across repositories. Mount the repos your design work lands in, start a session, and every session gets Figma from the same ivar.json, on every branch and worktree, without another login. The quickstart takes it from here.
Do you need this?
If you use only Claude Code, its own Figma login works and you do not need ivar for this. The failure above is specific to Figma's allowlist and to harnesses that register under a name Figma does not accept: OpenCode today, and OMP, which has no MCP login of its own.
Limits
-
ivarsupports three harnesses: Claude Code, OpenCode and OMP. - It runs on macOS and Linux. Windows is not supported, and WSL is untested.
- The OAuth flow talks to Figma's servers directly.
ivarhas no server of its own in the middle. - The Figma MCP server gives your agent read access to files, frames, comments and component metadata. It does not edit designs, and
ivardoes not sync designs into code.
Related
- One MCP config for Claude Code, OpenCode and OMP: where each harness's MCP auth breaks, and one declaration for all three.
- One repo, many agents: parallel features from a Figma prototype: Figma MCP in every parallel session on one repository.
- Figma integration: the reference page for this setup.
Top comments (2)
I'm a Flutter developer, and my usual input is a big Figma prototype that I'd like to implement with several agents working in parallel, each on its own branch. Keeping Figma MCP set up for every one of those sessions is exactly the chore you describe, so the Hall + ivar sync idea caught my attention. Does ivar also make sense when it's one app repo with many parallel feature branches, or is it really meant for work that spans several repos?
Yes, it works great with a single repo! For your case, you'd add the Flutter app to a hall and set up Figma MCP just once. Then create a main feature for the whole prototype, with sub-features under it, say onboarding, checkout, and profile. Each sub-feature gets its own branch and its own copy of the app, so you can put an agent on each and let them run in parallel with Figma already set up.
The main feature is where you orchestrate it all. You can see how every sub-feature is doing, and as each one finishes, you integrate it back into the main feature branch. When the prototype comes together, Ivar opens a single PR for the main feature.
If you want to give it a try ivar.run/docs/quickstart