[BUG] Claude Desktop for Linux: main process spins at 100% CPU on session start, generates repeated coredumps

Status Fixed / completed
Maintainer reply None cached
Activity 0 comments · opened Aug 3, 2026 · closed Aug 25, 2026

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 Claude Desktop for Linux (official .deb, package claude-desktop 1.24012.9, Maintainer: Anthropic PBC), not the Claude Code CLI. There is no dedicated issue tracker for the desktop app, so filing here.

The Claude Desktop main process enters an unrecoverable 100% CPU loop shortly after session start, without any user interaction with the application. XFCE session restoration relaunches it at login, so the loop begins immediately and persists indefinitely. The process also crashes repeatedly, generating large coredumps via systemd-coredump that saturate disk I/O and make the entire desktop unresponsive.

top output, 15 minutes after boot, application never opened manually in this session:

%Cpu(s): 10,0 us, 8,5 sy, 34,4 id, 47,1 wa
MiB Mem: 15933,5 total, 178,4 free
MiB Swap: 0,0 total

PID USER VIRT RES SHR S %CPU TIME+ COMMAND
2803 pc 48,7g 258896 158136 R 100,3 4:53.35 claude-desktop
3868 root 17328 7160 6264 D 5,3 0:14.75 systemd-coredum
2736 pc 1448,3g 295876 148544 S 2,3 0:37.01 claude-desktop

Key observations:

  • PID 2803 accumulated 4:53 of CPU time within 15 minutes of uptime, i.e. pinned at 100% since session start.
  • Its VIRT is 48.7 GB versus ~1.4 GB for other processes of the same application.
  • systemd-coredump sits in uninterruptible sleep (state D) writing dumps from repeated crashes. This pushed I/O wait to 77% in an earlier measurement, at which point the desktop stopped responding entirely and required a hard power-off (twice).
  • pkill -9 -f claude-desktop immediately restores normal system responsiveness.
  • Process does not respond to SIGTERM.

This shares a failure signature with #83624 (state R busy-loop, 100% CPU on one core, unresponsive to SIGTERM) and the issues it references (#22158, #22041, #22240), though the trigger and product differ.

What Should Happen?

The application should idle at near-zero CPU when not in use, and should not crash repeatedly on startup.

Error Messages/Logs

systemd-coredump[3179]: Process 2646 (claude-desktop) of user 1000 terminated abnormally without generating a coredump
systemd[1848]: app-com.anthropic.Claude-2646.scope: Consumed 7.344s CPU time.

Steps to Reproduce

  1. Have Claude Desktop open when logging out of an XFCE session with session saving enabled (XFCE default).
  2. Log back in. XFCE restores the application automatically.
  3. Within seconds the main process reaches 100% CPU and stays there. No window needs to be opened or interacted with.

Observed across multiple sessions and on two separate user accounts on the same machine.

Workaround: clearing XFCE saved sessions (rm -rf ~/.cache/sessions/*) and disabling session autosave prevents the automatic relaunch. Disabling coredump storage prevents the disk saturation, though the CPU loop itself remains.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A - this is Claude Desktop, package claude-desktop 1.24012.9 (official .deb)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Coredumps from AppRun.wrapped (the Claude Desktop binary) had accumulated in /var/lib/systemd/coredump/ across multiple days before I cleared them, so the crashes are not a one-off.

Linux Mint 22.3 "Zena", XFCE edition
Display server: X11
GPU: NVIDIA GeForce GTX 1060 6GB, driver 580.173.02
RAM: 16 GB, no swap configured
Motherboard: Gigabyte Z370 AORUS Gaming 3

View original on GitHub ↗