How to Fix Remote Development Slowness When Using VS Code with SSH / WSL — The Network & File-Watch Tweak That Restored Speed

If you’ve ever worked with remote development in Visual Studio Code (VS Code) using either SSH or the Windows Subsystem for Linux (WSL), you’ve probably hit moments of painful sluggishness. Files take forever to load, your terminal becomes unresponsive, and even small coding tasks become an obstacle course. This article will walk you through how to identify and fix one of the most common yet overlooked causes of that slowness — file watching and remote network behavior.

TL;DR

VS Code can slow dramatically when working with SSH/WSL due to excessive file-watching and inefficient sync over the network. Adjusting the file-watching settings using files.watcherExclude and configuring your SSH setup can dramatically improve responsiveness. On WSL, disabling recursive watching and excluding certain folders can produce near-native speed. A few key tweaks in VS Code settings and system configurations might be all you need to feel like you’re developing locally again.

The Problem: Awesome Tools, Sluggish Experience

Visual Studio Code has transformed development usability by allowing you to work seamlessly with code hosted remotely. Whether you’re SSH’ing into a Linux server or coding inside WSL on your Windows laptop, VS Code makes it feel local — until it doesn’t.

The slowness often creeps in once your codebase gets bigger. It might start slow, get noticeably worse with multitasking, and start feeling like you’re working over dial-up. But why?

It’s Not Just the Network

While poor internet connectivity can be part of the issue with remote SSH slowness, there’s more to the story:

• File watcher overload: VS Code attempts to watch thousands of files in your workspace continuously.
• Inefficient file systems: WSL1/2 and remote SSH sometimes introduce performance bottlenecks depending on where your files are hosted.
• Third-party extensions: Extensions can sometimes aggressively watch or access files in a way that kills performance.

Let’s dissect how to fix this at the root — starting with the file-watcher settings and moving through some practical networking tweaks.

Victim #1: File Watching

VS Code tries to keep an eye on all of your project files for changes. That’s useful for hot reloads and responsive linting — but when you’re dealing with a large monorepo or high file counts, it becomes a liability.

File watching becomes especially expensive when used over SSH or through WSL because the backend (your server or WSL instance) is constantly pushed to track changes at high frequency. Windows’ and Linux’s handling of file notification APIs differ, and VS Code tries to compensate with excessive polling.

Solution: Exclude Large or Unneeded Paths

Start by fine-tuning your VS Code’s settings.json configuration to exclude folders that don’t need monitoring.

{
  "files.watcherExclude": {
    "/node_modules/": true,
    "/.git/objects/": true,
    "/dist/": true,
    "/build/": true
  }
}

This small change often leads to big performance improvements. You’re telling VS Code not to waste its resources watching files that don’t affect your day-to-day work — such as bundled output, version control internals, and dependencies that rarely change.

Another helpful setting to consider:

{
  "files.useExperimentalFileWatcher": true
}

This enables an improved file watcher implementation as of recent versions of VS Code that is designed to consume fewer resources and offer better performance in remote scenarios.

Victim #2: WSL or SSH Filesystem Lag

Both WSL and SSH introduce some filesystem translation overhead. In WSL2, files stored on the Windows side and accessed from Ubuntu feel torturously slow. In SSH, network latency exacerbates this issue, especially when back-and-forth communications are involved over a slower connection.

Solution: Organize your files better

If you’re using WSL2: Move your project files inside the Linux filesystem instead of opening them from Windows paths like /mnt/c/Users/…. This avoids the expensive cross-filesystem callbacks. Try placing your repo somewhere like:

/home/youruser/code/myproject

And open VS Code from within WSL:

wsl

cd ~/code/myproject

code .

If you’re using SSH: Avoid syncing too many symbolic links and don’t mount massive directories via remote filesystem features like sshfs unless you have a reason. Use scp, rsync, or Git to efficiently move files instead.

Tip: Avoid too many terminals or editors

When working over SSH, especially via VS Code’s Remote SSH extension, avoid spawning too many terminal instances or concurrently opened folders. Each one initiates another SSH session and sometimes a full server instance on the machine — compounding delay due to CPU/memory limits or connection throttling.

Bonus Tweak: Your SSH Config File

On your local machine, updating your SSH configuration can help reduce overhead or improve reconnection behavior.

Edit or create ~/.ssh/config with the following:

Host yourdevserver
  HostName remote.example.com
  User youruser
  ControlMaster auto
  ControlPath ~/.ssh/cm-%r@%h:%p
  ControlPersist 10m
  ServerAliveInterval 30
  ServerAliveCountMax 5

This setup reuses SSH control connections instead of launching a new one each time. As a result, VS Code reconnects faster and doesn’t stall when terminals or extensions reset their SSH sessions.

Disable Unused Extensions

Some extensions run in the background and start watching or indexing files as soon as a workspace is initialized. While useful, this activity can overwhelm a remote setup. Go through your installed extensions and disable the ones you’re not actively using when working remotely.

Also, consider disabling automatic extension sync on remote sessions:

{
  "remote.extensionKind": {
    "your-heavy-extension-id": "ui"
  }
}

This setting tells VS Code to run certain extensions only on your local machine instead of trying to run them over the remote session.

Verify: Are You Actually Faster?

You’ll know you’re on the right track when:

• Directory contents load instantly when you open a new folder
• Workspace search results appear within a couple of seconds
• Terminals don’t lag or freeze when many files are open
• Low CPU and memory usage are observed on the remote server or WSL instance

Final Thought: Local Tool Speeds for Remote Code

VS Code’s remote development experience is powerful, but defaults don’t always suit larger or more resource-constrained projects. With a few smart tweaks — particularly reducing aggressive file watching and optimizing connections — you can regain much of that “local” feeling, even when developing on a cloud server or via WSL2.

It’s worth spending 15–30 minutes today adjusting your setup. Those few minutes could save you days of frustration over the course of your project.

Key Takeaways

• Exclude directories like node_modules and .git from file watching to speed up VS Code over remote environments.
• Move files into the native Linux file tree if working inside WSL2 to avoid aggressiveness caused by filesystem conversions.
• Configure your SSH for connection reuse to eliminate long reconnect times.
• Disable or constrain heavyweight extensions that aren’t needed in your remote session.

Remote development should empower you — not bog you down. With these tweaks, you’re back on track to fast, efficient coding — wherever your code decides to live.