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

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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 ` 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//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 ` 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

```shell

```

### 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

_No response_

### 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

Start by reproducing the behavior with .claude/commands/plan.md, then compare `/plan` resolution in the terminal CLI with a Remote Control session opened in Claude Desktop. The report identifies Desktop's client-side slash handling as the likely entry point, but names no implementation files or tests. Done means project `/plan` commands receive precedence in Desktop as they do in the CLI, including `$ARGUMENTS`.

Escrito por el modelo de indexación a partir del texto del issue.