[BUG] Slash command autocomplete stops filtering after a '.' (period) in skill/command name
Summary
Slash-command autocomplete stops filtering as soon as a . (period) is typed in a command/skill name. Command/skill names that contain a dot (e.g. /foo.bar-daily-report) can no longer be reached by continuing to type past the dot — the suggestion list disappears. This used to work in earlier 2.0.x / early 2.1.x versions, so it appears to be a regression.
This is closely related to #65050 (typing // no longer filters to skills whose name: starts with /, regression in v2.1.160) — same class of problem, but for the . character mid-name rather than a leading /.
Repro
- Create a project or user skill whose
name:(or a custom slash command) contains a period, e.g.foo.bar-daily-report. - In the prompt, type
/foo— the command/skill appears in the autocomplete list as expected. ✅ - Continue typing the dot:
/foo.(or/foo.bar). - The autocomplete list stops filtering / disappears, and the command can no longer be selected by continuing to type. ❌
Expected
Typing /foo.bar should keep narrowing the autocomplete list to commands/skills matching that substring, just like dashes (-) and underscores (_) do. The . character should be treated as a literal part of the name for matching purposes.
Actual
Filtering breaks at the . boundary. Workaround is to type only up to /foo (before the dot) and use the arrow keys to select, but typing the dotted portion is not honored.
Why this matters
Some organizations use dotted naming conventions for their skills/commands (e.g. a team prefix like foo.bar-*) that cannot be changed for policy reasons. With this regression, every such command must be selected via arrow keys instead of type-to-filter, which is noticeably slower when there are many similarly-prefixed commands.
Environment
- Claude Code: 2.1.170
- OS: macOS 26.4.1
- Surface: CLI (TUI)
Related
- #65050 — leading
/in skillname:breaks//filtering (regression in v2.1.160) - #25477 — slash command autocomplete filtering stuck (v2.1.41)