Ctrl+C and other Ctrl shortcuts don't work on Windows with a non-Latin keyboard layout
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 68/100
Research direction
Read codex-rs/Cargo.toml, Cargo.lock, and MODULE.bazel.lock to see how Codex pins its crossterm fork. The reported fix is in crossterm PR 1156; check whether the fork includes it, then update the pins and verify Ctrl+letter shortcuts with Russian and Armenian layouts. Done means those shortcuts work across layouts.
Written by the indexing model from the issue text.
Description
What version of Codex CLI is running?
codex-cli 0.163.0
What subscription do you have?
Not relevant to terminal input handling.
Which model were you using?
Not model-dependent.
What platform is your computer?
Windows 11 Pro 10.0.26300, x86_64
What terminal emulator and version are you using (if applicable)?
Windows Terminal 1.24.12741.0
Native Windows Codex, not WSL. The same keys work under WSL.
Codex doctor report
Not collected. The failure is in the keyboard-event parser Codex pins.
What issue are you seeing?
With a Russian or Armenian keyboard layout active, Ctrl+C is not recognized by the Codex TUI on
Windows. Ctrl+D, Ctrl+R, Ctrl+T and the other Ctrl+letter shortcuts fail the same way. Switching
to an English layout makes them work again.
Windows delivers Ctrl+C as a console key record whose character is the control code 0x03. The
pinned crossterm (openai-oss-forks/crossterm@ed1cdab) sends every control code through
get_char_for_key, which looks the key up in the active layout with no modifiers. Under a
non-Latin layout that returns the layout's character or nothing, so no binding matches. A probe
that prints crossterm's event::read() recorded these Ctrl+C presses:
| Layout | Reported by the pinned crossterm | Reported with the fix |
|---|---|---|
| English | Char('c') + CONTROL |
Char('c') + CONTROL |
| Russian | no event | Char('c') + CONTROL |
| Armenian | Char('ց') (U+0581) + CONTROL |
Char('c') + CONTROL |
This is the Windows counterpart of #35599, which covers the same symptom from the kitty keyboard
protocol on Linux and macOS. The two paths are separate: #35599 needs the base-layout key from
crossterm#1074, and this one is fixed in crossterm's Windows parser.
What steps can reproduce the bug?
- On Windows, add a Russian keyboard layout and switch to it.
- Run
codex. - Press Ctrl+C, or Ctrl+D with an empty composer.
- Nothing happens. With an English layout, the same keys show the quit hint or quit.
At the parser level: a key record with u_char = 0x03, LEFT_CTRL_PRESSED and virtual key
0x43 is looked up in the active layout instead of being reported as Ctrl+C.
What is the expected behavior?
Ctrl+letter shortcuts work whatever keyboard layout is active, as they do on an English layout
and under WSL.
Additional information
Fix in crossterm: https://github.com/crossterm-rs/crossterm/pull/1156
When Ctrl is held without Alt, the parser reports Ctrl+A to Ctrl+Z by their control codes
(0x01..=0x1a) instead of going through the layout lookup. Armenian sends Ctrl+Shift+letter with
no character, so for those records the letter comes from the virtual key.
The table above comes from a probe built on the pinned crossterm before and after the fix. A Codex
build with the patched crossterm was also checked by hand under the Russian and Armenian layouts.
For Codex, the change is a crossterm pin bump in codex-rs/Cargo.toml, Cargo.lock and
MODULE.bazel.lock once the fork includes it.
- Dominant language
- Rust
- Stars
- 130k
- Forks
- 20.5k
- Avg merge
- 1m
- Merged PRs (30d)
- 998
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from openai/codex
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
app-server documentation
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
app bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
openai/codex#55328 · 1 comment ·
Maintainers usually reply within 1 day
-
bug CLI
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
openai/codex#55122 · 2 comments ·
Maintainers usually reply within 1 day
-
Python SDK: CodexClient.close() leaves the app-server's stdout/stderr pipes open (and never waits after kill)Possibly taken @akhil9tiet claimed this 4 days ago. Openapp-server bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
openai/codex#54908 · 2 comments ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
chrisdickinson/trivia#26 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 66/100