/keymap can save `minus`, but config loading rejects it on next startup
What version of Codex CLI is running?
codex-cli 0.130.0
What subscription do you have?
GPT pro
Which model were you using?
GPT-5.5
What platform is your computer?
Darwin 25.3.0 arm64 arm macOS 26.3.1 (a), build 25D771280a
What terminal emulator and version are you using (if applicable)?
cmux 0.63.2 (79) [179b16ce6]
What issue are you seeing?
The TUI /keymap flow can save a keybinding for the - key as minus, but the config loader rejects that same value later.
From the code paths:
codex-rs/tui/src/keymap_setup.rsserializesKeyCode::Char('-')asminus.codex-rs/tui/src/keymap.rsacceptsminusand maps it back toKeyCode::Char('-').codex-rs/config/src/tui_keymap.rsrejectsminusduring config deserialization.
This means a keybinding produced by Codex's own /keymap UI can be persisted to config.toml, work in the current session, and then fail when Codex reloads the config on the next startup.
What steps can reproduce the bug?
One way to reproduce from the user flow:
- Open Codex TUI.
- Run
/keymap. - Capture
-as a keybinding for an action. - Save the keymap.
- Restart Codex or reload the config.
The saved config can contain a value like:
[tui.keymap.global]
open_transcript = "minus"
A minimal code-level reproduction is to deserialize that keymap config. I verified this locally with a focused regression test against codex-config; it fails on current main because minus is rejected as an unknown key name.
What is the expected behavior?
Any keybinding value emitted by the /keymap UI should be accepted by the config loader.
Specifically, minus should deserialize successfully and map to the same - key that the runtime keymap parser already accepts.
Additional information
I checked for existing issues/PRs using searches around minus, tui.keymap, hyphen, dash, and keymap config, and did not find an exact duplicate.
The fix direction seems narrow: allow minus in config key-name normalization and add a regression test that deserializes a tui.keymap entry using minus.
I also have a small local branch with a failing regression test and a narrow fix direction for this. I’m happy to share it or prepare a focused PR if maintainers think this scope is right, following the invitation-only contribution policy.