Windsurf Cascade keeps spinning? Check progress before changing scope.

A spinner alone cannot distinguish planning, an active command, workspace scanning, or a stalled interface. Observe process and file activity before testing a narrower workspace.

Do this first: Preserve the diff and inspect progress first. If indexing is plausible, test one narrower workspace scope using the ignore controls documented for your installed version.

What the failure looks like.

The plan remains on screen, the spinner continues, and CPU or memory climbs while the repository produces no clear next action.

Why it happens.

A spinner does not identify the cause. Official documentation describes indexing overhead and ignored paths; investigate those only when process activity and a controlled scope comparison support the hypothesis.

Fix it without losing the task.

Note whether the plan or output changes, whether CPU or disk activity continues, and whether a terminal process is active. Do not infer the model is frozen from the spinner alone.

Save open work and check the Git diff. Record the workspace scope and any ignored paths before changing indexing settings.

If the project contains generated or dependency-heavy folders, test a narrower scope using Windsurf documented controls and compare startup/progress once.

Restore the original scope if the result does not change. Use the captured timing and logs to decide whether the issue is indexing, command execution, or an unresponsive session.

What the next AI should receive.

Windsurf version, workspace and ignored-path scope, visible plan progress, CPU/disk or terminal activity, changed files, one indexing/scope comparison, and its result.

Check before restarting

Check whether the plan is still changing, a command is running, or the UI is only showing a spinner. Preserve the working tree before narrowing workspace scope or restarting.

Boundary of the evidence

Repository size and indexing are possible factors, not a confirmed cause from the spinner alone. A narrower workspace test can provide evidence but is not a guaranteed fix.

Diagnostic checkpoint

A narrower workspace test is useful only when its scope and observed progress are recorded for comparison.

How ShardStitch helps.

ShardStitch can preserve the current task boundary and local diff while you distinguish a running command, workspace scan, and stalled interface. It cannot inspect Windsurf indexing internals or stop a remote/model request.

Workspace scope evidence.

Official indexing and ignore-file guidance, checked September 27, 2026, explains excluded paths and legacy ignore filenames. Current vendor documentation uses Devin Desktop naming. This supports a reversible scope test, not a diagnosis that indexing caused your spinner.

FAQ.

Does a Cascade spinner mean indexing is the cause?

Not by itself. Check visible progress, process activity, active terminal work, and logs. Treat repository indexing as a hypothesis until a controlled scope comparison supports it.

Should I add every large folder to .codeiumignore?

No. Exclude only paths that are generated, vendor, or irrelevant to the task, and check the current Windsurf guidance. Preserve the original ignore rules so the change can be reversed.

Scope note: Evidence boundary: use this as a diagnostic workflow, not a verified Windsurf-specific root-cause report. Change one workspace or indexing variable at a time and keep the result.