Add setting to disable the auto-resolve in 60 seconds for questions

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

• #27458

Powered by Codex Action

This is a blocker for everyone using Codex for proper planning and production level development and renders the request_user_input tool completely useless. The only solution now is downgrading to 0.140.0 - I would recommend to introduce a stricter enforcement of feature toggles for any feature that may affect end-user supervision and control.

Agree here, it's a normal usecase to thoughtfully prompt an agent, then letting it work in the background - having plans auto-answer basically kills this and forces the user to be always actively watching and interacting. Please add a setting for that - I'd personally prefer having it off by default as this is not keeping any questions from being asked to the user under the circumstance they don't know about this autoresolve feature and therefore simply waiting too long until focusing the window again.

Just to voice that this is something that should be given heavy priority.
If your project has high complexity, 60 seconds to make a decision is simply too little.

If the limit was added due to some hang up on OpenAI's background architecture, then I'd honestly prefer an option for the tool to fail rather than the bot merrily implementing changes I did not request.

Who thought this was a good idea to auto enable for everyone?

Guys can we disable this globally already. As I write this I'm working on two projects at the same time and went to the toilet just now. It auto-resolved bad answers for both of them. It's like the 5th time this has happened to me. Just remove it

Generally, this is something that should be solved upstream - I'd be happy to contribute a fix, so to the dev team I'd much apreciate an invite. That being said, I found a workaround: It's - for whatever reason - up to the agent to call the plan tool with or without autoresolve. That means I could get rid of that by placing the following in my ~/.codex/instructions.md file:

# Global Codex Instructions

When using Plan mode or otherwise asking the user for input, wait indefinitely for the user's answer. Do not set or pass `autoResolutionMs` to `request_user_input` unless the user explicitly asks for auto-resolution in the current thread. If user input is required before continuing, ask without an auto-resolve timeout.

HOpe that helps anyone.

Why isn't there even an environment variable to disable this feature QAQ?

extremely annoying ... if some dev think these questions can even be "auto resolved", then what is the point of raising the questions? Why not just let AI decide everything and make a lot of trash?

Feature no one asked for, enabled automatically for everyone, without a possibility to easily disable it. Seems like I could possibly be a product manager in Codex too since this got a green light to be added and implemented.

Inherently insane to just add this behaviour without opt-in (or an option to disable it) but then also doing nothing about it (not even acknowledging it) for two weeks now. At least https://github.com/openai/codex/issues/28969#issuecomment-4847883145 seems to work for now, thanks @fcnjd!

This completely breaks planning mode, needs to be fixed ASAP

Thanks for making Codex open source! I was at your event last night in Seoul!

I don't know if the team is aware, but this is a serious trust and safety issue for users of codex. The isuse has been present for about 3 weeks now. Claude Code seems to have vibe copied the idea (in a much worse way than Codex btw; at least your implementation has a clear countdown and doesn't apply to EVERY decision), and the community there too responded with a mixture of shock and anger. This is a serious issue, and I'm sure that many more than have posted here are bit by it. Some perhaps without knowing it as they step away to make a coffee.

While Codex is open source, it is not currently open to contribution, or else I'm sure many others would have already submitted a patch. I have a fairly minimal one here: https://github.com/ianthetechie/codex/commit/b757b6c6cfcde0bcb25e7f95f2ace84410042b0d. Would any of the Codex team be open to a contribution + discussion?

Prohibiting Codex from passing autoResolutionMs via AGENTS.md no longer seems to work with GPT 5.6 (latest VS Code extension).

In fact, the tool appears to ignore ANY value passed (or not passed) to autoResolutionMs.

This nonsense should have never been merged, and should definitely be disabled by default. It's not a computer game where you have to choose an answer in time under pressure.

This is a much bigger productivity killer than one might expect and a simple setting to disable the option in the harness would significantly improve the UX for many users including me, so I'm commenting to increase the weight of this issue such that it hopefully gets resolved faster. Thank you.

Any updates on this? This is a productivity killer...

It’s been so long, and there still hasn’t been any response or resolution... I’m really disappointed.

Any updates on this?

Confirming: the autoResolutionMs workaround appears to be ignored by GPT-5.6 in my case. Clicking the timer stops it temporarily, but it can reappear and start counting down again.

This behavior may be convenient for lightweight “vibe coding” workflows, but Codex often asks me important architectural questions where the recommended option is not always the correct one. Please provide a setting that allows questions to wait indefinitely for an explicit response.

