codex - 💡(How to fix) Fix TUI input lag while typing — worsens with session length (macOS arm64, terminal-agnostic)

Bug Report: Typing Lag in Codex TUI

Description

While typing in the Codex CLI prompt, there is a noticeable input lag — keystrokes appear on screen with a delay. The lag is not consistent: it seems to worsen as the session grows longer (more turns / more context), which aligns with the O(n) TUI rebuild described in #21945.

This is specifically keystroke-level lag (characters lagging behind as I type), not response time lag.

Happens across all terminals — confirmed in Ghostty, macOS Terminal.app, iTerm2, and notably inside IntelliJ IDEA's built-in terminal where it is most pronounced.

Environment

Configuration (relevant settings)

approval_policy = "on-request"
sandbox_mode = "workspace-write"
model = "gpt-5.5"
model_reasoning_effort = "xhigh"
service_tier = "fast"

[tui]
fast_default_opt_out = true
status_line_use_colors = true

Several plugins are enabled (official curated plugins + one local plugin). Multiple MCP servers are configured with hooks that fire on session_start and user_prompt_submit.

Steps to Reproduce

1. Start codex in any terminal (standalone or embedded, e.g. IntelliJ)
2. Send several multi-turn messages (5–10 turns with tool calls)
3. Try typing a new prompt in the input box
4. Observe: each keystroke takes ~50–200ms to render, making fast typing fall behind

Expected Behavior

Keystrokes should render instantly. The input field is local TUI rendering — it should be completely independent of network/model state.

Actual Behavior

Characters appear with visible delay. The delay compounds: if you type quickly, a backlog of characters catches up after you stop typing. The lag is noticeably worse after longer sessions compared to a fresh session.

The issue is not terminal-specific — it reproduces across all tested terminals. It is most severe inside IntelliJ IDEA's built-in terminal, which suggests the root cause is in Codex's own TUI rendering loop rather than terminal emulation.

Additional Context

• Possibly related to #21945 ("Improve transcript overlay rebuild performance to scale better with session length") — even without opening the transcript overlay (Ctrl+T), the O(n) session rebuild may affect regular input rendering on every keypress
• Does not happen in a fresh session with 0–2 turns
• Happens consistently on Apple Silicon (M-series chip)
• Terminal-agnostic: rules out any terminal-specific rendering issue

Possible Root Cause Hypothesis

The TUI may be re-rendering the full session cell list on every keystroke (to update the input box), triggering the same O(n) markdown/syntax-highlight rebuild described in #21945 — not just on Ctrl+T but on any state change that triggers a full re-render.

The fact that IntelliJ's embedded terminal makes it worse could be due to slightly higher PTY I/O overhead amplifying an already expensive per-keystroke render cycle.

Workaround

Starting a fresh codex session reduces lag temporarily.