Fix rich input trapping arrow keys in Codex/OpenCode TUIs

[SagarSDagdu]

Description

When running codex (or opencode without its plugin), Warp's CLI agent rich input would auto-open and trap the arrow keys meant for navigating the agent's interactive option menus, leaving users unable to make a selection.

The auto-open path assumed any detected CLI agent would later emit Blocked-state events (PermissionRequest, QuestionAsked) that auto-close the rich input when the agent needs raw keyboard input. That assumption breaks for:

• Codex — its listener (CodexSessionHandler) only forwards opaque OSC 9 notifications as Stop and never reports Blocked. supports_rich_status() already returns false, but the auto-open / auto-toggle paths weren't checking it.
• OpenCode without the plugin — no listener at all (listener: None), so even though the handler supports rich status, no Blocked events ever arrive.

This PR gates the three rich-input auto-toggle paths on both a registered listener AND agent_supports_rich_status(&agent), so we only auto-open when we'll be able to auto-close on Blocked. Codex's proactive listener registration is preserved (it still drives OSC 9 notification suppression and the footer chip); only the auto-open and auto-toggle behaviors are suppressed for Codex. Users can still open rich input manually via the chip or Ctrl-G.

Before the fix

https://www.loom.com/share/46351245a93a4a14aa666be81d240dc8

After the fix

https://www.loom.com/share/89b33b8b6e8b4bf6a0af9ac903a21dc8

Files touched:

• app/src/terminal/view.rs — maybe_auto_open_cli_agent_rich_input, status-change auto-toggle in handle_cli_agent_sessions_event
• app/src/terminal/view/use_agent_footer/mod.rs — maybe_close_rich_input_after_submit
• app/src/terminal/view_test.rs — regression test

Linked Issue

Fixes #9059

• The linked issue is labeled ready-to-spec or ready-to-implement.
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Screenshots / Videos

Attached above

Testing

Added regression test codex_status_change_does_not_auto_open_rich_input (app/src/terminal/view_test.rs) that asserts a Codex session with should_auto_toggle_input: true and a registered listener does not re-open rich input on a Stop status event — the only status Codex's handler emits.

Existing related tests still pass:

• status_blocked_auto_closes_rich_input
• status_in_progress_auto_opens_rich_input_after_blocked
• submit_with_plugin_and_auto_toggle_keeps_rich_input_open
• submit_with_plugin_but_auto_toggle_off_respects_auto_dismiss

All 140 cli-agent-related unit tests pass. cargo fmt and cargo clippy -p warp --all-targets -- -D warnings are clean.

Manually verified on a local debug build:

• codex no longer auto-opens rich input; arrow keys reach Codex's option menus.
• claude still auto-opens rich input and auto-closes on permission prompts (regression check).
• Manual open via the rich input chip / Ctrl-G still works for Codex.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode

[oz-for-oss]

@SagarSDagdu

I'm starting a first review of this pull request.

You can view the conversation on Warp.

I reviewed this pull request and requested human review from: @Advait-M.

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz

[oz-for-oss]

Overview

This PR gates rich-input auto-open and status-driven auto-toggle on sessions that both have a registered listener and report rich status, preventing Codex/OpenCode-no-plugin flows from trapping arrow keys while preserving auto-toggle for rich-status agents.

Concerns

• No blocking correctness or security concerns found in the annotated diff.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

Comment /oz-review on this pull request to retrigger a review (up to 3 times on the same pull request).

Powered by Oz