Windows Alt-code input (Alt+0151) unexpectedly opens a new chat

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

Installed Windows package version: 26.908.4834.0 (read from the installed package; not the About dialog).

What subscription do you have?

Not specified in this report.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

In Codex Desktop on Windows, attempting to enter an em dash using the Windows Alt code Alt+0151 unexpectedly takes me to a new chat instead of inserting the character in the current message.

What steps can reproduce the bug?

1. Open an existing chat in Codex Desktop on Windows.
2. Focus the message composer.
3. Attempt to type an em dash using Alt+0151 (hold Alt, enter 0, 1, 5, 1 on the numeric keypad, then release Alt).
4. Observe that the app navigates to a new chat instead of inserting the character.

What is the expected behavior?

The em dash character (—, U+2014) should be inserted at the cursor, and the current chat should remain open. Application keyboard shortcuts should not intercept Windows Alt-code text entry while the message composer is focused.

Additional information

This describes the user's observed behavior and was translated and submitted with their explicit permission. The issue has not been independently reproduced by the assistant; the specific shortcut responsible has not been determined.

Related report: #40260 concerns Alt-code input in the CLI/TUI. This report concerns the Windows desktop app and the additional navigation to a new chat.

Start by reproducing the issue in Codex Desktop on Windows with an existing chat and the message composer focused. Investigate the keyboard shortcut handling involved in navigation to a new chat; done means Alt+0151 inserts U+2014 at the cursor and leaves the current chat open, with regression coverage if the project provides a relevant test location.