Skip to content

/keymap can save minus, but config loading rejects it on next startup #22128

@chanwooyang1

Description

@chanwooyang1

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.rs serializes KeyCode::Char('-') as minus.
  • codex-rs/tui/src/keymap.rs accepts minus and maps it back to KeyCode::Char('-').
  • codex-rs/config/src/tui_keymap.rs rejects minus during 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:

  1. Open Codex TUI.
  2. Run /keymap.
  3. Capture - as a keybinding for an action.
  4. Save the keymap.
  5. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    TUIIssues related to the terminal user interface: text input, menus and dialogs, and terminal displaybugSomething isn't workingconfigIssues involving config.toml, config keys, config merging, or config updates

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions