Environment
- Claude Code desktop app, Windows 11 Home (10.0.26200)
- Version: not exposed anywhere I could find on this surface (no
claude --version on PATH, no version key in ~/.claude.json, no install dir under %LOCALAPPDATA%\Programs)
What happens
The slash-command autocomplete picker only opens when / is typed as the very first character of an empty composer. If any text already precedes it, the picker never appears, even when the command sits alone on its own new line.
The command is still recognised on submit. So the execution path and the autocomplete path disagree: the app will run a command it refused to help you find.
Steps to reproduce
- Open an empty composer. Type
/ — picker opens as expected.
- Clear it. Type any sentence, press Enter for a new line, then type
/wr.
- No picker, no filtering, no list-select, no highlight.
- Submit. The command is picked up and runs.
Expected
The picker should open for a /command at the start of any line in the composer, not only at position 0 of the input. If the submit path recognises a command there, autocomplete should too.
Why it matters
Chaining commands in one message is a normal workflow (e.g. /startup plus a second command in the same send). Today only the first one gets autocomplete support. For any command whose exact slug you don't have memorised, you have to either send it alone first to look it up, or guess. Discovery and typo-checking are lost precisely where a user is least sure of the name.
Related but distinct: #78278 (wrong text inserted on selection), #17816 (wrong item highlighted). Those are about the picker misbehaving once open; this is about it not opening at all.
Environment
claude --versionon PATH, no version key in~/.claude.json, no install dir under%LOCALAPPDATA%\Programs)What happens
The slash-command autocomplete picker only opens when
/is typed as the very first character of an empty composer. If any text already precedes it, the picker never appears, even when the command sits alone on its own new line.The command is still recognised on submit. So the execution path and the autocomplete path disagree: the app will run a command it refused to help you find.
Steps to reproduce
/— picker opens as expected./wr.Expected
The picker should open for a
/commandat the start of any line in the composer, not only at position 0 of the input. If the submit path recognises a command there, autocomplete should too.Why it matters
Chaining commands in one message is a normal workflow (e.g.
/startupplus a second command in the same send). Today only the first one gets autocomplete support. For any command whose exact slug you don't have memorised, you have to either send it alone first to look it up, or guess. Discovery and typo-checking are lost precisely where a user is least sure of the name.Related but distinct: #78278 (wrong text inserted on selection), #17816 (wrong item highlighted). Those are about the picker misbehaving once open; this is about it not opening at all.