What to Do When Cursor Is Down

If Cursor's AI features stop working, preserve your workspace before restarting or switching tools. The editor, the model request and a remote cloud agent can have different states. Knowing which one failed helps you keep moving without losing useful work.

Open the official Cursor Status page and match the incident to your affected surface. If you are still deciding whether the issue is local, use Is Cursor down?. Do not treat every slow agent as confirmation of a service outage.

Stop repeated prompts and inspect the workspace

Save open files and copy an unsent prompt into a local note. Record the last visible agent step and the exact error. Inspect the diff before approving another edit or asking the assistant to start over.

Check terminals for commands that are still running or waiting for input. A failed connection to an AI service does not establish that those commands stopped. Keep track of any test, publish or deployment operation whose result is unknown.

Pause new agent runs against the same files until you know who is editing them. Repeating the task in another window can create overlapping changes that take longer to untangle than the original interruption.

Confirm the boundary and tell your team

Try one small, harmless request if you need to compare behavior. Check whether local editing works, whether another teammate has the same symptom and whether the status notice names a model or specific surface.

Send an update with a concrete scope:

Cursor [IDE AI/CLI/cloud agents] is affecting [task]. Local editing is [working/not working]. We observed [error] at [time and timezone]. The official incident is [link], or confirmation is pending. Please avoid duplicate runs on [branch/task]. [Owner] will update us at [time].

If Claude is the implicated service, consult the Claude outage playbook. If repository access is the failure, use the GitHub playbook. Keep the team message centered on the blocked workflow rather than speculating about vendor blame.

Continue local development

Use Cursor's ordinary editing features if they remain available. Read the relevant implementation, run local tests, inspect logs and split a large task into smaller changes. Write a short checklist of what the assistant was expected to do next.

If the editor itself is unusable, open the existing repository in another installed editor. Confirm that your saved changes are present before editing further. Avoid reinstalling your entire environment or recreating the repository just because generation is unavailable.

Choose work with available inputs. Updating documentation, reproducing a bug and reviewing an existing diff do not necessarily require a new model request. If a test requires a remote dependency that is also unavailable, record that limitation rather than treating the unrun test as passing.

Handle IDE and CLI failures separately

For IDE requests, distinguish a network error from an account or model message. Cursor's network guidance can help when proxies or remote connections are involved. Follow targeted checks and keep organization security settings intact.

For CLI sessions, inspect the current directory, process state and last tool output. A command awaiting confirmation needs a different response from a failed generation. Save enough context to resume the task without reconstructing it from memory.

If another approved model is available, use it only after preserving the original work and checking the failure scope. Do not assume switching the model fixes repository permissions or a broken remote environment. Re-evaluate generated changes with the same review and tests you normally use.

Treat cloud agents as remote work

Cursor's cloud-agent documentation describes agents working in remote environments. Losing the interface is not proof that a run has stopped. Record its identifier and inspect remote state when the service permits it.

Before starting a replacement, check its branch, commits, logs and any resulting pull request. Fetch and compare rather than overwriting remote work. If the old run is still active, use the supported control to stop it or wait for its outcome before assigning the same task elsewhere.

Keep a clear handoff if you continue manually. List files you changed, checks you ran and remaining work. When the agent resumes, it needs the current repository state, not an assumption that the workspace has stood still throughout the outage.

Recover with a small task first

Read the provider's latest notes and test the exact feature you need. The shared status-page guide explains why a recovered headline and an unfinished remote run can coexist.

1. Confirm local files and unsaved buffers are safe.
2. Try a short request in the affected IDE or CLI surface.
3. Inspect interrupted commands and cloud-agent runs.
4. Compare local and remote changes before applying more edits.
5. Run the relevant tests on the combined result.
6. Resume one pending task, then restore the rest of the workflow.
7. Tell teammates which branches are available and which still have active owners.

Keep normal review boundaries. An outage does not make a large unreviewed diff more trustworthy. The useful recovery check is whether the intended change works and whether any old run can still modify it.

Take an optional break after the handoff

If everything useful is covered, join the Nines ping list for a small arcade that opens during qualifying official developer-tool outages. Degraded performance alone keeps it closed. It is an optional way to pass the wait once someone owns recovery.