Windsurf Cascade recovery guides.
Choose the guide by the symptom you can observe. These pages focus on preserving project work and preparing a verified continuation; they do not claim ShardStitch can repair a stuck Windsurf process.
Choose the matching symptom.
The IDE freezes after a response
Use this when the editor becomes unresponsive after Cascade replies. Record whether the terminal and file changes are still available before restarting.
Cascade stays on a spinning plan
Use this when the visible plan does not advance. Check the repository and activity before sending the same request again.
Cascade repeats unsuccessful edits
Use this when edits cycle without a passing check. Preserve the diff and failed verification so the next attempt does not repeat the same path blindly.
Prepare a continuation, not a session restore.
ShardStitch reads available local project evidence such as changed files, diffs, commits, notes, failed attempts, and verification state. Review the packet against the working tree before you restart Cascade or switch tools. It cannot recover unsaved edits, hidden remote state, or a private conversation that never reached disk.
What to include in the handoff.
Windsurf version, exact visible symptom, last completed action, and whether the editor remains responsive.
Changed paths, current diff, commands already run, and the result of the last test or check.
One bounded action and the verification that will show whether it worked. Label any suspected cause as unverified.
A public Windsurf IDE freeze report (#284) describes repeatable freezes after Cascade responses on Linux, on Windsurf 1.9544.35 (1.106.0), with a reporter-observed renderer stall. It is an individual, open issue, not a vendor-confirmed root cause, a universal defect, or a documented fix. ShardStitch provides a local continuation packet; it does not control Windsurf or repair the editor process.