macOS Input Bug: Control-F cursor movement is broken in the Codex app

Resolved 💬 28 comments Opened Mar 7, 2026 by SoraTakai Closed Apr 10, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.305.950 (863)

What subscription do you have?

Plus

What platform is your computer?

Darwin 23.6.0 arm64 arm

What issue are you seeing?

This report concerns cursor behavior in the text input field.

As you all know, under macOS, text field navigation follows Emacs-style key bindings by default:

Control-F = move forward one character
Control-B = move backward one character
Control-P = move up one line
Control-N = move down one line
Control-A = go to the beginning of line
Control-E = go to the end of line

Problem:

❌ Control-F = move forward one character ← BRINGS UP AND SHIFTS FOCUS TO "FIND" SEARCH BAR
✅ Control-B = move backward one character
✅ Control-P = move up one line
✅ Control-N = move down one line
✅ Control-A = go to the beginning of line
✅ Control-E = go to the end of line

This is standard default navigation behavior on macOS and should be respected.

Please fix Control-F navigation in the text input field.

Plus, you already have "Find" bound to Command-F (standard behavior and sensible); and it does NOT make sense to redundantly bind it to Control-F, which is something reserved for navigation.

What steps can reproduce the bug?

Open Codex App
Press Command-V (paste) something containing multiple lines of text
Press Control-A to go to the beginning of the line
Press Control-F - nothing happens (cursor stays there as opposed to expected forward-char cursor movement)
(Press Control-F)+ ad infinitum - nothing happens, ever

What is the expected behavior?

Control-F at text input field → move the cursor by 1 char (if there is some text after the cursor on the same line)

Additional information

_No response_

View original on GitHub ↗

28 Comments

github-actions[bot] contributor · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#11872

Powered by Codex Action

SoraTakai · 4 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Ctrl-M toggles microphone while editing the prompt (should act as Enter on macOS) #11872 _Powered by Codex Action_

No, it is not a dup - not even close. Thanks for your attempt nevertheless.

SoraTakai · 4 months ago

Anyone taking a look? Why does it take so long for anyone to even respond?

If there's no one, just use one of your models - Claude Code does this automatically.

stym06 · 4 months ago

@SoraTakai can you also include ctrl+w and ctrl+u in this issue since these commands help delete word or whole sentence?

SoraTakai · 4 months ago

@stym06 Both ctrl+w and ctrl+u do nothing under my environment (macOS).

I do not define any non-standard key handling via Hammerspoon or Karabiner or whatever, on Codex App.

So everyone should be getting this behavior on macOS, unless they change its default Emacs-like navigation keys.

kyu-suke · 3 months ago

In my current version (26.325.21211 (1255)), pressing Control-F now opens the search bar. However, this action is already available via Command-F.

Ideally, it would be great if macOS standard keybindings could be respected. Alternatively, having a setting to toggle between default OS keybindings and app-specific shortcuts would be very helpful.

SoraTakai · 3 months ago

Yes, recent update made it so that Control-F - regardless of whether the cursor is focused on the text input field or not - pops and moves focus to the "Find" bar - even worse behavior than before, no respect to macOS standard navigation.

This "Find" behavior is also bound to Command-F, which I understand; but why bind it to Control-F? It is redundant, breaks norm, and is among the worst UI/UX behavior. Ask your in-house ChatGPT or anything if you doubt that. Plus, Codex is for coders who make extensive use of keybinding; and navigation shortcuts are something most of us are accustomed to. It does not make sense to have it behave in a non-standard manner.

So please, fix this.
@stym06

dngpng · 3 months ago

There are already at least 3 other duplicated issues created regarding this bug -- kinda making it obvious that the problem is annoying and affecting many mac users.

⌃-F is for moving cursor forward on macOS, period. Not to mention there is ⌘-F mapped for the same functionality (search) already.

Had the Desktop App been opensourced as well, a fix/PR would have been created days ago. 🙃

shengyang998 · 3 months ago

FYI. Just used codex to reverse engineering the Codex.app. It won't bother me anymore on my machine now. The resolution is like below, you may send it to your LLM.

Found the root cause and local patch path.
`Ctrl+F` is bound in the packaged Electron app in two places:
- shortcut map: `findInThread: "CmdOrCtrl+F"`
- renderer keydown handler: `(e.metaKey || e.ctrlKey) && e.key.toLowerCase() === "f"`

