Custom slash commands with non-ASCII (Japanese) names cannot be sent from the composer

The defect is not limited to non-ASCII names: dotted ASCII names are blocked too

Measured on a separate machine from the issue author's. Command names are described by their character class rather than by name.

Environment

| | |
|---|---|
| Date | 2026-10-02 |
| Claude Code | 2.1.286 |
| Desktop app | 2.19675.0.0 (Microsoft Store build), Code tab composer |
| OS | Windows 11 Pro 10.0.26200 |

Results

Each command below was invoked on its own, from a fully cleared composer, selected from the / autocomplete.

| Command name | Kind | Result |
|---|---|---|
| /agents, /model | built-in, alphanumeric | works |
| alphanumeric only | user-defined | works |
| contains - | user-defined (2 tried) | works |
| contains : (plugin-namespaced) | user-defined | works |
| contains . | user-defined | blocked |
| non-ASCII | user-defined (per the issue body) | blocked |

Blocked ones show exactly the warning quoted in the issue body, and nothing is sent. The / autocomplete lists them and they can be selected with the arrow keys and Enter; the refusal happens at send. So discovery and registration work, and the failure is in the pre-send validation step, as the issue body says.

This is not the mid-line picker problem (#95735 / #89398): the composer was empty and / was the first character.

Narrower root cause

Hyphens and colons are accepted. The two failing classes are a dot in the name and non-ASCII characters in the name.

That is consistent with one defect: the pre-send validator extracts the command name with an ASCII word-character pattern — something equivalent to /[A-Za-z0-9_:-]+ — and matches the result against the registered command list.

• A dotted name is read only up to the dot, the remainder is left over, no registered command matches, so the whole thing is classified as a stray slash command inside a plain message and the send is refused.
• A non-ASCII name matches no characters at all, with the same outcome.

So the issue title describes one symptom of a wider defect. Dotted names are affected too, and they are pure ASCII. Dotted names are a common namespacing convention for grouped command sets, so this is not limited to non-English users.

Suggested repro, all user-defined and ASCII

| File | Invoke | Expected under the above |
|---|---|---|
| ~/.claude/commands/testcmd.md | /testcmd | works (already confirmed in the issue body) |
| ~/.claude/commands/test-cmd.md | /test-cmd | works |
| ~/.claude/commands/test.cmd.md | /test.cmd | blocked |

If that holds, the fix is to align the validator's accepted name pattern with what the autocomplete and the command registry already accept, rather than to special-case either dots or non-ASCII.

Confirmed on a second version and a second machine. Thank you for the measurements — your corrected root cause holds here too.

I ran your suggested repro on the machine from the issue body (Claude Code 2.1.183, Windows 11 Pro 10.0.26300, desktop app Code tab). Both files were plain description:-only frontmatter in ~/.claude/commands/, each invoked on its own from a fully cleared composer.

| File | Invoke | Result |
|---|---|---|
| testcmd.md | /testcmd | works (as reported originally) |
| test-cmd.md | /test-cmd | works |
| test.cmd.md | /test.cmd | blocked |

The blocked one shows exactly the warning in the issue body and nothing is sent; the / autocomplete lists it and it can be selected. So the dotted-name failure reproduces across 2.1.183 and 2.1.286, on two separate machines — it is not specific to your build.

This also confirms hyphens are fine, consistent with your correction.

Combined, the failing classes are a dot in the name and non-ASCII characters in the name, which matches a single validator that extracts the command name with an ASCII word-character pattern and then matches it against the registry.

I agree the title understates the defect. Suggested retitle:

Custom slash commands whose name contains a dot or non-ASCII characters are blocked by the composer validator

Happy for a maintainer to edit the title, or I can update it.

I am experiencing the same issue, in my case I believe it is because Claude automatically appends (MCP) to the custom command. Works in VS code and terminal, but fails in the desktop app (using the Linux Desktop Client)