DEV Community

Cover image for How My VS Code Spawned 15 Copies of Itself and Froze My Entire System (And How I Fixed It)
Anthony
Anthony

Posted on

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

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.


What Was Actually Going On

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-session
When 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 files
VS Code detected its own ghost, thought another instance was already running, and threw the warning dialog.
3. Session restore made it worse
VS 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 killer
I'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 on
My 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.


How I Debugged It

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:

# 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
Enter fullscreen mode Exit fullscreen mode

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.

The Fix (Step by Step)

Step 1 - Kill all VS Code processes
pkill -9 -f code && pkill -9 -f Code
Step 2 - Remove lock and singleton files
rm -rf ~/.config/Code/*.lock
rm -rf ~/.config/Code/Singleton*

Step 3 - Clear all cache, including GPU cache
rm -rf ~/.config/Code/Cache
rm -rf ~/.config/Code/CachedData
rm -rf ~/.config/Code/GPUCache
rm -rf /tmp/.code-*

Step 4 - Disable GPU acceleration permanently
nano ~/.config/Code/User/settings.json
Add:
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.json
nano ~/.config/Code/argv.json
Add:
json{
"disable-hardware-acceleration": true
}
Now you can click the VS Code icon normally without needing the terminal flag every time.

Step 6 - Test launch
code --disable-gpu
Clean single window. The Extensions are being reinstalled fresh. Problem solved.


Here are My Key Takeaways

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.


My Setup:

OS: Parrot OS (Debian-based)
GPU: Intel UHD 605
RAM: 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.

Top comments (0)