[TUI][tmux] Shift+mouse-wheel silently changes reasoning effort while attempting to scroll

What version of Codex CLI is running?

0.153.4

What subscription do you have?

Plus

Which model were you using?

No response

What platform is your computer?

No response

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

GNOME Terminal 3.58.0 + tmux 3.5a

Codex doctor report

What issue are you seeing?

When Codex CLI is running inside tmux, using the mouse wheel with Shift can silently change the active reasoning-effort level instead of scrolling the main conversation view.

I discovered this only after noticing that several recent Codex sessions had unexpectedly been running at low or xhigh, even though I had previously selected a different effort level.

This is particularly dangerous because reasoning effort affects model behavior, latency, and resource usage, yet the setting can be changed accidentally by a normal scrolling gesture without any explicit confirmation.

This is related to, but distinct from:

• #36158 - mouse wheel scrolls prompt history instead of the transcript under tmux
• #36099 - mouse wheel does not properly scroll the CLI TUI

The additional bug here is that a scrolling gesture can mutate the active reasoning-effort setting.

What steps can reproduce the bug?

1. Start a tmux session.
2. Run Codex CLI inside it.
3. Select a known reasoning effort, for example medium.
4. Stay in the main Codex TUI/chat view.
5. Hold Shift and scroll the mouse wheel up or down.
6. Observe the displayed reasoning-effort setting.

What is the expected behavior?

Mouse-wheel input over the main conversation view should scroll the conversation viewport.

It must not change model configuration such as reasoning effort.

In particular, mouse-wheel events translated by the terminal or terminal multiplexer into arrow-key-like input should not be allowed to trigger semantic configuration shortcuts such as reasoning-effort changes.

At minimum, Codex should distinguish genuine Shift+Up / Shift+Down keyboard input from mouse-wheel scrolling translated into similar terminal sequences.

Ideally, the main TUI should handle native mouse-wheel scrolling directly, as described in #36099.

Additional information

Why this is more serious than a scrolling bug

A failed scroll is immediately visible.

An accidental reasoning-effort change is not necessarily noticed. The user may continue working for many prompts before realizing that the session has been running with a different reasoning level.

This can result in:

• unintentionally reduced reasoning quality (low);
• unexpectedly expensive or slow requests (high / xhigh);
• inconsistent behavior between sessions;
• difficult-to-explain differences in agent performance.

Reasoning effort is a model execution parameter and should not be mutable as an accidental side effect of attempting to navigate the UI.

Suspected interaction

Codex currently has keyboard shortcuts for changing reasoning effort using Shift+Up / Shift+Down.

Terminal alternate-scroll behavior can translate mouse-wheel activity into arrow-key sequences. Under tmux, the combination appears capable of reaching the same reasoning-effort shortcut handler.

Therefore a gesture intended as:

Shift + mouse wheel

can effectively become:

Shift+Up / Shift+Down

from Codex's point of view and change reasoning effort.

Even if both behaviors are individually intentional, their interaction is unsafe.

Suggested fix

Mouse-wheel events should never trigger reasoning-effort changes.

Possible fixes include one or more of:

1. handle native mouse-wheel events in the main conversation viewport;
2. prevent alternate-scroll-generated arrow events from reaching reasoning-effort shortcuts;
3. distinguish physical keyboard Shift+Up/Down from translated wheel input where possible;
4. reconsider using Shift+Up/Down as default shortcuts for a model execution parameter.

Personally, I do not need a keyboard shortcut for reasoning effort at all; changing it explicitly through the appropriate slash command/model picker is much safer.

Environment

Codex CLI: 0.153.4
tmux: 3.5a
OS: Linux
Terminal emulator: GNOME Terminal
TERM inside tmux: tmux-256color

First reproduce the issue in the Codex TUI inside tmux using GNOME Terminal, then trace the Shift+Up/Shift+Down reasoning-effort shortcut handler and the main conversation view's mouse or alternate-scroll input path. Done means Shift+mouse-wheel only scrolls the conversation and never changes reasoning effort, while genuine keyboard shortcuts retain their documented behavior.