Cursor SSH Remote Connection Drops Mid-Edit: 6 Fixes

You are deep in a Composer session on a remote dev box over SSH Remote. Halfway through a refactor, the bottom-right status bar flips red: Disconnected from <host>. The agent transcript vanishes, an unsaved buffer turns gray, and reconnecting spawns a new remote extension host that does not see your prior chat. This is almost never Cursor “crashing” — it is the SSH transport dying. The fix lives in three layers: client keepalives, network path stability, and the remote extension host’s own lifecycle.

TL;DR — the fastest fix that resolves most cases. Add ServerAliveInterval 30 and ServerAliveCountMax 6 to the Host block in your local ~/.ssh/config, then close the remote window and reopen it. That alone stops the idle-timeout drops, which are the most common cause as of June 2026. If the connection dies seconds after reconnecting (not after idle) and you see ssh: Could not resolve hostname 7b22..., you are hitting a different problem — the anysphere.remote-ssh extension bug introduced in v1.0.51. Skip to the reconnect-bug fix for that one.

Which bucket are you in?

Match your symptom to the cause before changing anything. The fixes are very different.

Symptom pattern	Most likely cause	Go to
Drops after a quiet pause; constant typing never drops	Client keepalive too long / unset	Step 1
Fails immediately on reconnect; Could not resolve hostname 7b22...	remote.ssh v1.0.51+ hex-authority bug	Step 0
Drop tracks walking, sleep/wake, or VPN reconnect	Wi-Fi roam / IP change	Step 5
Very regular drops (~every 90-120s idle)	Server ClientAliveInterval mismatch	Step 4
dmesg shows Killed process ... cursor-server	Remote extension host OOM	Step 3
df -h ~ shows 100% on remote	Disk-full on remote $HOME	Step 2
uptime shows the box just rebooted	Box slept / spot instance preempted	Step 6

Common causes

Ordered by likelihood for SSH Remote disconnects.

0. The anysphere.remote-ssh v1.0.51+ reconnect bug (new, May 2026)

This one is not a transport problem at all. The anysphere.remote-ssh extension shipped a stricter authority validator in v1.0.51 (May 22, 2026) that fails to hex-decode a saved remote authority before handing it to OpenSSH. When you reopen a recent/saved remote workspace it tries to connect to the raw hex string instead of user@host.

How to spot it: The failure is immediate on reconnect, not after idle, and the error is literally ssh: Could not resolve hostname 7b22686f73744e616d65...: nodename nor servname provided. Fresh Connect to Host... entries work; only restoring a saved workspace breaks. As of June 2026, Cursor (Colin on the forum) has confirmed the validation change and said saved-workspace backward-compatibility will not be restored, so the practical fix is to downgrade the extension or re-add the host fresh.

1. SSH keepalive interval too long (or zero)

A NAT box, corporate proxy, or cloud load balancer silently drops idle TCP flows after a fixed idle window. Corporate firewalls are the strictest, often reaping idle flows in 60-300 seconds; managed cloud NAT is more generous (as of June 2026, AWS NAT Gateway idles out at 350s, Azure NAT Gateway at 4 minutes, Google Cloud NAT at 20 minutes for established TCP). If your ServerAliveInterval is unset or higher than the shortest middlebox timeout in the path, the connection looks dead and gets reaped.

How to spot it: Drops happen after a quiet pause (you stepped away, agent was thinking). Editing constantly never drops. ~/.ssh/config has no ServerAliveInterval.

2. Wi-Fi roam or VPN handover

Your laptop hops Wi-Fi access points, your VPN reconnects, or your IP changes when a corporate gateway re-leases. The original TCP socket is dead; Cursor’s resilience layer cannot re-bind.

How to spot it: Drop correlates with walking between rooms, sleep/wake, or tailscale status showing a relay swap. The macOS console log shows en0: link state change near the drop.

3. Remote extension host OOMs

The cursor-server process on the remote box hits its cgroup or container memory cap. The host dies, the SSH socket stays up briefly, then Cursor reports lost connection.

