[BUG] Claude Desktop (Linux/Wayland): renderer leaks deleted `/dev/shm` file descriptors until it hits the 1024 limit, then the window freezes (~7–25 h of use)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Note: this is about the Claude Desktop app on Linux (the .deb from the official apt repo), not the Claude Code CLI. This tracker is where Desktop bugs are filed (e.g. #29888).

On Linux, the main Claude Desktop renderer process keeps accumulating file descriptors that point at deleted /dev/shm/.org.chromium.Chromium.* shared-memory files and never releases them. The renderer's soft RLIMIT_NOFILE is 1024. When it reaches that limit the window stops repainting and the app is effectively frozen until it's restarted. Other Claude Desktop processes (main, GPU, network, node services, cowork-linux-helper) stay flat.

This is a different leak from #29888 / #29573 (the macOS Virtualization.framework VM REG/DIR descriptor leak). Here the Linux cowork helper is stable at ~100 fds, and system-wide open files are only ~28k.

Environment

| | |
|---|---|
| OS | Kubuntu / Ubuntu 26.04.1 LTS, kernel 7.0.0-34-generic |
| Desktop | KDE Plasma 6.6.6, Wayland (--ozone-platform=wayland) |
| GPU | Intel Arc (Arrow Lake-P, Arc Pro 130T/140T), --render-node-override=/dev/dri/renderD128 |
| Claude Desktop | 2.9939.4 (from the official apt repo downloads.claude.ai/claude-desktop/apt/stable); also reproduced on 1.24012.9 and 2.7032.0 |

Leak rate

Growth on 2.9939.4 (logged every 5 min; excerpt at 30-min intervals), normal interactive use:

10:30  120/1024     15:30  513/1024
11:30  235/1024     16:30  574/1024
12:30  364/1024     17:30  611/1024
13:30  408/1024     18:30  747/1024
14:30  487/1024     20:00  771/1024   → restarted

Two more days on 2.9939.4 (hourly samples) show the leak is driven by active use. While the app sits idle overnight it's almost flat. During active use it climbs 100–230 fds/hour:

2026-09-30 00:55  233   (idle overnight)
2026-09-30 07:55  286   ← +53 in 7 h idle
2026-09-30 08:55  421   (active use starts)
2026-09-30 09:55  654
2026-09-30 11:55  830
2026-09-30 13:55  940
2026-09-30 14:55 1001
2026-09-30 15:05 1016   → window frozen, restarted
2026-09-30 15:50  119
2026-09-30 18:50  460
2026-09-30 21:50  590
2026-10-01 07:50  630   (idle overnight: +40 in 10 h)

Across the first day that's an average of ≈ 72 fds/hour, so the window freezes after roughly 7–14 h of active use. On 2.7032.0 the rate was ≈ 40/h (froze in ~25 h); on 1.24012.9 it took ~2 days. So the leak has gotten faster across releases.

What Should Happen?

Shared-memory regions (GPU transfer buffers etc.) are closed when they're released, so the renderer's descriptor count stays bounded.

Error Messages/Logs

Renderer at the point of freezing (2.7032.0, 2026-09-29):


pid 2634235  --type=renderer  fds=1024/1024  (990 → /dev/shm/... (deleted))
all other claude-desktop processes: 12–177 fds


Breakdown of a renderer's fds (2.9939.4, ~1 h after start):


    168 /dev/shm/.org.chromium.Chromium.XXXXXX (deleted)
     10 socket:[N]
      4 anon_inode:[eventpoll]
      4 anon_inode:[eventfd]
      3 /dev/null
      2 /usr/lib/claude-desktop/vN_context_snapshot.bin


When the limit is hit, earlier versions logged:

TransferBuffer::Initialize() failed
AllocateRingBuffer() failed

Steps to Reproduce

1. Run Claude Desktop on Linux/Wayland and use it normally (chatting; long conversations).
2. Watch the renderer's descriptors:

``bash
for p in $(pgrep -f 'claude-desktop --type=renderer'); do
echo "$p total=$(ls /proc/$p/fd | wc -l) shm_deleted=$(ls -l /proc/$p/fd | grep -c '/dev/shm.*deleted')"
done
``

1. The shm_deleted count climbs steadily and never goes down. At 1024 the UI freezes.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop 2.9939.4 (Linux, apt). Also seen on 2.7032.0 and 1.24012.9. (Claude Code CLI 2.1.281 on the same machine is NOT affected.)

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Workaround

A user systemd timer that checks the renderer's descriptor count every 5 min, warns at 75% of the limit, and restarts Claude Desktop if it's frozen. Restarting always clears the problem temporarily.

Regression?

Not as far as I know: present in every version I've run on Linux (1.24012.9, 2.7032.0, 2.9939.4), and it got faster in each newer release.