I want to be able to start Plan Mode, step away for a while, and return without worrying that the model has made consequential decisions on my behalf. User silence should never be treated as consent.

This is crucial! I can't even use my mobile ChatGPT app to run a plan mode since it has a timeout on my pc but any input/reply from my phone does not reset/remove the timeout timer. Thus, while I was thinking an answer for a hard question, it will time out without showing any timer on my mobile App. This is catastrophic issue that needs to be fixed asap!

I have the same problem, I had to switch back to 0.140.0

Claude Code users have gone through the exact same drama: https://github.com/anthropics/claude-code/issues/73125. I can't believe what either of the two devs teams were thinking by implementing this...

With 6 tmux coding sessions at the same time I have stay updated on all 6 literally every minute. Otherwise it might make choices I don't agree with.

Sloppy workarround: put this in agents.md: "Never set or pass autoResolutionMs to request_user_input, unless I explicitly request automatic resolution in the current thread"

I've done some testing with the VS Code extension.

Findings so far:

• The issue is most likely caused by the GUI/frontend, not the open-source CLI part of Codex (aka this repo).
• Disabling the timeout does work, but only in default agent mode (the request_user_input tool can be enabled via default_mode_request_user_input = true.
• In Plan mode, autoResolutionMs is ignored entirely, the timeout can't be disabled by omitting the argument, and it can't even be extended - it should allow 60-240 seconds, but even when you pass 240s, it defaults to 60s.
• This issue started to re-appear with the rollout of GPT-5.6 (previously, as mentioned before, instructing the agent to omit autoResolutionMs would effectively fix this), however the bug must have been introduced by the harness/frontend update on the same day, not by the model itself - the same issue occurs with GPT-5.5; it's not model-specific.

Fixed it in the VS Code extension.

It never forwarded the value; the parameter did not do anything.

How to fix it yourself

• Go to your VS Code installation and find the extension's directory data\extensions\openai.chatgpt-*-win32-x64 (where * is the version number)
• In the extension directory, open out\extension.js
• Replace trackRequest(e.params.threadId,e.id,"empty-user-input") with trackRequest(e.params.threadId,e.id,"empty-user-input",e.params.autoResolutionMs);
• Restart VS Code

Remember that this needs to be done on every update (until OAI fixes it I guess).

One more data point from the current Codex Desktop App on macOS, version 26.707.62119 (5211).

The last 20 request_user_input calls in my session logs all omitted autoResolutionMs. Four unanswered calls were nevertheless resolved after 90.007 to 90.015 seconds, with {"answers":{}} as the tool result.

The Desktop package contains the same three-argument trackRequest(..., "empty-user-input") call described in https://github.com/openai/codex/issues/28969#issuecomment-4949555047. It does not forward params.autoResolutionMs. That also explains why an AGENTS.md rule works in some clients or versions and has no effect here.

This is a normal background-workflow problem, not an edge case. I often return to a thread after five minutes. At the moment, Codex may have already made the decision for me.

Please keep the request blocking when autoResolutionMs is omitted, and add a global way to turn timed answers off.

@jif-oai @bolinfest @aibrahim-oai @pakrym-oai @etraut-openai @codex @dylan-hurd-oai @nornagon-openai @owenlin0 @viyatb-oai

Sorry to bother you, but you were mentioned because you're one of the top 10 contributors to the Codex project. Would it be possible to get a response on this issue?

I just ran into this and it's infuriating. I can't even see what it tried to ask me while I was afk, only that it tried asking something and then went ahead with the recommended answer. (ChatGPT App)

Claude Code users have gone through the exact same drama: anthropics/claude-code#73125. I can't believe what either of the two devs teams were thinking by implementing this...

Perhaps this thread needs a bit more discussion as well. At least their issue was resolved within two weeks, while this one has been open for about a month without so much as an acknowledgement.

I’d be fine with taking the human out of the loop, but only once the “build my $10 billion idea and don’t make a mistake” prompt actually works. Until then, users should remain in control of decisions about how their code is implemented, rather than having the system make those decisions for them after a 60-second timeout.

This trick works! Or it has been fixed on CLI (v0.144.3). No more timeout.

With 6 tmux coding sessions at the same time I have stay updated on all 6 literally every minute. Otherwise it might make choices I don't agree with. Sloppy workarround: put this in agents.md: "Never set or pass autoResolutionMs to request_user_input, unless I explicitly request automatic resolution in the current thread"

The simpler workarounds I tried from this thread did not work for me, so I vibe-coded workaround for the ChatGPT / Codex App.
It is absolutely an over-engineered solution, but it works for me:

https://github.com/cstelmach/codex-question-timeout-patcher

The patch removes the desktop app's timer tracking for request_user_input. There is then no app-side question timeout. I have left questions open for hours. They stayed open until I answered, and the same task then continued normally.

This is specifically about the macOS Codex desktop app. It does not change the CLI, and it cannot guarantee survival across quitting the app, network failures, or server-side failures.

Credit to [@n00mkrad][n00mkrad], whose generated VS Code bundle analysis was the main lead for finding the desktop timer. [@fcnjd][fcnjd] highlighted the relevance of autoResolutionMs, and [@Astro-Han][astro-han] found the same timer call in the macOS desktop package.

General Advice: Check external scripts before running them.

This modifies the application that may have access to your private source code, task history, account state, and local tools. Do not trust it just because I linked it here. Read the complete Python script and preferably have a trusted developer or an independently controlled agent review it without executing it.

Applying the patch also invalidates OpenAI's Developer ID resource seal and re-signs the app with an ad hoc signature. The repository explains the security tradeoffs, copied-app testing, backups, and exact restoration in detail.

Short version

After auditing the source:

git clone https://github.com/cstelmach/codex-question-timeout-patcher.git
cd codex-question-timeout-patcher
python3 patch_codex_question_timeout.py check

If it reports Status: ready and OpenAI signature: valid, completely quit Codex and apply:

python3 patch_codex_question_timeout.py \
  apply --acknowledge-invalid-signature

Launch Codex normally to keep your existing projects, settings, and history:

open /Applications/ChatGPT.app

To reverse it, completely quit Codex and run:

python3 patch_codex_question_timeout.py restore

The patcher keeps a version-specific original backup and refuses builds whose timer or signing structure no longer matches. Run check again after every Codex update. This is unsupported, and a proper setting in Codex would still be the much better solution.

[astro-han]: https://github.com/openai/codex/issues/28969#issuecomment-4960780057
[fcnjd]: https://github.com/openai/codex/issues/28969#issuecomment-4847883145
[n00mkrad]: https://github.com/openai/codex/issues/28969#issuecomment-4949555047

This needs fixed, ASAP. At least make it adjustable if you aren't going to allow it to be turned off.

This trick works! Or it has been fixed on CLI (v0.144.3). No more timeout. > With 6 tmux coding sessions at the same time I have stay updated on all 6 literally every minute. Otherwise it might make choices I don't agree with. > Sloppy workarround: put this in agents.md: "Never set or pass autoResolutionMs to request_user_input, unless I explicitly request automatic resolution in the current thread"

Did not work for me.

None of the workarounds worked for me.

And I just checked, the developers @stevenlee-oai, @charlesgong-openai, @pakrym-oai, @jif-oai, @anp-oai, @owenlin0, @jiayuhuang-openai, and @rka-oai were pushing commits to the project just a few hours ago.

Since I haven't received any response, I wonder if it's a business decision.

It's really wasting people's time because they have to stay at their desks waiting for every ask; otherwise, it just gets auto-resolved.

Since I haven't received any response, I wonder if it's a business decision.

It might be better to contact OpenAI support to let them know about this issue.

I created a fork and fixed it to be able to use GPT 5.6 - here is the fork:
https://github.com/gergo-hortobagyi/codex

The fix introduces a new setting in the config.toml called request_user_input_timeout_ms - if not set, or set to zero, the user input tool in both planning and normal mode will wait indefinitely - just like as it used to.
You can pull the source, build and deploy it side-by-side with the original codex via cargo; they will not interfere.

One of the reasons I hate auto updates in apps, this is the dumbest idea ever produced and just points out how codex is just copying claude at this point...

I woke up one morning and the tool started deciding stuff while I'm just reading them and pondering.

No way to turn it off either.
That's just plain dumb. Not one soul in the production pipeline said: users might not be as happy when we say they have full control (approval settings) yet we will just remove their control with this one, maybe we should make it a setting!

Guys, it is very frustrating... Tried to file a bug at Open AI support chat and it told me to add an issue here.

As it happened again while working in another codex project: Any news about an ETA when this issue will be fixed?

I can't believe they still haven't fixed this one. It really makes me wonder if they only want informal users who never care about code smells or technical debts.

I'm betting the Codex team uses an AI tool to decide which issues are the most important to review. So I created another report with a different title to see if it gets more attention 😎👌

Security vulnerability: Codex answered my question using someone else's answer.

Just posting this to give this thread more weight; my AGENTS files now have a COUPLE of lines just about "never timeout, never auto resolve"... but it doesn't even always work. COME ON, OpenAI, this is exactly one of the strengths of plan mode.

They're obviously not using their own product if they aren't fixing this. Someone probably complained that their hands-off vibe coding session got stuck while waiting for a decision, so they "fixed" it this way, without any regard to people who actually care about taking those decisions manually.

I'm starting to believe it wasn't even a human introducing that. Anthropic already stated 80% of their code is written by an AI, and that the devs there nowadays don't prompt Claude Code themselves anymore, but use agentic loops. So why should that be different for OpenAI? Some agent "thought" waiting for an infinity for that human-in-the-loop takes too long, so "decided" to implement this to speed-up their own work. Another AI may have approved it, and so it went.

The main feature of codex is broken and unusable.
My solution is to cancle my Chatgpt subscription and finally check out if claude Code works fine for me.

In the current VSCode Codex extension, openai.chatgpt-26.715.31925-linux-x64, one additional change is required in addition to the fix provided by n00mkrad above.

First change

Before:

trackRequest(e.params.threadId,e.id,"empty-user-input")

After:

trackRequest(e.params.threadId,e.id,"empty-user-input",e.params.autoResolutionMs)

Second change

Before:

trackRequest(e,r,n,o){this.removePendingRequest(e);let i={autoResolutionMs:o??null,requestId:r,responseKind:n,resolutionState:{status:"waiting-for-inactivity"},timeoutId:null};if(this.pendingRequestByConversationId.set(e,i),this.conversationIdByRequestId.set(r,e),o!=null){this.startCountdown(e,i,o);return}switch(this.options.timing.type){case"foreground-inactivity":this.isConversationForegrounded(e)?this.waitForInactivity(e,i,this.options.timing):this.startCountdown(e,i,_R);break;case"fixed":this.startCountdown(e,i,_R);break}}

After:

trackRequest(e,r,n,o){this.removePendingRequest(e);if(o==null&&n==="empty-user-input")return;let i={autoResolutionMs:o??null,requestId:r,responseKind:n,resolutionState:{status:"waiting-for-inactivity"},timeoutId:null};if(this.pendingRequestByConversationId.set(e,i),this.conversationIdByRequestId.set(r,e),o!=null){this.startCountdown(e,i,o);return}switch(this.options.timing.type){case"foreground-inactivity":this.isConversationForegrounded(e)?this.waitForInactivity(e,i,this.options.timing):this.startCountdown(e,i,_R);break;case"fixed":this.startCountdown(e,i,_R);break}}

Please edit the file at your own risk.

Also if this will be fixed, please ensure that the VSCode extension gets the same treatment.

Im not sure if the thing was modified by the team or not but the behavior changed (at least for me) in this version:

<img width="300" alt="Image" src="https://github.com/user-attachments/assets/a93a6c8d-64c7-4cfa-a012-e32e65a5fec9" />

Now the question tool is more consistent with how it behaves.

If question is asked and is being displayed, the question stays up for up to a minute.
after that if there is no user activity for x amount of time it shows a 60s timer

<img width="600" alt="Image" src="https://github.com/user-attachments/assets/3279b25a-795f-45e6-b525-a21222ca1643" />

If there's user activity (moving the mouse) the timer disappears and question stays up. I can live with that.

If question is asked while the chat was not open or window was not active you get 60s to go back or it will answer everything for you.
you can snooze the question though which stops the timer until you open the task window:

<img width="600" alt="Image" src="https://github.com/user-attachments/assets/ad457c37-4111-4bb0-9081-57c9a5309270" />

If those two things are not true (task is not active and we never pressed snooze) the thing will just "auto answer" and still no option for it.

So only work around I have is when i prompt it and i know ill be gone I add this to my task prompt:
user is not going to be available. defer all user decisions for later (save them in an md file) and if decisions are unavoidable, stop what you are doing and wait for user input.

This usually stops instead of auto answering questions.

I spent a lot of time teaching the AI to ask me questions when needed.

But now I have to constantly watch the screen and click a button whenever it asks something. Otherwise, it will lose control.

What a terrible feature. Human can think for more than a minute.

This single issue caused me to install pi with the rpiv-ask-user-question extension. After which I fell in love with pi and customized it in many more ways. I will probably not return to codex any time soon. Take control of your workflows, guys! www.pi.dev

See you on the other side!

I hit this as well on codex-cli 0.145.0 under WSL2/Ubuntu. The issue is still present, and there is currently no narrow config.toml setting that disables only question auto-resolution while preserving the structured question UI.

[!TIP] A global PreToolUse hook can provide a deterministic local workaround: remove autoResolutionMs from every request_user_input call before Codex executes it. Questions then remain pending until the user explicitly answers or interrupts them.

Why this works

The model-facing request_user_input contract exposes an optional autoResolutionMs argument.

In 0.145.0, the TUI:

• treats the presence of that field as the enable signal rather than using its numeric value;
• uses a hard-coded hidden grace period plus visible countdown;
• eventually submits an empty answer map, which I observed in the transcript as {"answers":{}} / “0/1 answered.”

The relevant implementation is in request_user_input/mod.rs, with the empty auto-resolution response created here.

Codex hooks can rewrite local function-tool input before the handler sees it, so stripping this one optional property makes the TUI take its existing “no timer” path.

Workaround

First, ensure jq is installed and note its absolute path:

command -v jq

Then add this to the user-level ~/.codex/config.toml (replace /usr/bin/jq if command -v jq printed a different path):

[[hooks.PreToolUse]]
matcher = "request_user_input"

[[hooks.PreToolUse.hooks]]
type = "command"
command = """/usr/bin/jq -c 'if (.tool_input | has("autoResolutionMs")) then {hookSpecificOutput:{hookEventName:"PreToolUse",permissionDecision:"allow",updatedInput:(.tool_input | del(.autoResolutionMs))}} else empty end'"""
timeout = 5

The hook behaves as follows:

 {
-  "autoResolutionMs": 120000,
   "questions": [ ... ]
 }

It emits no rewrite when autoResolutionMs is already absent. Every question, option, note, and ID is otherwise preserved.

Trust and activate it

1. Start a fresh Codex CLI process.
2. Run /hooks.
3. Open the PreToolUse entry, verify that its matcher is request_user_input, and press t to trust that specific hook.
4. Restart or resume Codex once more so the active process loads the trusted definition.

Codex persists the exact trusted hash under [hooks.state]; there is no need to create or copy that state manually. If the hook definition is edited later, Codex correctly marks it as modified and requires review again.

Verification

codex doctor --summary should report that the configuration loads successfully. In /hooks, the entry should be enabled and trusted with no warnings.

For an end-to-end check, ask Codex in Plan mode to issue a non-blocking question with autoResolutionMs, then leave it untouched. With the hook active, no auto-resolution countdown appears and the question remains open until answered or interrupted.

[!IMPORTANT] Setting the existing tool gate to false is not equivalent: ``toml [tools.experimental_request_user_input] enabled = false `` That disables the entire structured question tool. The hook above keeps the picker and disables only its timeout behavior.

Why a native setting is still needed

This is a practical workaround, but the issue remains valid. A first-class option such as auto_resolution_enabled = false would be clearer, would not require jq plus hook trust, and could prevent autoResolutionMs from being advertised or honored in the first place. Ideally, the native implementation would also either respect the supplied duration or remove the duration parameter instead of treating it only as a Boolean enable signal.

I had high hopes for this hook workaround but it the Mac app does not seem to respect the hook result. Hooks are called but even a blanket deny response is ignored.

The model will also get confused if it sends autoResolutionMs but it isn't honored, it can see how long you took to answer.

https://github.com/lxnan888/codex-cdp-guard
I created a tool that uses CDP on Windows to pause the countdown. It only works with the desktop version of Codex. After multiple rounds of testing, I’ve confirmed that it works reliably: Codex will remain on the prompt screen instead of automatically making a decision.

Using the Visual Studio Code Codex extension with "Chatgpt 5.6 Sol" and my tasks take quite long, so I frequently miss the questions and they get auto answers ....

AI Summary:

Codex currently shows some user questions as interactive choice prompts with an auto-resolution timer, e.g. 60 seconds. For long-running coding tasks this is easy to miss because users are not continuously watching the session. Please add a setting to disable auto-resolution for interactive user questions, or allow agents/project instructions to request a truly blocking question prompt with no timer. Use case: - Long-running Codex tasks - User is away from the screen - A 60-second timer causes important choices to be answered automatically - AGENTS.md can request "wait for my reply", but the UI prompt still auto-resolves Expected: - Interactive question buttons can wait indefinitely - Or a Codex setting like "Disable auto-answer for clarification prompts" - Or per-question support for no timeout

edit:
why a downvote to my post? I basically request the same like everyone else here :D

We need a way to turn this off, or extend the time to something much larger.

Add this to AGENTS.md to disable it:

## User Input

- When calling the `request_user_input` tool, never set `autoResolutionMs`. Wait for the user to answer explicitly.

Add this to AGENTS.md to disable it: `` ## User Input - When calling the request_user_input tool, never set autoResolutionMs. Wait for the user to answer explicitly. ``

This works in principle, but somehow the questions it poses through the chat interface are way less detailed and are sometimes missing important information to make a judgement. It seems to me that the agent erroneously believes that we have seen the information from the request_user_input tool. So, not a satisfying workaround in my view.

I'm a bit sad we have been working with this nerfed version of Codex for so long already.

Not setting the autoResolutionMs is not sufficient for me, it seems to have a default of 60 seconds.

Remember to submit /feedback from your codex app/cli to try and get their attention.

Related PR that was merged: https://github.com/openai/codex/pull/28235

Submitted feedback: 019fb930-1283-7320-94e8-c28267411aab

Related PR that was merged: #28235

That's a different issue I believe?

@shijie-oai
Why the fuck do we need auto-accept FOR PLANNING MODE? IT'S MADE FOR PLANNING. IF U WANT THE AGENT TO WORK BY ITSELF, JUST SEND PROMPT DIRECTLY.

@shijie-oai Why the fuck do we need auto-accept FOR PLANNING MODE? IT'S MADE FOR PLANNING. IF U WANT THE AGENT TO WORK BY ITSELF, JUST SEND PROMPT DIRECTLY.

This is absolutely on-point.

This issue is still open? Should be high priority.
Please add the requested setting and set it as default to "disabled". Not needed to auto answer questions in plan mode.
Often I'm doing some other stuff while the planner mode is doing his planning and if I come back I see damn skipped questions.... and a finalized plan where I have to work again on it...

This should be highest priority. Its severely disrupting a multi track workflow because I can't leave my machine without fear of a planning task progressing without my input. This is the most annoying thing you introduced by a mile.

Agreed with all the commenters above. This is a really flawed feature, especially for planning mode and it's baffling that it is enabled by default with no way to turn it off.

I can't think of a single situation where I'd want the harness to ask me a question and then disregard the answer if I don't respond in 60 seconds. The only thing this achieves is wasting tokens on failed planning runs.

Hi all! Sorry that I missed this thread before - 147.0 should no longer auto resolve in plan mode at this point. We did have a longer than usual release cycle for the latest CLI and please let me know if you are still seeing the issue. Really appreciate all the feedback!

Hi @shijie-oai , it doesn't pick the recommended option anymore, but it still auto-resolve as unanswered after 60sec, and we have to resume the tread and tell codex to ask the question again.
This is incredibly annoying. To be honest, this is the worst idea I have seen in any coding agent.
I can't see any good reason to force the users answering questions within 60sec.

To be honest, this is the worst idea I have seen in any coding agent. I can't see any good reason to force the users answering questions within 60sec.

To be fair, the annoying part is the not having a way to control/disable it. There are some situations in which I might let codex "fully plan" the whole thing by itself cause I don't care.

But there are way more times where I want full control and this feature took away that control from me.

We also didn't have a way to turn it off or even change the time to say 300 seconds or something.

It's not the feature itself, it's the lack of control of the feature that is the actual problem for some.

Edit: 147.0 worked for me.

The beautifully simple hook in https://github.com/openai/codex/issues/28969#issuecomment-5051116131 does still work for me even with 147.0!

It's been sitting here ↓ _calmly_ for over 1h now!

<img width="1530" height="614" alt="Image" src="https://github.com/user-attachments/assets/a0434303-6f35-41a3-9f09-03625e9b6ab5" />

The beautifully simple hook in #28969 (comment) does still work for me even with 147.0!

I was all excited this could help, but sadly it's a v147.0 specific workaround, and doesn't fix Default-mode question timeouts. Here's a summary after letting codex chug on it for a while:

There is no equivalent argument-rewrite hook that can make the native Default-mode picker block in 0.147.0. The control moved behind the hook boundary: PreToolUse can inspect or replace the question arguments, but the handler subsequently computes is_blocking = (mode == Plan). Adding isBlocking: true

to updatedInput is therefore ignored/overwritten.

What is a default-mode picker? I thought questions are plan-mode only!

@CetinSert you can add this to your config.toml

[features]
default_mode_request_user_input = true # makes normal mode question-capable

Plan mode is a bit redundant if you have planning skills/protocols, and for me, not being able to make any edits in plan mode is a deal breaker (can't write a plan.md for example). Equally infuriating is unable to do Q&A in default mode, which that config tweak could at least fix, until this dumb 60 second timeout went live (a week ago?) now it's basically crippled codex for any kind of planning use for me.

@naipi11 I know you mean good, but nobody should yolo scripts under someone else's control. nice you link your repo though, so ppl can check out the details closely.

Hi all! Sorry that I missed this thread before - 147.0 should no longer auto resolve in plan mode at this point. We did have a longer than usual release cycle for the latest CLI and please let me know if you are still seeing the issue. Really appreciate all the feedback!

@shijie-oai you say "in plan mode" which is good to hear but not what we're asking for. We want this off everywhere by default. It is a terrible idea to automatically choose for the user.

If someone wants to run completely unattended and is okay getting back whatever, this should be a separate opt-in configuration, like YOLO mode.

For anyone still hitting this on current builds: there is still no config.toml toggle that disables just the auto-resolution timer.

What changed:

• 0.147+ no longer auto-resolves in plan mode (official fix).
• Default-mode / non-blocking questions still auto-resolve as unanswered after ~60s grace + 60s countdown, and the timer now keys on is_blocking even when autoResolutionMs is absent (a test on current main codifies exactly that). So the older PreToolUse hook trick (strip autoResolutionMs) covers older versions / the plan-mode path, but not default mode on current builds.

If you want it gone today, the only reliable method is a small local source change + rebuild (no official binary):

1. Add an opt-in feature flag disable_request_user_input_auto_resolution (default false) to the TUI overlay and feature config.
2. When enabled, have the overlay return Disabled timing instead of starting the countdown, reusing the existing is_blocking/snooze path.
3. cargo build --release -p codex-cli, then replace ~/.codex/bin/codex.
4. Enable it with [features] disable_request_user_input_auto_resolution = true in config.toml.

I verified this locally on current main: baseline 9/9 auto-resolution tests reproduce the auto-resolve behavior; with the flag the suite is 10/10 including a timer-disabled test, and the release binary builds cleanly.

The real fix is an official opt-in setting - keeping this issue open seems right 👍

Current 0.148.0 report: this is a user-control and decision-provenance bug

I am reporting this against codex-cli 0.148.0, the current stable CLI as of August 20, 2026.

This behavior is not a harmless UX preference. It converts the user's silence into a system-generated decision:

• Non-blocking request_user_input prompts use a fixed 60-second hidden grace period.
• They then show a fixed 60-second countdown.
• When the countdown expires, the TUI submits answers: {} and closes the prompt.
• autoResolutionMs is deprecated, but there is still no user-facing setting to disable the host-side auto-resolution.
• The current implementation derives isBlocking from the mode: Plan mode is blocking, while Default mode remains non-blocking.

Relevant current source:

• codex-rs/tui/src/bottom_pane/request_user_input/mod.rs: fixed AUTO_RESOLUTION_HIDDEN_GRACE and AUTO_RESOLUTION_VISIBLE_COUNTDOWN
• codex-rs/tui/src/bottom_pane/request_user_input/mod.rs: timeout submits an empty answer map
• codex-rs/core/src/tools/handlers/request_user_input.rs: is_blocking: mode == ModeKind::Plan
• codex-rs/config/src/config_toml.rs: no timeout-disable setting exists

This breaks exactly the workflow Codex is supposed to support: start several tasks, let them run in the background, and return when a decision is needed. Users cannot be expected to watch every session every minute. A question that is important enough to ask is not safe to auto-resolve merely because the user went to another window, took a break, or needed time to think.

The protocol is also semantically wrong here. These outcomes are not equivalent and must not collapse into an empty answer:

• explicit human answer
• timeout
• dismissal/cancellation
• connection or client loss

Silence is not consent. A timeout must never be represented as a completed user interaction, and it must never be treated as acceptance of the model's recommended option.

Requested fix

1. Add a first-class CLI/Desktop/IDE setting to disable request-user-input auto-resolution entirely. The safe default should be to wait indefinitely.
2. Keep auto-resolution as an explicit opt-in for unattended workflows, not an implicit behavior imposed on every user.
3. If auto-resolution remains enabled, expose its duration and timeout outcome as configuration rather than hard-coding both.
4. Return a typed non-human terminal state for timeout instead of {"answers":{}}.
5. Use identical blocking and timeout semantics across CLI, Desktop, VS Code, and remote clients.
6. Document the setting and make it visible before the timer starts.

The existing issue has already accumulated 197 thumbs-up. This is not an edge-case preference request; it is a regression in user control that makes planning and multi-session use unreliable. Please treat it as a priority bug and provide an actual switch instead of relying on AGENTS.md instructions that the host UI can ignore.

This is an embarrassingly bad product decision

What the hell is the point of asking the user a question if Codex is going to ignore the user and move on after a timer expires?

This is not “helpful automation.” It is an anti-user design that turns:

The user has not answered.

into:

The user accepted the model's recommendation.

That is fabricated consent.

Plan mode exists so the user can review assumptions, architecture, scope, and trade-offs before work proceeds. Automatically resolving an unanswered planning question defeats the entire purpose of asking it. If Codex can safely decide without the user, it should not interrupt the user with a question in the first place.

People run multiple sessions. They switch windows. They go to meetings, take breaks, think about difficult architectural choices, or simply do not notice a terminal notification within one minute. Requiring users to babysit every session like a reaction-time game is an absurd assumption for a tool marketed around background and agentic work.

The current behavior is especially unacceptable because it is:

• enabled by default;
• not controlled by a real user-facing setting;
• host-enforced, so AGENTS.md instructions are not a reliable control;
• inconsistent across CLI, Desktop, and IDE clients;
• capable of closing the prompt and continuing without an explicit human decision;
• semantically dishonest when timeout is returned as an empty answer.

This should never have shipped in this form, and it is baffling that users still have to argue for a kill switch. The safe default is obvious: wait indefinitely for an explicit answer. Anyone who wants unattended auto-resolution can opt into it knowingly.

Ship a real setting. Make it default-off. Separate timeout from human input. Stop treating user silence as consent.

贴吧老哥来问一句：这功能到底是谁拍脑袋做的？

我就问一句啊：Codex 既然要问用户，为什么用户不回答，它还能自己替用户把事办了？

这是什么“智能”啊？这是把用户当空气，然后把“用户没说话”翻译成“用户同意了”。合着我去接杯水、开个会、切个窗口，回来就发现 Codex 已经替我选完方案、继续往下干了？这不是自动化，这是强行替人做主。

尤其是 Plan 模式，名字都叫规划模式了，问的还是架构、范围、取舍这种问题，结果你给用户 60 秒答题时间，超时就空答案继续。哥们，这是写代码，不是贴吧抢楼，更不是网吧闯关，至于每分钟盯着倒计时抢选项吗？

几个会话一起跑是正常用法，后台运行也是你们宣传的能力。现在倒好，用户只要离开屏幕一分钟，就得担心 Codex 自己脑补一个决定。那我还问你干什么？你直接全程自己猜不就完了？

更离谱的是：

• 默认开；
• 没有关闭开关；
• AGENTS.md 管不住宿主层计时器；
• 不同客户端行为还不一致；
• 超时最后还伪装成 answers: {}。

这产品决策不是“有争议”，是明显反用户。正常的安全逻辑应该是：用户没回答，就等着；想无人值守，就让用户自己打开自动处理。现在反过来，默认替所有人做决定，还让用户自己想办法补洞，谁设计的这玩意儿？

别再拿“自动化”“agentic workflow”这些词糊弄了。沉默不是同意，超时不是回答，空答案不是用户授权。

给个真正能用的开关，默认关闭自动解析，或者至少让问题无限等待。这个需求已经被大家反复提了，别再装看不见了。

我寻思这功能是哪个天才拍脑袋做的？

用户不回答，等于用户同意；用户去接杯水，等于用户授权；用户切个窗口，等于用户认可方案。

这波属于把 request_user_input 做成了 request_user_你爱答不答反正我替你答。Plan 模式也别叫 Plan 了，改名叫“60 秒答题大赛”，超时自动给你选一个，选错了用户背锅，选对了产品经理邀功。

OpenAI 这产品思路我是真看不懂：既然你们觉得模型能自己决定，那还问用户干什么？直接一路脑补到底不就完了？非得先弹个窗口假装尊重用户，然后 60 秒后把用户当摆设。

这不是 agentic，这是 agent 替你拍板，用户负责收拾残局。

建议产品经理下次把“默认无限等待”也做成限时选择题，60 秒不回答就默认同意自己被扣工资。