So changing only the menu shortcut is not enough; the renderer also hardcodes `Ctrl+F`.

Also, if you patch `app.asar`, Codex will crash unless you update `ElectronAsarIntegrity` correctly.

Important detail:
`ElectronAsarIntegrity` is NOT the SHA-256 of the whole `app.asar` file.
It is the SHA-256 of the ASAR header string.

If you use the file hash, startup fails with:
`Integrity check failed for asar archive`

After updating the correct integrity hash, re-sign the app:
`codesign --force --deep --sign - /Applications/Codex.app`

tranch · 3 months ago

@shengyang998 I just tried, and after two failed attempts, it gave up:

I’m not going to patch the packaged app again. Two different patch strategies caused launch regressions, so the bundle is not safely editable this way. If you want, I can help with a safer workaround next, such as remapping Ctrl-F at the macOS level or finding a runtime injection path that does not modify app.asar.

shengyang998 · 3 months ago

Yeah, it may have failed in the first several attempts. Here’s what I did. I copied the Codex.app to Codex Back.app. Then I opened the Back one and asked it to try to reverse engineer the original one. And I asked it to run until it found the way. Then I started to do something else. I saw it modify something and tried to open the original Codex app. I don’t know how many times it tried; it was just working on other things. And at the end, I found the Codex app just ran successfully. So I asked it to tell me what it did. And that’s what I texted here before.
I also sent this link to the Codex to help it understand the issue.
I don’t know why yours tells you it cannot be patched, but maybe let it try multiple times, or just let it loop until it is done. Hope it helps.

@shengyang998 I just tried, and after two failed attempts, it gave up: > I’m not going to patch the packaged app again. Two different patch strategies caused launch regressions, so the bundle is not safely editable this way. If you want, I can help with a safer workaround next, such as remapping Ctrl-F at the macOS level or finding a runtime injection path that does not modify app.asar.

jottos · 3 months ago

the Ctrl+F is a killer for Mac users, makes the CLI almost unusable if you are a Mac CLI user

dngpng · 3 months ago

The point is, ⌃-A, ⌃-E and ⌃-B still all work for moving cursor around, you would naturally assume ⌃-F do the same, and frequently press that out of habits and muscle memory.

Kudos to @ambrosino-oai to have given it a 'keyboard' label. Let's hope for a prompt fix (pun intended 🤣).

QuincyLarson · 3 months ago

I just want to point out that this is a MAJOR issue for me too. It completely ruins my flow when I have to move my fingers off the home row and reach for the arrow keys just because of this. Thanks in advance for fixing this, @codex team.

jottos · 3 months ago

I am with both Andy and Quincy - on a MAC ^F not mapping to forward char
and WORSE mapping to search is just plain broken and is killing my ability
to use the command line, for complex input i have to use emacs to edit and
then paste into the command area
John Schneider
C 408 203 7891
E @.***

On Fri, Apr 10, 2026 at 2:30 PM Quincy Larson @.***>
wrote:

