[BUG] Desktop and web clients resolve /plan to built-in plan mode; CLI correctly resolves it to the project's /plan command

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

I have a project-level /plan command (.claude/commands/plan.md) that invokes a project planning skill. In the terminal CLI this works as expected: typing /plan shows my command's description with (project) next to it, and it runs my command. In a Remote Control session driven from the Claude Desktop app, the same /plan <slug> <context> enters the built-in plan mode with my argument string as the plan description. My command is unreachable from Desktop.

So the two surfaces disagree on slash-command precedence, and Desktop's answer is the wrong one: the CLI already gives project commands priority over the built-in, and Desktop should match it.

The semantics are incompatible, not just different. Plan mode is a read-only permission mode. My /plan is a workflow: it interviews the user, explores the repo via subagents, drafts .claude/plans/<slug>/PLAN.md, runs review agents against the draft, may write and run tests to validate assumptions before they go into the plan, then commits and lands the plan on origin/main. Read-only is the wrong mode for it. Its companion /work <slug> executes a plan.

Related issues

Searched the tracker (Sept 9, 2026) for a Desktop-side intercept of /plan shadowing a user command; found no existing report. Adjacent issues, which suggest Remote Control's slash handling has disagreed with the CLI in both directions:

• #82676 (open) — Desktop SSH: slash palette omits remote custom skills in a fresh session because the CLI is spawned lazily.
• #89398 (open) — Desktop slash picker only opens when / is the first character in the composer, yet the command still runs on submit. Shows the Desktop composer does its own slash handling.
• #85654 (open) — a slash command inside a collapsed pasted-text block is never dispatched. Same layer.
• #68252, #68102, #29156, #28379 — the opposite failure: built-in commands typed in Remote Control routed to the model as plain text.
• #92138 (open) — two built-in commands share the name /design. Different bug, same missing namespace-collision discipline.

What Should Happen?

1. Desktop/Remote Control uses the same slash-command resolution as the CLI (user/project commands and skills take precedence over built-ins).
2. Until then, or as a general safeguard: a visible notice when a built-in shadows a user-defined command, and/or a disabledCommands setting.

Error Messages/Logs

Steps to Reproduce

1. Create .claude/commands/plan.md with any content and a description: frontmatter line.
2. In the terminal, run claude, type /plan — observe the project command is listed with (project) and runs. (Correct.)
3. Start a Remote Control session (claude --remote-control --spawn worktree) and connect from the Desktop app.
4. In Desktop, type /plan foo bar and press Enter.

Expected: same behavior as the CLI — the message is submitted and the project command runs with $ARGUMENTS = "foo bar".

Actual: the Desktop client handles it instantly and locally, before anything is submitted: the permission mode flips to Plan, /plan is stripped from the input, and foo bar is left sitting in the composer unsent. There is no round trip to the session, so the server-side command resolution that works in the CLI never gets a chance to run.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown (first noticed on 2.1.266)

Claude Code Version

2.1.266

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• Claude Code CLI: 2.1.266
• Claude Desktop: Claude for Windows 1.49585.0 (41ad1d), built 2026-09-08T05:21:03Z
• Session: --remote-control --spawn worktree, connected from Desktop
• Note: the intercept appears to be entirely client-side in Desktop (instant, no submission), so the fix is likely in the Desktop app's slash handling rather than in the CLI
• OS: Windows 11 Pro 23H2, build 22631.3155
• Regression: I used /plan from Desktop/Remote Control routinely and it ran the project command, until it stopped. First noticed on 2.1.266; last working version unknown.
• Also reproduces on web.
• Workaround: writing /plan in backquotes avoids the client intercept, and the model then invokes the project command itself.