Most cursor vs vscode debates focus on features, yet the daily pain is configuration. Cursor and VS Code share an ancestor, but they do not share a config folder. That gap bites the moment you install both. Your Prettier rules, keybindings and snippets live in one editor, the other starts from factory defaults, and every tweak you make drifts into two copies that never match again.
The gap widened on October 12, 2026, when Cursor joined The X Subscription and began steering new signups to a five-tier lineup that runs from a free plan to a $200 Ultra plan. Plenty of teams now keep VS Code with GitHub Copilot for some repositories and Cursor for others. If you switch between them daily, a shared configuration layer stops being a nice idea and starts saving real minutes.
This tutorial builds that layer. You will create a small Git repository called editor-parity with one Bash script of about 230 lines, a strict-JSON settings system, extension lists that tolerate gaps between marketplaces, a workspace template, and a single source of truth for AI rules. It takes 13 steps and about 40 minutes. If you want speed numbers instead of setup mechanics, a separate 13-step Cursor vs VS Code benchmark covers performance on a real codebase.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
Why Run Cursor and VS Code on One Config in 2026
Cursor is a fork of Visual Studio Code, so it reads the same settings schema, the same keybinding format and the same .vscode workspace folder. A cursor vs vscode setup that you maintain by hand rots fast. That shared DNA tempts people into assuming the two editors stay in sync on their own. They do not. Each editor keeps its own User directory, its own extension store and its own list of installed add-ons.
The built-in migration path works once, and it works in one direction. Cursor offers an import of VS Code settings, extensions and keybindings, and an exported VS Code profile also moves across. After that, the two copies diverge. You install a linter in VS Code on Monday, a theme in Cursor on Tuesday, and by Friday you cannot say which editor has which. A Git repo fixes the drift because it makes one folder the owner of the truth.
Usage data shows why this matters. The 2025 Stack Overflow Developer Survey found that 75.9% of respondents regularly used Visual Studio Code, while 17.9% regularly used Cursor. Among professional developers, the figures were 76.2% for VS Code and 19.3% for Cursor. Cursor sits well behind in absolute reach, yet nearly one in five professionals uses it, and many of them still open VS Code for specific projects.
| Metric (2025 survey) | VS Code | Cursor |
|---|---|---|
| All respondents, regular use | 75.9% | 17.9% |
| Professional developers, regular use | 76.2% | 19.3% |
| Gap, all respondents | 58.0 points ahead | 58.0 points behind |
| Gap, professional developers | Not listed | Not listed |
| Source | Stack Overflow 2025 | Stack Overflow 2025 |
The gap rows come from simple subtraction on the survey figures. They tell you the editors coexist on a large number of machines. They do not tell you which one you should prefer, and this guide takes no side. It treats the two editors as tools that should behave the same way for the 90% of work that has nothing to do with AI features. For broader coverage of editors and frameworks, see the software section of the site.
What Changed in October 2026: Plans, Billing and the Import Command
Three recent changes shape the setup, so it helps to read them before you touch a config file. The first is pricing. Cursor now sells through The X Subscription, which shares one usage pool across Cursor and Grok and refreshes it weekly. Third-party models such as Claude, GPT and Gemini bill separately at API list prices on the tiers where they apply. Existing Pro subscribers reportedly keep their legacy plan for now, while new signups land on the lineup below.
| Plan | Price per month | What the headline offer says |
|---|---|---|
| Free | $0 | Entry tier for trying the editor |
| Plus | $8 | Entry-level paid tier, covers Grok models |
| Premium | $30 | Adds cloud agents and Bugbot |
| Super | $100 | Higher usage allowance than Premium |
| Ultra | $200 | Top individual tier |
Nothing in this tutorial needs a paid plan. Settings, keybindings, extensions and rules files work the same on the Free tier. The pricing matters only when you compare cost against VS Code with Copilot, and the Cursor vs Devin Desktop vs VS Code Copilot piece shows how Cursor’s plans stack up against VS Code with Copilot in dollar terms.
The second change is a warning about the import command. Forum reports from October 16, 2026 describe Cursor’s Import VS Code Extensions and Settings action as having no built-in undo. It can replace your user settings and install extensions in one pass. If you want to roll back, you restore earlier copies of settings.json and keybindings.json and remove the imported extensions by hand. That is the reason Step 1 of this tutorial takes a snapshot before anything else runs.
The third change sits on the VS Code side. On October 15, 2026, Microsoft published a post on modernizing the VS Code UI, with new Dark 2026 and Light 2026 themes. The interface moved from an experimental setting to Insiders and then into a controlled Stable rollout, and it keeps an option to return to the classic look. None of this blocks the setup, but it affects the theme choice in Step 9.
Prerequisites and Versions
You need both editors installed, their command-line launchers on your PATH, and a handful of small utilities. The script avoids Bash 4 features on purpose, so the stock Bash 3.2 that ships with macOS runs it without complaint.
| Requirement | Version | Why you need it |
|---|---|---|
| Visual Studio Code | Latest stable | Provides the code CLI and the Microsoft Marketplace |
| Cursor | Latest stable (any plan) | Provides the cursor CLI and the Open VSX registry |
| Bash | 3.2 or newer | Runs the parity script on macOS, Linux and Git Bash |
| jq | 1.6 or newer | Merges strict-JSON settings and keybinding files |
| Git | 2.30 or newer | Versions the config and runs the post-merge hook |
| OS | macOS, Linux, Windows 10/11 with Git Bash | Each has a different User directory path |
Check the launchers first. Run code --version and cursor --version in a terminal. If either prints a command-not-found error, open that editor, press the command palette shortcut and look for the action that installs the shell command. On Windows, run everything from Git Bash, not from WSL. WSL has its own home directory and would write config files that your Windows editors never read.
Developers who also run Claude Code in a terminal can pair this setup with a guide on setting up Cursor with Claude Code. Budget about 40 minutes. The first 10 go to backups and the shared settings. The next 20 cover extensions, keybindings and the workspace layer, and the last 10 handle verification and automation.
How the Project Is Laid Out
The design rests on one rule: you never edit an editor’s User folder by hand again. You edit files in the repo, run a build, and let the script copy the results into both editors. A base file holds everything the two editors share. A small overlay file per editor holds the exceptions. The build step merges them into a generated dist folder.
editor-parity/
bin/
parity # the one Bash script
shared/
settings.json # strict JSON, no comments
keybindings.json
snippets/
project.code-snippets
overlays/
vscode.settings.json
cursor.settings.json
vscode.keybindings.json
cursor.keybindings.json
extensions/
common.txt # installed in both editors
vscode-only.txt
cursor-only.txt
workspace-template/
.vscode/
extensions.json
tasks.json
launch.json
AGENTS.md # single source for AI rules
dist/ # generated, git-ignored
.gitignoreTwo choices deserve a defense. First, the JSON files stay strict, with no comments and no trailing commas, because jq cannot parse the relaxed JSONC dialect that editors tolerate. You lose inline comments and gain a merge step that cannot silently corrupt a file. Second, extension lists are plain text, one ID per line. Text files diff cleanly in pull requests, and a failed install on one marketplace does not block the other.
Phase 1: Back Up Both Editors (Steps 1-2)
Step 1: Create the repository
Make the folder tree, initialize Git, and keep generated output out of version control. Generated settings can contain machine-specific paths, so dist never gets committed.
mkdir -p editor-parity/{bin,shared/snippets,overlays,extensions,workspace-template/.vscode}
cd editor-parity
git init
printf 'dist/\n.DS_Store\n' > .gitignoreStep 2: Write the script header and the backup command
Create bin/parity with the header below. It detects the operating system, resolves each editor’s User directory, and defines the backup function. The backup copies settings, keybindings, snippets and a versioned extension list into a timestamped folder under your home directory, then prunes everything past the newest 20 snapshots.
#!/usr/bin/env bash
set -euo pipefail
ROOT="$(cd "$(dirname "${BASH_SOURCE[0]}")/.." && pwd)"
STAMP="$(date +%Y%m%d-%H%M%S)"
BACKUPS="$HOME/.editor-parity-backups"
EDITORS="vscode cursor"
case "$(uname -s)" in
Darwin) BASE="$HOME/Library/Application Support" ;;
Linux) BASE="${XDG_CONFIG_HOME:-$HOME/.config}" ;;
MINGW*|MSYS*|CYGWIN*) BASE="$(cygpath -u "$APPDATA")" ;;
*) echo "Unsupported OS" >&2; exit 1 ;;
esac
user_dir() {
case "$1" in
vscode) echo "$BASE/Code/User" ;;
cursor) echo "$BASE/Cursor/User" ;;
esac
}
cli() {
case "$1" in
vscode) echo code ;;
cursor) echo cursor ;;
esac
}
have_cli() { command -v "$(cli "$1")" >/dev/null 2>&1; }
cmd_backup() {
local out="$BACKUPS/$STAMP" ed dir
for ed in $EDITORS; do
dir="$(user_dir "$ed")"
mkdir -p "$out/$ed"
if [ -f "$dir/settings.json" ]; then cp "$dir/settings.json" "$out/$ed/"; fi
if [ -f "$dir/keybindings.json" ]; then cp "$dir/keybindings.json" "$out/$ed/"; fi
if [ -d "$dir/snippets" ]; then cp -R "$dir/snippets" "$out/$ed/"; fi
if have_cli "$ed"; then
"$(cli "$ed")" --list-extensions --show-versions > "$out/$ed/extensions.txt"
fi
done
ls -1dt "$BACKUPS"/* 2>/dev/null | tail -n +21 | while read -r old; do rm -rf "$old"; done
echo "Backup written to $out"
}
cmd_restore() {
local from="${1:?usage: parity restore <backup-dir>}" ed dir f
for ed in $EDITORS; do
if [ ! -d "$from/$ed" ]; then continue; fi
dir="$(user_dir "$ed")"
for f in settings.json keybindings.json; do
if [ -f "$from/$ed/$f" ]; then cp "$from/$ed/$f" "$dir/$f"; fi
done
echo "Restored $ed files. Compare $from/$ed/extensions.txt with:"
echo " $(cli "$ed") --list-extensions --show-versions"
done
}Make it executable and run the first snapshot. This is your safety net, and the rest of the tutorial depends on it.
chmod +x bin/parity
./bin/parity backupExpected output (illustrative, your path and timestamp will differ):
Backup written to /home/dana/.editor-parity-backups/20261022-094512Open that folder and confirm that vscode/settings.json and cursor/extensions.txt exist. An empty cursor folder means Cursor has never run on this machine, which is fine. It simply has no state to protect yet.
Phase 2: Build the Shared Settings Layer (Steps 3-5)
Step 3: Write the shared settings
Resist the urge to paste your whole current settings.json. Copy only the keys you want identical in both editors. A short base file stays readable, and it forces you to decide what really belongs to your workflow. Skip anything machine-specific, such as interpreter paths, and never put tokens or secrets in this file. If you build extensions yourself, a tutorial on a VS Code AI extension that runs in Cursor shows how a single extension can target both editors.
{
"editor.fontFamily": "'JetBrains Mono', Menlo, Consolas, monospace",
"editor.fontSize": 14,
"editor.fontLigatures": true,
"editor.tabSize": 2,
"editor.formatOnSave": true,
"editor.minimap.enabled": false,
"editor.bracketPairColorization.enabled": true,
"files.autoSave": "onFocusChange",
"files.trimTrailingWhitespace": true,
"files.insertFinalNewline": true,
"files.exclude": {
"**/.DS_Store": true,
"**/node_modules": true
},
"git.autofetch": true,
"git.confirmSync": false,
"git.openRepositoryInParentFolders": "never",
"terminal.integrated.fontSize": 13,
"workbench.colorTheme": "Default Dark Modern",
"workbench.startupEditor": "none",
"telemetry.telemetryLevel": "off"
}Save it as shared/settings.json. The theme name Default Dark Modern ships inside both editors, so it needs no extension. That choice matters in Step 9.
Step 4: Add one overlay per editor
Overlays hold the differences. They should stay short, because every key you add here is a spot where the two editors behave differently on purpose. The VS Code overlay keeps GitHub Copilot active for code but silent in prose files. The Cursor overlay switches off Cursor’s own inline completions for the same file types.
// overlays/vscode.settings.json
{
"github.copilot.enable": {
"*": true,
"markdown": false,
"plaintext": false
}
}
// overlays/cursor.settings.json
{
"cursor.cpp.disabledLanguages": ["plaintext", "markdown"]
}Strip the two comment lines before saving, since each file must be strict JSON. They appear above only to label the files. Cursor-specific keys use a cursor. prefix, and key names can change between releases. Open Cursor’s settings UI, change the option you care about, then copy the exact key from the settings.json the editor writes. Do not trust any tutorial’s key name over your own build, including this one.
Step 5: Add the build and apply commands
The build merges base and overlay with jq. For objects, the * operator merges recursively, so an overlay can add or change a single nested key. For keybindings, which are arrays, the build concatenates the two lists. The apply command runs a fresh backup first, then copies the generated files into each editor.
cmd_build() {
local ed
mkdir -p "$ROOT/dist"
for ed in $EDITORS; do
mkdir -p "$ROOT/dist/$ed"
jq -s '.[0] * .[1]' "$ROOT/shared/settings.json" \
"$ROOT/overlays/$ed.settings.json" > "$ROOT/dist/$ed/settings.json"
jq -s 'add' "$ROOT/shared/keybindings.json" \
"$ROOT/overlays/$ed.keybindings.json" > "$ROOT/dist/$ed/keybindings.json"
done
echo "Built dist/ for: $EDITORS"
}
cmd_apply() {
local ed dir
cmd_backup
for ed in $EDITORS; do
dir="$(user_dir "$ed")"
mkdir -p "$dir/snippets"
cp "$ROOT/dist/$ed/settings.json" "$dir/settings.json"
cp "$ROOT/dist/$ed/keybindings.json" "$dir/keybindings.json"
cp "$ROOT/shared/snippets/"*.code-snippets "$dir/snippets/" 2>/dev/null || true
echo "Applied to $dir"
done
}You also need the keybinding files, even if two of them start nearly empty. Create shared/keybindings.json with the three shortcuts below and give each overlay an array. The VS Code overlay binds ctrl+l and cmd+l to the Copilot chat panel, which mirrors the chat shortcut Cursor uses by default. That keeps your muscle memory intact when you switch windows.
// shared/keybindings.json
[
{ "key": "ctrl+alt+t", "command": "workbench.action.terminal.toggleTerminal" },
{ "key": "ctrl+shift+d", "command": "editor.action.copyLinesDownAction", "when": "editorTextFocus" },
{ "key": "ctrl+alt+w", "command": "editor.action.toggleWordWrap" }
]
// overlays/vscode.keybindings.json
[
{ "key": "ctrl+l", "command": "workbench.action.chat.open" },
{ "key": "cmd+l", "command": "workbench.action.chat.open" }
]
// overlays/cursor.keybindings.json
[]Again, drop the comment lines when you save. On Windows and Linux, ctrl+l normally expands the line selection in VS Code, so this binding overrides that default on purpose. Run the build now and inspect the result:
chmod +x bin/parity
./bin/parity build
jq '.["github.copilot.enable"], .["editor.fontSize"]' dist/vscode/settings.json
jq '.["cursor.cpp.disabledLanguages"]' dist/cursor/settings.jsonExpected output (illustrative):
Built dist/ for: vscode cursor
{
"*": true,
"markdown": false,
"plaintext": false
}
14
[
"plaintext",
"markdown"
]Phase 3: Handle Extensions Across Open VSX and the Marketplace (Steps 6-8)
Extensions cause most of the friction. VS Code pulls from Microsoft’s Visual Studio Marketplace. Cursor’s migration documentation says it uses the Open VSX registry instead, and compatibility is not guaranteed because of that. Some extensions exist on both, some on one, and a few carry licenses that bar use outside Microsoft’s own builds. A parallel guide on running VS Code extensions in Cursor in 12 steps walks through the manual route. Here the script does the bookkeeping, and a third-party reference on installing VS Code add-ons in Cursor gives extra background.
Step 6: Write the three extension lists
Put cross-editor tools in common.txt. Put anything the other editor cannot or should not run in an editor-specific file. GitHub Copilot belongs in the VS Code list only, since running it beside Cursor’s own completions produces double suggestions and fights over the Tab key.
# extensions/common.txt
esbenp.prettier-vscode
dbaeumer.vscode-eslint
editorconfig.editorconfig
eamodio.gitlens
redhat.vscode-yaml
tamasfe.even-better-toml
usernamehw.errorlens
streetsidesoftware.code-spell-checker
# extensions/vscode-only.txt
github.copilot
github.copilot-chat
# extensions/cursor-only.txt
# (empty on purpose, add Open VSX-only picks here)Treat every ID above as a starting point, not a promise. The install step in a moment tells you which ones each registry actually serves. Lines that begin with # and blank lines are ignored, and trailing comments after an ID are not supported.
Step 7: Add the install command with a failure log
The installer loops over both editors and both lists. It captures each CLI’s output instead of trusting the exit code alone, then logs every miss to dist/ext-failures.txt. One bad ID never stops the run.
read_ids() { grep -Ev '^[[:space:]]*(#|$)' "$1" || true; }
cmd_ext_install() {
local ed c list id out
mkdir -p "$ROOT/dist"
: > "$ROOT/dist/ext-failures.txt"
for ed in $EDITORS; do
if ! have_cli "$ed"; then echo "skip $ed: CLI not on PATH"; continue; fi
c="$(cli "$ed")"
for list in "$ROOT/extensions/common.txt" "$ROOT/extensions/$ed-only.txt"; do
if [ ! -f "$list" ]; then continue; fi
while read -r id; do
out="$("$c" --install-extension "$id" --force 2>&1 || true)"
if echo "$out" | grep -Eqi 'successfully installed|already installed'; then
echo "ok $ed $id"
else
echo "FAIL $ed $id" | tee -a "$ROOT/dist/ext-failures.txt"
fi
done < <(read_ids "$list")
done
done
}Run it with ./bin/parity ext-install. Expect a few minutes on a cold machine.
Expected output (illustrative, a failed line means that registry does not serve the ID):
ok vscode esbenp.prettier-vscode
ok vscode dbaeumer.vscode-eslint
ok vscode eamodio.gitlens
ok vscode github.copilot
ok cursor esbenp.prettier-vscode
ok cursor dbaeumer.vscode-eslint
FAIL cursor usernamehw.errorlens
ok cursor eamodio.gitlensStep 8: Report drift and handle the leftovers
After the install, compare what each editor actually holds. The drift report below lowercases every ID, sorts both lists and prints what exists in only one editor. It also replays the failure log, so you see the gaps in one place.
cmd_ext_check() {
local a b
a="$(code --list-extensions | tr '[:upper:]' '[:lower:]' | sort)"
b="$(cursor --list-extensions | tr '[:upper:]' '[:lower:]' | sort)"
echo "== Only in VS Code"; comm -23 <(echo "$a") <(echo "$b")
echo "== Only in Cursor"; comm -13 <(echo "$a") <(echo "$b")
echo "== Install failures"; cat "$ROOT/dist/ext-failures.txt" 2>/dev/null || true
}For each failure, pick one of three paths. Search Open VSX for a maintained equivalent and swap the ID in common.txt. Download a .vsix file from the publisher if its license allows it, then run cursor --install-extension ./vendor/name.vsix. Or accept the gap and move the ID into vscode-only.txt. If you publish your own tooling, the guide on how to publish a VS Code extension to Open VSX closes the loop from the other side.
Phase 4: Align Keybindings, Themes and Profiles (Steps 9-10)
Step 9: Pin one theme on both editors
A mismatched theme is the fastest way to feel that the two editors are strangers. The VS Code team’s new Dark 2026 and Light 2026 themes belong to the modernized interface, and a copy of them may not exist in Cursor’s older base. The safe fix is to pin Default Dark Modern, which both editors carry and which Microsoft’s own UI timeline dates to 2023. You already did this in Step 3.
If you prefer the new VS Code look, set workbench.colorTheme to Dark 2026 in overlays/vscode.settings.json and leave Cursor on the older theme. The overlay is the right home for that kind of deliberate difference. Microsoft also kept a switch for returning to the classic UI, so you can revert without touching your repo.
Step 10: Move profiles and snippets the safe way
Profiles bundle settings, extensions, snippets and UI state under a name, such as “Python work” or “Docs.” VS Code can export a profile, and Cursor’s migration notes say you can import that export. Use this path only for profiles you built outside the repo. Anything you want to keep long term should live in shared/ instead, where Git tracks it.
Snippets already ride along with apply. Drop any .code-snippets file into shared/snippets/ and the next apply copies it to both editors. A first snippet to test the pipe:
{
"Console log": {
"scope": "javascript,typescript",
"prefix": "clg",
"body": ["console.log('$1:', $1);"],
"description": "Log a labeled value"
}
}Phase 5: Share Workspace Files and AI Rules (Steps 11-12)
Step 11: Build the workspace template
Workspace folders travel with the project, so they are the cleanest place for team-level agreement. Both editors read .vscode/extensions.json, tasks.json and launch.json. The template below gives every new repo the same recommended extensions, a test task and a Node launch profile. For a deeper look at how workspaces behave over remote links, see the notes on VS Code vs Cursor remote development over SSH and containers.
// workspace-template/.vscode/extensions.json
{
"recommendations": [
"esbenp.prettier-vscode",
"dbaeumer.vscode-eslint",
"editorconfig.editorconfig"
]
}
// workspace-template/.vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{ "label": "test", "type": "shell", "command": "npm test", "group": "test", "problemMatcher": [] }
]
}
// workspace-template/.vscode/launch.json
{
"version": "0.2.0",
"configurations": [
{
"type": "node",
"request": "launch",
"name": "Run app",
"program": "${workspaceFolder}/src/index.js",
"console": "integratedTerminal"
}
]
}Step 12: Generate AI rules from one file
AI assistants read instruction files, and the two editors look in different places. Cursor reads rule files under .cursor/rules in its .mdc format. GitHub Copilot in VS Code reads .github/copilot-instructions.md, and current builds of both tools also pick up an AGENTS.md at the repo root, though you should confirm that on your version. Keeping three hand-edited copies guarantees they disagree within a month.
The fix is one source file and a generator. Write your rules once in AGENTS.md. The command below mirrors that file into the Cursor rule and the Copilot instructions. Whichever model answers, whether you pick Grok 4.7, Claude Opus 5.5 or Composer 2.5 from Cursor’s model list, it reads the same rules. For a deeper dive into the rules format, there is a guide that shows how to build a Cursor rules extension for VS Code.
# workspace-template/AGENTS.md
# Project rules
- Use TypeScript in strict mode.
- Run `npm test` before proposing a commit.
- Keep functions under 40 lines.
- Never edit files under dist/ or generated/.cmd_init_workspace() {
local dest="${1:?usage: parity init-workspace <project-dir>}" f
mkdir -p "$dest/.vscode" "$dest/.cursor/rules" "$dest/.github"
for f in extensions tasks launch; do
if [ ! -f "$dest/.vscode/$f.json" ]; then
cp "$ROOT/workspace-template/.vscode/$f.json" "$dest/.vscode/$f.json"
fi
done
if [ ! -f "$dest/AGENTS.md" ]; then
cp "$ROOT/workspace-template/AGENTS.md" "$dest/AGENTS.md"
fi
{
printf -- '---\ndescription: Project rules mirrored from AGENTS.md\nalwaysApply: true\n---\n\n'
cat "$dest/AGENTS.md"
} > "$dest/.cursor/rules/project.mdc"
cp "$dest/AGENTS.md" "$dest/.github/copilot-instructions.md"
echo "Workspace files generated in $dest"
}The generator never overwrites an existing .vscode file or an existing AGENTS.md, so running it on a live project is safe. It does rewrite the two mirrored files every time, which is the point. Edit AGENTS.md, rerun the command, commit all three.
Model-context servers follow the same pattern with a twist. The setup for Cursor MCP servers and VS Code agents shows both editors consuming the same server definitions, and the Advanced Tips section below adds a one-line jq converter for the config files.
Phase 6: Verify and Automate (Step 13)
Step 13: Add the doctor command and the dispatcher
The doctor command is your smoke test. It checks that the tools exist, that each generated file is valid JSON, and that the live files in each editor still match the build. A DRIFT line means someone, usually you, edited a file in the editor directly.
cmd_doctor() {
local ed dir f tool bad=0
for tool in jq git; do
if ! command -v "$tool" >/dev/null; then echo "MISSING $tool"; bad=1; fi
done
for ed in $EDITORS; do
if have_cli "$ed"; then
echo "cli $ed: $("$(cli "$ed")" --version | head -n 1)"
else
echo "MISSING cli for $ed"; bad=1
fi
dir="$(user_dir "$ed")"
for f in settings.json keybindings.json; do
if jq empty "$ROOT/dist/$ed/$f" 2>/dev/null; then
echo "json $ed/$f valid"
else
echo "BAD dist/$ed/$f"; bad=1
fi
if [ -f "$dir/$f" ] && cmp -s "$ROOT/dist/$ed/$f" "$dir/$f"; then
echo "sync $ed/$f matches dist"
else
echo "DRIFT $ed/$f differs from dist"
fi
done
done
return $bad
}
case "${1:-help}" in
backup) cmd_backup ;;
restore) shift; cmd_restore "$@" ;;
build) cmd_build ;;
apply) cmd_apply ;;
ext-install) cmd_ext_install ;;
ext-check) cmd_ext_check ;;
init-workspace) shift; cmd_init_workspace "$@" ;;
doctor) cmd_doctor ;;
all)
cmd_build
cmd_apply
cmd_ext_install
cmd_doctor
;;
*) echo "usage: parity {backup|restore DIR|build|apply|ext-install|ext-check|init-workspace DIR|doctor|all}" ;;
esacPlace the dispatcher at the very bottom of the file, below every function. Bash reads top to bottom, so a function must exist before the case statement calls it. Then run the whole pipeline in one go:
./bin/parity allExpected output (illustrative, trimmed):
Built dist/ for: vscode cursor
Backup written to /home/dana/.editor-parity-backups/20261022-101733
Applied to /home/dana/.config/Code/User
Applied to /home/dana/.config/Cursor/User
ok vscode esbenp.prettier-vscode
...
cli vscode: (your VS Code version)
cli cursor: (your Cursor version)
json vscode/settings.json valid
json vscode/keybindings.json valid
sync vscode/settings.json matches dist
json cursor/settings.json valid
json cursor/keybindings.json valid
sync cursor/settings.json matches distYour version lines will show whatever you installed. Reload both editor windows after the run, since each reads settings.json at startup and keeps a cached copy in memory.
To rebuild automatically after you pull changes on a second machine, add a Git hook. Save the file below as .git/hooks/post-merge and mark it executable:
#!/usr/bin/env bash
cd "$(git rev-parse --show-toplevel)"
./bin/parity build && ./bin/parity applyThe Finished Project: Layout, Commands and Daily Workflow
At this point the cursor vs vscode repository holds one script, four overlay files, three extension lists and a workspace template. Commit it with a clear message and push it to a private remote. Public remotes are a bad idea, because settings files drift toward containing paths, usernames and the odd token.
| Command | What it does | When you run it |
|---|---|---|
parity backup | Snapshots settings, keybindings, snippets and extension versions | Before any import or experiment |
parity build | Merges base and overlays into dist/ | After editing any JSON file |
parity apply | Backs up, then copies dist files into both editors | After a successful build |
parity ext-install | Installs common and editor-only extensions, logs failures | On a new machine or after editing lists |
parity ext-check | Prints extensions present in only one editor | Weekly, or after a manual install |
parity init-workspace DIR | Copies workspace files and mirrors AI rules | When starting or adopting a repo |
parity doctor | Validates JSON and reports drift | After every apply |
The daily loop is short. Need a new setting everywhere? Edit shared/settings.json, then run parity build and parity apply. Need it in one editor only? Edit the overlay. Installed something by hand to try it out? Add the ID to a list if it earns a place, or let the next ext-check show it as drift and remove it. On a new laptop, clone the repo, install both editors and run parity all. Expect that bootstrap to take under 10 minutes, mostly extension downloads.
Common Pitfalls to Avoid
Most cursor vs vscode setup problems trace back to the same seven mistakes. Check this list before you debug anything else.
- Editing the User folder directly. The next
applyoverwrites your change without warning. Edit the repo, then build. If you slip, the backup folder still holds the previous copy. - Comments in the JSON files. Editors accept them and
jqrejects them. A single stray//in an overlay breaks the build with a parse error. Keep labels in the README, not in the files. - Running Cursor’s import after
apply. The import can replace your user settings and install extensions, and it has no undo. Run it, if at all, before your firstapply, and always after a freshbackup. - Installing Copilot in both editors. Cursor ships its own completions. Two inline-suggestion engines fight over the Tab key and double every ghost-text line. Keep Copilot in
vscode-only.txt. - Assuming registry parity. An ID that installs in VS Code can fail in Cursor because Open VSX does not carry it, or carries an older build. Trust the failure log, not your memory.
- Syncing machine-specific values. Interpreter paths, font names that exist on one OS only, and tokens in settings all break on the second machine. Put OS-specific values in a per-OS overlay or leave them local.
- Committing backups. Snapshot folders sit outside the repo for a reason. They may hold secrets from old settings files, so never copy them into Git.
Troubleshooting: 10 Fixes for Setup Problems
cursor: command not found. The shell launcher is not installed. Open Cursor, open the command palette and search for the action that installs thecursorcommand. On Linux, symlink the binary into a folder on yourPATH. Open a new terminal afterwards.jq: error: Invalid numeric literal. One of the JSON files contains a comment or a trailing comma. Runjq empty file.jsonon each input to find the offender. Overlay and keybinding files are the usual suspects.- An extension prints FAIL in Cursor only. The ID is missing from Open VSX. Search that registry for a maintained fork, install a
.vsixby path, or move the ID tovscode-only.txt. - Settings look unchanged after
apply. The editor still holds the old copy in memory. Run the reload-window command or restart. If nothing changes, confirmuser_dirpoints at the right path, since Snap, Flatpak and portable installs keep config elsewhere. - Windows:
cygpath: command not foundor an emptyAPPDATA. You are probably in WSL or plain PowerShell. Switch to Git Bash, which setsAPPDATAand includescygpath. - The chat shortcut does nothing in VS Code. Another binding with a
whenclause is winning. Open the keyboard shortcuts view, search forctrl+land remove or disable the competing rule. Also confirm Copilot Chat is installed and signed in. - Double suggestions while typing in Cursor. Copilot is installed there. Uninstall
github.copilotfrom Cursor and confirm it appears only under “Only in VS Code” inext-check. Permission deniedonbin/parity. Runchmod +x bin/parity. If you cloned onto a Windows drive, also rungit config core.fileMode trueand check line endings, because CRLF in a shebang line breaks Bash.- Cursor ignores the generated rule file. Check that the file sits at
.cursor/rules/project.mdcand starts with the front matter block, includingalwaysApply: true. Then open the rules panel in Cursor settings to confirm it lists the file. - The import overwrote settings you wanted. Run
parity restore ~/.editor-parity-backups/<timestamp>to put back the files, then compare the savedextensions.txtwith the live list and remove the extras by hand.
Advanced Tips for Power Users
Per-OS overlays. Extend the build with a third merge input such as overlays/linux.settings.json chosen by uname -s. It keeps font names and shell paths out of the shared base. The change is one extra argument to jq -s.
Convert MCP configs. Cursor reads .cursor/mcp.json with a mcpServers key, while VS Code reads .vscode/mcp.json with a servers key. Keep one file and convert it:
jq '{servers: .mcpServers}' .cursor/mcp.json > .vscode/mcp.jsonValidate in CI. A short GitHub Actions workflow catches broken JSON before it reaches a teammate’s laptop. It needs only jq, since the build never calls an editor.
name: validate
on: [push, pull_request]
jobs:
json:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: |
sudo apt-get install -y jq
./bin/parity build
jq empty dist/*/settings.json dist/*/keybindings.jsonShare rules with a team. The October 2026 Cursor announcement says Teams users get Premium, Super or Ultra at the same per-seat prices as individual plans, with SSO, admin controls, consolidated billing, usage analytics and SOC 2 compliance. If your team standardizes on one editor but allows the other, commit AGENTS.md to every repo and let the generator keep the editor-specific copies honest.
Try agent sandboxes and hooks on both sides. VS Code’s agent features and Cursor’s agent features keep moving. The walkthrough on the VS Code Copilot agent sandbox setup shows how to contain agent commands in VS Code, and the guide to building Cursor hooks covers the equivalent control point in Cursor. Treat both as per-project settings, and keep the experiments in workspace files rather than in your shared base.
Pin before big upgrades. Run parity backup right before you accept a major editor update. Because the backup includes --show-versions output, you can see exactly which extension builds worked on the old release and which changed.
FAQ: Cursor vs VS Code Setup Questions
Can I use Cursor and VS Code on the same project at the same time?
Yes. Both read the same .vscode folder and the same Git repository. Avoid editing the same file in both windows at once, since each editor keeps unsaved buffers in memory. Pick one as the writer and use the other for review or for running an agent.
Does Cursor sync settings the way VS Code does?
This tutorial does not rely on a built-in sync service. The Git-backed approach works on any machine, covers both editors, and gives you history and review that a hidden cloud profile cannot match.
Why not just use Cursor’s import command?
The import handles a one-time move and nothing more. Reports from October 2026 describe no built-in undo, and it does not keep the two editors aligned afterward. Use it for a first migration if you like, but take a backup first.
Do VS Code extensions work in Cursor?
Many do. Cursor pulls from Open VSX rather than the Microsoft Marketplace, so some extensions are missing or behave differently. The install step logs each miss, and you can load a .vsix file when the license permits it.
Do I need a paid Cursor plan for this?
No. Settings, extensions, keybindings and rules files work on the Free plan. Paid tiers start at $8 per month for Plus and reach $200 per month for Ultra, and they change AI usage allowances, not your configuration options.
Will my theme match after the VS Code UI refresh?
Pin Default Dark Modern on both editors for an exact match. The new Dark 2026 and Light 2026 themes arrived with the modernized VS Code interface, and Cursor may not ship them.
What should I back up before changing editors?
Back up settings.json, keybindings.json, your snippets folder and a versioned extension list. The parity backup command captures all four in one timestamped folder, so a bad import takes seconds to reverse.