How to spot it: dmesg | tail on the remote shows Out of memory: Killed process ... cursor-server. Or the remote ~/.cursor-server/data/logs/<date>/remoteagent.log ends with FATAL.

4. Disk-full on remote $HOME

Cursor writes telemetry, logs, and language-server caches under ~/.cursor-server. A full disk causes the host to error and exit; the agent looks like it disconnected.

How to spot it: df -h ~ on the remote shows 100% use. ~/.cursor-server/data/logs/ is multi-GB.

5. Remote box went to sleep / autoscaler killed the instance

Spot instances, ephemeral preview environments, and laptops left lid-closed all terminate without notice. The SSH session dies cleanly from the kernel side.

How to spot it: uptime on reconnect shows the box just rebooted. Cloud console shows the instance was replaced or preempted.

6. Server-side ClientAliveInterval mismatch

If the remote sshd_config has ClientAliveInterval 30 and ClientAliveCountMax 3, the server kicks the client after 90s of one-way silence — even if the client thought everything was fine.

How to spot it: Drops are very consistent (every ~90s or 120s of idle). Remote /var/log/auth.log shows Timeout, client not responding.

Before you start

• Note whether drops are time-correlated (always at ~N minutes) or random — deterministic points to a timeout, random points to network or OOM.
• Capture the exact text of the status-bar error and the timestamp.
• Confirm whether vanilla ssh <host> from a terminal also drops under the same idle pattern. If it does, the issue is purely SSH transport, not Cursor.
• Record your ~/.ssh/config keepalive settings before changing anything.

Information to collect

• Output of ssh -v <host> for the first 10 lines (proves which config + identity loaded).
• ~/.ssh/config Host block for the dev box.
• Remote dmesg | tail -50 immediately after a drop.
• Remote df -h ~ and du -sh ~/.cursor-server.
• Tail of ~/.cursor-server/data/logs/<latest>/remoteagent.log on the server.
• Whether you are on Wi-Fi vs ethernet, and whether a VPN/Zero-Trust agent is in the path.

Step-by-step fix

Ordered cheapest to most invasive.

Step 0: Rule out the v1.0.51 reconnect bug

Only relevant if you see ssh: Could not resolve hostname 7b22... immediately on reconnect. First check the installed extension version: open the Extensions panel (Cmd/Ctrl+Shift+X), search Remote - SSH, and look at the anysphere.remote-ssh version. If it is 1.0.51 or later, you have two options.

Quick path — re-add the host fresh instead of restoring the saved workspace. Cmd+Shift+P -> Remote-SSH: Connect to Host... -> + Add New SSH Host..., retype ssh user@host, and connect. Fresh entries decode correctly; only the stored authority is mangled. The cost is losing that workspace’s saved remote chat history.

Durable path — downgrade to 1.0.50 and stop it from auto-updating. In the Extensions panel, click the gear on Remote - SSH -> Install Specific Version... and pick 1.0.50. Then disable auto-update so it does not silently revert: open Settings (Cmd/Ctrl+,), search extensions.autoUpdate, and set Extensions: Auto Update to None (or right-click the extension -> Auto Update to toggle it off for just this one). Reload the window. This is the only fix that keeps saved-workspace reconnects working as of June 2026.

Step 1: Enable client keepalives in ~/.ssh/config

Add or update the Host block:

Host devbox
  HostName 10.0.0.42
  User you
  ServerAliveInterval 30
  ServerAliveCountMax 6
  TCPKeepAlive yes

ServerAliveInterval 30 sends a keepalive every 30 seconds, which is safely under every middlebox timeout in the path — even strict corporate NATs that reap idle flows in 60s. ServerAliveCountMax 6 means six missed replies (3 minutes) before SSH declares the link dead, which tolerates brief Wi-Fi blips. Restart Cursor’s remote window after editing — the SSH config is read fresh on each new connection, not live.

Step 2: Move the server install off the home volume on the remote

If df -h ~ shows pressure, the cleanest fix is to relocate the whole remote server tree to a bigger volume. Cursor inherits VS Code’s remote.SSH.serverInstallPath setting: open Settings (Cmd/Ctrl+,), search remote.SSH.serverInstallPath, and map the host to a roomy path, for example:

