Configurable Hotkeys Support

I can't use Ctrl+J when codex CLI is running in a terminal in VS Code because Ctrl+J toggles the terminal view.

So codex is less usable when running inside a VS Code terminal (such as when running on a remote machine using the "Remote-SSH" extension).

For me, most of the line editor commands seem to work (option+delete kills word, and option+f and option + b move forward and back). However, option+d does not kill word forward. I don't understand why some work and others don't?

I really would prefer the default to be shift-enter instead of ctrl-j for newline. ctrl-j is not intuitive or at least support configurable key bindings to allow this change. You go from ChatGPT web or any other LLM web interface and then you get here and it's another paradigm.

in particular, having ctrl-k killing to end of line but not putting it into a buffer you can use with ctrl-y is maddening

For me it's super important feature because:

• when I want to use it inside PhpStorm's terminal, current keymap collides with some PhpStorm's which makes it less-usable and makes me use regular Terminal app
• I'm using corne keyboard and I don't even have some of the keys that are used in default keymap

I 👍 this issue but the only thing I really care about is the newline hotkey. CTRL+J or even ALT+Enter is not intuitive at all. Shift+Enter is the most common combination for most messaging clients (Slack, Signal, etc.) that auto-submit on enter. Please make it configurable or add that as a default.

This one things makes the agent almost unusable for truly interactive usage. Muscle-memory is so baked in for shift+enter....accidentally submitting prompts is infuriating.

How many times have I pressed ENTER to wrongly send everything I've written off, instead of just creating a new line.
I hate this in codex and in ChatGPT.

But they made Alt + Enter work. Have developers ever heard of https://en.wikipedia.org/wiki/Principle_of_least_astonishment !?

I vote for either making it configurable or either Ctrl + Enter or Shift + Enter ( Alt + Enter is first time in my life and I am 34 years with computers).

I am pressing Ctrl + Enter and it start processing partial prompt instead of letting me enter the rest. This is an example how one not very thoughtful decision ruins the entire great product. Or there is a plan to move the entier world to Alt + Enter :)

How many times have I pressed ENTER to wrongly send everything I've written off, instead of just creating a new line. I hate this in codex and in ChatGPT.

Seems like they even dont care about that ffs =\

yep this issue tracker is just smoke and mirrors

+1 here ctrl+a conflicts with my tmux prefix

Linking #14386 here because it is a good example of why configurable hotkeys are not just a nice-to-have.

That issue proposes a keyboard modal for navigating and actioning structured reply units with bindings like:

• Alt+Up / Alt+Down to move across semantic units
• a to append quoted and remain
• Enter to append quoted and return to the composer
• Space / shifted navigation for multi-select

If Codex starts exposing richer keyboard-native interaction surfaces like that, hardcoded bindings will become a real bottleneck very quickly. The key and action layer should be configurable so users can adapt the workflow to tmux, IMEs, editor terminals, vim muscle memory, and personal composition patterns.

Another concrete example of why configurable hotkeys matter: #12882.

That ticket starts from missing Shift+Arrow selection in the prompt textarea, but the natural baseline set is larger:

• character-wise selection with Shift+Left/Right
• word-wise selection with modified word jumps
• cut on selected text (Ctrl+X)

These are basic editor/TUI expectations, and as Codex grows richer composer and reply-surface workflows, hardcoded bindings will keep falling behind user environments and muscle memory.

Another concrete place where configurable hotkeys matter: #14677.

That issue proposes turning queued messages into a first-class keyboard-navigable stack, ideally with Alt+Up/Down selection and possibly Alt+Shift+Up/Down reordering. If Codex goes in that direction, these bindings will inevitably need flexibility across terminals, IMEs, and user muscle memory.

So the queue UX and the hotkey-config story reinforce each other.

Bumping this because it is becoming more and more obvious that configurable shortcuts are not an optional polish item. They are foundational.

The recent interaction proposals around Codex all increase the pressure here:

• reply-structure keyboard mode: #14386
• queue selector/editor with Alt+Up/Down: #14677
• composer selection/editing parity: #12882
• shell-like path completion in the composer: #14673
• session browser / resume management flows: #6500, #14712, #14713

At some point the product stops being “a textbox with a few shortcuts” and becomes a real TUI with multiple modes, selectors, destructive flows, and structured interaction surfaces.

When that happens, hardcoded keybindings turn from annoyance into architecture debt.

This needs pressure for a few reasons:

• terminal conflicts (tmux, editor terminals, IMEs, OS/global shortcuts)
• international keyboards and input methods
• vim/readline muscle memory
• future features needing coherent user-configurable control schemes instead of one-off defaults

Codex is already lagging behind very old terminal/editor expectations here. The longer this stays hardcoded, the more every new interaction feature piles onto a brittle foundation.

This should be treated as a priority substrate issue, not as a cosmetic enhancement.

I rely heavily on assistive technology and several keyboard shortcuts to offset my physical disability. I cannot realistically change some of the key bindings I use for other globally-active software because I require those actions more frequently. I'm not as efficient with Codex than I otherwise could be, and fatigue more easily while using it, due to the lack of configurability here.

@nobodyzxc Your comment is completely irrelevant to this issue.

+1 Would love to have configurable keybindings. Running in terminal multiplexers like cmux, many default key combos get intercepted before reaching Codex.

For anyone using the Codex desktop app and running into the Ctrl+F conflict (triggering search instead of moving the cursor like in Emacs), here’s a temporary workaround that works on macOS:

You can use Karabiner-Elements to remap Ctrl+F globally (or per-app if needed). For example:

{
  "title": "Codex Ctrl+F workaround",
  "rules": [
    {
      "description": "Map Ctrl+F to Right Arrow",
      "manipulators": [
        {
          "type": "basic",
          "from": {
            "key_code": "f",
            "modifiers": {
              "mandatory": ["control"],
              "optional": ["any"]
            }
          },
          "to": [
            {
              "key_code": "right_arrow"
            }
          ]
        }
      ]
    }
  ]
}

I would value being able to turn off key bindings like Cmd + number to jump between threads.

Implemented in #18594 as part of the keymap stack. That PR added the /keymap slash command with a guided picker/remapping flow, backed by the configurable keymap foundation from #18593. Closing this as shipped.