[BUG] Cowork (Windows): a typed plugin slash command only executes when the picker resolves it into the blue chip; identical text submitted unselected is sent to the model as plain text

### Preflight Checklist

- [x] I have searched existing issues and this hasn't been reported yet (closest: #78274, closed stale, macOS; #89628, open, Windows chip styling; #58102, closed not planned)
- [x] This is a single bug report
- [x] I am using the latest version of Claude Code (Cowork's app-managed CLI; control test on 2.1.270)

### What's Wrong?

In **Claude Cowork on Windows**, a plugin command is executed **only if it was resolved by the `/` picker into the blue chip token**. The same command typed in full, character for character, but submitted without selecting the picker entry is rejected by the Cowork client itself with a toast **"Unknown skill: sofia."** and the message is never sent.

Concretely, with our organisation plugin (`sofia`, a top-level `commands/sofia.md` entrypoint, plugin displayed as "Sofia plugin"):

1. Type `/sofia`. The picker opens and lists `sofia`, `sofia-skills`, `sofia-backend`, `sofia-playbooks`, … with the "Sofia plugin" tooltip. **Select** the `sofia` entry. The token turns blue. Submit. The command file runs. ✅
2. Type `/sofia` in full, **do not select** anything, submit. The text stays black. Cowork shows the toast `Unknown skill: sofia.` in the bottom-right corner, the composer keeps the text, nothing is sent to the model. ❌

The two inputs are byte-identical in the composer. The only difference is whether the picker was clicked or confirmed. The picker had just listed `sofia` as the first entry, so the registry knows the name; the submit-time resolver does not. Our reading is that the chip stores the plugin-qualified reference (`sofia:sofia`) while the typed text is resolved as the bare short name, and the bare-name fallback documented for the CLI ("the bare `/fancy` also invokes the skill unless another command already uses that name", [skills docs](https://code.claude.com/docs/en/skills)) is not applied in Cowork's composer.

This affects every employee who types faster than the picker, which in practice is most of them, and it lands on non-technical staff who have no way of knowing the colour is load-bearing.

### What Should Happen?

A message whose first token is `/` should be dispatched to that command whether or not the picker was used, exactly as the CLI and the Agent SDK do. The [Agent SDK docs](https://code.claude.com/docs/en/agent-sdk/slash-commands#dispatch-commands-by-name) state: *"Send a command by including it in your prompt string, the same way you send regular text."* Cowork's submit-time resolver should accept whatever the picker just offered, including the bare short name of a plugin command, or at minimum resolve the typed text against the registry on submit rather than only on picker selection.

Selecting from the picker should be a convenience, not a requirement.

### Error Messages/Logs

```
Unknown skill: sofia.
```

(Cowork toast, bottom-right, shown on submit of the unselected `/sofia`; the message stays in the composer.)

Control experiment on the plain CLI (2.1.270, Linux), same command-file mechanism, no picker involved. Typed text at position 0 dispatches correctly, so the engine is fine and the loss is in Cowork's composer:

```
$ claude -p "/ping" --max-turns 1 → PONG-COMMAND-FIRED
$ claude -p "/ping please" --max-turns 1 → PONG-COMMAND-FIRED
$ claude -p "/pin" --max-turns 1 → Unknown command: /pin. Did you mean /ping?
$ claude -p "hello /ping" --max-turns 1 → (passed to the model as text)
```

(`.claude/commands/ping.md` contains "Reply with exactly the text PONG-COMMAND-FIRED and nothing else.")

### Steps to Reproduce

1. On Windows, install any plugin that ships a top-level command, e.g. `commands/hello.md` containing `Reply with exactly HELLO-FIRED and nothing else.` (Our production case is the `sofia` plugin from a private org marketplace, v1.2.0, but any plugin command should reproduce it.)
2. Open a Cowork task.
3. Type `/hello`, press the entry in the dropdown so it renders as a blue chip, submit. Observe `HELLO-FIRED`.
4. New task. Type `/hello` in full. Do **not** touch the dropdown. Submit while the text is still black.
5. Observe the toast `Unknown skill: hello.` and the message left unsent.
6. Repeat step 4 with arguments (`/hello world`). Same result.

Reproduced by multiple employees across separate Windows machines on Claude Desktop `1.49585.0.0` (Microsoft Store), Windows 11 build `26200.9168`. Screenshots in the comments below.

### Claude Model

Opus

### Is this a regression?

I don't know

### Last Working Version

Unknown. #89628 reports the chip rendering changing after the 2026-08-25 Windows Desktop update, which may be related.

### Claude Code Version

Cowork's app-managed CLI (Claude Desktop 1.49585.0.0, Windows, Microsoft Store build). Control run: `2.1.270 (Claude Code)` on Linux.

### Platform

Anthropic API (claude.ai organisation, Cowork)

### Operating System

Windows

### Terminal/Shell

Other (Claude Desktop / Cowork composer, no terminal)

### Additional Information

- **Related, none of them holding this case:**
- #78274 (Cowork, macOS): pre-filled `/skill` text → "Unknown skill" until the picker is triggered and the entry "turns blue". Closed as stale. Same defect, different entry path.
- #89628 (Windows Desktop, open): chip styling gone after the 2026-08-25 update, picker only on first character.
- #58102 (Cowork, Windows, closed not planned): plugin commands → "Unknown skill", including the built-in `/feedback`.
- #36031 (Desktop, closed not planned): skill in picker but treated as text.
- **Why it matters for plugin authors:** we cannot work around this from inside a plugin. The rejection happens in the client before anything reaches the model, so no skill description or hook can catch it (Cowork also drops plugin-scoped hooks, #27398, #47993). A deterministic submit-time resolution is the correct fix.
- Happy to test a build or provide the plugin for reproduction.

Reproduce the issue in the Cowork composer on Windows with the described commands/hello.md or .claude/commands/ping.md fixtures, comparing picker-selected and typed submissions. Trace the submit-time command resolution entry point rather than the CLI control path. Done means a typed top-level plugin command, including one with arguments, dispatches without requiring picker selection and existing CLI behavior remains intact.

Written by the indexing model from the issue text.