"remote.SSH.serverInstallPath": {
  "devbox": "/var/tmp"
}

Cursor then installs the server under that directory (for example /var/tmp/.cursor-server) on the next connection instead of ~. Either delete the old ~/.cursor-server after switching, or prune just the bulky logs:

find ~/.cursor-server/data/logs -mtime +7 -delete

This eliminates cause #4 entirely and usually frees several GB. Note: remote.SSH.serverInstallPath controls where the server is installed; it does not move data after the fact, so set it then reconnect.

Step 3: Raise the remote extension host memory budget

If dmesg shows OOM kills, the cursor-server Node process needs more heap. Edit your remote shell rc:

echo 'export NODE_OPTIONS="--max-old-space-size=4096"' >> ~/.bashrc

Then kill the running server so it picks up the new env:

pkill -f cursor-server

Cursor will spawn a fresh remote host on the next connection. For repos over 100k files, 8192 is more realistic.

Step 4: Add a server-side keepalive that matches the client

On the remote, edit /etc/ssh/sshd_config (or the user-level ~/.ssh/sshd_config.d/ if your sshd is configured for it):

ClientAliveInterval 30
ClientAliveCountMax 6

Reload sshd:

sudo systemctl reload sshd

Symmetric intervals prevent the case where the server impatiently kicks a client that thought it was healthy.

Step 5: Switch to a stable transport if the network is hostile

For flaky Wi-Fi or VPN handovers, mosh or tailscale ssh survives IP changes:

brew install mosh

Cursor itself does not speak mosh, but for the underlying box you can wrap a stable tunnel:

tailscale up
ssh -o ProxyCommand="tailscale nc %h %p" devbox

Or use Cursor’s Tunnels feature instead of raw SSH — it auto-reconnects on IP changes.

If the reconnect itself hangs on Opening Remote... over a slow link, raise remote.SSH.connectTimeout (Settings -> search remote.SSH.connectTimeout; default is 15 seconds) to 60 so a slow server install does not abort the handshake. As a last resort when the bundled anysphere.remote-ssh keeps misbehaving, the community open-remote-ssh extension is a drop-in alternative some users prefer:

cursor --install-extension jeanp413.open-remote-ssh

Step 6: Treat the remote as ephemeral and persist state explicitly

If your dev box is a spot/preemptible instance, save the things that matter outside the box:

# Push uncommitted work to a wip branch every 5 min via a cron on the remote
*/5 * * * * cd ~/proj && git add -A && git commit -m "wip" --allow-empty && git push origin HEAD:wip-$(hostname)

Combine with Cursor’s Chats: Persist Remote History setting so the agent transcript syncs to your local profile. Now a drop costs you nothing.

Verify

• Open Cursor on the remote, leave it idle for 10 minutes, return — status bar stays green.
• Run a deliberately long agent task (large refactor) and watch turn-by-turn — no mid-stream disconnect.
• After a real network blip (toggle Wi-Fi for 5 seconds), the bottom bar should reconnect within 30s without losing the open editors.
• If you hit the v1.0.51 bug: confirm the anysphere.remote-ssh version reads 1.0.50 in the Extensions panel, then reopen the previously broken saved workspace — it should connect to user@host, not a hex string.

Long-term prevention

• Ship a team-wide ~/.ssh/config template with ServerAliveInterval 30 baked in.
• Provision dev boxes with at least 8 GB RAM and a logs/cache volume separate from $HOME.
• Add a daily cron to prune ~/.cursor-server/data/logs older than 7 days.
• Prefer Tailscale or Cursor Tunnels over raw SSH for laptop-to-cloud sessions.
• For spot instances, automate wip branch pushes every few minutes.
• Monitor dmesg and disk usage in your dev-box bootstrap script; alert before the box dies.
• After you settle on a working anysphere.remote-ssh version, set extensions.autoUpdate to None so a future release does not silently reintroduce the reconnect bug.

