Claude Desktop has Chat, Cowork, and Code. Then Claude Design arrived. The names suggest the boundaries, but in use the boundaries blur — Claude Code can build UI, Claude Design can produce prototypes.
Two things I got wrong, which cost me an afternoon:
- I assumed
/design-syncpulls Design output into Claude Code. It does the opposite: it converts a React design system in your repository and uploads it to Claude Design. Going the other way — design to implementation — is the handoff bundle, not/design-sync. - I assumed the Desktop Code tab is Claude Code. It is not quite. In my environment, on June 21, 2026,
/design-syncfrom the Desktop Code tab stopped at Design-side authorization, and I could not run/design-loginthere either.
Neither was a plan problem. Claude Design itself worked fine in the browser, and the standalone CLI got me through.
Originally published in Japanese on June 21, 2026. This English version was written in September 2026 and corrects two points from the original.
Status, as of September 2026
Claude Design launched from Anthropic Labs on April 17, 2026, in research preview for Pro, Max, Team, and Enterprise subscribers. As of the help documentation dated August 6, 2026, it is in beta on those same plans. On Enterprise it is off by default; an administrator enables it under Organization settings.
My hands-on notes below are from June 21, 2026. Commands, behavior, and usage accounting have already moved once since then, so treat the observations as dated and check the current documentation before relying on any of it.
One change since those notes matters to the boundary this article draws. Claude Code now has its own /design [brief] command, on sessions where artifacts are available. It drafts the design as artboards on a canvas and publishes that canvas as an artifact running a research preview of Claude Design’s editor. So “Design lives in the browser, Code lives in the repo” is no longer the whole picture: /design-sync still pushes your design system up and the handoff bundle still brings a design down, but there is now a third route that starts inside Claude Code.
The correction that matters most: which way /design-sync points
I expected this flow:
- Build screens and components in Claude Design
- Run
/design-syncin Claude Code - Design’s output and design system land on the Code side
- Start implementing
That is backwards. Per the Claude Code slash command reference, /design-sync [hint] converts the React design system in your repository and uploads it to Claude Design, so that Design generates screens consistent with the components you already have. /design-login exists to authorize that design-system access against your claude.ai account.
The other direction — from a finished design into code — is a separate mechanism. Anthropic’s announcement describes Claude Design packaging a design into a handoff bundle that you pass to Claude Code with a single instruction, and the help documentation lists “Handoff to Claude Code” among the export options.
So the model to hold is: /design-sync pushes your existing components up so Design stays on-brand. Handoff brings a design down into implementation. I was trying to use the upload command as a download command.
The Desktop Code tab is not the standalone CLI
The second problem was environmental. In my testing, running /design-sync from the Desktop Code tab stopped at Design-side authorization, and /design-login was not runnable there to resolve it.
The Claude Code Desktop documentation explains the general shape of this: built-in commands that open an interactive panel in the terminal behave differently in the Code tab, and commands with no argument form reply isn't available in this environment. It recommends running such commands from the standalone CLI. /design-login takes no argument, which fits that description — though I should be clear that the Desktop documentation does not name the design commands specifically. That connection is my inference from observed behavior, not a documented statement.
Where that leaves things:
| Goal | Status in my environment, June 2026 |
|---|---|
| Use Claude Design in the browser | Works |
| Open Claude Design from the Claude Desktop sidebar | Works (appeared by June 26) |
Run /design-sync from the Desktop Code tab | Did not work |
Run /design-login from the standalone CLI | Works — the practical route |
Getting this wrong is expensive because the symptom reads as “Claude Design is unavailable to me” when the actual situation is “this particular entry point does not carry the authorization.”
One update from five days later: by June 26, 2026, a Design entry appeared in the Claude Desktop left menu in my environment, opening the Claude Design home screen with Design system, Template, and Model selectors. That is a separate thing from the Code tab problem — being able to open Design from Desktop does not make /design-sync work from the Code tab.
The workaround: standalone CLI
If you want the connection to hold, install the CLI globally and authorize there.
npm install -g @anthropic-ai/claude-code
claude
/login
/design-loginWith the globally installed claude, /design-login proceeded. On macOS the credentials go to the Keychain, so there is no plaintext credential file to go poking at.
Worth stating plainly: when authorization fails, the temptation is to go read config files and token values. Don’t put those in a write-up or a work log. The thing you need to know is whether authorization succeeded, not what the value was.
Design and Code have different jobs
Judged only on model capability the distinction is hard to see. Claude Code writes CSS, builds web pages, and fixes a lot from a screenshot. So: if Code can do it, why Design?
Because the loop is different.
| Claude Design | Claude Code | |
|---|---|---|
| Purpose | Visuals, prototypes, decks | Implementation, fixes, verification |
| Strength | Setting direction, comparing options, editing the artifact directly | Working in a repo, matching existing code, running tests |
| The human question | Does this look and feel right? | Does this work without breaking anything? |
| Where output lives | A Design project; HTML/PDF/PPTX exports | Local code, a PR, a commit |
| Best stage | Before implementation — concepts, comparison | Implementation, fixes, pre-release checks |
With Claude Code you can absolutely drive UI: run a dev server, screenshot it, read the DOM, iterate. I do this constantly. But you have to construct the verification loop each time — render, capture, describe what looks off, edit CSS, look again. That is a natural loop for code quality and a heavy one for design exploration.
Claude Design starts from the visual, and assumes you will comment on it, edit it directly, and ask for alternatives. The help documentation describes exactly that mix of chat, inline comments, and direct editing.
The better mental model is not “an AI that can also write code” but “a workbench for settling how something looks, by talking about it.”
What Design was actually good at
I had it build a homepage concept in the browser. The part that surprised me was not the HTML. It was that after generating a screen, it suspected its own implementation of causing a layout problem, then went and inspected the DOM and render state to fix it.
Not flawless. The connection got unstable mid-session. Driving it through a browser, screenshot capture and tab handling were sometimes unreliable. And output stays inside Claude Design first, so getting it into a real repository means an export or a handoff.
For the stage where you want to see a direction, that is enough.
Usage comes out of the shared pool
This is the other thing I want to correct from the original Japanese version, where I described the documentation as contradicting itself.
It does not. The current help documentation states that Claude Design counts toward the same usage limits as the rest of Claude, drawing from the shared pool used for chat, Claude Code, and Cowork, with no separate Design allowance to track. It also states explicitly that Claude Design previously had its own weekly allowance and that all activity now counts toward the plan’s shared limits. So the “separate allowance” description is not a live contradiction — it is the older behavior, and the documentation says so.
That matched my Claude Desktop usage screen, which showed plan limits, the current session, the weekly limit, all models, and usage credits — with no Design-specific meter.
The practical consequence: Design encourages iteration. “Give me three alternatives” is a cheap sentence and not a cheap operation. If you also lean on Claude Code daily on the same plan, exploring freely in Design will show up later as less room for implementation work. On Team and seat-based Enterprise, Design draws from each member’s seat limits.
How I use them now
Claude Design is not a general-purpose UI production tool. It is where you explore direction: a new web app’s homepage, an admin dashboard, a form’s appearance, a landing page hero, a slide or one-pager. Things where the first requirement is to see something.
Implementation goes to Claude Code: matching existing components, wiring routing, connecting form submission, testing, committing.
A sensible order for a first try:
- Make a small screen concept in Claude Design in the browser
- Ask for two or three variants to find where it is strong and weak
- Check your usage screen
- Look at what export formats you get
- Confirm
/design-loginworks from the standalone CLI - Try
/design-syncon a small repository, remembering it pushes your design system up - In a real repository, decide the direction yourself before handing anything to Code
The failure mode is trying to connect everything on day one.
FAQ
Is Claude Design available on Pro?
Yes. It is in beta for Pro, Max, Team, and Enterprise. On Enterprise it is off by default and needs administrator enablement.
Can I run /design-sync from the Claude Desktop Code tab?
It did not work in my environment in June 2026. The Desktop documentation notes that some terminal-dialog commands behave differently in the Code tab and should be run from the standalone CLI. Authorize with /login and /design-login there.
Does using Claude Design eat into my Claude Code usage?
Yes. The documentation states Design draws from the same shared pool as chat, Claude Code, and Cowork.
Can Claude Design generate character illustrations?
Anthropic’s documentation does not address image generation either way. In my own use it behaved as a design and prototyping workbench rather than an image model, so I would not plan on it — produce visual assets in a dedicated image tool and use Claude for structure, direction, and getting them into the UI.
Design explores, Code implements
The confusion here is real and mostly structural: Code can build UI, Design can emit code-shaped prototypes, Desktop has a Code tab, the browser has Design, and the CLI is a third entrance with different capabilities.
So fix the roles first. Design is where you explore how something looks. Code is where you implement and verify. /design-sync sends your existing design system up to Design; the handoff bundle brings a design down into implementation. Usage is one shared pool.
Get those three straight and most of the confusion goes away. Start with one small screen concept, then build the path into Code.
References
- Introducing Claude Design by Anthropic Labs | Anthropic (April 17, 2026)
- Get started with Claude Design | Anthropic Help Center
- Claude Design admin guide for Team and Enterprise plans | Anthropic Help Center
- Claude Code slash commands reference
- Claude Code Desktop application | Claude Code documentation