Fix VS Code Crash: The window has crashed (reason: 'oom', code: '139')

What's happening

VS Code pops up a dialog: The window has crashed (reason: 'oom', code: '139'). The editor freezes, the window goes blank, and sometimes takes down your whole workspace. This is an out-of-memory (OOM) kill — the OS or Electron runtime terminated the renderer process because it ran out of heap space.

Large monorepos, too many extensions running simultaneously, or TypeScript projects with a massive type graph are the usual triggers. The fix comes down to two things: give VS Code more memory, and cut down what's actually consuming it.

Step 1 — Confirm it's really OOM

Don't jump to fixes yet. First, rule out a corrupted extension or a bad workspace state as the real culprit.

Open the VS Code process explorer: Help → Open Process Explorer. Watch the Memory column while you reproduce the crash. If the renderer process climbs past 1–2 GB and then vanishes, you've got an OOM problem.

On Linux, cross-check with the kernel OOM killer log:

dmesg | grep -i 'killed process'
# or
journalctl -k | grep oom

Look for a line mentioning Out of memory: Killed process tied to a code or code-oss binary. That confirms the OS pulled the trigger, not a VS Code bug.

Step 2 — Increase the renderer heap limit

Electron's V8 renderer starts with roughly 700 MB–1.5 GB of heap, depending on your platform. That ceiling is easy to hit on large projects. Raise it.

Open your VS Code startup flags file:

Ctrl+Shift+P  →  "Preferences: Configure Runtime Arguments"

Add this entry to bump the heap to 4 GB:

{
  "js-flags": "--max-old-space-size=4096"
}

Save, then fully restart VS Code — close all windows, don't just reload. Rule of thumb: use 4096 on an 8 GB machine, 8192 on 16 GB.

Launching from the terminal? Pass the flag directly instead:

code --js-flags="--max-old-space-size=4096" .

Step 3 — Find which extension is leaking memory

Extensions share a single host process. One poorly written extension can silently eat several gigabytes while everything else looks innocent. Use extension bisect to track it down fast:

Ctrl+Shift+P  →  "Start Extension Bisect"

VS Code disables half your extensions, asks you to reproduce the crash, then narrows it down automatically — no manual toggling required.

Prefer the blunt approach? Launch with everything off:

code --disable-extensions .

If the crash disappears, an extension is to blame. The usual suspects: Pylance on large Python projects, ESLint on sprawling JS codebases, GitLens on repos with tens of thousands of commits, and language servers in general.

Step 4 — Tune TypeScript memory for large projects

The TypeScript language server is consistently among the top memory consumers in VS Code. Its default cap is 3 GB — fine for small projects, not enough for a large monorepo with 500+ source files.

In your workspace .vscode/settings.json:

{
  "typescript.tsserver.maxTsServerMemory": 8192,
  "typescript.tsserver.experimental.enableProjectDiagnostics": false
}

While you're at it, check your tsconfig.json excludes. Without them, tsserver type-checks everything under the project root — including millions of lines inside node_modules:

{
  "exclude": [
    "node_modules",
    "dist",
    "build",
    "**/*.spec.ts"
  ]
}

This one missing exclude block can double or triple tsserver's memory usage on its own.

Step 5 — Reduce workspace scope

Every folder in your workspace gets file watchers, a search index, and language features. Open your entire home directory or a huge monorepo root, and VS Code is doing an enormous amount of background work before you type a single character.

• Use a .code-workspace file and include only the subdirectories you actually edit.
• Exclude large generated folders from file watching and search:

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

Step 6 — Disable features you don't use

Some built-in VS Code features are surprisingly expensive. Turn off what you don't need:

{
  "editor.minimap.enabled": false,
  "editor.codeLens": false,
  "git.decorations.enabled": false,
  "extensions.autoUpdate": false,
  "telemetry.telemetryLevel": "off"
}

Code Lens is a quiet offender here. Those inline reference counts and test-run buttons require VS Code to keep a live symbol table in memory at all times. Disabling it alone can free 100–300 MB on a large TypeScript project.

Verify the fix

Clean restart first — don't just reload the window:

• Close VS Code completely (pkill code on Linux if needed).
• Reopen your project.
• Wait 2–3 minutes for all language servers to finish indexing.
• Open Help → Open Process Explorer — the renderer process should plateau below your new heap limit rather than keep climbing.

On Linux you can watch memory live in the terminal:

watch -n 2 'ps aux | grep code | grep -v grep | awk "{print \$6/1024 \" MB \", \$11}"'

If memory levels off and the OOM crash doesn't come back after an hour of normal use, you're done.

Quick reference

• Crash stops with --disable-extensions → run extension bisect to identify the bad one.
• Crash only on large TypeScript projects → raise typescript.tsserver.maxTsServerMemory and add proper tsconfig.json excludes.
• Crash on any project → bump --max-old-space-size in argv.json.
• Crash on Linux only → check dmesg; the kernel may be killing VS Code before its own heap limit kicks in. If RAM is tight (under 8 GB), adding a swap file can help.