Slash command menu stops triggering after first use in a draft (Windows desktop app, Korean input)

Bug Report: Slash command menu fails to re-trigger in composer (Windows, Korean input)

Environment

• Claude Desktop (Windows): app 1.25927.0.0 (MSIX, Claude_pzs8sxrjxfjjc), Claude Code CLI 2.1.221
• OS: Windows 11 Pro 10.0.26200
• User input: Korean + English toggle (Microsoft IME), heavy daily use
• Reproduced under BOTH the legacy ("previous version") Microsoft IME and the

current/new Microsoft IME, and across app restarts

Summary

The slash command menu reliably opens for the FIRST / typed in an empty composer,
but frequently never opens again for subsequent / typed later in the same draft
(typically after a command chip has been inserted and free text — especially Korean —
has been typed). The user perceives slash commands as "broken; only works once."
Restarting the app clears the state. Fully typed commands still execute when sent,
proving only the trigger/menu is blocked, not command dispatch.

Evidence collected

1. Trigger-level failure, not rendering. During a failing window

(2026-08-25 20:20–20:29 KST), main.log shows zero
LocalAgentModeSessions.getSupportedCommands calls despite many / attempts —
the menu component never mounted, so the suggestion trigger itself never fired.
Immediately after an app restart (20:29:50), a call appears again at 20:30:34.

1. IME ruled out as sole cause. Initial suspicion was IME-injected zero-width

characters defeating the allowedPrefixes: [" "] prefix check. This was tested
directly: in a plain Chromium contenteditable probe on the same machine, typing
Korean + space + / with the new Microsoft IME produced no zero-width or
exotic characters (U+200B–U+200D, U+2060, U+FEFF etc.) and a fully clean
compositionstart/update/end sequence. The bug also persisted after switching
from the legacy IME to the new IME and restarting the app. (Broken-jamo artifacts
like 그리고나거ㅗ were observed in the composer under the legacy IME, so
ProseMirror-specific composition handling may still contribute, but plain-DOM
IME output is clean.)

1. Leading suspicion is editor-internal suggestion state, e.g.:

• dismissedTriggerFrom blocking a position after a dismiss (outside click /

focus loss such as the Win+Shift+S screenshot overlay counts as a dismiss),
invisible and unrecoverable to the user until the / is deleted;

• the suggestion plugin's active/composing state machine getting stuck after

chip insertion + IME text in the same draft (app restart clears it).

1. Compounding UX issues observed live:

• When the filter query matches 0 commands, the menu renders null (no

"no results" row). Users read this as "menu broken", mash /, and then
press Enter — which selects the highlighted item instead of sending,
causing accidental command launches (/ultrareview, /schedule were launched
unintentionally this way; both returned "isn't available in this environment").

• A / typed directly after any non-space character (including another /)

never triggers by design, so rapid retries all silently fail.

Repro (as experienced)

1. Open a Claude Code session in the desktop app (Korean IME active).
2. In the empty composer type / → menu opens (OK). Select any command → chip inserted.
3. Type Korean free text after the chip, then a space, then /.
4. Menu frequently does not open. Retyping / repeatedly never helps.

Ctrl+A → Delete → / works again (fresh input). App restart also clears it.

Suggested fixes

• Audit the suggestion plugin's state (dismissedTriggerFrom, active/composing

flags) for paths where it wedges for the lifetime of the draft/window.

• Do not treat focus loss (screenshot overlays, alt-tab) as an intentional dismiss;

consider clearing dismissedTriggerFrom on focus regain.

• Render an explicit "no matching commands" empty state instead of hiding the menu.
• Still worth hardening: treat zero-width characters as whitespace in the prefix

check, and audit ProseMirror composition handling for Korean IME (broken jamo).

---

(한국어 요약)

증상

빈 입력창의 첫 /는 100% 메뉴가 뜨지만, 명령 칩 + 한글 텍스트 입력 뒤의 /는
메뉴가 시동조차 걸리지 않는 경우가 잦음. 앱 재시작 시 해소. 명령어를 끝까지 치고
전송하면 실행은 됨(트리거만 죽음).

근거

• 실패 구간(2026-08-25 20:20~20:29) 동안 main.log에 명령 목록 요청 0건 →

메뉴가 "떴는데 비어 보인 것"이 아니라 트리거 자체가 차단됨.

• 입력기(IME)는 단독 범인이 아님: 같은 PC의 일반 브라우저 입력창에서

한글+스페이스+/ 입력 시 유령 문자 0건, 조합 이벤트 완전 정상.
구버전→신버전 IME 교체 + 앱 재시작 후에도 증상 지속.

• 유력 원인: 에디터 내부 제안(suggestion) 상태 꼬임 — 포커스 이탈을 '닫기'로

처리해 해당 위치를 계속 차단하는 dismissedTriggerFrom 등. 사용자에게는
보이지 않고 복구 불가.

• 부수 문제: 검색 결과 0개일 때 메뉴가 안내 없이 사라짐, 메뉴 열린 상태의 Enter가

전송 대신 항목을 선택해 의도치 않은 명령 실행 발생.

요청

suggestion 상태 머신 점검(칩+한글 입력 후 고착 경로), 포커스 이탈을 '의도적
닫기'로 처리하지 않기, "결과 없음" 표시 추가, 폭 0 문자 공백 취급 및
한글 IME 조합 처리 보강.