Slash-command picker does not open unless "/" is the first character of the composer, but the command still runs on submit

Environment

• Claude Code app: CLI (terminal)
• OS: macOS 26.6.2 (build 25G83)
• Version: 2.1.243

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

1. Open an empty message box.
2. Type: asdfasdfasdfasdf / asdfasdfasdf
3. Look at the screen. The picker does not open for the "/" in the middle.
4. Send the message. The app runs the command anyway.

Expected

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

• 2025-12-04 — #13073 (closed)
• 2026-03-01 — #29752 (closed)
• 2026-03-18 — #35589 (closed)
• 2026-05-01 — #55173 (closed as "not planned" — a bot closed it for inactivity, not because a fix landed)
• 2026-08-25 — #89398 (open, exact duplicate of this report)

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

• Picker opens only when / is the first character of an empty composer.
• With any preceding text the picker never appears - no list, no filtering, no selection.
• The command is still recognized on submit, so the autocomplete path and the execution path disagree.

Re: "Version: not exposed in UI"

The desktop app does not use the globally installed npm package, which is why claude --version is 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:

C:\Users\<user>\AppData\Roaming\Claude\claude-code\<version>\claude.exe

That directory holds 2.1.235 and 2.1.237 here; 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:

Get-AppxPackage -Name "*Claude*" | Select-Object Name, Version

Name    : Claude
Version : 1.34493.1.0

The app log also records version transitions on launch:

Version changed since last launch: 1.32885.1 -> 1.34493.0

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

Observation, not a claim.

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

• Desktop app: the package folder name, C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc. The WindowsApps directory itself cannot be listed, but a direct path into it resolves fine.
• Bundled Claude Code: 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.

• 1.24012.0.0, installed 21 July: works. The slash suggestion extension takes three arguments, and the string startOfInputOnly does not appear anywhere in that build.
• 1.37937.0.0, installed 25 August 20:05: broken from here on. The extension now takes five arguments, two of them new, skillCommandsOnly and startOfInputOnly. addOptions defaults startOfInputOnly to false, but the composer mount that also passes skillCommandsOnly hardcodes it to true.
• 1.37937.1.0, installed 26 August 09:12: unchanged. The chunk is byte identical to the previous build, confirmed by the two paths sharing a single hard link.

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

• Windows 11 Pro 10.0.26100, Claude Desktop (MSIX), Code tab composer
• App 1.37937.1.0, bundled CLI 2.1.246

Update timeline from %LOCALAPPDATA%\Claude\Logs\main.log:

2026-08-21 09:48:28 [info] [updater] Version changed since last launch: 1.32885.1 -> 1.34493.1
2026-08-26 09:09:06 [info] [updater] Version changed since last launch: 1.34493.1 -> 1.37937.1

This machine sat on 1.34493.1 from 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 to 1.37937.1. So on this machine the breakage tracks the build, not a server-side flip.

Narrowed range: 1.34493.1 working, 1.37937.1 broken.

Independently confirming the flag mechanism on 1.37937.1.0, under app\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 with false:

