Stop Claude Code from Killing Your Ubuntu Session — The Swap Setup I Wish I Had Sooner

If you’ve been running multiple AI coding tools like Claude Code or Gemini CLI alongside your usual dev workflow, chances are you’ve already met Linux’s most infamous process: the OOM Killer. One moment you’re deep in a build, the next your entire desktop session is gone.

I hit this wall hard last week. Two Claude Code windows, Gemini CLI in another terminal, three VS Code instances, a couple of Docker containers, and Chrome with a dozen tabs — my 16GB machine just couldn’t take it anymore. Sessions were crashing, builds dying mid-way, the whole thing.

After digging in, I realized the problem wasn’t just RAM. It was how my swap was (poorly) configured. Here’s the setup that actually fixed it.

Why This Keeps Happening on Linux (Not Windows)

If you’re coming from Windows, the crash behavior feels unfair. Windows expands its pagefile dynamically — things slow to a crawl, but your apps stay alive.

Linux plays differently. Once physical RAM and swap are exhausted, the kernel doesn’t try to be nice. It fires up the OOM Killer, picks the fattest process, and kills it instantly. The system stays stable, sure, but the victim is always your most important process.

The default swap size on most Ubuntu installs is tiny — usually 2GB or 4GB. Fine for browsing. Nowhere near enough for modern AI tooling.

Step 1: Check What You’re Working With

Before touching anything, see where you stand:

free -h
swapon --show

Here’s what mine looked like when things were crashing:

               total        used        free      shared  buff/cache   available
Mem:            15Gi        14Gi       607Mi       5.5Gi       6.7Gi       1.2Gi
Swap:          511Mi       511Mi       216Ki

NAME      TYPE SIZE   USED PRIO
/swapfile file 512M 511.6M   -2

512MB of swap. And it was already maxed out. No wonder things were falling over.

Step 2: Turn Off the Existing Swap

You can’t resize a swap file while it’s active, so:

sudo swapoff /swapfile

This might take a moment — the kernel has to move whatever’s in swap back into RAM.

Step 3: Delete the Old File and Check Disk Space

sudo rm /swapfile
df -h

Make sure you’ve got enough room on / for whatever size you’re about to allocate.

Step 4: How Big Should Swap Actually Be?

This is where most guides hand-wave. The honest answer depends on what you’re doing:

Your setup	Swap size
Casual use	4–8GB
Normal dev work	8–16GB
AI CLI tools + Docker + IDEs	16–32GB
You want hibernate to work	At least your RAM size

I went with 32GB. With 16GB of RAM, that puts me at 48GB of total virtual memory. Overkill? Maybe. But I haven’t seen a single OOM crash since.

sudo fallocate -l 32G /swapfile

If fallocate complains (some filesystems don’t play nice with it), fall back to dd. It’s slower but always works:

sudo dd if=/dev/zero of=/swapfile bs=1G count=32

Step 5: Lock It Down and Format It

Swap files should only be readable by root. Don’t skip this:

sudo chmod 600 /swapfile
sudo mkswap /swapfile

You’ll see something like:

Setting up swapspace version 1, size = 32 GiB (34359734272 bytes)
no label, UUID=...

Step 6: Turn It On

sudo swapon /swapfile
free -h

               total        used        free      shared  buff/cache   available
Mem:            15Gi        14Gi       576Mi       5.2Gi       6.4Gi       1.1Gi
Swap:           31Gi        11Mi        31Gi

There it is. 32GB ready to catch anything that spills out of RAM.

Step 7: Make It Stick After Reboots

If you were already using /swapfile, your /etc/fstab probably already has the entry. Worth checking:

grep swapfile /etc/fstab

You should see:

/swapfile swap swap defaults 0 0

If it’s missing, add it:

echo '/swapfile swap swap defaults 0 0' | sudo tee -a /etc/fstab

Step 8: The Setting Nobody Tells You About — Swappiness

Here’s what most blog posts miss, and it’s the single biggest lesson I learned.

After bumping up my swap, I assumed I was done. But my SSD was getting hammered with writes, and things felt sluggish even with plenty of RAM free. Something was off.

The culprit: vm.swappiness.

This kernel parameter controls how eagerly Linux pushes memory to swap. On Ubuntu, it ships at 60 by default — meaning the kernel starts swapping stuff out way before it actually needs to, even when you have gigabytes of RAM available.

For a desktop or dev machine, that’s the wrong default.

cat /proc/sys/vm/swappiness
# 60

Change it to 10. That tells the kernel: “Only touch swap when RAM is genuinely running out.”

# Apply now
sudo sysctl vm.swappiness=10

# Make it survive reboots
echo "vm.swappiness=10" | sudo tee -a /etc/sysctl.conf

Value	Behavior
60 (default)	Swaps eagerly, even when RAM is free
10 (what you want)	Only swaps when RAM is almost full
0	Basically never swaps (risky, can trigger OOM)

Why this matters:

• SSD lifespan — fewer unnecessary writes
• Performance — RAM is orders of magnitude faster than disk
• Responsiveness — no weird lag when switching apps

Before and After

	Before	After
Swap size	512MB	32GB
Swappiness	60	10
OOM crashes	Multiple per day	Haven’t seen one in weeks
Max concurrent tools	Maybe 2-3 before things got shaky	Everything at once, no issues

A Few Things Worth Knowing

ZRAM is an alternative worth exploring

Instead of (or alongside) a swap file on disk, you can use ZRAM — a compressed RAM-based swap. It’s much faster than disk swap and doesn’t touch your SSD at all. The trade-off is that it consumes some RAM for the compressed data.

sudo apt install zram-tools

Works great in combination with a traditional swap file: ZRAM fills up first, then swap catches the overflow.

Swap isn’t a substitute for real RAM

I’ll be honest — 32GB of swap got me out of trouble, but the real fix is more physical RAM. If your laptop supports it, upgrading to 32GB of actual RAM is the proper solution. Check your max capacity:

sudo dmidecode -t memory | grep -E "Maximum Capacity|Size|Speed"

AI CLI tools like Claude Code are Electron apps running Node.js processes, and they love to eat memory. A machine with 32GB of RAM handles them comfortably. 16GB can do it, but you need the swap safety net.

Wrapping Up

If your sessions have been dying under the weight of modern dev tools, the fix isn’t complicated — it’s just two settings that almost nobody gets right out of the box. Bigger swap, lower swappiness.

Took me longer than I’d like to admit to figure this out. Hopefully this saves you the headache.