Tools: Essential Guide: How My VS Code Spawned 15 Copies of Itself and Froze My Entire System (And How I Fixed It)

Tools: Essential Guide: How My VS Code Spawned 15 Copies of Itself and Froze My Entire System (And How I Fixed It)

What Was Actually Going On

How I Debugged It

The Fix (Step by Step)

Here are My Key Takeaways It started innocently. I opened VS Code on my Parrot OS machine to get some work done.

Then my system started lagging.Then popups appeared.Then it froze completely.Then VS Code opened again. And again. And again, until I had 15 stacked dialog boxes all screaming: "Another instance of Code is running but not responding. Please close all other instances and try again." Each pop-up was spawning another. My GUI was frozen. I couldn't type. I tried switching to a TTY terminal, but it wouldn't load. I tried Ctrl+Alt+F3 again the whole system restarted.I genuinely had no idea what was happening. After rebooting and doing some serious investigation (with help from both Claude and ChatGPT - yes, I used both, I'll explain), here's the full root cause chain:1. VS Code crashed mid-sessionWhen it crashed, it left behind corrupted lock files and IPC socket files. These are flags the app sets to say "I'm currently running." A clean exit removes them. A crash doesn't.2. Next launch saw the lock filesVS Code detected its own ghost, thought another instance was already running, and threw the warning dialog.3. Session restore made it worseVS Code has a setting that restores all previously open windows on the next launch. I had 5 windows open when it crashed. So it tried to reopen all 5 simultaneously.4. GPU acceleration was the silent killerI'm running an Intel UHD 605 GPU. Electron apps (VS Code is built on Electron, which is essentially a Chromium browser) have known conflicts with Intel Mesa drivers on Debian-based Linux distros. The GPU cache was corrupted, causing VS Code to crash on startup, which triggered the loop again.5. containerd was piling onMy system had Docker's container runtime (containerd) running in the background. Combined with VS Code's IO-heavy startup, it was hammering my disk simultaneously, making everything worse. I want to be transparent: I was actively using AI during this. I had Claude walk me through log analysis, and I cross-validated with ChatGPT, which added the crucial GPU angle I had missed.The ChatGPT insight that cracked it: "GPU / rendering crash is VERY COMMON on Parrot + Intel UHD 605. Electron tries GPU → driver glitch → crash → restart loop."That's what unlocked the full fix. Here's the exact diagnostic flow: My RAM was actually fine (5.7GB available). The OOM killer hadn't fired. This ruled out memory exhaustion and pointed clearly toward GPU + lock file corruption. Step 1 - Kill all VS Code processespkill -9 -f code && pkill -9 -f CodeStep 2 - Remove lock and singleton filesrm -rf ~/.config/Code/*.lockrm -rf ~/.config/Code/Singleton*Step 3 - Clear all cache, including GPU cacherm -rf ~/.config/Code/Cacherm -rf ~/.config/Code/CachedDatarm -rf ~/.config/Code/GPUCacherm -rf /tmp/.code-*Step 4 - Disable GPU acceleration permanentlynano ~/.config/Code/User/settings.jsonAdd:json{ "disable-hardware-acceleration": true, "window.restoreWindows": "none", "window.reopenFolders": "none"}The window.restoreWindows: none is what stopped the multi-window spawn cascade. VS Code now always opens fresh instead of trying to restore a crashed session.Step 5 - Make --disable-gpu permanent via argv.jsonnano ~/.config/Code/argv.jsonAdd:json{ "disable-hardware-acceleration": true}Now you can click the VS Code icon normally without needing the terminal flag every time.Step 6 - Test launchcode --disable-gpuClean single window. The Extensions are being reinstalled fresh. Problem solved. VS Code is an Electron app - yes, it's essentially a browser. It inherits all of Chromium's GPU quirks on Linux.Intel UHD 605 + Mesa drivers + Electron = known bad combo on Debian-based distros. Disable hardware acceleration for VS Code, Discord, and Chrome if you're on this GPU.Lock files are silent saboteurs. Any crash that doesn't clean up after itself leaves a ghost that haunts your next launch.Session restore is a trap after a crash. Disable it. Open your files manually.Using multiple AIs isn't cheating - it's smart. Claude caught the lock file. ChatGPT caught the GPU angle. Cross-validating got me to the full picture faster.TTY is your emergency exit. Learn Ctrl+Alt+F3 and Ctrl+Alt+F7. When your GUI dies on Linux, TTY is the difference between a 5-minute fix and a full reinstall, lol. OS: Parrot OS (Debian-based)GPU: Intel UHD 605RAM: 8GB

VS Code version: 1.112.0 If this saved your system, drop a reaction. And if you've hit something similar on a different distro, share it in the comments. I'd love to know how it manifested differently. Templates let you quickly answer FAQs or store snippets for re-use. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse

Command

Copy

# Check RAM and swap free -h && swapon --show # Check if OOM killer fired journalctl -b | grep -i "oom\|killed process\|out of memory" # Check what's running ps aux --sort=-%cpu | head -10 # Check RAM and swap free -h && swapon --show # Check if OOM killer fired journalctl -b | grep -i "oom\|killed process\|out of memory" # Check what's running ps aux --sort=-%cpu | head -10 # Check RAM and swap free -h && swapon --show # Check if OOM killer fired journalctl -b | grep -i "oom\|killed process\|out of memory" # Check what's running ps aux --sort=-%cpu | head -10