Add request user input auto-resolution timer#28235
Conversation
avinashkamat48
left a comment
avinashkamat48
left a comment
There was a problem hiding this comment.
auto_resolution_ms is currently treated only as an enable flag, while the actual timeout is hard-coded to 60s hidden grace plus 60s visible countdown. That means a request asking for a shorter or longer auto-resolution window will still resolve after 120s. Since the protocol field is a duration, the TUI should either honor the provided value when computing the due time/countdown, or the field should be renamed/documented as a boolean before clients start depending on the millisecond value.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f9b58d56aa
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| fn auto_resolution_timing_at(&self, now: Instant) -> AutoResolutionTiming { | ||
| // The TUI currently treats autoResolutionMs as an enable signal. The | ||
| // model-provided duration value is reserved for future runtime policy. | ||
| if self.request.auto_resolution_ms.is_none() || self.auto_resolution_snoozed { |
There was a problem hiding this comment.
When callers pass autoResolutionMs=60000 or 240000, this ignores the advertised timeout and always waits 60s hidden + 60s visible, so 60s prompts resolve a minute late and 240s prompts resolve two minutes early. Please base the due time on the supplied value. guidance
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Intentional right now to introduce consistency.
| let needs_redraw = view.pre_draw_tick(now); | ||
| let view_complete = view.is_complete(); | ||
| if view_complete { | ||
| self.view_stack.clear(); |
There was a problem hiding this comment.
When a request_user_input prompt auto-resolves while stacked above an unresolved modal such as ApprovalOverlay, clear() drops the lower modal and on_active_view_complete() re-enables the composer even though that request never completed. Key-driven completion already pops only the active view; this tick path should do the same so pending lower modals are preserved.
Useful? React with 👍 / 👎.
fcoury-oai
left a comment
fcoury-oai
left a comment
There was a problem hiding this comment.
Thank you for addressing this, it will be very helpful and finally allow us to ask questions in default mode.
The only remark would be changing the autoResolutionMs from Option to a bool to better reflect what it's being used for: either wait 120s or wait forever.
Code looks good, approved 👍
3 participants
Summary
request_user_inputprompts whenautoResolutionMsis present.Notes
autoResolutionMsas an enable signal and intentionally does not use the provided duration value for the countdown policy.Auto resolution
Screen.Recording.2026-06-14.at.5.25.53.PM.mov
Snooze after interaction
Screen.Recording.2026-06-14.at.5.27.24.PM.mov