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.
Updated Cursor again today, and still the AskTool times out.
Version: 3.9.0
Also, adding a button to minimize the Questions panel and allowing me to read what the agent said on the chat would be welcome - if you don’t know what I mean, press Ctrl + (or Cmd +) to make the font larger and you’ll see (the last user prompt occupies the top part of the window, the prompt box + the panel take the center->bottom part, and I get a little slot free to read the chat thread).
Thanks
P.S. I really can’t say how long it takes to time out. A few minutes, I guess, perhaps more than 5, but either I miss the panel opening, or I miss the timeout occurring, sorry.
Hey, thanks for coming back with an update. The fact that the timeout still happens on 3.9.0 is exactly what we needed to confirm. Auto-skip Questions skipped by the user, continue… shouldn’t show up at all on the latest builds, so if it’s still triggering for you, that’s an anomaly. I’ve already passed your case to the engineers, tied to 3.9.0 and your previous Request IDs.
To help the engineers confirm it’s the same code path on the new build, can you grab one fresh Request ID on 3.9.0 via chat menu top right > Copy Request ID and post it here? Even one is enough.
On minimize or collapse for the questions panel, that’s a clear and reasonable request and I’ll pass it along separately. To make sure it doesn’t get lost in the bug thread, please create a separate post in Feature Requests so it’s easier to track and doesn’t mix with the timeout discussion.
I’m sorry to report this, but it still times out.
The panel is left open, but if I select an option and submit it, the panel close and nothing else happens.
Still lets the agent turn hung. I have a global Rule to instruct the agent to stop if the AskTool panel is skipped. It then writes a message and stops.
But when I write the next message on the normal chat input, it’s still left hanging as a pending message, until I force sending it.
Sometimes it takes more time to time out, other times it takes less. I set up two contrived tests on separate chat panels and they stood there waiting for one hour with no timeouts, but after that, another chat (a normal development one) timed out after a few minutes.
That’s perhaps why your team didn’t catch the but yet. It doesn’t happen always (the worst kind of bug).
Cursor v3.9.11
The intermittent part is what makes this especially hard to trust.
If the panel sometimes waits for an hour and sometimes skips after a few minutes, users cannot build a reliable habit around it. For questions that gate the next agent action, I would rather have an explicit expired state than a panel that still looks usable after the turn has already moved on.
Thanks for coming back with details, and extra thanks for the info about it being intermittent. That’s the most valuable clue here. The fact that two controlled chats waited an hour with no timeout, but a normal dev chat got skipped after a few minutes, explains why this is hard for us to catch on our side. The auto-skip message “Questions skipped by the user, continue…” shouldn’t trigger on current builds at all, so seeing it on 3.9.11 is an anomaly.
To tie this exact reproducible case to the investigation, can you share one fresh Request ID from 3.9.11, taken from a chat where the timeout actually happened? Chat menu in the top right > Copy Request ID. Even one is enough. If you can also catch the approximate time until it triggers, that’s helpful too, but not required.
@Jason_Luo1, your point about having an explicit expired state instead of a panel that looks usable makes sense. I’ll pass that along separately.
On the minimize or collapse button for the questions panel, the request is clear, but let’s move it to a separate post in Feature Requests so it doesn’t get lost in this bug thread. That’ll make it easier to track.
