Cursor Settings Sync Overwrites Local Config on Another Machine

Q: Can I roll back to an earlier config from before the clobber?

There is no sync-history UI. Your `Cursor-User.backup-*` and `.cursor.backup-*` directories from Step 2 are your rollback. Close Cursor, restore the directory, reopen.

Q: My sync says "merged" but my keybindings on machine B are wrong.

No Cursor sync layer does a real merge of `keybindings.json`. It is last-write-wins. Identify the canonical machine and push its `keybindings.json` (Steps 3 and 4).

Q: My MCP server entries arrived but the servers fail with "command not found".

The binaries are not installed on machine B. The config in `~/.cursor/mcp.json` moved, the executables did not. Run your MCP install step on the new machine. See [Cursor MCP server not connecting](/en/articles/cursor-mcp-server-not-connecting/).

Cursor has no native Settings Sync. When a Gist-sync extension, dotfiles symlink, or cloud folder pushes stale config to a second machine, your rules, keybindings, or MCP servers get clobbered. Diagnose which sync layer did it and recover the good version.

Published: May 24, 2026 Updated: Jun 21, 2026 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 that evening and the desktop’s old config has overwritten everything you did last night.

The first thing to know (as of June 2026): Cursor has no native “Settings Sync” feature. Unlike VS Code, there is no Settings Sync: Turn On command and no per-category sync UI in Cursor. So if config is moving between your machines at all, some other layer is doing it: a third-party Gist-sync extension, a dotfiles symlink, a cloud-synced folder (iCloud/Dropbox/OneDrive), the “Import from VS Code” button, or a Profiles export/import. Each of those is last-write-wins, and the “winner” is whichever machine wrote most recently, not the one with the change you want.

Fastest fix: stop every sync layer right now, pick the machine that has the config you want, make a file-level backup of its Cursor config directory, and only then push that state outward. Steps below, cheapest first.

First: which sync layer is actually moving your config?

Cursor itself does not sync. Identify the mechanism before you touch anything, or you will fight the wrong thing.

Layer	Tell-tale sign	Where it lives
Gist-sync extension (e.g. “Sync Everything”, “cursor-settings-sync”)	An installed extension with a GitHub token; an “upload/download settings” command in the palette	Extension’s status bar item or `Cmd+Shift+P` -> type “sync”
Dotfiles + symlink (`stow`/`ln -s`)	`settings.json` is a symlink, not a real file	`ls -l "~/Library/Application Support/Cursor/User/settings.json"` shows an arrow `->`
Cloud-synced folder	The whole Cursor config dir sits inside iCloud Drive / Dropbox / OneDrive	Check the path of the config dir against your cloud mount
”Import from VS Code”	You recently clicked it; VS Code config landed on top of Cursor’s	Cursor Settings -> General -> Account -> “VS Code Import”
Profiles export/import	You exported a `.code-profile` / Gist and imported it elsewhere	`Cmd+Shift+P` -> `Preferences: Open Profiles (UI)`
Not sync at all (git state)	Only `.cursor/rules` or workspace `mcp.json` differ	`git status` in the project shows uncommitted changes

If none of these apply, your two machines simply have independent config and nothing is syncing. That is the most common surprise: people assume Cursor syncs like VS Code, it does not, and the “missing” config was never uploaded anywhere.

Where Cursor keeps the files you care about

You will reference these constantly during recovery. (As of June 2026.)