Common pitfalls

• Setting ServerAliveInterval 300 because “less chatter is better” — most corporate NATs drop idle flows in 120s, and the strictest in 60s.
• Editing ~/.ssh/config while Cursor still has an open remote window. The change does not apply until the next connection.
• Assuming the agent transcript is saved server-side. By default it lives in the local profile; a remote crash plus a stale local cache loses it.
• Running pkill cursor-server while editing — the buffer goes gray and any unsaved change vanishes. Save first.
• Blaming Cursor when ssh devbox from a plain terminal also drops at the same interval.
• Ignoring the remote ~/.cursor-server/data/logs/ directory growing into the tens of GB.

FAQ

Q: I see ssh: Could not resolve hostname 7b22... the instant I reconnect. What is that?

That hex string is your encoded SSH authority leaking through unmodified — a bug introduced in anysphere.remote-ssh v1.0.51 (May 22, 2026) that only triggers when restoring a saved/recent remote workspace. Either re-add the host fresh with Remote-SSH: Connect to Host..., or downgrade the extension to 1.0.50 and set extensions.autoUpdate to None. See Step 0.

Q: Cursor reconnects but the agent forgot everything. How do I keep the chat?

Enable Chats: Persist Remote History in settings — the transcript syncs to your local profile and survives remote host restarts. See also Cursor chat history lost on restart.

Q: My SSH config changes do not take effect.

Cursor reads ~/.ssh/config only when a new remote window is opened. Close the remote window, then Cmd+Shift+P -> “Reload Window” is not enough. Use “Remote: Close Remote Connection” first.

Q: Should I use a persistent screen/tmux on the remote?

It does not help Cursor — the remote extension host is a separate process from your shell. But a tmux for terminals inside the remote is still valuable as a fallback when the extension host restarts.

Q: Is mosh supported directly?

No, Cursor’s Remote-SSH transport uses standard SSH. Use mosh for a separate terminal session and Tailscale or Cursor Tunnels for the IDE itself.

Related

• Cursor chat history lost on restart
• Cursor indexing never completes
• Cursor IDE state out of sync
• Cursor MCP server not connecting

Tags: #Cursor #Troubleshooting #Debug #AI coding

Related Articles

Troubleshooting

Cursor Auto Routes a Hard Task to a Weak Model

Cursor's Auto router sends a complex refactor to a small model and you get shallow edits. Diagnose the routing signals and force the right model for hard tasks.

May 24, 2026 #Cursor #Troubleshooting

Troubleshooting

Cursor Chat or Composer History Missing After Restart

Cursor reopens with an empty chat list, only the latest thread, or stuck on 'Loading Chat'. Usually a workspace-hash change, a botched update migration, or a corrupted state.vscdb. How to recover and prevent it.

May 24, 2026 #Cursor #composer

Troubleshooting

Cursor Cmd-K Inline Edit Spinner Never Returns: Fix It

Cmd-K (Ctrl+K) spins forever or shows "Taking longer than expected…" with no diff. The fast fix: Reload Window or update Cursor. Walk the six verified causes.

May 24, 2026 #Cursor #Troubleshooting

Troubleshooting

Fix Cursor Extensions: Network Error or Empty Marketplace

Cursor's Extensions panel shows a network error, empty list, or a stuck spinner. Cursor uses Open VSX, not Microsoft's marketplace. Pick the right cause and fix it fast.

May 24, 2026 #Cursor #extensions

Troubleshooting

Cursor MCP Server Shows Disconnected or No Tools

Added an MCP server in Cursor but it stays disconnected, or no tools appear in chat. 90% of the time it's a bad PATH, a JSON typo, or a stdout leak. Diagnose and fix in five minutes.

May 24, 2026 #Cursor #mcp

Troubleshooting

Cursor Python Venv Not Detected (Wrong Interpreter)

Cursor uses system Python instead of your project venv, breaking imports, linting, and agent edits. Fix the interpreter picker, venv discovery, shell PATH, and the new Python Environments panel.

May 24, 2026 #Cursor #Troubleshooting