Difficulty entering chat text in Codex CLI.

Resolved 💬 2 comments Opened Feb 6, 2026 by zubapita Closed Apr 3, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

0.98

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.2-codex, gpt-5.3-codex

What platform is your computer?

macOS Tahoe 26.2

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

iTerm2, Ghostty

What issue are you seeing?

When using Codex on Mac, text input in the chat field becomes difficult after the first use, even though it works fine initially. It feels extremely sluggish, and frequently fails to capture entered characters.
Previously, input was nearly impossible after the first use, but recently it has become somewhat possible, and copy-pasting from text editors now works.
OS version is macOS Tahoe 26.2.
Terminals used are iTerm2 and Ghostty.
Hardware is an M2 MacBook Air with 24GB RAM.

This issue did not occur until about last week.
Other tools like Claude Code, Gemini CLI, and OpenCode work without problems.

What steps can reproduce the bug?

Enter text into the Codex CLI chat field.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

2 Comments

etraut-openai contributor · 6 months ago

Thanks for the bug report. This is the first we've heard of this issue, so it's likely that it's something specific to your system. Let's see if we can figure it out.

You mentioned that this was working last week. Can you confirm that if you downgrade to an earlier version of the CLI that the problem goes away? If so, in which version does it first occur?

zubapita · 6 months ago

Key input freeze resolved — caused by notify config and stale ~/.codex/ state

Environment:

codex-cli: 0.98.0 (also reproduced on 0.96.0)
OS: macOS (Darwin 25.2.0, Apple Silicon)

Resolution:

I resolved the intermittent key input freeze issue by:

Removing the notify option from ~/.codex/config.toml (primary cause)
Resetting ~/.codex/ — renaming the directory and letting Codex CLI recreate it from scratch (contributing factor)

After these two changes, all MCP servers (10 total) and all [features] (unified_exec, shell_snapshot, steer, collaboration_modes) work
without any input issues.

The Problem:

Codex CLI intermittently stopped accepting keyboard input. The issue occurred randomly — sometimes keys worked normally, other times the
input field became completely unresponsive. The UI remained rendered, but no keystrokes were registered.

Investigation:

I performed systematic elimination to isolate the cause:

Reset ~/.codex/ (rename and recreate) → Partially improved
Disabled all MCP servers → Issue persisted
Disabled both notify and [features] → Issue resolved
Re-enabled notify only → Issue returned
Disabled notify, re-enabled [features] one by one → All features OK
Re-enabled all 10 MCP servers (notify still disabled) → No issues

The notify config that triggers the issue:

notify = [
"bash",
"-lc",
"~/.agents/scripts/notify.sh send -s codex-cli -t task_complete --auto; afplay /System/Library/Sounds/Ping.aiff",
]

Hypothesis:

The notify option spawns an external bash process (and afplay) on task completion. This likely interferes with the terminal's stdin
handling, causing key input to become unresponsive. The issue is intermittent because it depends on the timing of when the notify process
runs relative to input polling.

Stale state files in ~/.codex/ (e.g., history.jsonl, models_cache.json, .codex-global-state.json, sessions/) appear to worsen the problem.

Suggestion:

The notify command should spawn processes fully detached from the main stdin/stdout so it does not interfere with terminal input handling.