What	macOS	Windows	Linux
User config dir	`~/Library/Application Support/Cursor/User/`	`%APPDATA%\Cursor\User\`	`~/.config/Cursor/User/`
`settings.json`	`.../User/settings.json`	`%APPDATA%\Cursor\User\settings.json`	`~/.config/Cursor/User/settings.json`
`keybindings.json`	`.../User/keybindings.json`	`%APPDATA%\Cursor\User\keybindings.json`	`~/.config/Cursor/User/keybindings.json`
Snippets	`.../User/snippets/`	`%APPDATA%\Cursor\User\snippets\`	`~/.config/Cursor/User/snippets/`
Global MCP servers	`~/.cursor/mcp.json`	`%USERPROFILE%\.cursor\mcp.json`	`~/.cursor/mcp.json`
Per-project MCP	`<project>/.cursor/mcp.json`	`<project>\.cursor\mcp.json`	`<project>/.cursor/mcp.json`
Project rules	`<project>/.cursor/rules/`	`<project>\.cursor\rules\`	`<project>/.cursor/rules/`

Note: a lot of Cursor’s UI-toggled settings are not in settings.json. They live in a SQLite blob at .../User/globalStorage/state.vscdb. That database is what cloud-folder sync most often corrupts, because two machines write the same state.vscdb and the last save wins (or the file ends up half-written).

Common causes

Ordered by likelihood for “second machine clobbered my config.”

1. A Gist-sync extension pushed stale state (last-write-wins)

These extensions are not merge engines. Machine B was opened, the extension auto-downloaded the old Gist (or auto-uploaded B’s stale state over your good Gist), and your laptop edits lost.

How to spot it: open the extension’s output/log channel or its command (Cmd+Shift+P -> type “sync”). The last upload timestamp and source machine tell the story. If the Gist’s last commit is from the wrong machine, that is your clobber.

2. Cloud-folder sync corrupted or overwrote `state.vscdb`

If your Cursor config dir sits inside iCloud Drive, Dropbox, or OneDrive, both machines fight over the same state.vscdb. This is the worst case because the file is binary, so a partial sync can corrupt it, not just overwrite it.

How to spot it: the config-dir path contains a cloud mount, or the cloud client shows a conflict copy like state (machine-B's conflicted copy).vscdb.

3. Dotfiles extension-list reconciliation uninstalled extensions

The dotfiles pattern tracks cursor --list-extensions output in a file, then on the other machine installs what is in the list and uninstalls what is not. If the list was stale, it silently removes extensions you added.

How to spot it: your sync script compares a tracked extensions.txt and runs cursor --uninstall-extension. Extensions you installed manually disappear after a sync run.

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

.cursor/rules lives inside the workspace, not the user config dir. 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 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.

5. MCP server config moved but the binaries did not

When ~/.cursor/mcp.json (or workspace .cursor/mcp.json) is synced/copied, the actual mcp-server-foo executable is 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 (or stay yellow/red in Cursor Settings -> MCP). See also Cursor MCP server not connecting.

6. “Import from VS Code” overwrote Cursor’s config

Cursor Settings -> General -> Account -> “VS Code Import” copies VS Code’s Extensions, Themes, Settings, and Keybindings on top of Cursor’s. Run it after you already customized Cursor and it can clobber your Cursor-specific tweaks.

How to spot it: your keybindings/theme suddenly match your old VS Code setup; you remember clicking Import recently.

7. Different Cursor versions interpret the same setting differently

A setting added in a newer Cursor build may be ignored by an older one, and an older build may strip it when its config is written back out.

How to spot it: both machines show the setting present, but on one it has no effect. Cursor -> About (or cursor --version) 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 the user config dir, the SQLite state.vscdb, workspace .cursor/, or somewhere else.
Make a manual backup of the trusted machine’s whole Cursor config dir (paths above) before doing anything else.

Information to collect

Which sync layer is active (use the decision table above).
For a Gist-sync extension: its last upload/download timestamp and source machine.
The categories/files each layer touches.
cursor --version on both machines.
A copy of the disputed files: settings.json, keybindings.json, snippets/, ~/.cursor/mcp.json, .cursor/rules/*.
Sign-in identity / Gist account on each machine. Mixing a personal Gist account on one machine and another account on the other splits state into two stores.

Step-by-step fix

Ordered cheapest to most invasive.

Step 1: Identify the canonical machine and freeze every sync layer

Decide which machine has the config you want. Then, on every machine, disable whatever is moving config:

Gist-sync extension: disable its auto-upload/auto-download (or disable the extension) so it stops pushing.
Cloud folder: pause the cloud client, or move the Cursor config dir out of the synced location entirely (best long-term fix; see Step 5).
Dotfiles: do not run the sync script until the canonical state is settled.

Until the canonical state is restored, nothing should write config to any other machine.

Step 2: Back up the canonical state explicitly

On the canonical machine, copy the whole config dir (this captures settings.json, keybindings.json, snippets/, and the state.vscdb blob):

cp -R "$HOME/Library/Application Support/Cursor/User" "$HOME/Cursor-User.backup-$(date +%Y%m%d-%H%M%S)"
cp -R "$HOME/.cursor" "$HOME/.cursor.backup-$(date +%Y%m%d-%H%M%S)"

On Windows PowerShell:

Copy-Item -Recurse "$env:APPDATA\Cursor\User" "$env:APPDATA\Cursor\User.backup"
Copy-Item -Recurse "$env:USERPROFILE\.cursor" "$env:USERPROFILE\.cursor.backup"

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

Step 3: Make the canonical state authoritative

How you “push” depends on the layer:

Gist-sync extension: on the canonical machine, force an upload to the Gist (the extension’s “upload settings” command). This replaces the remote Gist with your good state. Confirm the Gist’s new commit timestamp.

Dotfiles: commit the canonical machine’s files (including a fresh cursor --list-extensions dump) and push:

cursor --list-extensions > extensions.txt
git add settings.json keybindings.json snippets extensions.txt
git commit -m "chore: pin canonical Cursor config"
git push

Cloud folder: skip pushing; you are going to remove this layer in Step 5. Just make sure the canonical machine’s files are intact.

Step 4: Pull the canonical state onto the other machines, one at a time

On each non-canonical machine, with Cursor closed:

Gist-sync extension: run its “download settings” command to overwrite local with the canonical Gist.

Dotfiles: git pull, re-link (stow --no-folding -t ~ * or your ln -s), then reconcile extensions:

cursor --list-extensions > current.txt
comm -13 <(sort current.txt) <(sort extensions.txt) | xargs -I\{\} cursor --install-extension \{\}

Manual: copy settings.json, keybindings.json, snippets/, and ~/.cursor/mcp.json from the backup over the local files.

Reopen Cursor, verify it matches the canonical machine, then move to the next machine. Do not do all machines at once.

Step 5: Get config out of any binary-fighting sync layer

The biggest cause of silent clobbers is two machines writing the same binary state.vscdb (cloud folders) or extension lists racing each other. Fix the boundary:

Never keep the Cursor config dir inside iCloud/Dropbox/OneDrive. If it is, move it out and let Cursor recreate it from your backup.
Prefer text-file sync (Gist of settings.json + keybindings.json) over whole-directory sync, because text files survive partial syncs and merge conflicts are visible.
Set the Gist-sync extension to manual upload/download, not auto, so two machines can never race.

Step 6: Move workspace-scoped config into git (not sync)

.cursor/rules, workspace .cursor/mcp.json, .vscode/settings.json, and .vscode/extensions.json belong in the project repo, not in any settings-sync layer:

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

Now the second machine gets these via git pull, which is the correct boundary. This also removes them from the clobber surface entirely.

How to confirm it’s fixed

Edit a benign setting (e.g. font size) on machine A, run your push step, pull on machine B: B reflects it, and only it.
Edit .cursor/rules on machine A: it should arrive on machine B only via git pull, never through the settings-sync layer.
cursor --list-extensions returns the same set on both machines.
Cursor Settings -> MCP shows your servers green on every machine (or see Cursor MCP server not connecting if not).
There is no conflicted-copy file (e.g. state (...'s conflicted copy).vscdb) anywhere in the config dir.

Long-term prevention

Remember Cursor has no native sync. Choose exactly one sync mechanism and use it on every machine. Mixing two (a Gist extension and a cloud folder) guarantees races.
Keep the Cursor config dir out of any cloud-synced folder. Sync text files, not the whole directory or state.vscdb.
Commit .cursor/rules, .vscode/, and project-level .cursor/mcp.json to git.
Keep Cursor versions roughly aligned across machines (same minor at minimum) so newer settings are not stripped by older builds.
Track cursor --list-extensions output in git so extension drift is visible and reproducible.
Use one Gist account / sign-in identity across all machines. Mixing accounts splits state into separate stores.

Common pitfalls

Expecting Cursor’s Cmd+Shift+P to have a Settings Sync: Turn On command. It does not. That is a VS Code feature Cursor did not ship.
Putting the Cursor config dir inside iCloud/Dropbox/OneDrive and assuming it “just syncs.” It races on the binary state.vscdb and can corrupt it.
Running “Import from VS Code” after you already customized Cursor. It overwrites Cursor-specific settings and keybindings.
Editing config on two machines while any auto-sync is active. Whichever writes last wins; the other loses silently.
Storing API keys in synced settings.json. They will land on every machine and in the Gist/cloud store. Use environment variables or per-machine secret files.
Assuming .cursor/rules syncs because other config does. It is workspace-scoped and only moves via git.
Restoring a backup by copying only settings.json and forgetting keybindings.json, snippets/, ~/.cursor/mcp.json, and the state.vscdb blob.

FAQ

Q: Where is the Settings Sync: Turn On command in Cursor?

There isn’t one. As of June 2026 Cursor has no built-in Settings Sync. If your config is moving between machines, a third-party extension, dotfiles, a cloud folder, or an import did it. Identify which using the table at the top.

Q: My sync says “merged” but my keybindings on machine B are wrong.

No Cursor sync layer does a real merge of keybindings.json. It is last-write-wins. Identify the canonical machine and push its keybindings.json (Steps 3 and 4).

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

The binaries are not installed on machine B. The config in ~/.cursor/mcp.json moved, the executables did not. Run your MCP install step on the new machine. See Cursor MCP server not connecting.

Q: Can I roll back to an earlier config from before the clobber?

There is no sync-history UI. Your Cursor-User.backup-* and .cursor.backup-* directories from Step 2 are your rollback. Close Cursor, restore the directory, reopen.

Q: Is putting my Cursor folder in iCloud/Dropbox a good way to sync?

No. The whole config dir is the worst thing to cloud-sync because state.vscdb is a binary file two machines will overwrite or corrupt. Sync settings.json and keybindings.json as text instead, or use a Gist-based extension set to manual.

Q: Does any of this work across personal and work accounts?

Only if both machines point at the same Gist/account. A Gist on a personal GitHub account and another on a work account are two separate stores; config will not cross between them.

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