Visual Studio Code System Requirements for Windows, macOS and Linux

Visual Studio Code can start on modest hardware, but “it launches” is not the same as “it supports your workload comfortably.” The editor, language servers, extensions, terminals, browsers, containers and local build tools all compete for the same CPU and memory. This guide separates Microsoft’s official baseline from practical configurations for real development work.

Official minimum requirements

Microsoft currently recommends a processor running at 1.6 GHz or faster and 1 GB of RAM. The download is under 200 MB and the installed editor uses less than 500 MB before extensions, caches and project data are added.

These values are compatibility requirements, not a recommendation for a TypeScript monorepo, Android project or container-based environment. Your compiler, browser and database do not become part of VS Code simply because they are launched from its terminal.

Practical hardware tiers

The practical values are planning guidance rather than Microsoft minimums. Measure the whole development session: editor processes, language servers, test runners, browser tabs and virtualized services.

Check the machine before installation

Windows

Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, OSArchitecture,
    @{Name='RAM_GB';Expression={[math]::Round($_.TotalVisibleMemorySize/1MB,1)}}

Get-CimInstance Win32_Processor |
  Select-Object Name, NumberOfCores, NumberOfLogicalProcessors

Get-Volume | Select-Object DriveLetter,
  @{Name='Free_GB';Expression={[math]::Round($_.SizeRemaining/1GB,1)}}

macOS

sw_vers
sysctl -n machdep.cpu.brand_string
sysctl -n hw.memsize
df -h /

Linux

uname -m
ldd --version | head -n 1
free -h
lscpu | grep -E 'Model name|CPU\(s\)'
df -h "$HOME"

On Linux, a 64-bit CPU is not enough if the distribution ships an older C library. Check the glibc line before downloading the current desktop build. An older unsupported distribution may still run an old VS Code release, but it will not receive current product and security updates.

Why extensions change the requirement

Extensions run in one or more extension-host processes. Language tooling may also start separate processes such as tsserver, pylance, Java language servers or linters. Find the actual consumers instead of assuming the window itself is slow:

Help → Open Process Explorer
Developer: Show Running Extensions
Developer: Startup Performance

Run one comparison with extensions disabled:

code --disable-extensions

If startup and typing latency disappear, adding RAM may hide the symptom but will not identify the extension responsible. Re-enable extensions in small groups and inspect the extension-host CPU time.

Remote SSH, WSL and Dev Containers

• Remote SSH: the VS Code Server and remote extensions consume CPU, RAM and disk on the remote host. The local client still renders the interface.
• WSL: the Linux environment uses a virtualized memory pool and virtual disk. Builds, package caches and Docker integration can exceed the editor’s footprint by many gigabytes.
• Dev Containers: the editor client remains on the desktop while VS Code Server runs in the container. Docker or another container runtime adds its own requirements.

For a remote-only workflow, a modest laptop with 8 GB RAM can be usable when compilation and indexing occur on a capable server. Running the same repository locally inside WSL and several containers is a different workload even though the editor window looks identical.

Low-memory configuration checks

Before replacing hardware, reduce avoidable indexing and file-watching work. Exclude generated directories that do not need editor search:

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

Do not exclude source or generated files required by your language server without checking its documentation. Also review duplicate linters, overlapping formatters and extensions installed “just in case.”

A five-minute acceptance test

1. Open the real repository, not an empty folder.
2. Wait until indexing and language-server startup complete.
3. Open Process Explorer and record the largest processes.
4. Run the project’s build or test command while watching available memory.
5. Repeat once with code --disable-extensions if typing or navigation stalls.

The machine is suitable when the real project can index, build and keep the editor responsive without sustained memory pressure or heavy paging. The official 1 GB baseline answers whether the editor can run; this test answers whether your development environment can.

References: official VS Code requirements and remote development overview.