This is more than a UX annoyance — the askTool timeout introduces functional bugs that break the chat workflow.
Observed incorrect behaviors:
Custom answers are silently discarded mid-typing. When writing custom (“Other”) answers to the agent’s questions, the timeout can expire while the user is still typing. The questions panel is cleared without warning, and all typed content is permanently lost with no way to recover it.
The questions panel remains open after timeout but is non-functional. After the timeout fires, the questions panel stays visible and appears interactive, but submitting answers at that point does nothing — no agent response is triggered. This is misleading and wastes the user’s time.
Any choice or custom answer submitted after the timeout is silently ignored by the model, yet the model’s turn remains in a pending/processing state. This means any new message the user types is queued and not delivered immediately. The user is then forced to manually press the Stop button to break out of the stuck state, just to be able to interact with the chat again.
Steps to Reproduce
Just leave the askTool questions panel open for a while.
Expected Behavior
If a timeout must exist, it must be cancelled automatically if the user has already made any selection or typed anything in the questions panel.
If the user did not interact with the questions panel, it should be dismissed and clearly marked as expired the moment the timeout fires, so the user is not misled into interacting with a non-functional UI.
If you don’t implement the automatic dismissal of the panel, then at least let answers submitted after the timeout to either be accepted and forwarded to the model, or the user should be clearly informed they were not sent.
The model’s processing state should not be left pending after a timeout-triggered submission failure; the chat should return to an interactive state automatically.
Ideally, the timeout should be configurable or disableable entirely - some users never want to let the agent proceed with defaults and really want it to wait for the answers, no matter how much time the user takes to reply.
Hey, thanks for the detailed report. The symptoms are really clear, and that helps.
Good news: the behavior you described, auto-skip on timeout for ask_question, was removed in recent builds. Now the questions panel blocks the turn and will wait as long as needed, with no auto-skip and no timer-based loss of typed text.
Your build f5bfa92e from June 15 should already include this change, but I want to make sure. Can you check a couple things:
Update to the latest Nightly via Help > Check for Updates and restart Cursor.
Reproduce the scenario. Leave the questions panel open for a while, then start typing a custom answer.
If the issue still happens on the latest build, let me know here and include the Request ID for that chat, right chat menu top right > Copy Request ID. There are a couple related edge cases around resuming the turn after an answer, and your case will help confirm if you are hitting one of them.
Thank you very much for your response. And I’m glad the team decided to fix this issue!
Unfortunately, it still not totally fixed yet.
I’m using the latest version 3.7.40
I created three contrived examples to test this, having the agent ask me for a question and letting it hang in there, until a timeout occurs:
a) I left the text cursor (caret) on the normal message text box, and I didn’t select any option
b) I left the text cursor on an automatic option “D Other…” that gets added to every question set, with a small text string already typed in, to emulate what happens when I’m typing and the AskQuestion tool times out and my answer is cleared
c) selected answer A but didn’t press Continue
The bad news is that all scenarios a) b) and c) timed out, sending this message to the agent: “Questions skipped by the user, continue with the information you already have”. And the questions panel was still left open, as usual, while the agent went ahead and did something else.
Scenario b) did take more time to time out, so I was hopeful for a moment, but alas, it also eventually timed out.
The difference between a) and c) is that in the later I already interacted with the panel, selecting an option, while on the former I didn’t interact at all. Anyway, no difference.
Here are the request IDs for examples:
a) 52938f6c-4412-4cc6-88b2-afacd97fc116
b) 80eb7d22-b87c-4182-9bc0-a20b15ad80c6
and c) 2ad477aa-c370-4163-b693-ca69ec93d3b0
Thanks for testing and sharing the Request ID for all three scenarios, that really helps.
The fact that auto-skip Questions skipped by the user… still triggers on your build is exactly the anomaly. In the latest builds, that behavior should be gone, and the questions panel should block the turn without a timer. Since you’re seeing the skip on f5bfa92e, it means the change didn’t reach you for some reason or it’s being overridden by something else. I shared your Request IDs and the three scenarios with the engineers so they can figure out why the timer still fires on this build.
A couple quick questions to narrow it down:
About how long does it take before the skip triggers in scenario a) when you don’t touch anything? Is it around 6 minutes or less?
After restarting Cursor, does the behavior stay the same in all new chats?
I can’t share an ETA for the fix yet, but I’ll post an update in the thread as soon as I have one.