Allow request_user_input in Default mode to wait indefinitely

Independent reproduction on codex-cli 0.147.0 in Default mode.

Reproduction

1. Enable/use request_user_input in Default mode.
2. Ask one question and leave the card unanswered.
3. The card closes automatically after about one minute.
4. The tool returns an empty answer map:

{"answers":{}}

A controlled timing sample was 64 seconds from the tool invocation to auto-resolution. The behavior reproduced multiple times in one session.

Impact

This is not equivalent to an explicit user response. An agent can interpret the synthetic empty map as a completed interaction and advance to the next decision, so one-question-at-a-time planning and specification workflows become unreliable and frustrating.

The request_user_input tool schema exposed to the model in this mode accepts only the questions payload; it exposes no isBlocking, timeout, or opt-out field. Therefore neither the model nor project instructions can keep the card pending.

Expected behavior

• Default mode should support an indefinitely blocking request_user_input, or expose a host/user setting that disables auto-resolution.
• A timeout must be distinguishable from an explicit user answer; it should not be returned as {"answers":{}}.
• When a request is blocking, the card should remain pending until an explicit answer, cancellation, or authoritative turn cleanup.

This report intentionally omits thread IDs, workspace paths, account details, and other user-specific data.

We are still iterating on request user input tool outside of plan mode and default_mode_request_user_input is currently marked as UnderDevelopment. Thanks for your patience and we will incoporate those feedback.

I traced this on current main (9ded177) and put together a small local prototype for the Default-mode case described here.

Proposed config:

[features]
default_mode_request_user_input = true

[tools.experimental_request_user_input]
default_mode_is_blocking = true

default_mode_request_user_input continues to control whether the tool is available in Default mode. The new default_mode_is_blocking setting would default to false, preserving current behavior unless explicitly enabled. Plan mode remains blocking.

Implementation outline:

• extend the existing ExperimentalRequestUserInput config with default_mode_is_blocking: bool (false by default);
• resolve it into the runtime config;
• set RequestUserInputArgs.is_blocking for Plan mode, or for Default mode only when the new option is true;
• regenerate config.schema.json;
• add config parsing/resolution tests and app-server v2 round-trip coverage for both default-false and explicit-true behavior.

Local verification:

• just test -p codex-config: 259 passed
• just test -p codex-core request_user_input: 22 passed
• just test -p codex-app-server request_user_input: 4 passed
• just write-config-schema, just fmt, and scoped just fix passed

This keeps timeout policy out of core and uses the existing isBlocking contract introduced by #36410. It also preserves Default-mode question capability rather than disabling default_mode_request_user_input. This intentionally addresses indefinite blocking in Default mode; the broader timeout-duration and timeout-outcome policy remains covered by #34455.

I also checked the current open PRs for request_user_input, default_mode_request_user_input, default_mode_is_blocking, and autoResolutionMs. The only match was #12293, which concerns interrupted/partial answers rather than blocking configuration.

Since external code contributions are invitation-only, would this config shape and placement align with the intended direction? I have the focused patch ready and would be happy to submit it if invited.

Desktop multitasking use case

I’m experiencing this in Codex App 26.814.41407 on macOS, with the bundled codex-cli 0.148.0-alpha.15.

I routinely have several Codex tasks and other desktop applications open at the same time. While one task works, I switch to something else and return when the task needs attention.

If request_user_input appears while that task is not focused, the Default-mode prompt automatically resolves before I return. The intended interaction is then lost, and the task can continue or stop without the decision I wanted to give.

The structured request_user_input interface is valuable because it presents clear options and trade-offs. Replacing it with an ordinary chat question loses that interface. Switching the entire task to Plan mode is not an equivalent workaround because Plan mode changes what Codex can do.

I would like blocking behaviour to be a user-controlled setting that is independent of whether the tool is enabled in Default mode. The proposed configuration from the comment above would address the immediate problem:

[tools.experimental_request_user_input]
default_mode_is_blocking = true

The app could expose this setting as:

• Always wait for my answer
• Auto-resolve after: 5 minutes / 1 hour / custom

The important requirements are:

• A Default-mode question can remain pending indefinitely.
• Switching tasks or applications does not dismiss it.
• It resolves only after an explicit answer or cancellation.
• A timeout is not treated as an empty user answer.
• Existing non-blocking behaviour can remain the default for compatibility.

This is fundamentally a multitasking issue. A short response window assumes that the user continuously watches one task. That assumption conflicts with the Codex desktop workflow of running and monitoring several tasks at once.