On a Snapdragon Windows laptop, choosing the wrong VS Code installer quietly taxes everything you do: slower startup, laggy IntelliSense, extensions that half-work, and a terminal full of architecture surprises. VS Code ships proper ARM64 builds for Windows, and they are dramatically better on ARM hardware — but the default download button, old habits, and migrated settings often land people on the emulated x64 build without realizing it. The architecture of your editor, your runtimes, and your extensions must all agree — one x64 holdout in the chain is enough to make the whole setup feel broken.

The first diagnostic is simple: open Task Manager while VS Code runs and check the process architecture. If it says x64 on your ARM laptop, you are emulated. This is the same native-first triage as checking whether any app is ARM-native — learn that check once and apply it everywhere. Search quirks can compound the confusion; if Recall search operators misbehave on the same machine, treat it as a separate platform issue rather than a VS Code problem.

This guide shows you how to identify your build, migrate cleanly to ARM64, fix the extension and terminal issues that follow a mixed install, and decide the rare cases where x64 is still justified. Privacy-conscious developers should also review Click to Do privacy settings since AI features now touch code editors.

Why this happens

  • x64 build installed by habit: The x64 installer runs fine under emulation, so nothing warns you. You just get a slower editor forever.
  • Mixed ARM64/x64 toolchain: ARM64 VS Code paired with x64 Node, Python, or Git creates subtle failures in debuggers and terminals.
  • Extensions with x64-only binaries: A few extensions ship native components compiled only for x64, breaking features like debugging on ARM64.
  • Migrated settings from an Intel machine: Settings sync can carry over paths and extension choices that assume x64, causing odd behavior on ARM.
  • Emulated language servers: IntelliSense engines running translated are the main source of typing lag in emulated setups.
  • Outdated VS Code version: ARM64 support and performance improved steadily; old builds had gaps that current ones closed.

How to fix it

Work through these in order — diagnose first, then act.

Fix 1: Confirm which build you are running

You cannot fix what you have not measured. This check takes ten seconds.

  1. Open Task Manager with VS Code running.
  2. Go to the Details tab and find Code.exe.
  3. Check the Architecture column — ARM64 is native, x64 is emulated.
  4. Also check Help, then About in VS Code for the architecture string.
  5. If it says x64 on an ARM laptop, plan a migration to ARM64.

Fix 2: Install the ARM64 build cleanly

A proper ARM64 install is the foundation everything else builds on.

  1. Download the Windows ARM64 build from code.visualstudio.com.
  2. Uninstall the x64 build first to avoid a mixed install.
  3. Install the ARM64 build (user setup is fine for most people).
  4. Sign in to Settings Sync to restore your configuration.
  5. Verify the architecture in Task Manager after launching.

Fix 3: Align your toolchain architecture

The editor is only half the story — your runtimes must match.

  1. Install ARM64 builds of Node.js, Python, and Git.
  2. In VS Code settings, point tool paths at the ARM64 installs.
  3. Check the integrated terminal with commands that reveal architecture.
  4. Reinstall language extensions so they fetch ARM64 binaries.
  5. Test debugging and IntelliSense in a real project.

Fix 4: Fix misbehaving extensions

One bad extension can make a healthy ARM64 install feel broken.

  1. Disable all extensions and test performance.
  2. Re-enable in groups to isolate the culprit.
  3. Check the marketplace page of suspects for ARM64 support notes.
  4. Look for maintained forks or alternatives with native binaries.
  5. Report x64-only blockers to the extension author.

Fix 5: Tune settings carried over from Intel

Synced settings sometimes encode x64 assumptions. A quick audit prevents strange failures.

  1. Review settings.json for hardcoded Program Files paths.
  2. Replace x86 paths with their ARM64 equivalents.
  3. Clear workspace storage for projects that behave oddly.
  4. For persistent editor issues, Microsoft documents platform help at Copilot in Windows support .
  5. Keep Settings Sync on so fixes propagate to your other machines.

Fix 6: Know when x64 is still justified

Rarely, but it happens — usually a single x64-only toolchain with no ARM alternative.

  1. Identify the exact x64-only dependency blocking you.
  2. Consider running just that tool under emulation, not the whole editor.
  3. Use Remote-SSH or WSL to sidestep local architecture limits.
  4. Revisit the decision every few months as ARM support grows.
  5. Default back to ARM64 the moment the blocker is resolved.

Fix 7: Benchmark with a real project

Synthetic checks only go so far — the real test is your actual work. Opening a representative project and exercising IntelliSense, debugging, and the terminal reveals architecture mismatches that settings screens hide, and gives you a before-and-after baseline for every change you make.

  1. Open a medium-sized project you work with daily.
  2. Time cold startup, IntelliSense response, and a debug session launch.
  3. Note which operations feel slow and which tools they invoke.
  4. After each fix in this guide, repeat the same measurements.
  5. Keep the faster configuration and document it for your team.

Closing

For VS Code on ARM Windows, the rule is simple: native ARM64 editor, native ARM64 toolchain, matching extensions. Get those three aligned and the Snapdragon laptop becomes a genuinely pleasant dev machine — fast, cool, and long-lived on battery. Measure with a real project, align every layer to ARM64, and the Snapdragon laptop rewards you with a development environment that is fast, silent, and sips battery. Once the editor, runtimes, and extensions all report ARM64, keep it that way by always downloading the ARM64 installer first and questioning any setup that suggests otherwise.

Frequently asked questions

Should I install the ARM64 or x64 version of VS Code on a Snapdragon laptop?
Install the ARM64 (user or system) build. It launches faster, uses less battery, and runs extensions natively. The x64 build works through emulation but is noticeably slower, especially with large workspaces.
Can ARM64 and x64 VS Code coexist on the same machine?
They can, but it causes confusion: separate installs, separate extension folders, and terminals that may launch the wrong Node or Python. Pick one architecture and uninstall the other.
Do all VS Code extensions work on ARM64?
Almost all do. A handful of extensions bundle x64-only native binaries — typically language servers or debuggers. Check the extension’s page for ARM64 support, and prefer extensions that ship multi-architecture binaries.
Why is my integrated terminal opening the wrong shell architecture?
The terminal inherits VS Code’s environment plus your shell choice. If tools behave oddly, check whether the terminal is launching ARM64 or x64 versions of Node, Python, or Git, and align them with your VS Code build.