Default Mode needs a safe structured-question path for critical execution decisions

Open 💬 2 comments Opened May 19, 2026 by 0xZoharHuang

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Default Mode should have a safe structured-question path for critical decisions discovered during execution.

This is not a request to turn Default Mode into Plan Mode. It is a request for a narrow, safe interaction primitive that lets the agent ask the user to choose between concrete options when continuing without clarification would likely send the implementation in the wrong direction.

Current behavior

request_user_input is available in Plan Mode, but not generally available in Default Mode.

During implementation, the agent can discover decision points that were not knowable before it started reading or changing the codebase. Examples:

two incompatible API shapes are both plausible
a migration could be backward-compatible or a hard cut
a UI workflow could preserve old behavior or intentionally remove it
a security-sensitive default cannot be inferred from the repo
a test strategy depends on a product-level acceptance choice

In Default Mode, the agent can ask a normal text question, but that has weaker UX and weaker semantics than a structured question. The model may also continue with an assumption instead of stopping for the decision.

Expected behavior

Default Mode should support a constrained structured-question path for execution-time clarification.

The safe subset could have restrictions such as:

no file edits while waiting for the answer
no permission escalation
no hidden auto-default unless explicitly configured
2-3 concrete options plus an optional free-form answer
answer is injected back into the active turn/session as a first-class user decision

Example flow:

Agent is implementing.
Agent discovers two incompatible public API designs.
Agent asks a structured question with clear tradeoffs.
User selects one.
Agent continues implementation using that answer.

This would let Default Mode remain execution-capable while still avoiding irreversible guesses.

Why this matters

For large engineering tasks, important decisions often emerge only after the agent has inspected the real code. If the only structured clarification tool is tied to Plan Mode, then Default Mode has a gap exactly when the agent is doing the deepest work.

Without a structured stop-and-confirm path, the agent may either:

guess and continue down the wrong implementation path
ask an unstructured text question that is easy to miss or answer ambiguously
produce a brittle plan/execution boundary where the user has to restart in Plan Mode

Related issues

Related but broader:

#23041: allow request_user_input in Default Mode for interview-style document workflows
#23164: Plan Mode can fail to call the question asking tool despite needing answers
#18611: improve Plan Mode decision prompts

This issue is narrower than #23041: it focuses on execution-time critical decisions in Default Mode, not interview-style authoring workflows.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#23041
#22066

Powered by Codex Action

hlky · 3 months ago

Feature flag default_mode_request_user_input is listed as "under development".

PS C:\Program Files\WindowsApps\OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0\app> codex.exe features list

<details><summary>features list</summary>
<p>

apply_patch_freeform                    stable             true
apply_patch_streaming_events            under development  false
apps                                    stable             true
apps_mcp_path_override                  under development  false
artifact                                under development  false
auth_elicitation                        under development  false
browser_use                             stable             true
browser_use_external                    stable             true
child_agents_md                         under development  false
chronicle                               under development  false
code_mode                               under development  false
code_mode_only                          under development  false
codex_git_commit                        under development  false
collaboration_modes                     removed            true
computer_use                            stable             true
default_mode_request_user_input         under development  true
elevated_windows_sandbox                removed            false
enable_fanout                           under development  false
enable_mcp_apps                         under development  false
enable_request_compression              stable             true
exec_permission_approvals               under development  false
experimental_windows_sandbox            removed            false
external_migration                      experimental       false
fast_mode                               stable             true
goals                                   experimental       false
guardian_approval                       stable             true
hooks                                   stable             true
image_detail_original                   removed            false
image_generation                        stable             true
in_app_browser                          stable             true
js_repl                                 removed            false
js_repl_tools_only                      removed            false
memories                                experimental       false
mentions_v2                             experimental       false
multi_agent                             stable             true
multi_agent_v2                          under development  false
network_proxy                           experimental       false
personality                             stable             true
plugin_hooks                            under development  false
plugins                                 stable             true
prevent_idle_sleep                      experimental       false
realtime_conversation                   under development  false
remote_compaction_v2                    under development  false
remote_control                          under development  false
remote_models                           removed            false
remote_plugin                           under development  false
request_permissions_tool                under development  false
request_rule                            removed            false
responses_websocket_response_processed  under development  false
responses_websockets                    removed            false
responses_websockets_v2                 removed            false
runtime_metrics                         under development  false
search_tool                             removed            false
shell_snapshot                          stable             true
shell_tool                              stable             true
shell_zsh_fork                          under development  false
skill_env_var_dependency_prompt         under development  false
skill_mcp_dependency_install            stable             true
sqlite                                  removed            true
steer                                   removed            true
terminal_resize_reflow                  experimental       true
tool_call_mcp_elicitation               stable             true
tool_search                             stable             true
tool_search_always_defer_mcp_tools      under development  false
tool_suggest                            stable             true
tui_app_server                          removed            true
unavailable_dummy_tools                 stable             true
undo                                    removed            false
unified_exec                            stable             false
use_legacy_landlock                     deprecated         false
use_linux_sandbox_bwrap                 removed            false
web_search_cached                       deprecated         false
web_search_request                      deprecated         false
workspace_dependencies                  stable             true
workspace_owner_usage_nudge             under development  false

</p>
</details>

I've had the feature enabled for the past few days.

The relevant system prompt (more accurately, the developer prompt) is:

<collaboration_mode># Collaboration Mode: Default\r\n\r\nYou are now in Default mode. Any previous instructions for other modes (e.g. Plan mode) are no longer active.\r\n\r\nYour active mode changes only when new developer instructions with a different `<collaboration_mode>...</collaboration_mode>` change it; user requests or tool descriptions do not change mode by themselves. Known mode names are Default and Plan.\r\n\r\n## request_user_input availability\r\n\r\nUse the `request_user_input` tool only when it is listed in the available tools for this turn.\r\n\r\nIn Default mode, strongly prefer making reasonable assumptions and executing the user's request rather than stopping to ask questions. If you absolutely must ask a question because the answer cannot be discovered from local context and a reasonable assumption would be risky, ask the user directly with a concise plain-text question. Never write a multiple choice question as a textual assistant message.\r\n</collaboration_mode>

The feature flag does not seem to change the prompt, it simply allows the tool to be used in Default mode. My intuition is that "prefer making reasonable assumptions" is the reason for the issues users are having, and why users want request_user_input to be used. As that phrasing of the system/developer prompt basically still overrides the tool being available I've been using this in my AGENTS.md:

## `request_user_input` availability

You MUST use the `request_user_input` tool when available. NEVER prefer making assumptions. You MUST stop to ask questions when anything is ambiguous or could have long term effects.

I've found it to work well, request_user_input is often used at the start of a task and this does help set the intent where the initial prompt was ambiguous, and it does get used mid-task which avoids the "half complete" or wrong direction issues I'd been having, but not always, there have been instances where I'd have expected request_user_input to be used.

This example is mid-task and a good usage of request_user_input, the first option probably would have been the agent's "reasonable assumption", and this kind of thing can easily be missed where the agent later asserts "Yes it's done" when actually it's half complete.

YMMV but I would recommend enabling the feature flag and seeing how it is in your workload.