Issue: Codex appears to timeout while waiting for user input

I have noticed that there seems to be a 5 minute timeout when questions are asked in planning mode, and if I don't see it, think about it, and answer in time, then it just takes the default value. This is much too quick - often enough I don't even know what deeper architectural choice to make within only 5 minutes. Best would be if there was a way to just disable that timeout for e.g. planning questions.

The timeout seems to be related to model_providers.<id>.stream_idle_timeout_ms, and can only be increased (a broad change that affects all stream idle situations, not only planning mode questions) by specifying a custom model provider and making it shadow the default 'openai' one as closely as possible.

Clearly this is not a good stable 'fix' or workaround, as it means users need to guess how to completely correctly emulate the openai model provider, which could silently change in any future update anyway unbeknown to the user. And what's worse, there seem to be some hardcoded checks whether the current model provider is "openai" in the code, meaning completely the same behaviour is likely not even possible to emulate using a custom model provider.

I think this shortcoming, in particular regarding planning mode questions, should be addressed. In previous versions of Codex CLI planning questions never timed out, and it should be possible for users to opt in to that behaviour.

I’m running into the same class of problem, especially in Plan Mode.

For me the main issue is not just the timeout duration, but that user-input prompts can auto-resolve and let Codex continue with recommended/default choices that I did not explicitly approve. Increasing stream_idle_timeout_ms feels too broad because it affects unrelated stream-idle behavior and requires shadowing the built-in OpenAI provider config.

I’d be happy to help address this if the maintainers think it is a good fit for an external contribution.

A narrow fix I’d be willing to implement would be something like a dedicated config option for structured user-input auto-resolution, for example:

```toml
[tools.experimental_request_user_input]
enabled = true
auto_resolution_enabled = false
auto_resolution_grace_ms = 60000
auto_resolution_countdown_ms = 60000

The intended behavior would be:

  - `auto_resolution_enabled = false` disables auto-resolution entirely;
  - `auto_resolution_grace_ms` controls how long Codex waits before showing the visible countdown;
  - `auto_resolution_countdown_ms` controls how long the visible countdown runs;
  - defaults preserve current behavior;
  - structured Plan Mode questions still work normally.

I’m aware external PRs are by invitation only, so I’m not trying to bypass the contribution process. If this direction is acceptable, I’d be glad to prepare a focused PR for this issue and would also like to contribute to Codex development more generally where the team thinks outside help would be useful.

I'm facing a similar issue in plan mode. Sometimes when Codex asks questions and I have to take a while to answer, it automatically marks them as "not answered" and skips them. It's happening in the VSCode extension, I haven't tried CLI a lot to validate whether it happens there as well or not.

<img width="578" height="220" alt="Image" src="https://github.com/user-attachments/assets/920f382f-1ef9-4b66-bade-1b7766e2ad37" />

We should be able to configure or at least disable this behavior.

Also a suggestion: The timeout should be visible when it's present. So it'd be cool to have a timer displayed somewhere so the user knows that this question has a an auto-resolution countdown.

---

I have an unrelated optional educational side question (feel free to ignore it); @otanim mentioned stream_idle_timeout_ms, does it mean that Codex keeps a connection stream alive while we're answering to questions ? If yes, why ?

These Q&A really should not timeout. Noone has to need to stare at the screen to constantly check for questions. It was not having this bad behavior before, so it's something that should be reverted.

I absolutely agree - it often enough hinders the ability to even mildly multitask, because you can't risk switching tabs or desktops just in case you suddenly get a question during planning, and if you miss it you're rolling the dice on whether you have to immediately replan again.

Totally agree, and issue #28969 goes into the same direction. Since tickets are prioritized according to reactions, let's unite our thumbs up reactions on both to not split them across the community, hoping this will get resolved soon.

Still nothing change about this. Is there no codex contributor uses it? Or all pure vibe coder, and everyone think this feature good?

Coming back almost daily to this issue, it's baffling to me that there's still no way to disable this ridiculous timeout, makes multitasking wastes so much time.

EDIT: the workaround below doesn't work consistently for me.

One workaround exists and works for me, but it is still crazy that this isn't being fixed properly as it completely destroys planning mode...

https://github.com/openai/codex/issues/28969#issuecomment-4847883145

Turns out you can just ask Codex to please not apply the auto-timeout. I put it into my Codex home AGENTS.md

I have a $Planning skill in which I explicitly ask Codex never to use timed questions. It was a good workaround until today's update rolled out.

On the bright side, I can now thankfully see a timer on the questions on my VSCode Extension, but Codex itself (after switching to 5.6 Sol) is now ignoring my $Planning skill's instructions and setting the timer anyway. I don't know if it's because of the model or the recent harness update.

It only listened to me once; When another pack of questions were skipped because I was focused on another window, I interrupted and said Please ask your questions again without timers, NEVER USE TIMERS, Let me answer them.

In that one case Codex didn't use the timers, but it used timers again for the later questions after that.

Turns out you can just ask Codex to please not apply the auto-timeout ...

So yes, this does work sometimes but it's not reliable. This is extremely annoying, why do we even have auto-resolution at all ?
If I wanted auto-resolution, I wouldn't have used plan-mode.

So yes, this does work sometimes but it's not reliable. This is extremely annoying, why do we even have auto-resolution at all ? If I wanted auto-resolution, I wouldn't have used plan-mode.

This is a complete squandering of context length, and it’s gambling that the model will see this instruction every single time it calls the tool. Actually, even the most advanced models can’t reliably do that.

Maybe this is exactly what OpenAI intends — make you skip answering the question, halt your working progress, and demand that Codex either re-ask or answer directly, all while burning your tokens on utterly pointless busywork.