[Bug]: /design only manages consent in Claude threads and never runs the design skill

[sergiolopez94]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Open a Claude-provider thread in T3 Code (Alpha) on a repo.
2. Type /design consent. First attempt: "Couldn't record Design agent access for your Claude Design projects - Request failed with status code 403. Try again, or run /design-login".
3. Type /design-login: "/design-login isn't available in this environment."
4. After authorizing elsewhere, /design consent reports access granted.
5. Type /design <a design brief> in the thread.

Expected behavior

/design with a brief starts Claude Code's native design skill, as it does in an interactive Claude Code terminal session.

Actual behavior

Every /design invocation, with or without arguments and after consent is granted, is delivered to the agent as:

/design was invoked. In this session /design only manages agent access to Claude Design projects: tell the user to run /design consent or /design revoke, and stop.

The design skill never runs. The skill is disable-model-invocation, so the agent cannot start it either, and the brief is lost. /design-login cannot be completed in the thread, so the only way to authorize is outside T3 Code.

Impact

Claude Design cannot be used from T3 Code at all; users have to switch to a terminal Claude Code session for any design work, and the consent flow suggests it will work when it will not.

Version or commit

T3 Code (Alpha) 0.0.42, Claude Code 2.1.281

Environment

macOS 26.6.2, Claude provider

Logs or stack traces

No stack trace; the behaviour is the substituted command text quoted above.

Workaround

Run claude in a terminal in the same repo and use /design there.

It is possible the routing originates in the Claude Agent SDK's non-interactive mode rather than T3 Code itself; if so, a pointer to the right upstream would help.

[juliusmarminge]

Triage #13511

Verdict: upstream. Claude Code rewrites /design in Agent SDK sessions. T3 delivers the slash command unchanged. Still present in Claude Code 2.1.282 (npm latest as of today). No matching issue in this repo.

What happens

T3 starts Claude through @anthropic-ai/claude-agent-sdk query(). The SDK sets CLAUDE_CODE_ENTRYPOINT=sdk-ts when it is unset. A typed /design <brief> is the last text block of the user message (buildUserMessageEffect in apps/server/src/provider/Layers/ClaudeAdapter.ts), which is what the CLI treats as a slash command. $skill rewriting in ClaudeSkillDispatch does not touch a leading /design.

Inside Claude Code 2.1.281 (the reporter’s CLI; same router in 2.1.282), /design picks a mode:

1. Bundled skills disabled → consent only.
2. Canvas skill (isDesignCanvasSkillEnabled) → the real design skill.
3. Hub (tengu_omelette_fouet, default off) → Claude Design tools.
4. Otherwise, if design-sync policy allows it → the consent command.

SDK sessions hit step 4. The artifact/canvas gate returns sdk_default_off when the entrypoint is sdk-ts, sdk-py, or sdk-cli and CLAUDE_CODE_ARTIFACT is not explicitly 1/true/yes/on. An interactive claude terminal is not an SDK entrypoint, so the canvas skill runs there. With canvas and hub both off, every /design invocation, with or without a brief, is replaced with:

/design was invoked. In this session /design only manages agent access to Claude Design projects: tell the user to run /design consent or /design revoke, and stop.

disableModelInvocation is on unless the mode is canvas, so the model cannot start the skill, and the brief is discarded.

/design-login is a separate headless filter. In a non-interactive session the CLI answers cmd_unavailable_headless: “/design-login isn't available in this environment.” The first /design consent 403 is the missing design-scope grant. After a terminal login, consent can succeed while the skill still stays on the consent path, because consent does not clear sdk_default_off.

T3 does not set CLAUDE_CODE_ARTIFACT, CLAUDE_CODE_ENTRYPOINT, or CLAUDE_CODE_DISABLE_BUNDLED_SKILLS.

Related upstream

• anthropics/claude-code#90686 — /design-login unavailable outside a terminal; consent 403.
• anthropics/claude-code#91063 — design auth has no non-interactive path.

Neither describes this SDK /design → consent substitution.

Recommendation

Label upstream and bug. Leave the code as-is unless we explicitly want Claude threads to opt into artifacts.

A T3-side opt-in would be CLAUDE_CODE_ARTIFACT=1 on the Claude session environment. That is the CLI’s own switch for sdk_default_off, and it turns on the Artifact tool for every Claude thread, which the CLI leaves off for SDK hosts. It does not make /design-login work; that command stays terminal-only.

[sergiolopez94]

Workaround result: outside T3 Code, typing /design <brief> in Claude Code on the same machine worked. The brief came through, the design skill ran, and it produced a Claude Design canvas.

Two details that may help:

• This was the Claude desktop app's Code tab, not the plain terminal CLI, so strictly it is not a terminal test.
• When the /design <brief> text arrived inside pasted content instead of being typed as the command, the skill did not start. It had to be typed.

claude --version on that machine prints 2.1.281 (Claude Code). I have not tried 2.1.282, which the triage above mentions.