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

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).

1. Continue briefly.
2. Observe that the entire app exits and all Codex/ChatGPT processes disappear.
3. 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.