Wl.create({name:"slash-command-suggestion",addOptions:()=>({placement:"onpage",hostInterceptSurface:!1,skillCommandsOnly:!1,startOfInputOnly:!1,menuComponent:void 0})
...
var Dw=O(!1);function Nw(){return D(Dw)}

c594d9137-Crxagp_e.js -- the composer mount hardcodes it:

Vs.configure({placement:"onpage",hostInterceptSurface:e.hostInterceptSurface??!1,skillCommandsOnly:e.skillCommandsOnly??!1,startOfInputOnly:!0,menuComponent:qr})

Literal !0 at the call site, and no provider for Dw anywhere -- 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

• macOS 15.x, arm64
• Claude desktop app 1.37937.2
• Bundled CLI 2.1.246

Same 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:

slash-command-suggestion",addOptions:()=>({placement:"onpage",hostInterceptSurface:!1,skillCommandsOnly:!1,startOfInputOnly:!1,menuComponent:void 0

c594d9137-5QbG-Gak.js — composer mount hardcodes it true:

configure({placement:"onpage",hostInterceptSurface:e.hostInterceptSurface??!1,skillCommandsOnly:e.skillCommandsOnly??!1,startOfInputOnly:!0,menuComponent:qr})

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 (/fi completes 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

• macOS 27.0 (26A5421a), arm64
• Claude desktop app 1.37937.3
• Bundled CLI 2.1.246 (at ~/Library/Application Support/Claude/claude-code/2.1.246/)
• Separately installed Homebrew CLI 2.1.245, not what the desktop composer uses

Same 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:!0 appears 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 on 1.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:!0 to !1 in the copy (one byte, file size unchanged), and ran the copy with its own --user-data-dir so 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 id YHS8McfgFb), occurs in exactly one chunk across the whole of ion-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:

• Not a remote fetch of the chunks. The profile's HTTP cache contains only cdn-cgi/challenge-platform scripts from claude.ai, no app chunks. Assets are served over the app:// handler the main process installs on the local ion-dist directory.
• Not a stale profile. The --user-data-dir was created fresh for the run.
• Not the bundled CLI. ~/Library/Application Support/Claude/claude-code/2.1.246/claude.app is a single Mach-O binary and contains none of startOfInputOnly, slash-command-suggestion, or Type to filter.

Two practical notes for anyone trying the local edit on macOS

1. Modifying any file under Contents/Resources/ breaks the bundle seal, and the app then fails to launch silently. Not a crash dialog, not a Gatekeeper message: --version simply prints nothing. An unmodified copy of the same bundle in the same directory ran fine, so this is the signature, not the location.
2. Re-signing to get past that has a cost worth knowing before you start. codesign --force --deep --sign - drops TeamIdentifier (Q6L2SF6YDW) and the hardened-runtime flag. The bundle declares keychain-access-groups, so the re-signed copy is treated as a different app and prompts for the login keychain password to reach Claude 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:

Added slash command autocomplete support when / appears anywhere in input, not just at the beginning

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 (startOfInputOnly absent in 1.24012.0.0, present and hardcoded from 1.37937.0.0) and @cyber2e's log-based narrowing to 1.34493.1 working and 1.37937.1 broken.

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.

Confirming this is still present on the current Windows desktop build, and adding a version timeline, since the original report notes the app version is not exposed anywhere findable.

Where the version is available on Windows: %LOCALAPPDATA%\Claude\Logs\main.log contains appVersion: entries on each launch. Extracting first-seen dates from that log on this machine:

| App version | First seen |
|---|---|
| 1.34493.1 | 2026-08-22 |
| 1.40609.0 | 2026-08-29 |
| 1.44121.4 | 2026-09-03 |
| 1.46388.4 | 2026-09-05 |
| 1.49585.0 | 2026-09-08 |

Behavior is unchanged on 1.49585.0 as of 2026-09-09.

Two notes that may help correlate the related reports:

1. The desktop app versions (1.x) and the bundled CLI versions (2.1.x) are separate numbering schemes. #91337 bisects this to CLI 2.1.247 with 2.1.246 as last good. That is not directly comparable to the app versions above, and I have not been able to map one to the other.

1. The Windows and macOS timelines do not line up. #90441 attributes the break to the 2026-08-27 update to 1.40609.0 on macOS. This issue was filed 2026-08-25 on Windows, before 1.40609.0 appeared here (2026-08-29). So on Windows the break appears to predate that version. I am not asserting a specific breaking version from this, only that the two platforms do not appear to have broken on the same one.

Additional inconsistency not covered above: the sent-message renderer and the command parser disagree.

Typing look at /status of the deploy mid-sentence produces no picker and no highlight while composing, as described in this issue. After submitting, the sent message renders /status styled as a command token, in the same blue used for a genuine command invocation. The command does not execute.

So three components apply three different rules to the same text:

• Composer autocomplete: does not recognize it.
• Sent-message renderer: recognizes it and styles it.
• Executor: does not run it.

A deliberate index-0 restriction would be applied consistently across all three. A renderer that styles what the parser declines to execute is what makes this read as intended behavior to a user, which is likely part of why this has been filed several times independently.

One open question on the original report: it states the command is still recognized on submit, using a repro where the command sits alone on a new line. In the inline mid-sentence case above it did not execute. If own-line and inline submits differ, that may be worth splitting out.

bump, coming across the exact same issue.

Yes same here. on mac os x 26.6.2

@AleksBiSonic Claude Desktop version from about screen: Claude 1.52386.6 (612f3f) 2026-09-13T00:45:40.000Z. I'm not sure where to fine the Mac OS equivalent of main.log sorry. I looked in my application support but didn't find a mirrored file there.

Same for me MacOS 26.6.2 - has also been like this for 3 weeks

Thanks to everyone who bisected this. @zola-dev, @cyber2e, @0mar-K and @oyeeamir each found the same two lines independently, and @tupetmen, @cyber2e and @maverick-jackson built the version timeline. I am the original reporter and I have one update: transcript evidence that answers @maverick-jackson's open question about what "still runs on submit" actually means.

1. What the harness does with two commands in one message

On 15/09/26 I typed two lines in the desktop composer, /startup on line 1 and /reskill on line 2, and sent. The raw user turn in the session JSONL is:

<command-message>startup</command-message>
<command-name>/startup</command-name>
<command-args>/reskill</command-args>

One command was expanded. The second line became the first command's argument string.

I then scanned every session transcript on this machine: 137 JSONL files, July to September 2026, 374 user turns that contain a <command-name> block.

• Turns with two or more <command-name> blocks: 0.
• Turns where <command-args> contains another /command: 18. The earliest is 20/07/26 (/startup with args /ads-google-hygiene-check). The latest is 14/09/26.

So on this machine the harness has expanded exactly one command per message in every recorded case since 20/07/26. That predates the picker regression by five weeks. The execution behaviour is not part of the August regression. It is longstanding.

Whether the model then runs the swallowed command is up to the model. In the 15/09 session the model called the reskill skill from the argument text and did not run the startup skill's steps until I asked "confirm full start up complete?" a turn later. I did not check the other 17 cases.

2. Correction to my original report

I wrote that the second command "is picked up and runs." That was the visible outcome. The harness does not recognise it as a command. It passes it as text inside the first command's arguments. Any run of it depends on the model reading that text. That is not reliable, and it is not a command execution path.

3. The position-0 check on the submit side (desktop bundle, read directly)

c099c328d-CyyK55oB.js contains c=/^\/([\w:-]+)(?=\s|$)/.exec(o)?.[1]?.toLowerCase(). The regex is anchored with ^ and has no m flag. It runs against a string o, and the matched name is then checked against a set. I have not traced what o is or what the set contains, so I do not claim what this check decides. The same file contains the global regex /(?<=^|\s)\/(\w[\w:.-]*)(?=\s|$)/g, which matches after any whitespace. I have not traced where that one is used.

4. Related issues

• #70886 "Pasting two slash commands at once folds the second into the first command's arguments" describes the same <command-args> shape. Closed as duplicate by the bot. No human reply.
• #93076 "Allow multiple slash commands on a single line" is the open feature request. No comments.
• #89522 covers picker rendering for a stacked second command. Open, no comments.

5. Two asks

1. Could a maintainer add the regression label here? #91337 carries it. The v2.1.0 changelog line @oyeeamir quoted shows mid-input triggering was a shipped feature.
2. To anyone adding "same here": please include your app version from main.log (Version changed since last launch) and your platform.

Four earlier reports of this were closed without a fix, one by the stale bot. Please do not close this one as stale.

Same on Windows 11 Home (10.0.26200), Desktop app 2.2553.1.0, Claude Code 2.1.229.

Confirming the execution/autocomplete split you describe, with a clean case: typing a second / later in the same line opens nothing, but typing the full skill name by hand and submitting does get parsed — the skill is recognised and its arguments are peeled off correctly. So the parser accepts input the menu never offered to help with, exactly as you found.

The workaround that works here is the one your title implies: move the cursor to the very start of the message and type / there, which does open the menu. The cost is that the new skill is then inserted ahead of the previous one, so composing several in a deliberate order means typing them backwards.

(Filed #95469 for a separate problem sitting below this layer — worth noting only because fixing the menu will not fix that one.)

Re-read the bundle on the 2.x line today, Windows 10, app 2.2553.1.0. @DraftingDreamer already confirmed this build behaviourally above, so the survival itself is not the news. What the code now shows is.

The extension has been actively worked on, and the flag was kept through that work

Every code excerpt in this thread so far, mine included, came from 1.37937.x. Back then addOptions took five arguments. On 2.2553.1.0 it takes eight:

// shared-11-CDihEvbJ.js — the default, unchanged
addOptions(){return{placement:"onpage",hostInterceptSurface:!1,skillCommandsOnly:!1,
  usageCommandIntercept:!1,projectCommandIntercept:!1,projectRail:!1,
  startOfInputOnly:!1,menuComponent:void 0}}

Three options were added since August: usageCommandIntercept, projectCommandIntercept and projectRail. So this is not an untouched file that slipped through a release. Somebody edited this exact addOptions block, and the same composer mount, and left the hardcoded override in place:

// c099c328d-CbkcmYSW.js — the Claude Code composer mount
...skillCommandsOnly??!1,usageCommandIntercept:e.usageCommandIntercept??!1,
   projectCommandIntercept:e.projectCommandIntercept??!1,projectRail:e.projectRail??!1,
   startOfInputOnly:!0,menuComponent:Cs

Everything else is structurally identical to August

One mount hardcodes !0. Two others read it from a React context that still has no provider anywhere in the bundle, so they stay at the !1 default and the menu works mid-input on those surfaces. The chunk names rotated completely (c594d9137-* to c099c328d-*, shared-10-* to shared-11-*), which is why searching by filename across versions does not work. Search the structure instead.

Still nothing on the user side

No setting, no environment variable, no feature gate reaches it. It is a literal at the call site.

The ask is unchanged: leave startOfInputOnly at its own default for the Claude Code composer, or expose it. Given the block was edited three times since August without the override being revisited, it would help to know whether the true is deliberate for this surface or just inherited from a copy of another mount.

Follow-up: partially fixed in a newer build, but the autocomplete part is still only half done.

Environment

• Windows 11 Pro 10.0.26200, Claude desktop app (MSIX), Code tab composer
• App 2.9939.2.0, bundled CLI 2.1.281

Slash commands are now recognized anywhere in a message, not just at position 1, and the picker now opens mid-message. Thanks for that. But the picker behaves differently when the command is not the first thing in the message.

Current behavior when the command is NOT at position 1

• Typing /wrap opens the suggestion list, and /wrap-up shows as a match.
• Nothing in the list is highlighted or pre-selected.
• Pressing Enter sends the message with the half-typed /wrap. The suggestion is never accepted, so no command runs.

When the command IS at position 1, the top match is highlighted and Enter fills in /wrap-up as expected.

Expected
The same autocomplete behavior at any position. If commands are recognized anywhere in the message, the picker should work anywhere too: pre-select the top match, and have Enter or Tab complete the command rather than send the message.

Repro

1. Type some text, then /wrap.
2. The suggestion list shows /wrap-up with no highlight.
3. Press Enter. The message sends with /wrap and the command does not run.