[Feature]: Respect Codex `default_mode_request_user_input` in Default mode

[ParsaZa79]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

Codex provider integration / apps/server

Problem or use case

Codex now has an under-development feature flag that makes request_user_input available in Default mode:

[features]
default_mode_request_user_input = true

This works in the native Codex app after restarting and starting a fresh task. The interactive question renders normally and returns the selected answer.

T3 Code correctly loads the setting for a Codex provider instance, including one using a shared Codex home plus a shadow home for separate authentication. Codex even emits the warning confirming that default_mode_request_user_input is enabled.

However, T3 Code still injects Default-mode developer instructions that explicitly say:

The request_user_input tool is unavailable in Default mode. If you call it while in Default mode, it will return an error.

As a result, a Codex Personal provider in T3 Code cannot use the feature in Default mode even though its effective Codex configuration enables it.

T3 already supports the underlying item/tool/requestUserInput app-server request and answer UI in Plan mode, so most of the interaction path appears to exist already. The mismatch seems to be in T3's hardcoded Default-mode instructions/tool availability rather than the provider profile or Codex home configuration.

Proposed solution

Please make the Codex Default-mode integration respect the effective features.default_mode_request_user_input setting.

Possible approaches:

• Generate the Default-mode developer instructions based on the effective Codex feature configuration.
• When the flag is enabled, expose/retain request_user_input and describe it as available.
• When the flag is disabled, preserve the current behavior.
• Alternatively, allow Codex app-server's resolved collaboration-mode settings to remain authoritative instead of replacing them with a static T3 instruction block.

Why this matters

This is a very helpful and frequently requested interaction pattern for coding-agent applications. Users often need the agent to ask a structured question during implementation—not only during a dedicated planning phase.

Supporting it in Default mode would improve:

• clarification of ambiguous requirements without switching modes;
• explicit confirmation before risky or production-facing actions;
• selection between meaningful implementation tradeoffs;
• iterative design and development workflows;
• structured answers that are easier to understand than questions embedded in ordinary chat messages.

T3 Code already has a polished pending-user-input UI, so allowing Codex to use it during normal Default-mode work would make that existing experience considerably more useful.

Smallest useful scope

For Codex provider sessions only:

1. Detect whether features.default_mode_request_user_input is enabled in the effective Codex configuration.
2. Stop injecting the “unavailable in Default mode” instruction when it is enabled.
3. Allow the existing request_user_input request/response UI to operate in Default mode.
4. Keep current behavior unchanged when the flag is absent or disabled.

Steps to reproduce

1. Enable the feature in the Codex home used by T3 Code:

   [features]
   default_mode_request_user_input = true

2. Restart T3 Code and create a fresh Codex thread in Default mode.

3. Ask Codex to invoke request_user_input.

4. Observe that the feature is recognized by Codex, but T3's injected Default-mode instructions still declare the tool unavailable.

5. Run the same test in the native Codex app; the interactive question works.

Environment

• T3 Code Nightly
• macOS arm64
• Codex provider using a Personal account/auth overlay
• Codex CLI 0.146.x
• default_mode_request_user_input reported enabled

Alternatives considered

• Always switch to Plan mode before asking a question. This works, but it changes the workflow and is unnecessary when Codex explicitly supports the tool in Default mode.
• Ask questions as ordinary assistant text. This loses the structured answer UI and cannot serve as a dependable confirmation gate.
• Duplicate or move the config into the shadow Codex home. T3 already materializes the setting there and Codex confirms it is enabled, so this does not resolve the hardcoded mode instruction.

Risks or tradeoffs

The Codex flag is currently marked under development, so T3 may want to keep support conditional and avoid enabling it by default. Respecting an explicit user opt-in would preserve the existing default behavior while allowing users who intentionally enabled the feature to use it.

Please consider supporting this—the capability is genuinely useful in everyday implementation workflows and fits T3 Code's existing structured question UI very well.

Contribution

• I would be open to helping implement this.