Agent stopped retrying
The connection was interrupted repeatedly without saving progress, so the agent stopped to avoid repeating the same work. Retry to continue from the last saved state. Request ID: d70a3663-3e72-4a14-aafa-812ea9fdd65f
the client is Cursor 3.22.12 on a Windows AWS WorkSpace, HTTP/1.0 is set, and the failure is in the main window
For AI issues: add Request ID with privacy disabled
Request ID: d70a3663-3e72-4a14-aafa-812ea9fdd65f
The connection was interrupted repeatedly without saving progress, so the agent stopped to avoid repeating the same work. Retry to continue from the last saved state.
Agent turn stopped after repeated resume attempts made no progress
RetriableError: Agent turn stopped after repeated resume attempts made no progress
at GbS (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7537:6850)
at async gxa.run (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7537:16790)
at async Rve.runAgentLoop (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:8939:31457)
at async Foc.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:20940:17007)
at async Foc.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:20940:39112)
at async cGe._submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:8917:4491)
at async cGe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:8912:72061)
at async DEm.submitMessage (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:8964:40067)
at async TjT.submitMessage (vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:22140:27195)
at async vscode-file://vscode-app/c:/Users/apalumbo/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:19497:82224
Thanks for the details and the request ID. The agent’s connection closed partway through the turn, and the two automatic retries also closed before they could save any progress. At that point, Cursor stops retrying on its own, so it doesn’t repeat the same work. Using Retry on the message continues from the last saved point.
To see why the connection is closing on this Workspace, could you share two things?
Open Cursor Settings > Network, click Run Diagnostics, and paste the results here.
Open the Command Palette and run “Capture and Send Debugging Data”. If it says the upload worked, just let us know here. If it saves a zip file instead, please send it to me in a direct message rather than posting it publicly.
This is happening from the agents window. Does this help?
What I can add to your report
For the repro/description, the concrete signal from this session: three StrReplace calls on nbk/reports/06_***.ipynb each reported “interrupted by the user” after extreme durations (~5,619,621 ms, ~1,722,523 ms, ~2,585,262 ms — i.e. ~26–94 min hangs) — yet in each case the edit actually applied to disk (verified: single clean copy, valid JSON). So the symptom is: StrReplace on a large single‑line JSON (notebook) cell completes the write but doesn’t return, appearing to hang until manually interrupted.
If your build does show a command literally named “Capture and Send Debug Data” (some builds vary), tell me the exact string and I’ll confirm what it maps to. Want me to also log this tooling issue under a [hub] note in the work log so it’s captured?
That last bit gave me a clue. I think it may just be that the jupyter notebook file it’s trying to edit is too big. I’m moving to a jupytext format to see if that fixes it.
Thanks, this is really helpful. The diagnostics look healthy.
We can see a clear pattern: each time the connection closed, it was right after the agent edited that large notebook in nbk/reports. The edit saves to disk, but the connection closes before the agent gets confirmation, so the retries repeat the same edit and Cursor stops. That’s also why the edits looked like they hung. They actually finished in seconds and stayed marked as in progress after the drop.
To keep working in the meantime:
Ask the agent to change the notebook with a script in the terminal (e.g. Python with json or nbformat) instead of editing it directly.
Clear the notebook’s saved outputs to shrink the file, which makes direct edits much lighter.