ctrl-c not captured in iterm tmux setup (codex thinks it knows why, see below)

Resolved 💬 9 comments Opened May 20, 2026 by MiladInk Closed May 26, 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.132.0

What subscription do you have?

Pro

Which model were you using?

not related

What platform is your computer?

Linux 5.15.0-173-generic x86_64 x86_64

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

iTerm2 + tmux (for ssh to compute luster)

Codex doctor report

{
      "schemaVersion": 1,
      "generatedAt": "1779292586s since unix epoch",
      "overallStatus": "ok",
      "codexVersion": "0.132.0",
      "checks": {
        "app_server.status": {
          "id": "app_server.status",
          "category": "app-server",
          "status": "ok",
          "summary": "background server is not running",
          "details": {
            "control socket": "/home/mila/a/aghajohm/.codex/app-server-control/app-server-control.sock",
            "daemon state dir": "/home/mila/a/aghajohm/.codex/app-server-daemon",
            "mode": "ephemeral",
            "pid file": "/home/mila/a/aghajohm/.codex/app-server-daemon/app-server.pid (missing)",
            "settings": "/home/mila/a/aghajohm/.codex/app-server-daemon/settings.json (missing)",
            "status": "not running",
            "update-loop pid file": "/home/mila/a/aghajohm/.codex/app-server-daemon/app-server-updater.pid
    (missing)"
          },
          "remediation": null,
          "durationMs": 0
        },
    … +198 lines (ctrl + t to view transcript)
            "tmux set-clipboard": "external",
            "tmux xterm-keys": "on"
          },
          "remediation": null,
          "durationMs": 18
        },
        "updates.status": {
          "id": "updates.status",
          "category": "updates",
          "status": "ok",
          "summary": "update configuration is locally consistent",
          "details": {
            "cached latest version": "0.131.0",
            "check for update on startup": "true",
            "last checked at": "2026-05-19T21:39:33.579492539Z",
            "latest version": "0.132.0",
            "latest version status": "current version is not older",
            "update action": "standalone installer",
            "version cache": "/home/mila/a/aghajohm/.codex/version.json"
          },
          "remediation": null,
          "durationMs": 194
        }
      }
    }

What issue are you seeing?

When I hit ctrl-C nothing happens in the codex cli. It happened after updating from 0.130 to 0.132. I have asked codex itself to diagnose what is going on and this what it thinks:

<img width="3014" height="688" alt="Image" src="https://github.com/user-attachments/assets/3dee039f-f6a8-4d99-bf08-d27f2984de63" />

This is troubling because while I can exit the main conversations with /exit, I cannot exit side conversations as the only thing that works there is ctrl-c!

What steps can reproduce the bug?

Just open codex cli and hit ctrl-c and nothing happens.

What is the expected behavior?

It should do what ctrl-c should do in codex cli.

Additional information

_No response_

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 2 months ago

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

  • #23702
  • #23679
  • #23166
  • #23196

Powered by Codex Action

kylevedder · 2 months ago

I can confirm a very similar regression with iTerm2 + tmux integration on macOS connected to a Linux backend.

For me, the version boundary was specifically:

  • 0.130.0: key handling worked normally
  • 0.131.0: regression appeared

Symptoms I saw in 0.131.0:

  • Ctrl-C was no longer properly consumed by Codex
  • Ctrl-J / multiline-related input became unreliable
  • Shift+Enter behavior regressed in the same setup
  • occasionally even plain spaces / typed characters appeared to get eaten

Downgrading back to 0.130.0 restored the expected behavior for me. So this may have been introduced in the 0.131.0 keyboard/TUI changes and then persisted into 0.132.0, rather than being new only in 0.132.0.

kylevedder · 2 months ago

This issue still presents in 0.133.0

MiladInk · 1 month ago

I confirm that as @kylevedder reported, Shift+Enter also does not work for me.

fcoury-oai contributor · 1 month ago

Can you try running /keymap debug on Codex CLI and check if those keys are being captured by the terminal and, if they are, what they are being captured as?

fcoury-oai contributor · 1 month ago
I can confirm a very similar regression with iTerm2 + tmux integration on macOS connected to a Linux backend.

Is the tmux on the macOS side or on the tmux side? Meaning is it:

macOS -> iTerm2 -> tmux -> ssh -> Linux
or
macOS -> iTerm2 -> ssh -> Linux -> tmux
?

MiladInk · 1 month ago
Can you try running /keymap debug on Codex CLI and check if those keys are being captured by the terminal and, if they are, what they are being captured as?

I tried /keymap debug and my ctrl-c was not captured. It just did not show anything. But all other keys like pressing a, b, c, enter, ctrl are being captured.

Is the tmux on the macOS side or on the tmux side?

It is for me the following:
macOS -> iTerm2 -> ssh -> Linux -> tmux

So, it is a tmux that is running inside the Linux, and I am sshing via iTerm2 to access it. It is this tmux integration of iTerm2 that is popular. It is at the core ssh -t mila2 'tmux -CC new -A -s main'.

Please let me know if extra information is needed.

fcoury-oai contributor · 1 month ago

I have been able to replicate the issue and it will be fixed on the next release.

Until then, here is a workaround for the time being: always start codex with CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 codex.

Let me know if this fixes it temporarily.

MiladInk · 1 month ago

Thank you!