AI AI Tools Guidebook
Troubleshooting

Cursor Settings Sync Overwrites Local Config on Other Machine

Cursor Settings Sync pushes outdated config to a second machine, clobbering local rules, keybindings, or MCP servers. Diagnose conflict direction, last-write-wins, and selective sync.

Published: Author: AI Productivity Guide Team 🌐 查看中文版本

You spent an hour on your laptop tightening Cursor: refined .cursor/rules, added two MCP servers, rebound Cmd+L. Next morning you open Cursor on the desktop — and the new rules are gone. Or worse: you open the laptop again later and the desktop’s old config has overwritten everything you did last night. Settings Sync uses last-write-wins on most categories, and the “winner” is whichever machine pushed most recently, not which one has the change you want. The remedy is not “disable sync” — it is understanding which categories sync, in what direction, and how to recover from a clobber without losing the good version.

Common causes

Ordered by likelihood for sync clobbers.

1. Last-write-wins overwrote your local changes

Settings Sync is not a merge — it is a push of the most recent local state. Machine B was opened after machine A’s edits but had stale state, so its push won.

How to spot it: In Cursor’s settings, “Settings Sync: Show Activity” shows the most recent upload was from the machine whose config you do not want. The timestamps tell the story.

2. Selective sync is enabled but the wrong categories are on/off

Cursor lets you sync only some categories (keybindings, extensions, snippets, UI state). If “Extensions” is off on one machine and on on another, install state diverges silently.

How to spot it: Cmd+Shift+P -> Settings Sync: Configure shows different category toggles between machines.

3. .cursor/rules is per-workspace and was never expected to sync

.cursor/rules lives inside the workspace, not in the user profile. If you cloned the repo to two machines and edited rules on one without committing, the other never sees it. This looks like a sync failure but is actually a git-state issue.

How to spot it: git status in the project shows uncommitted .cursor/rules changes on machine A. Machine B has the prior committed version.

4. MCP server config syncs but the binaries do not

MCP server entries in ~/.cursor/mcp.json get synced. The actual mcp-server-foo executable does not. Machine B receives a config pointing at a binary that is not installed.

How to spot it: Cursor on machine B shows MCP server entries but they fail to start with command not found errors. See also Cursor MCP server not connecting.

5. Sync paused or signed out on the source machine

If sync was paused, signed out, or hit an auth refresh failure, edits never reached the cloud. The other machine just sees the last successful push.

How to spot it: Status bar shows a small warning on the sync icon, or Settings Sync: Log Activity shows the last successful upload was hours/days ago despite recent edits.

6. Different Cursor versions interpret the same setting differently

A setting added in a newer Cursor version may not be respected by an older one — and the older version may strip it on its next push.

How to spot it: Both machines show the setting present, but on one it has no effect. Cursor: About shows different versions.

Before you start

  • Stop editing config on both machines until you decide which one has the version to keep.
  • Note the timestamps of your last intentional edit on each machine.
  • Identify whether the lost data is in user profile, workspace .cursor/, or somewhere else.
  • Make a manual backup of the current ~/.cursor/ (or %APPDATA%/Cursor/User/) on the machine you trust.

