### 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? In the Claude desktop

Same symptom here, but with **pure ASCII** command names, so non-ASCII characters may not be the root cause, or at least not the only one. Our project skills contain a **dot** in their name (namespaced, ` . `): | Command | Result | |---|---| | `/compact` (built-in) | ✅ sent | | `/bloomays.work-linear-issue TEC-9999` | ❌ blocked | | `/bloomays.create-linear-issue` (no argument) | ❌ blocked | Same warning as in the original report ("commands may only contain file @mentions; other

[BUG] [Desktop Code tab] Slash commands with non-ASCII (Korean) names are rejected on send

Status Open

Reported on v2.1.284

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 3 comments · opened Oct 1, 2026

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?

In the Claude desktop app (Code tab), custom slash commands whose name contains Korean characters can no longer be sent.
The composer recognizes and highlights the command and shows it in autocomplete, but on send it is blocked with a warning and nothing is sent.
Every Korean-named command we have (20+) is affected. ASCII-named commands with identical content work normally.

What Should Happen?

Commands with non-ASCII names should be sent and run, the same as ASCII-named commands.

Error Messages/Logs

명령에는 파일 @멘션만 포함할 수 있으며 다른 @멘션, 슬래시 명령, 링크, 인라인 서식은 포함할 수 없어 아무것도 전송되지 않았습니다. 해당 항목을 제거해 주세요.

(English: Commands may only contain file @mentions; other @mentions, slash commands, links, or inline formatting are not allowed, so nothing was sent. Please remove them.)

Steps to Reproduce

Create ~/.claude/commands/테스트.md with only a description in the frontmatter.
Create ~/.claude/commands/test-alias.md with exactly the same content.
Start a new session in the desktop app Code tab.
Type "/테스트" and press Enter -> blocked with the warning above.
Type "/test-alias" and press Enter -> sent and runs normally.

Ruled out (still blocked in every case):

Name starting with a digit vs. a letter
Slash-command examples inside the description (removed)
allowed-tools / argument-hint in the frontmatter (removed)
With or without arguments, and in a fresh session
Filename Unicode normalization (all files are NFC)

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unknown — worked until about 2026-09-29

Claude Code Version

2.1.284 (Claude desktop app 2.16120.0)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment: Claude desktop app 2.16120.0, Code tab (not the CLI), macOS 27.0, Korean UI / Korean input method
Workaround: ASCII-named alias files that reference the original command
Screenshot of the warning attached

View original on GitHub ↗

3 Comments

stanleyloo · 15 days ago

Same bug here with Chinese-named commands (e.g. /指令), and it also reproduces in Claude Code on the web (claude.ai/code), not only the desktop Code tab. Frontend build 87128b6b3c (built 2026-09-30 21:11 UTC); the CLI (2.1.286) is unaffected.

Likely cause, from the shipped JS bundle: before sending, the composer validates the leading skillChip, and the name check uses /^\/([\w:-]+)(?=\s|$)/ — no u flag, so \w is ASCII-only. Any CJK/Korean name fails the match, so the chip is rejected as a disallowed "other slash command". Pressing Esc doesn't help (the text is already a chip by then).

Suggested fix: a Unicode-aware pattern, e.g. /^\/([\p{L}\p{N}_:-]+)(?=\s|$)/u.

jomaora · 10 days ago

Same symptom here, but with pure ASCII command names, so non-ASCII characters may not be the root cause, or at least not the only one.

Our project skills contain a dot in their name (namespaced, <namespace>.<name>):

| Command | Result |
|---|---|
| /compact (built-in) | ✅ sent |
| /bloomays.work-linear-issue TEC-9999 | ❌ blocked |
| /bloomays.create-linear-issue (no argument) | ❌ blocked |

Same warning as in the original report ("commands may only contain file @mentions; other @mentions, slash commands, links, or inline formatting…"). The command is recognized in the composer (highlighted, offered by autocomplete), then rejected on send, with or without arguments.

This fits the hypothesis from #98925: the pre-send validator seems to match command names against a narrower character set than the autocomplete does (letters, digits, -, _). With a dot, it probably reads /bloomays only, finds no such command, and classifies it as a stray slash command. Non-ASCII letters and dots would then be two symptoms of the same bug.

This likely affects a lot of users: spec-kit generates dotted command names (/speckit.plan, /speckit.specify, …), although I haven't tested those specifically.

Workarounds: invoke the skill in plain language without the leading /, or use the CLI.

Platform: macOS, Claude desktop app, Code tab
App version: 2.19675.0 (5706e5), still reproducible on this build, newer than the one in the original report

hithawk · 10 days ago

Same here on macOS — Claude desktop app 2.19675.0 (Code tab), Claude Code 2.1.215.

Korean-named personal commands in ~/.claude/commands/ (/저장, /종료, /현황) show up in the / list and are highlighted in the composer, but sending is blocked with the exact warning quoted in the report. Reproduces in an idle session and when the command is picked from the list with no other text.
An ASCII-named command in the same folder (/detail-page) sends and runs normally.
The command files have not changed for months and worked before; the app auto-updated around 2026-10-01. The model can still invoke the same commands itself, so the files load fine.

Workaround for now: ASCII-named symlinks to the Korean files.