[Windows][Desktop] Typing `/` crashes MSIX-launched Codex with Chromium breakpoint exception

Summary

On Windows, typing the forward slash character (/) into the Codex desktop app composer deterministically terminates the entire application. The same crash occurs with a physical keyboard and Windows On-Screen Keyboard.

Debugger and runtime testing isolate the failure to the Microsoft Store/MSIX package-identity launch context. The identical packaged executable renders the slash-command menu successfully when launched directly without MSIX package identity.

Environment

• Microsoft Store package: OpenAI.Codex 26.803.10989.0
• Internal app release: 26.803.81509
• Executable: ChatGPT.exe
• Electron: 42.3.0
• Chromium: 151.0.7922.76
• Architecture: x64
• Platform: Windows

Reproduction

1. Launch Codex normally through the installed Microsoft Store/MSIX app entry.
2. Focus the task composer.
3. Type /.
4. The entire application exits immediately.

The crash is deterministic.

Expected behavior

Typing / should open the slash-command menu.

Actual behavior

The browser process terminates immediately with no visible error dialog.

Input and third-party-software exclusions

The failure was reproduced using:

• A Keychron physical keyboard.
• Windows On-Screen Keyboard.
• Windows On-Screen Keyboard after unplugging the Keychron keyboard and YubiKey.

DisplayFusion was initially installed and had injected its hook DLL. It was then fully uninstalled; its processes, services, and loaded modules were verified absent. The crash remained unchanged.

Other trigger characters work:

• @ opens its panel normally.
• $ opens its panel normally.

This indicates that general keyboard input and general composer-panel creation work. The failure is specific to the slash-command path.

Crash evidence

Crashpad sidecars are created at each reproduction and identify a browser-process crash:

{"capture_kind":"crash","osarch":"x86_64","ptype":"browser"}

The normal application log ends abruptly without a JavaScript exception or stack trace.

WinDbg result

Attaching WinDbg/CDB to the main browser process and typing / captures a deterministic breakpoint exception:

Exception code: 0x80000003 (breakpoint)
Module: chrome.dll
Instruction: chrome.dll+0x9362037
Failure bucket: BREAKPOINT_80000003_chrome.dll!Unknown
Failure hash: {be0d4058-7058-b7fb-5291-62cb1f25d882}
WER process version: 151.0.7922.76

The stack passes through:

USER32!UserCallWinProcCheckWow
USER32!DispatchMessageWorker
chrome.dll frames
ChromeMain
ChatGPT.exe

This is a Chromium deliberate breakpoint/CHECK-style termination in the Windows message loop, rather than an access violation, out-of-memory condition, or project subprocess failure. Public symbols were insufficient to resolve the internal Chromium assertion.

Static analysis of the packaged application

The packaged app.asar was extracted and the composer command code inspected.

The ProseMirror matcher classifies:

• / as slash-command
• @ as at-mention
• $ as skill-mention

The registry selects slash commands using the equivalent of:

commands.filter(command =>
  (command.triggers ?? ["/"]).includes(trigger)
)

Because / is the default trigger, it selects all commands whose triggers property is omitted. No obviously malformed static definition was found.

Live renderer inspection

A second isolated instance was launched with Chromium remote debugging, and a source breakpoint was placed at the slash-command registry filter.

The live registry contained 12 commands:

service-tier:priority
feedback
goal
mcp
memories
model
pet
plan-mode
reasoning
status
usage
project

All entries had:

• unique string IDs
• string titles
• valid icon functions
• valid submenu structures

No duplicate or malformed command data was observed.

Decisive control experiment: MSIX identity

The packaged executable was launched directly with an isolated user-data directory and --disable-features=ProcessSingleton, instead of through the Microsoft Store/MSIX application entry.

In that directly launched instance:

• The same account/session was available.
• The same 12-command slash registry loaded.
• Typing / rendered the command menu correctly.
• The application did not crash.

Returning to the normally MSIX-launched app reproduced the crash immediately.

Therefore the current evidence indicates:

same binary + same account + same slash-command registry
MSIX-launched                    -> crash
direct executable, no identity   -> works

Probable failure area

A Chromium/Electron native Windows CHECK appears to be triggered during the slash-menu window/message transition only when the process has the Codex MSIX package identity.

This does not appear to be:

• a keyboard/HID problem
• a DisplayFusion hook problem
• a generic popup-rendering problem
• malformed slash-command registry data
• a project or shell subprocess crash

Workaround

Launching the packaged ChatGPT.exe directly, outside the MSIX app activation path, avoids the crash in testing. The executable path is version-dependent, so this is only a temporary workaround.

Suggested engineering investigation

1. Symbolize chrome.dll+0x9362037 for Chromium 151.0.7922.76.
2. Inspect CHECK/ASSERT paths reached from the Windows message loop when opening the slash-command UI under package identity.
3. Compare HWND ownership, activation, popup, input-method, and app-identity behavior between MSIX activation and direct executable launch.
4. Reproduce using the Store package while entering / in the composer.
5. Test whether a newer Electron/Chromium build changes the behavior.

Privacy

Usernames, local paths, project contents, prompts, credentials, and raw logs have intentionally been omitted. Additional debugger output can be provided after privacy review.