Information to collect

  • Output of Settings Sync: Show Activity on both machines (timestamps + machine names).
  • The categories enabled in Settings Sync: Configure.
  • cursor --version on both machines.
  • A copy of the disputed config files: settings.json, keybindings.json, mcp.json, .cursor/rules/*.
  • Sign-in identity on both machines — sometimes one is signed in with a personal account, the other with a work SSO account, and they sync to different buckets.

Step-by-step fix

Ordered cheapest to most invasive.

Step 1: Identify the canonical machine and pause sync everywhere else

Decide which machine has the config you want. On every other machine:

Cmd+Shift+P -> Settings Sync: Turn Off

When prompted, choose “Keep Local Data” — this stops further uploads from these machines while you stabilize.

Until the canonical state is restored, no other machine should sync.

Step 2: Back up the canonical state explicitly

On the canonical machine:

cp -R ~/.cursor ~/.cursor.backup-$(date +%Y%m%d-%H%M%S)

On Windows PowerShell:

Copy-Item -Recurse $env:APPDATA\Cursor $env:APPDATA\Cursor.backup

This is your insurance policy. If a future sync clobbers something, you restore from here.

Step 3: Push the canonical state with a forced upload

From the canonical machine:

Cmd+Shift+P -> Settings Sync: Turn On
Cmd+Shift+P -> Settings Sync: Show Activity

In the activity view, choose “Replace remote with local” (also surfaced as “Sync Now: Push Local”). This makes the canonical state the authoritative remote version.

Step 4: Re-enable sync on other machines with “Replace Local”

On each non-canonical machine:

Cmd+Shift+P -> Settings Sync: Turn On

When the sync conflict dialog appears, choose “Replace local with remote” — this discards the stale state and pulls the canonical version. Do this one machine at a time, verify, then proceed to the next.

Step 5: Move workspace-scoped config into git

.cursor/rules, .cursor/mcp.json (workspace-level), .vscode/settings.json, and .vscode/extensions.json should be committed:

git add .cursor .vscode
git commit -m "chore: pin workspace config"
git push

Now the second machine gets these via git pull, not Settings Sync — which is the correct boundary.

Step 6: Configure selective sync identically across machines

On each machine:

Cmd+Shift+P -> Settings Sync: Configure

Match the category toggles exactly. The minimum useful set is usually keybindings + snippets + UI state. Leave extensions OFF if you intentionally have different toolchains on different machines.

Verify

  • Edit a benign setting (e.g., font size) on machine A. Within 30 seconds, machine B reflects it.
  • Edit .cursor/rules on machine A — it should NOT sync via Settings Sync. It should arrive on machine B only via git pull.
  • Sign out and back in on machine B; pulled state matches machine A.
  • Settings Sync: Show Activity shows recent successful uploads with no conflicts.

Long-term prevention

  • Treat Settings Sync as for user preferences only (keybindings, theme, font). Never rely on it for project rules or MCP configs.
  • Commit .cursor/rules, .vscode/, and project-level .cursor/mcp.json to git.
  • Keep Cursor versions roughly aligned across machines — same minor at minimum.
  • Disable Extensions sync if you deliberately curate different extension sets per machine.
  • Tag major config changes with a manual backup snapshot of ~/.cursor/.
  • Use a single sign-in identity for Settings Sync across all your machines — mixing personal and SSO accounts splits state.

Common pitfalls

  • Choosing “Merge” in the conflict dialog and assuming it does a smart merge — Cursor’s “merge” is mostly union for some categories and last-write-wins for others. Inspect the result.
  • Editing config on two machines simultaneously while sync is active. Whichever closes last wins; the other loses silently.
  • Storing API keys in synced settings. They will end up on every machine and in the cloud sync store. Use environment variables or per-machine secret files.
  • Assuming .cursor/rules syncs because other config does. It does not — it is workspace-scoped.
  • Restoring a Cursor backup by copying only settings.json and forgetting keybindings.json, snippets/, and mcp.json.
  • Signing out of Settings Sync to “fix” a conflict, then signing back in and choosing “Replace remote” without backing up first — you may have just nuked the version you wanted.

FAQ

Q: Settings Sync says “merged” but my keybindings on machine B are wrong.

Keybindings are typically last-write-wins, not merged. Identify the canonical machine and run Step 3 to push its version.

Q: My MCP server entries synced but the servers fail with “command not found”.

The binaries are not installed on machine B. Run your MCP install script on the new machine. See Cursor MCP server not connecting.

Q: Can I roll back Settings Sync to an earlier point in time?

Cursor does not expose a sync history UI for individual settings. Your ~/.cursor.backup-* directory is your rollback. Restore by replacing ~/.cursor (with Cursor closed) and signing in again.

Q: Does Settings Sync work across organizations / SSO boundaries?

No. Settings Sync is tied to the signed-in Cursor identity. Personal vs work accounts are separate sync stores.

Tags: #Cursor #Troubleshooting #IDE sync #AI coding

Related Articles