Ctrl+C can become non-functional during /review and MCP startup (startup/shutdown deadlock)

[mingley]

Summary

Ctrl+C can become non-functional in startup-heavy flows (notably /review and MCP initialization), leaving Codex running in a state where keyboard interrupts do not exit the app.

In affected runs, repeated Ctrl+C does not recover. The only reliable escape is external process termination (closing terminal/tab, killing tmux pane, kill, etc.).

User impact

• Breaks the primary safety/escape interaction in the CLI.
• Can strand users in long-running or hung startup paths.
• Makes /review and initial MCP setup feel deadlocked even when user requests cancellation.

Reproduction scenarios

Scenario A: /review during startup pressure

1. Start Codex in an environment where startup is slow/hanging (for example MCP server startup delays).
2. Trigger /review.
3. Press Ctrl+C one or more times.

Observed in failing cases: app does not exit, and keyboard interrupt appears ignored.

Scenario B: MCP initialization with unresolved client future

1. Start with MCP servers where one startup future does not resolve promptly.
2. During initialization, press Ctrl+C.

Observed in failing cases: shutdown request can be starved; process stays alive until externally killed.

Root cause analysis

This was a compound bug with multiple contributing paths:

1. Startup op starvation in TUI agent startup path

   • Before fix, spawn_agent awaited start_thread before consuming queued ops.
   • If startup hung, Op::Shutdown (triggered by quit flow / Ctrl+C) could not be handled.

2. Unbounded or effectively unbounded MCP client waits in startup-sensitive paths

   • Several MCP manager call sites awaited shared client futures directly.
   • If client creation/startup stuck, startup progress and related status flows could stall.

3. Shutdown-first exit lacked hard escalation path

   • Repeated quit requests could continue routing through ShutdownFirst without a guaranteed fallback to immediate exit when shutdown completion was stuck.

4. Review sub-agent startup was not cancellation-aware while spawning

   • /review path called sub-agent spawn directly; cancellation token was not raced for the spawn await.

Implemented fix

I prepared and validated a two-commit fix on branch mingley/ctrlc-interrupt-fix:

• e403fd6c7dd5aa277ad6d6f6b6c1323b7a1d102a
• 3d8dccdea337b2b5ff44db929a50d57a1ecdf565

1) Keep startup interruptible in TUI (codex-rs/tui/src/chatwidget/agent.rs)

• While startup is pending, consume ops from the op channel.
• If Op::Shutdown arrives pre-startup, emit AppEvent::Exit(ExitMode::Immediate) and return.
• Buffer non-shutdown startup ops and flush after startup completes.

2) Bound MCP startup waits across manager call paths (codex-rs/core/src/mcp_connection_manager.rs)

• Added startup timeout-aware client helper and applied it to startup-sensitive operations.
• Added timeout-based behavior for startup-failure checks and aggregate listing paths.
• Updated additional remaining raw startup waits (notify_sandbox_state_change, startup join task) to use bounded waits.

3) Add shutdown escalation fallback (codex-rs/tui/src/app.rs)

• Added explicit escalation behavior: repeated ShutdownFirst quit request exits immediately.
• This preserves graceful shutdown attempt first, but guarantees a hard user escape hatch on repeated request.

4) Make review sub-agent spawn cancellation-aware (codex-rs/core/src/codex_delegate.rs)

• Wrapped Codex::spawn(...) with cancellation (or_cancel) in review/delegate startup path.
• Prevents /review from hanging uninterruptibly during spawn waits.

Test coverage and validation

Added/validated tests relevant to these regressions:

• mcp_connection_manager::tests::required_startup_failures_times_out_pending_server
• mcp_connection_manager::tests::list_all_tools_skips_pending_server_after_timeout
• app::tests::shutdown_first_exit_escalates_on_second_request
• chatwidget::tests::ctrl_c_shutdown_works_with_caps_lock

Validation commands run:

