The following has happened to me twice this week during longer brainstorming sessions with the agent. It asks multiple questions at once — sometimes up to 10 — and before I can answer them all, a timeout is reached and the model continues without waiting for my responses. This is especially frustrating because answering these questions requires sometimes significant thought and manual investigation. Once the timeout hits, there is no way to recover the answers I had already written.
I suggest increasing the timeout or removing it entirely. If users want to skip the questions, they can always do so manually.
My case was that I had to postpone answering the questions at the time they were presented. When I came back to Cursor, the tool simply skipped automatically and the model received the wrong information that I chose to skip answering the questions.
At least two things must change in this tool:
Allow users to tweak any existing timeout mechanism, including turning it off completely, and
Provide proper answer to the model when there was a timeout instead of a skip.
It is useful to have a timeout in the Ask Questions tool for cases when we leave the agent running alone and expect it to figure things out by itself. But there are cases where we just don’t want the agent to follow through without our own answers for any particular reason.
Hi there, sorry for the delay. I missed this one in my first pass of open posts.
You’ve pinned down two separate problems, and both are fair:
The timeout isn’t tunable — there’s no way today to extend it or turn it off, so a slow-but-deliberate answer can get cut off.
A timeout is reported to the model as a skip — the model can’t tell whether you opted out or just ran out of time, so it proceeds as if you skipped. This default is enabled to be the best “default behavior” for the majority of users, but it might not be the best default for you personally, and I totally get that.
In the meantime, if a prompt times out, you can send your answers as a normal follow-up message, and the agent will pick them up. Not a fix, but it saves the thinking.
+1 — and I would frame the two changes @douglascaetano and @kevinn identified as the actual fix:
Make the timeout tunable (including off). A deliberate, well-considered answer should not be cut off, and for interactive sessions many of us would disable it entirely.
Report a timeout to the model as a timeout, not a skip. Today the return string is byte-identical to a real user skip, so the model treats “ran out of time” as “user opted out / consented to defaults.” A distinct return string (e.g. “prompt timed out; user did not respond”) would let the agent stop and wait instead of guessing.
The second point is really a safety issue: on a high-impact prompt the agent currently proceeds on an uninformed default. Hit this again today on Cursor 3.7.19 (macOS), so it is still very much live. Related confirmed bug report: Questionnaire timeout falsely treated as “skipped”.
Cursor team needs to fix it!! It is so annoying … it has turned an amazing tool into a hand-to-hand fight. They have done it so that the background agents don’t get stuck, but failed to consider the user experience for people that don’t use background agents.
At the very least they could have added an option to turn it off!
Bumping this with a cross-reference, since it’s now at 10 likes and several people in-thread are hitting the same wall.
The two changes @douglascaetano and @kevinn already identified remain the right fix: (1) make the timeout tunable, including fully off, and (2) report a timeout to the model as a timeout, not as a skip.
Worth linking the confirmed-bug side of point (2): Questionnaire timeout falsely treated as “skipped”. The problem there is that the timeout return string is byte-identical to a real user skip, so the agent treats “ran out of time” as “user consented to defaults” — which on a high-impact prompt is a genuine safety hazard, not just an annoyance. A distinct return string plus a user-configurable (or disable-able) timeout would resolve both threads together.