[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) 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 /<command> 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 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.