[Bug] Input freezes after prolonged idle period — unable to type or activate IME

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

26.601.21317

What subscription do you have?

Plus

What platform is your computer?

_No response_

What issue are you seeing?

Description

After leaving the Codex session idle (no keyboard input or interaction) for an extended period, the input area becomes completely unresponsive. The cursor may still be visible/blinking, but no typed characters appear, and sometimes the input method (IME) cannot even be activated. The only way to recover is often to click out of the window and back in, or forcibly restart the session.

This occurs on the desktop environment (not mobile).

Steps to Reproduce

1. Start a Codex session (e.g., in terminal or desktop app).
2. Leave the window idle for a significant amount of time (e.g., 10–30 minutes, or after system sleep / screen lock / display off).
3. Attempt to type or switch IME (e.g., Win+Space / Ctrl+Space) and observe the behavior.

Expected Behavior

Input should resume immediately upon returning to the window, or at most require a simple click into the input area. The IME should reconnect and function as before.

Actual Behavior

• Typed characters do not appear, even though the cursor may blink.
• Switching input methods sometimes revives input, but not reliably.
• Clicking outside the Codex window and back in occasionally restores input, but not always.
• The rest of the UI (if any) remains responsive, suggesting the app is not fully frozen.
• If using the CLI version, it may feel as if the terminal is still echoing but Codex is not processing keystrokes.

Environment

• Codex version: 26.601.21317 (released Jun 3, 2026)
• OS: [e.g., Windows 11 23H2 / macOS 15.0 / Ubuntu 24.04]
• Keyboard: [Built-in / USB / Bluetooth]
• IME: [e.g., Microsoft Pinyin, Sogou, Google Japanese, macOS ABC]
• Terminal / App: [If CLI: Windows Terminal, iTerm2, GNOME Terminal, etc. If desktop app: specify version]
• Power settings: [e.g., Balanced/High Performance, USB selective suspend enabled/disabled]
• Does the issue occur after system sleep/lock? [Yes / No / Sometimes]

Additional Context

• The problem does not happen in other CLI tools (e.g., bash, zsh, python REPL) under the same conditions — only in Codex.
• Switching to the system default IME sometimes immediately fixes the issue, suggesting an IME reconnection problem.
• Disabling USB selective suspend and setting power plan to High Performance reduced the frequency but did not eliminate the bug.
• The issue resembles a loss of “raw mode” or focus grab in the terminal, or an internal editor focus loss in the desktop app.

Possible Related Areas

• Focus restoration after idle/sleep/app switching.
• IME (Input Method Editor) lifecycle and reconnection.
• Terminal raw mode / PTY handling after background idle (for CLI).
• Interaction with system power management (USB/Bluetooth suspension).

Logs / Screenshots

(If any terminal logs, debug output, or a screen recording showing the frozen input are available, please attach them here.)

What steps can reproduce the bug?

Description

After leaving the Codex session idle (no keyboard input or interaction) for an extended period, the input area becomes completely unresponsive. The cursor may still be visible/blinking, but no typed characters appear, and sometimes the input method (IME) cannot even be activated. The only way to recover is often to click out of the window and back in, or forcibly restart the session.

This occurs on the desktop environment (not mobile).

Steps to Reproduce

1. Start a Codex session (e.g., in terminal or desktop app).
2. Leave the window idle for a significant amount of time (e.g., 10–30 minutes, or after system sleep / screen lock / display off).
3. Attempt to type or switch IME (e.g., Win+Space / Ctrl+Space) and observe the behavior.

Expected Behavior

Input should resume immediately upon returning to the window, or at most require a simple click into the input area. The IME should reconnect and function as before.

Actual Behavior

• Typed characters do not appear, even though the cursor may blink.
• Switching input methods sometimes revives input, but not reliably.
• Clicking outside the Codex window and back in occasionally restores input, but not always.
• The rest of the UI (if any) remains responsive, suggesting the app is not fully frozen.
• If using the CLI version, it may feel as if the terminal is still echoing but Codex is not processing keystrokes.

Environment

• Codex version: 26.601.21317 (released Jun 3, 2026)
• OS: [e.g., Windows 11 23H2 / macOS 15.0 / Ubuntu 24.04]
• Keyboard: [Built-in / USB / Bluetooth]
• IME: [e.g., Microsoft Pinyin, Sogou, Google Japanese, macOS ABC]
• Terminal / App: [If CLI: Windows Terminal, iTerm2, GNOME Terminal, etc. If desktop app: specify version]
• Power settings: [e.g., Balanced/High Performance, USB selective suspend enabled/disabled]
• Does the issue occur after system sleep/lock? [Yes / No / Sometimes]

Additional Context

• The problem does not happen in other CLI tools (e.g., bash, zsh, python REPL) under the same conditions — only in Codex.
• Switching to the system default IME sometimes immediately fixes the issue, suggesting an IME reconnection problem.
• Disabling USB selective suspend and setting power plan to High Performance reduced the frequency but did not eliminate the bug.
• The issue resembles a loss of “raw mode” or focus grab in the terminal, or an internal editor focus loss in the desktop app.

Possible Related Areas

• Focus restoration after idle/sleep/app switching.
• IME (Input Method Editor) lifecycle and reconnection.
• Terminal raw mode / PTY handling after background idle (for CLI).
• Interaction with system power management (USB/Bluetooth suspension).

Logs / Screenshots

(If any terminal logs, debug output, or a screen recording showing the frozen input are available, please attach them here.)

What is the expected behavior?

_No response_

Additional information

_No response_