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.