[BUG] `/` no longer opens the slash-command menu mid-message — only at index 0 (regressed in 2.1.247, last good 2.1.246)

Still present on desktop 1.46388.4 (2026-09-05) — and this release edited the exact line without changing the flag

Environment

• Claude desktop app 1.46388.4, macOS 26.6.2 (25G83), arm64
• app.asar mtime 2026-09-05 02:07 local; bundled CLI dirs 2.1.258, 2.1.260; npm CLI on PATH 2.1.261

Adding this because it is a newer build than anything reported so far (previous reports top out at 1.37937.x / 1.40609.0), and because of what changed between them.

The bundle really was rebuilt

Every asset filename and hash under Contents/Resources/ion-dist/assets/v1/ is different from 1.40609.1:

| | 1.40609.1 | 1.46388.4 |
|---|---|---|
| composer mount | cd089cf92-CPpbZ5h_.js | c099c328d-Bo-ro4Ku.js |
| extension | shared-11-BFWs2XIz.js | shared-12-RJIRw5sU.js |

The extension's addOptions was also refactored from an arrow property to a method (addOptions:()=>({…}) → addOptions(){return{…}}), so this is a real rebuild, not a repackage.

The configure() call itself was edited in this release — and still hardcodes the flag

// c099c328d-Bo-ro4Ku.js — composer mount
configure({placement:"onpage",hostInterceptSurface:we,skillCommandsOnly:e.skillCommandsOnly??!1,
  usageCommandIntercept:e.usageCommandIntercept??!1,
  projectCommandIntercept:e.projectCommandIntercept??!1,   // new in this build
  projectRail:e.projectRail??!1,                           // new in this build
  startOfInputOnly:!0,                                     // unchanged
  menuComponent:no})

// shared-12-RJIRw5sU.js — extension default, still false
name:"slash-command-suggestion",addOptions(){return{placement:"onpage",hostInterceptSurface:!1,
  skillCommandsOnly:!1,usageCommandIntercept:!1,projectCommandIntercept:!1,projectRail:!1,
  startOfInputOnly:!1,menuComponent:void 0}}

Two new options were threaded through this exact argument list in this release, each with the e.x??!1 pass-through shape used by every other option. startOfInputOnly is the only one that is a bare literal. startOfInputOnly:!0 occurs exactly once in all of ion-dist.

The option is designed to be dynamic

The gate resolves it as a callable:

(typeof o=="function"?o():o)&&(t.from!==1||e.doc.firstChild?.type!==e.schema.nodes.paragraph)||t.to-t.from>51)return!1

So it accepts a function and can be decided per-keystroke — it just never is, because the only mount site passes a literal true. Combined with the extension's own default of false, this reads like a value that was meant to be conditional and got pinned.

Not asking for a behavioural decision here — just noting that the line has been in the diff twice now (1.40609.x, 1.46388.4) and passed over both times. If mid-input triggering is being kept off deliberately, a one-line note would let ~20 open reports be closed; if not, the fix is the literal.

Still present on desktop 1.52386.3 — and the sibling mounts in the same bundle pass the flag dynamically, which makes the hardcoded !0 look accidental

Environment

• Claude desktop app 1.52386.3, macOS 26.6.2 (25G83), arm64
• app.asar mtime 2026-09-11; npm CLI on PATH 2.1.270

Adding this because it is a newer build than anything reported so far (the last comment tested 1.46388.4), and because there is a detail in this bundle I have not seen mentioned yet.

The flag survived another rebuild

Asset filenames have rotated again since 1.46388.4, so this is a fresh build, and the value is unchanged:

| | 1.46388.4 | 1.52386.3 |
|---|---|---|
| composer mount | c099c328d-Bo-ro4Ku.js | c099c328d-CyyK55oB.js |
| extension | shared-12-RJIRw5sU.js | shared-13-D4O01Gj8.js |

// c099c328d-CyyK55oB.js - composer mount
configure({placement:"onpage",hostInterceptSurface:Ne,skillCommandsOnly:e.skillCommandsOnly??!1,
  usageCommandIntercept:e.usageCommandIntercept??!1,
  projectCommandIntercept:e.projectCommandIntercept??!1,
  projectRail:e.projectRail??!1,
  startOfInputOnly:!0,                  // still hardcoded
  menuComponent:No})

The new part: two other mounts in the same build pass it dynamically

shared-13-D4O01Gj8.js contains two further configure() call sites for the same extension, and neither hardcodes anything:

uO.configure({placement:T,startOfInputOnly:Oe,menuComponent:j})   // Oe = J(()=>De), De = fO()
uO.configure({placement:n,startOfInputOnly:M,menuComponent:d})    // M  = J(()=>j),  j  = fO()

Both read the value from a context that defaults to false:

var dO=F(!1);function fO(){return S(dO)}

I could not find any dO.Provider in the bundle, so as shipped those two surfaces resolve startOfInputOnly to false.

And the plugin does honour the option - it is threaded straight into the suggestion wiring:

this.options.usageCommandIntercept??!1,this.options.projectCommandIntercept??!1,
this.options.projectRail??!1,this.options.startOfInputOnly??!1,this.editor,e)

So the option is plumbed correctly end to end, the extension's own addOptions() default is !1, two of the three mounts pass it dynamically, and exactly one mount - the one behind the composer people actually type into - passes a literal !0. Every sibling flag on that same call uses the e.X??!1 pattern; startOfInputOnly is the only one that ignores e. That reads much more like a leftover literal than a deliberate product decision, though obviously you can settle that from the source in a second.

Why it stings

The distinction in the original report between invocation and discovery is the whole problem. Invocation is fine - a skill named in full mid-message still runs. But on an install with a few hundred skills in ~/.claude/skills/, index-0-only turns the menu from discovery into recall: you have to already know the exact name of the thing you wanted to find. The menu is the only affordance that makes a large skill library usable, and it is reachable only when the message is empty, which is exactly when you have not yet decided what you are asking for.

The word-boundary behaviour proposed in the original report (/ after start, whitespace or newline; silent inside src/utils, and/or, http://) would restore that without reintroducing whatever the literal was guarding against.

Opened #95735 with a consolidated write-up of this behaviour on Windows desktop 2.2553.1.0.

It carries the two rules (/ works only as the first character of an empty composer; anything before it, even a single space or an already accepted /skill, means the list never opens), six verbatim changelog lines including the 2.1.0 entry that added mid-input completion, a first-hand check, a proposed trigger rule, and a runnable reference implementation with 100 passing tests.

Linking rather than duplicating. A thumbs-up there keeps the signal in one place.