[FEATURE] Linux: raise oom_score_adj while a session is idle, so OOM killers pick idle sessions first

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When a Linux desktop runs out of memory, the OOM killer that acts (the kernel's,
or earlyoom) picks its victim mostly by size. To that killer, an idle Claude
Code session looks like any other process. Yet it is the cheapest process on
the machine to kill: its whole state is in its transcript, and
claude --resume <id> brings it back.

• Idle sessions pile up. I leave sessions open in terminal tabs for hours or

days, for example a session resumed after a reboot that then waits at the
prompt. Each one holds 250–350 MB RSS here, and more after a long session.

• The killer can't tell them apart. All of them inherit the terminal's

oom_score_adj (200 here, from the systemd user session). An idle session
scores the same as the active one I am typing in. On my machine, earlyoom
would first kill a 74 MB Firefox Web Content process (it frees almost
nothing and then has to kill again), not an idle session.

• What it cost me. A laptop (15 GB RAM + 11 GB swap, 5 days of uptime with

suspend/resume) filled its swap to 100 % and thrashed (load 240, 42 %
iowait) until the desktop froze and I had to power it off. Claude Code was
not shown to be the cause. But idle sessions marked as first victims would
have given the OOM killer a harmless way to free memory before the freeze.

Proposed Solution

Claude Code knows when a session is idle; the kernel does not. On Linux:

1. Idle means all of the following:

• waiting for user input;
• no tool call in flight;
• no background Bash task or Monitor;
• no running subagent;
• no pending scheduled wakeup (/loop, cron);
• no Remote Control activity;
• idle for longer than a delay (default e.g. 30 min).

1. When idle: save /proc/self/oom_score_adj, then write the configured

value (default 1000).

1. When active again (a keystroke at the prompt, an incoming message, a

wakeup): write the saved value back before anything else, so that the
commands it then runs inherit the normal value.

1. On SIGTERM: exit cleanly, with the transcript flushed, and print

claude --resume <id> in the terminal, so that the user sees what happened
and how to get the session back.

1. Settings, e.g. "idleOomScoreAdj": 1000 (null turns the feature off)

and "idleOomDelayMinutes": 30.

No privilege is needed. A process may raise its own oom_score_adj, and lower
it back to the value it started with (not below it). Checked on Linux 7.0:

$ sleep 60 & echo 1000 > /proc/$!/oom_score_adj   # 200 → 1000: ok
$ echo 200 > /proc/$!/oom_score_adj                # back to 200: ok
$ echo 0 > /proc/$!/oom_score_adj                  # below the start value: EACCES

On other platforms this is a no-op.

Alternative Solutions

I run a workaround today: a script, run every 2 minutes by a systemd user
timer. It detects idle sessions from the outside:

• the session ID comes from the fd the process keeps open on

/tmp/claude-<uid>/<project>/<session>/tasks;

• the last activity is the mtime of ~/.claude/projects/<project>/<session>.jsonl

and of its subagent transcripts;

• the process must have no child process and use no CPU during a 2 s sample.

The script then sets oom_score_adj to 1000, and restores the saved value
when the session is active again.

It works: the idle session's oom_score goes to 1339, against at most 823 for
every other process, so it is the first victim. But it has limits that only
Claude Code can lift:

• it cannot see a pending scheduled wakeup, so a waiting /loop session looks

idle and could be killed;

• it reacts up to 2 min late when a session becomes active again;
• it depends on internal paths that may change.

I also considered closing idle sessions by hand. It works, but it is easy to
forget, and the point is to free memory only when the machine needs it.

Priority

Medium - Would be very helpful

Feature Category

Performance and speed

Use Case Example

1. I work in 3–4 Claude Code sessions in terminal tabs, across projects. Two of

them have been waiting at the prompt since yesterday.

1. A browser, a mail client and a container build push the machine into swap.
2. Today, the OOM killer (or earlyoom) kills browser tabs one by one, or

nothing gets killed and the desktop thrashes until it freezes.

1. With this feature, it kills the two idle sessions first, frees about 600 MB

at no cost, and the machine stays usable.

1. Later I run claude --resume <id> in those tabs and continue where I was.

Additional Context

• Related, not duplicates:
• #31942 (closed, not planned) asked for a fixed, higher oom_score_adj

for Agent Teams teammates than for the lead. This request is about the
idle state of any session, and changes at runtime.

• #91081 asks for resource governance of the process trees a session spawns

(memory caps, pressure feedback).

• #18859 and #67433 report idle sessions whose memory keeps growing; this

feature would make such sessions the first to go under pressure.

• #101710: the Desktop app already has a memory governor that evicts idle

sessions. This request is a lightweight equivalent for the CLI that lets
the system's own OOM killers do the eviction.

• Prior art: browsers rank their processes for the OOM killer through

oom_score_adj. On this machine Firefox sets 233 on its Web Content
processes, against 100 on its main process.

• Environment:
• Claude Code 2.1.299
• Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic, GNOME (Wayland)
• earlyoom 1.9.0, systemd-oomd active