[Windows Desktop 26.721] Per-key composer input terminates CrBrowserMain at fixed chrome.dll breakpoint

Start by reproducing per-key composer input on Windows with physical or on-screen keyboard, then inspect the Crashpad reports under %APPDATA%\Codex\web\Codex\Crashpad\reports and the desktop log around method=thread/start. Compare those results with mouse right-click paste and batch voice input; done means keyboard and IME typing no longer terminates the desktop process and the regression is covered by an appropriate check.

What version of the Codex App are you using (From “About Codex” dialog)?

• Codex app release: 26.721.81911
• Microsoft Store/MSIX package: OpenAI.Codex_26.721.11231.0_x64__2p2nqsd0c76g0
• Bundled Chromium: 150.0.7871.128

What subscription do you have?

ChatGPT subscription (authenticated through the desktop app).

What platform is your computer?

• Windows 10 Enterprise LTSC x64
• Build 19044.7548
• Intel Core i7-6700HQ, 16 GB RAM

What issue are you seeing?

Codex Desktop fully exits when text is entered into the composer one key at a time. This is a native main-process crash, not merely input lag or a renderer freeze: after the window disappears, no Codex/ChatGPT process remains.

Three independently reproduced Crashpad dumps all have the exact same signature and stack offsets:

Crash reason: EXCEPTION_BREAKPOINT
Crashing thread: CrBrowserMain
Crash instruction: int 0x3
chrome.dll + 0x96e98c7
chrome.dll + 0x96e9c32
chrome.dll + 0x96e9f3d
chrome.dll + 0x39f88e1

The process uptimes in the captured dumps were 188 seconds, 140 seconds, and 57 seconds. The fixed EXCEPTION_BREAKPOINT in CrBrowserMain suggests a Chromium/Electron fatal check rather than a random access violation.

The trigger is associated with per-key input events, not the resulting text:

• Physical keyboard typing reproduces the crash.
• Windows On-Screen Keyboard (osk.exe) also reproduces it, ruling out the physical keyboard and its hardware driver.
• Microsoft English input reproduces it.
• Microsoft Pinyin reproduces it.
• Both new and existing conversations reproduce it.
• Composing text in Notepad and inserting it with mouse right-click Paste does not reproduce it.
• Voice dictation, which commits text in a batch, usually does not reproduce it (one intermittent exit was observed).
• Remote use does not normally reproduce it because it bypasses the local composer input path.

This appears related to #29543, but the severity differs: in this case Codex does not buffer input and recover; the entire desktop main process terminates and produces a Crashpad dump.

What steps can reproduce the bug?

1. Launch Codex Desktop on Windows.
2. Open either a new conversation or an existing conversation.
3. Focus the composer.
4. Type several English characters one at a time using either:
   • a physical keyboard, or
   • Windows On-Screen Keyboard (osk.exe).
5. Continue briefly.
6. Observe that the entire app exits and all Codex/ChatGPT processes disappear.
7. Observe a new dump under:

%APPDATA%\Codex\web\Codex\Crashpad\reports

Control:

1. Type the same text in Notepad.
2. Copy it.
3. Use the mouse context menu to paste it into the Codex composer, without pressing Ctrl+V.
4. The app remains running.

What is the expected behavior?

Typing should update the composer without terminating the Electron/Chromium main process. Physical, on-screen, IME, dictated, and pasted text should all be accepted safely.

Additional information

Troubleshooting and controlled isolation already completed:

1. Removed the user-level ELECTRON_FORCE_RENDERER_ACCESSIBILITY environment variable and rebooted Windows.
2. Completely uninstalled Tencent WeType/WeChat Input and rebooted Windows.
3. Reproduced with Microsoft English input after uninstall.
4. Parsed the third Crashpad dump and verified that it contains no WeType modules (wetype_tip.dll, wetype_tip_core.dll, or CrashRpt1500.dll).
5. Verified that the accessibility environment variable is absent.
6. Verified that no other non-Microsoft input module is present in the third dump.
7. Tested physical keyboard, OSK, right-click paste, Microsoft English, Microsoft Pinyin, new conversations, and existing conversations.
8. Available RAM was healthy; this was not an OOM event.
9. Windows Event Viewer did not record a conventional Application Error event, but Codex Crashpad consistently captured the native main-process termination.

In a new-conversation reproduction, the desktop log showed the first-text path reaching:

method=thread/start durationMs=318

before the later main-process exit. However, existing conversations also reproduce, so new-thread prewarming is not the complete trigger. The strongest differential signal is per-key input versus batch insertion by mouse paste.

The raw .dmp files are not attached publicly because process-memory dumps may contain private conversation text, account data, and local paths. I can provide a dump privately to an OpenAI maintainer if a secure upload channel is available.