• cargo fmt
• cargo clippy --all-targets --all-features -- -D warnings
• cargo test -p codex-core required_startup_failures_times_out_pending_server
• cargo test -p codex-core list_all_tools_skips_pending_server_after_timeout
• cargo test -p codex-tui shutdown_first_exit_escalates_on_second_request
• cargo test -p codex-tui ctrl_c_shutdown_works_with_caps_lock
• cargo test -p codex-tui
• cargo test (workspace)

Workspace test note:

• cargo test fails in this environment only on pre-existing core tests unrelated to this fix:
  • shell::tests::detects_bash
  • seatbelt::tests::create_seatbelt_args_with_read_only_git_pointer_file
  • seatbelt::tests::create_seatbelt_args_with_read_only_git_and_codex_subpaths

Why this contribution should be accepted

1. High user impact: restores reliability of Ctrl+C, the primary fail-safe control.
2. Clear causal diagnosis: fix addresses each independent blocking path, not just symptoms.
3. Surgical scope: targeted changes in affected startup/shutdown paths only.
4. Regression coverage: added focused tests for timeout and shutdown escalation behavior.
5. Low behavior risk: normal successful flow remains unchanged; only failure/cancellation paths are hardened.

Request for contribution path

External PRs are currently invitation-only. Please consider one of:

1. Allowing me to submit this as a PR directly, or
2. Cherry-picking the two commits above.

I can also split the commits further if maintainers want each root-cause fix isolated.

[mingley]

Opened PR with the proposed fix set: #11268

This PR includes the startup interruptibility changes, bounded MCP startup waits, review spawn cancellation handling, and shutdown escalation fallback discussed in this report.

[mingley]

Update: PR #11268 was closed by maintainer comment on 2026-02-10 due current contribution policy (invitation-only code contributions):
#11268 (comment)

To keep this issue actionable, the tested fix set remains available in that PR and in these commits:

• e403fd6c7dd5aa277ad6d6f6b6c1323b7a1d102a
• 3d8dccdea337b2b5ff44db929a50d57a1ecdf565

What the fix covers:

• startup op starvation in TUI bootstrap (Op::Shutdown handled during pending start_thread)
• bounded MCP startup waits in remaining startup-sensitive paths
• shutdown escalation fallback (repeat shutdown-first request -> immediate exit)
• cancellation-aware review/sub-agent spawn startup

Validation run for these changes:

• cargo fmt
• cargo clippy --all-targets --all-features -- -D warnings
• targeted tests for MCP startup timeout and Ctrl+C/exit behavior
• cargo test -p codex-tui

If maintainers want, I can provide this as split commits by root cause to make internal cherry-picking/review easier.

[cipher982]

Reproduced on v0.122.0, macOS 26.4 arm64, 9 MCP servers configured.

sample <codex_pid> 3 output:
26/26 tokio-runtime-worker threads + main thread all parked in _pthread_cond_wait / __psynch_cvwait.
Zero threads doing I/O.

/healthz and /readyz on the app-server WS port don’t respond.
TUI stuck on "Starting MCP servers (8/9): " for 10+ min.
Ctrl-C inert.

Child MCP processes themselves are healthy, isolated initialize handshake responds in ~500ms. They’re waiting on stdin that never arrives because the parent is deadlocked. Plus a reference to mcp_connection_manager.rs pre-spawn loop + emit_update(...).await on bounded channel as the suspected culprit.

I can optionally attach the full sample file as a gist if they want the raw stacks.

[m13v]

hit this same pattern across three stdio MCP setups on macOS last quarter. the bounded channel emit_update during startup is the immediate trigger, but the deeper issue is the initialize handshake has no watchdog separate from the RPC timeout. if a child binary spawns but stalls before reading initialize, the parent blocks on the pipe write because macOS pipe buffers default to 16KB vs linux 64KB. i wrap every spawn in a 5s initialize deadline plus a 2s 'first bytes out' watchdog on stdout, kill on either. double-Ctrl-C hard-exit is the right call, matches how reliable daemon wrappers handle it.

[etraut-openai]

Thanks for the bug report. This will be fixed in the next release.

[braines-blw]

Looks like a regression here, ctrl+c consistently fails to kill the process when running codex review.

OS: MacOS Tahoe Version 26.6.1
CLI: codex-cli 0.146.0