Cursor Agents Went Down Tonight, and I Briefly Forgot I'm a Developer

Tonight my coding agents stopped answering. I sent a task, got an error, sent it again, got another error, and then did what any senior developer with years of experience would do: I stared at the screen for a couple of minutes waiting for someone else to write the code.

Then it hit me. I know how to do this. I've been doing it a lot longer than AI agents have existed. I opened VS Code, connected to the server over SSH and got back to work.

It's a little funny how fast you get used to having help. It's also a good reminder that AI tools make me faster, but they're not the job. The job is still knowing your systems well enough to keep going when the help goes quiet.

When I checked Cursor's status page around 10 PM Central on October 29, there were two open incidents, both marked "investigating":

• Cloud Agent Degradation, posted at 6:29 PM CDT: "We are investigating a degradation to Cloud Agents." Cloud Agents, Automations and the IDE were all listed at degraded performance.
• Service Degradation with VS Code Extensions, posted at 4:38 PM CDT, also affecting the IDE.

No cause and no ETA yet. That's normal early on, and it's not a knock on anybody. Every platform has a bad night. What matters is what you do with yours.

Agents are a layer on top of the work. Underneath, it's still a server, a repo and a terminal. If you can reach those, you can keep shipping.

In VS Code, the Remote - SSH extension gets you there in about thirty seconds. Run Remote-SSH: Connect to Host from the command palette, pick a host from your ~/.ssh/config and open the project folder. You get the full editor, a terminal on the box and your extensions running remotely. It's the same server the agent was working on, just with you driving.

If you don't have a host entry ready, now's a good time to make one, so the next outage costs you thirty seconds instead of ten minutes:

Host myapp-prod
    HostName your.server.example
    User deploy
    IdentityFile ~/.ssh/id_ed25519

This is the part people skip, and it's the part that bites. An agent that died mid-task can leave things half done: a branch with three of five commits, a migration that ran on one table but not the next, a file it was in the middle of rewriting. If you start typing on top of that without looking, you end up with two versions of the truth.

Here's what I do, in order.

On your machine and on the server, see exactly what's there:

git status
git branch --show-current
git log --oneline -10
git stash list
git fetch --all --prune

Uncommitted changes, a stash you didn't make or a branch you don't recognize are all clues about where the agent was.

Cloud agents usually work on their own branch and push as they go. Fetch and see what made it up:

git log --oneline main..origin/the-agent-branch
git diff main...origin/the-agent-branch --stat

Check for an open pull request too. A half-written PR description is often the best summary of what the agent planned and what it actually finished.

If you can still read the agent's last messages, copy its plan and its last "done" summary somewhere you'll find it, like the PR description or your task tracker. Don't drop a NOTES.md into the repo just to hold it. That's clutter you'll forget to delete. Git and the PR already track the code; you only need to capture the intent.

This is where an interrupted agent can do real damage. Look at anything that changes state:

• Database migrations. Check the migrations table against the migration files. A half-applied migration is the one thing you really don't want to guess about.
• Deploys. Check whether a deploy was in progress and which commit is actually live.
• Background processes. Look for a long-running script, queue worker or screen/tmux session the agent started.
• Temp files. Dumps, exports and scratch copies the agent made and meant to clean up.

Work on the agent's branch or a fresh one off it, never straight on main and never directly in production files. Commit under your own name and email so the history is honest about who did what. Small commits with clear messages help most here, because the agent will need to read them when it comes back.

Write one line where your team (or just future you) will see it: "Agent stopped at X, I picked up Y, Z is still open." Thirty seconds now saves a lot of "wait, who did this?" tomorrow.

Don't just hit retry on the old task. The agent's context is stale now, because you changed things while it was gone.

• Tell it what changed. Point it at the branch, the commits you added and what's still left.
• Make it pull first. One writer per branch at a time. If you and the agent both push to the same branch without syncing, you'll spend your morning untangling it.
• Re-check anything it was halfway through. If it was mid-migration or mid-deploy, verify the real state yourself before letting it continue.
• Clean up. Delete temp files and stray stashes, and finish with a clean git status. No .bak copies. Git already has your history.

I'm all in on AI-assisted development. It's made me faster and, honestly, it writes better comments than a lot of the code I've inherited. But tonight was a good gut check. The agents are a tool. The skill is still yours: reading a repo, understanding a server, knowing what's safe to touch.

So laugh at yourself for the two minutes you spent waiting for a robot to do your job, then SSH in and get back to it. That's what I did.

If you want a hand setting up a workflow that keeps working when your tools don't, get in touch.

• Cursor status page, incidents "Cloud Agent Degradation" and "Investigating Service Degradation with VS Code Extensions," checked October 29, 2026 around 10 PM CDT
• Visual Studio Code docs, "Remote Development using SSH"
• Cursor, "Security notice: malicious version of Anthropic.claude-code (2.1.313) identified in the Cursor Extension Marketplace" (October 29, 2026)