macOS: Ctrl+F is globally bound to Search and interrupts text input (expected “move forward one character”)

Resolved 💬 4 comments Opened Mar 26, 2026 by tranch Closed Apr 1, 2026

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

26.324.21641 (1228)

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

On macOS, Ctrl+F is a standard text-editing shortcut that moves the caret forward by one character in text fields (especially common for users coming from Emacs-style bindings).

In the Codex App, Ctrl+F appears to be globally bound to Search. When I’m typing in a text input (chat composer / prompt field), pressing Ctrl+F unexpectedly opens the Search UI instead of moving the cursor. This breaks the normal text-editing flow and feels inconsistent with macOS's native input behavior.

What steps can reproduce the bug?

  1. Open the Codex App on macOS.
  2. Focus a text input where you can type (e.g., the main prompt/composer).
  3. Type any text.
  4. Press Ctrl+F.

What is the expected behavior?

When a text input is focused, Ctrl+F should behave like a normal macOS text-editing shortcut: move the caret one character forward (or at least not trigger global search). Global Search should only trigger when focus is not inside a text field, or be moved to a more standard shortcut (e.g., Cmd+F) and respect focus/context.

Additional information

This is particularly disruptive for users who rely on Ctrl-based navigation for editing—e.g., HHKB keyboard users—because it makes a common cursor-movement key chord unusable while typing.

Suggested fix: make global Search context-aware (don’t fire when an editable text field has focus), and/or use Cmd+F for Search on macOS to match platform conventions.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