Slash-command picker does not open unless "/" is the first character of the composer, but the command still runs on submit
Environment
- Claude Code desktop app, Windows 11 Home (10.0.26200)
- Version: not exposed anywhere I could find on this surface (no
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
- 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.
7 Comments
Environment
Summary
The slash-command picker opens only when the user types "/" as the first character in an empty message box. If text comes before the "/", the picker does not open. This is true even when spaces separate the text from the "/". The command still runs when the user sends the message. So the app runs a command it did not help the user find or check for spelling errors.
Steps to reproduce
asdfasdfasdfasdf / asdfasdfasdfExpected
The picker should open for any "/" that could start a command name, not only at the first character of the message.
Actual
The picker does not open for a "/" that is not the first character of the message. The app does not filter commands. The app does not highlight a command.
Why it matters
A user can type a command name wrong with no warning. This blocks a normal way of writing: add context first, then add a command. Example: "please also /command-name this."
History — other users reported this same bug many times before
Do not close this issue as stale. This is a real, unfixed bug. Contact the reporter for more repro steps if needed.
Confirming this on Windows 11, Claude Code desktop app.
Same behavior
/is the first character of an empty composer.Re: "Version: not exposed in UI"
The desktop app does not use the globally installed npm package, which is why
claude --versionis misleading - on my machine it reports a much older, unrelated version from%APPDATA%\npm\node_modules\@anthropic-ai\claude-code.The version that actually matters is the CLI embedded in the app:
That directory holds
2.1.235and2.1.237here; the running process is 2.1.237.The app itself ships as an MSIX package from the Microsoft Store, so its version comes from PowerShell:
The app log also records version transitions on launch:
in
C:\Users\<user>\AppData\Local\Claude\Logs\main.log- handy for pinning down when a regression landed.Environment
| | |
| --- | --- |
| OS | Windows 11 Pro 10.0.26200 |
| App | Claude Code desktop, MSIX from Microsoft Store |
| App version |
1.34493.1.0|| Embedded CLI |
2.1.237|| Install channel | Store auto-update (
[CCD-autoupdate] Disabled: MSIX install) |Timeline note
I am fairly confident the picker did open mid-message until around Aug 24, and stopped on Aug 25. My app has not been updated since Aug 21, 10:36 (MSIX install timestamp), so if the behavior did change on Aug 24/25, it was not caused by a local update on my side.
@tupetmen @AleksBiSonic Hi, has anyone found a solution to this issue yet? I'm thinking of rolling back versions.
Same behaviour on Windows 10 in the Claude Code composer. Adding the version bisection and the flag behind it, since the report says the version is not exposed on this surface and someone above is considering a rollback.
Where the versions actually are on Windows
C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc. The WindowsApps directory itself cannot be listed, but a direct path into it resolves fine.C:\Users\<you>\AppData\Roaming\Claude\claude-code\<version>\claude.exe.Bisection
Windows keeps the previous packages, so the older builds are still readable and this is reproducible.
startOfInputOnlydoes not appear anywhere in that build.skillCommandsOnlyandstartOfInputOnly.addOptionsdefaultsstartOfInputOnlyto false, but the composer mount that also passesskillCommandsOnlyhardcodes it to true.Two things that suggest the default was meant to stay false
The same file still carries a mid-input matcher for the slash token, used in
handleScrollToSelection. And@mentions still open mid-input in the same composer, so only/changed.No user-side workaround
The value is a literal in the bundle. There is no provider for the React context the other two mount sites read, and no setting, environment variable or feature gate controls it. I checked all three.
For context on why this matters beyond convenience: I have 93 project skills of my own, and I cannot recall their exact names. Filtering in the menu was how I reached them, so gating the picker to position 0 removes name completion exactly where it was carrying the most weight.
Confirming, and adding a data point that tightens @zola-dev's bisection and conflicts with the "changed on Aug 24/25 without a local update" note above.
Environment
1.37937.1.0, bundled CLI2.1.246Update timeline from
%LOCALAPPDATA%\Claude\Logs\main.log:This machine sat on
1.34493.1from Aug 21 through Aug 26 09:09, i.e. straight across the Aug 24/25 window. The mid-input picker was still working here during that period (user recollection, not instrumented -- treat as soft) and broke immediately after the 09:09 update to1.37937.1. So on this machine the breakage tracks the build, not a server-side flip.Narrowed range:
1.34493.1working,1.37937.1broken.Independently confirming the flag mechanism on
1.37937.1.0, underapp\resources\ion-dist\assets\v1\.shared-10-DNNUIVVF.js-- extension default is false, and the two mounts in that file read it from a React context created withfalse:c594d9137-Crxagp_e.js-- the composer mount hardcodes it:Literal
!0at the call site, and no provider forDwanywhere -- which matches @zola-dev's read that no setting, env var or gate can reach this from the user side.Confirming on macOS, with bundle evidence and a note on the CLI.
Environment
1.37937.22.1.246Same flag, same hardcoding, different asset filename
@zola-dev's and @cyber2e's reading holds on the macOS bundle. Under
/Applications/Claude.app/Contents/Resources/ion-dist/assets/v1/, the hashes differ but the code is the same:shared-10-BqfmBy1p.js— extension default is false:c594d9137-5QbG-Gak.js— composer mount hardcodes it true:The literal appears exactly once in that file.
Scope: the terminal CLI is not affected
Worth separating, since the two surfaces get conflated. In the standalone terminal CLI, a mid-message slash still produces single-candidate inline completion (
/ficompletes to/file-bug, Tab accepts). I checked 2.1.150 from the npm cache and 2.1.247, and both behave the same, so the CLI has not regressed. This looks specific to the desktop composer.@inputoutput9 above reports this on the macOS CLI at 2.1.243. I want to be careful not to overstate the disagreement: the picker indeed does not open mid-message in the CLI. What I could not reproduce is a change there. Both 2.1.150 and 2.1.247 behave identically, so on my machine the CLI looks like a long-standing gap rather than part of this regression.
To be precise about what the CLI does and does not give you: it is inline ghost text, not the picker. Up, Down and a repeated Tab all leave the single candidate unchanged, so it does not substitute for the menu when you cannot recall a skill name.
Workaround on macOS
Editing that one literal back to the extension's own default restores the picker until the next app update overwrites it.
Confirming on macOS, and adding a build newer than the ones reported so far, plus a negative result on the workaround in @0mar-K's comment.
Environment
1.37937.32.1.246(at~/Library/Application Support/Claude/claude-code/2.1.246/)2.1.245, not what the desktop composer usesSame flag, third set of asset hashes
The reading in the comments above holds here. Under
/Applications/Claude.app/Contents/Resources/ion-dist/assets/v1/:shared-10-Dd7y3BVf.js— extension default is false:addOptions:()=>({placement:"onpage",hostInterceptSurface:!1,skillCommandsOnly:!1,startOfInputOnly:!1,menuComponent:void 0})c594d9137-CYdid7X9.js— composer mount hardcodes it:Vs.configure({placement:"onpage",hostInterceptSurface:e.hostInterceptSurface??!1,skillCommandsOnly:e.skillCommandsOnly??!1,startOfInputOnly:!0,menuComponent:qr})startOfInputOnly:!0appears exactly once in that file. Three platforms, three different asset hashes, same two lines.Editing the literal did NOT restore the picker on this build
@0mar-K reports that editing the literal back to the default works on
1.37937.2. It did not work here on1.37937.3, and I want to record the negative result with the method, because I could not explain it and someone with more context might.Method: I copied the app bundle, changed
startOfInputOnly:!0to!1in the copy (one byte, file size unchanged), and ran the copy with its own--user-data-dirso it could not collide with the installed app.To check whether the copy was reading its own assets at all, I also replaced the slash menu's placeholder string with a marker. That string,
"Type to filter"(message idYHS8McfgFb), occurs in exactly one chunk across the whole ofion-dist, and it is the same chunk that carries the extension default. After patching, the copy's file contained the marker and zero occurrences of"Type to filter".The running patched copy displayed
Type to filter, and the picker still opened only at position 0. So the process was not using the patched chunk. I could not determine what it was using instead. What I ruled out:cdn-cgi/challenge-platformscripts from claude.ai, no app chunks. Assets are served over theapp://handler the main process installs on the localion-distdirectory.--user-data-dirwas created fresh for the run.~/Library/Application Support/Claude/claude-code/2.1.246/claude.appis a single Mach-O binary and contains none ofstartOfInputOnly,slash-command-suggestion, orType to filter.Two practical notes for anyone trying the local edit on macOS
Contents/Resources/breaks the bundle seal, and the app then fails to launch silently. Not a crash dialog, not a Gatekeeper message:--versionsimply prints nothing. An unmodified copy of the same bundle in the same directory ran fine, so this is the signature, not the location.codesign --force --deep --sign -dropsTeamIdentifier(Q6L2SF6YDW) and the hardened-runtime flag. The bundle declareskeychain-access-groups, so the re-signed copy is treated as a different app and prompts for the login keychain password to reachClaude Safe Storage. I stopped there rather than granting a locally modified binary access to that item, and would suggest others do the same.On the timeline
The v2.1.0 changelog (2026-01-07) has this line:
So mid-input triggering was an intentional feature, which supports reading the current state as a regression rather than a scope decision. Combined with @zola-dev's bisection (
startOfInputOnlyabsent in1.24012.0.0, present and hardcoded from1.37937.0.0) and @cyber2e's log-based narrowing to1.34493.1working and1.37937.1broken.Also noting the four earlier reports listed at the top of this thread were all closed without a fix, one of them by a staleness bot.