Scrollback search doesn't work in `foot`

Resolved 💬 6 comments Opened May 2, 2026 by chriselrod Closed May 2, 2026

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

What version of Codex CLI is running?

0.128.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5, gpt-5.4

What platform is your computer?

Linux 7.0.2-2-cachyos-server-lto x86_64 unknown

What terminal emulator and version are you using (if applicable)?

foot

What issue are you seeing?

https://codeberg.org/dnkl/foot
foot has a scrollback search you can start with ctrl + shift + r.
The scrollback search selects matching text, allows you to cycle through matches, grow the selection, enter to leave scrollback search mode while maintaining the selection, ctrl + shift + v to copy.

This feature is the biggest reason I prefer foot over alternatives like ghostty, which don't let me copy/paste fully with the keyboard.

What steps can reproduce the bug?

Install a Linux desktop environment that uses Wayland.
Install foot.
ctrl + shift + r.
type text matching what you see in the scrollback.
enter to leave selection mode.
start codex.
ctrl + shift + r
start typing gpt-5.5 (or some other sample text that currently appears on the screen [to avoid any possible scrollback related issues], e.g. the name of the model you're using, which should be displayed on codex startup).

With step 8, instead of the normal selection matching that you'd get outside of codex, what you get is that every time you type a character, everything you typed in the search box matches for an instant, and then (perhaps on the next frame refresh) it says there is no match: the search-box turns red, and the matching text is no longer selected. When you type the next character, you get a match again, which is again immediately unselected.
I've never had this happen with any other cli I've used with foot (text editors, other harnesses), so the problem seems unique to codex+foot.
codex+ghostty search, for example, works fine. So I'm not certain to what extant it is a foot issue vs a codex issue (codex seems to be refreshing the screen in some way other apps don't, but foot doesn't seem to handle it the same way ghostty does).

What is the expected behavior?

The expected behavior is that foot can select text in codex like it can when codex isn't running. E.g., ctrl-c to leave codex, and then you can select all the text from codex just fine.

Please let me know if there's any extra info I can provide.

Additional information

_No response_

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 2 months ago

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

#20063

Powered by Codex Action

chriselrod · 2 months ago

I'll look through #20063 and #19645. FWIW, claude code (both w/ and w/out tui mode) work fine, so I don't think alternative scrollback buffers are the problem by themselves.

#19645's solution was changing an iTerm2 setting, which doesn't help when using a different terminal.
#20063's workarounds don't work for foot, just like they didn't solve the filer's problem.
#20063 seemed to be about searching through history that no longer appears on the screen, my issue is about not being able to use the keyboard to select text at all, as codex causes text to instantly be unselected as a non-match, after about 1 frame of the text correctly showing as a match.

So, not a duplicate.

chriselrod · 2 months ago

It still reproduces when launching codex --no-alt-screen -c 'tui.animations=false'

etraut-openai contributor · 2 months ago

This is probably not going to be a priority for us to look at because it's so niche. You're welcome to analyze on your own by cloning the codex repo and using codex to help root cause the issue. If you find a concrete root cause and it's an issue with Codex rather than your terminal emulator, let us know.

chriselrod · 2 months ago

Codex found that CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex fixes it.
I'll use this workaround, and may file an issue with foot.

GPT 5.5 said:

  Root cause is confirmed as foot search + kitty REPORT_EVENT_TYPES, not Codex drawing.
  Codex’s current workaround is:

  CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex

  The useful issue update is:

  Confirmed root cause with a terminal-output minimizer.

  Codex enables kitty keyboard enhancement flags 7:
    DISAMBIGUATE_ESCAPE_CODES | REPORT_EVENT_TYPES | REPORT_ALTERNATE_KEYS

  In foot:
    plain passes
    kitty5 (flags 1|4, no REPORT_EVENT_TYPES) passes
    kitty3 (flags 1|2) fails
    kitty7 (flags 1|2|4, Codex-like) fails
    codex-modes fails

  Workaround:
    CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex

  Likely failure chain:
    foot search consumes key presses, so the match appears
    key releases are not routed through search_input()
    with REPORT_EVENT_TYPES enabled, release events are handled by kitty_kbd_protocol()
    foot then calls selection_cancel()
    selection_cancel() calls search_selection_cancelled()
    the search match disappears

  If you want to help further, file the same minimized repro upstream to foot. A likely
  foot-side fix is to ignore/consume key release events while term->is_searching, or at
  least avoid selection_cancel() for those release events. A Codex-side mitigation would be
  to avoid REPORT_EVENT_TYPES for foot, using kitty flags 5 instead of 7, but that is a
  terminal-specific workaround for what looks like a foot search-mode bug.

chriselrod · 2 months ago

Existing foot issue: https://codeberg.org/dnkl/foot/issues/2316
Existing (merged) foot pr that fixed it: https://codeberg.org/dnkl/foot/pulls/2319
The PR was merged on April 9, 2026. I'm on foot 1.26.1, which was released March 14, 2026.

So this should be fixed on the next foot release. Until then, I'll use CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex.