DesignSync has no non-interactive authorization path — blocks headless/CI design-system sync

Status Open
Reported on v2.1.251
Maintainer reply None cached
Activity 5 comments · opened Aug 31, 2026

/design-login is the only way to obtain design-system authorization, and it requires an interactive terminal. There is no equivalent for a session without a TTY, so DesignSync cannot be used from CI, a scheduled job, or an agent sandbox.

Repro

  1. Run Claude Code non-interactively (no TTY) in an environment authenticated to claude.ai.
  2. ToolSearch("select:DesignSync") → succeeds, the schema loads.
  3. DesignSync(list_projects) →
DesignSync needs design-system authorization, but /design-login requires an interactive terminal and is not available in this environment.

Same result on the same machine's interactive terminal: everything works. The authorization itself is fine — it just cannot leave the terminal.

Not a duplicate of #69496 / #75024. Those describe an interactive grant that fails where it should succeed (the scope upgrade 400s, or /design-consent 403s). On my account the interactive grant works and I sync normally from a terminal. If both were fixed tomorrow, this would still be blocked, because the grant would still be terminal-only.

The read methods are blocked too, which I haven't seen reported. list_projects and get_file fail alongside the writes. That closes the obvious workaround: you cannot verify headlessly and upload from an interactive session, because the headless half can't read the project's _ds_sync.json sync anchor. Without the anchor the converter loses its incremental scope and re-captures the entire library, so the split pipeline costs more than the manual one.

Suggested shape. claude setup-token already mints a long-lived OAuth token for exactly this situation. If user:design:* could ride on that token, or be provisioned as an environment secret, the non-interactive path exists with no new mechanism. Failing that, granting the read methods without the interactive step would at least make a split pipeline viable.

What it unblocks. We sync a ~92-component React design system into a Claude Design project. The mechanical half is already automation-ready: one driver command chains build → diff → validate → capture and emits a machine-readable verdict whose schema is documented as a CI contract. It runs unattended end to end. This authorization is the only human gesture left, so the sync stays a ~75-minute manual session someone sits through weekly, rather than a scheduled job that runs ahead of our release.

Environment: Claude Code 2.1.251 — macOS interactive (works), Linux agent sandbox without a TTY (blocked).

View original on GitHub ↗

4 Comments

taltcher · 1 month ago

Is there an update about this?

RKJuve · 23 days ago

I could use this capability as well, we are wanting to run /design-sync in CI when changes to our design system merge.

greglaspina · 20 days ago

Same - would love to see support for running /design-sync in CI.

April-Ingage · 20 days ago

+1, this would be really helpful for my team. We need to keep Claude Design in sync with our component library, and a supported non-interactive auth path (e.g. design scopes on claude setup-token) would let us run it in CI on every merge instead of relying on someone to remember to re-sync.

Showing cached comments. Read the full discussion on GitHub ↗