QuincyLarson left a comment (openai/codex#13822) <https://github.com/openai/codex/issues/13822#issuecomment-4226896114> I just want to point out that this is a MAJOR issue for me too. It completely ruins my flow when I have to move my fingers off the home row and reach for the arrow keys just because of this. Thanks in advance for fixing this, @codex <https://github.com/codex> team. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/13822#issuecomment-4226896114>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFIMUXNU5VUY7N6Z3X4AR34VFRVZAVCNFSM6AAAAACWKEVIGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMRWHA4TMMJRGQ> . You are receiving this because you commented.Message ID: @.***>

tranch · 3 months ago

Still reproducible for me on macOS in 26.409.20454 (1462).

I initially thought a recent update might have fixed this. However, during this same update flow I also hit a separate in-app
updater issue: #17413.

Because of that updater failure, I’m not fully confident that the new version was applied cleanly, even though the app now reports 26.409.20454 (1462) locally.

At least from what I can observe, Ctrl+F still behaves incorrectly in the input field instead of doing the normal macOS forward-character movement.

So either this issue is still present in 26.409.20454 (1462), or the updater bug in #17413 may have left the app in a partially updated/bad state.

dngpng · 3 months ago

Still reproducible for me on macOS in 26.409.20454 (1462). I initially thought a recent update might have fixed this. However, during this same update flow I also hit a separate in-app updater issue: #17413. Because of that updater failure, I’m not fully confident that the new version was applied cleanly, even though the app now reports 26.409.20454 (1462) locally. At least from what I can observe, Ctrl+F still behaves incorrectly in the input field instead of doing the normal macOS forward-character movement. So either this issue is still present in 26.409.20454 (1462), or the updater bug in #17413 may have left the app in a partially updated/bad state.

can confirm the issue still exists in 26.409.20454 (1462). The issue is marked as closed, but we may not assume the fix is shipped yet.

jottos · 3 months ago

not fixed on Version 26.409.20454 (1462)
running MAC OS 26.3.1 (25D2128)

John Schneider
C 408 203 7891
E @.***

On Fri, Apr 10, 2026 at 10:31 PM Andy @.***> wrote:

dngpng left a comment (openai/codex#13822) <https://github.com/openai/codex/issues/13822#issuecomment-4228268109> Still reproducible for me on macOS in 26.409.20454 (1462). I initially thought a recent update might have fixed this. However, during this same update flow I also hit a separate in-app updater issue: #17413 <https://github.com/openai/codex/issues/17413>. Because of that updater failure, I’m not fully confident that the new version was applied cleanly, even though the app now reports 26.409.20454 (1462) locally. At least from what I can observe, Ctrl+F still behaves incorrectly in the input field instead of doing the normal macOS forward-character movement. So either this issue is still present in 26.409.20454 (1462), or the updater bug in #17413 <https://github.com/openai/codex/issues/17413> may have left the app in a partially updated/bad state. can confirm the issue still exists in 26.409.20454 (1462). The issue is marked as closed, but we may not assume the fix is shipped yet. — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/13822#issuecomment-4228268109>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFIMUQ2F2PL6YKSRUUI4UL4VHKCFAVCNFSM6AAAAACWKEVIGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEMRYGI3DQMJQHE> . You are receiving this because you commented.Message ID: @.***>

April-June-August · 3 months ago

It’s confusing that this is the earliest, most‑discussed report of the Ctrl+F bug and was marked “completed,” even though several people here have confirmed it’s still broken in recent versions (I can confirm that too!). Meanwhile, a newer duplicate (#17114) from last week with far fewer replies is left open. @etraut-openai

April-June-August · 3 months ago

Anyway, I found a workaround for any Alfred user out there to try out. Please note that you have to pay for the Powerpack to be able to use workflows.

Make sure the Hotkey is only registered in Codex by double-clicking the object, go to “Related Apps”, and drag Codex into the sheet. You can search for Codex in Alfred and drag the result from there.

It's a bit laggy but it gets the job done.

tranch · 3 months ago

@April-June-August So it sounds like I have to pay for a Powerpack add‑on just to work around a bug in this app?

April-June-August · 3 months ago

@tranch I posted it here for the existing users who already paid.

To be clear, it’s not that this workflow (add-on) is paid, instead, once you unlock the Powerpack, you’ll be able to use every add-on there is or make your own ones.

And for the ones who have never heard of Alfred, I put the disclaimer that paid features are required so they won't go to download the app only to be frustrated.

So to answer your question: No, I don't think you have to pay for an app to work around a bug in Codex.

SoraTakai · 3 months ago

@openai Anyone taking a look at this?
If not, have one of your models take a look.
If you are somehow unable to do so, let me know - because I can fix it for you.

Clearly, it is a bug in Codex and no one should have to suffer implementing a workaround for this.

A viable, free workaround is to use Hammerspoon and bind ctrl-f to right key on 'Codex' app window only.
But that causes unnecessary delay (a few ms) for every control-F keystroke.

In short, OpenAI should fix this.

SoraTakai · 3 months ago

@ambrosino-oai Please reopen this bug.

This is an outstanding bug and nothing has been fixed.

SoraTakai · 3 months ago

@etraut-openai @dylan-hurd-oai @nornagon-openai @tibo-openai
Please, kindly, reopen this critical bug that still remains unresolved.

Just reproduced the issue on version 26.409.20454 (1462)

SoraTakai · 3 months ago

New version (26.415.20818; 1727) just arrived and I now confirm Control-F works as expected - the way it should (no find/search bar).

Many thanks to whoever made a commit for this.

5amfung · 3 months ago

Kudos to the Codex team. Love the browser and file viewer (CMD-P) as well.

April-June-August · 3 months ago

Finally. After more than 3 months.