›_ Claude Code Issues
Claude Code Issues / #83453

[BUG] Claude Desktop (Linux): GPU process launch retries at ~9,000/sec, writing 346 GB to /var/log/syslog in 24 hours

Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in thread ↓
Activity 5 comments · opened Aug 3, 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?

[BUG] Claude Desktop (Linux): GPU process launch retries at ~9,000/sec, writing 346 GB to /var/log/syslog in 24 hours

Summary

On Ubuntu 22.04 with an NVIDIA GPU, Claude Desktop's GPU process fails to launch with error_code=1002. The launch is then retried repeatedly, and each attempt writes an ERROR line to stderr. These lines reach /var/log/syslog via systemd-journald and rsyslog.

Measured from the log timestamps, the retries occur at roughly 9,000 per second and continue for as long as the process runs. Observed disk usage:

$ sudo du -h --max-depth=1 /var/log | sort -rh | head -3
469G    /var/log
4.1G    /var/log/journal
2.0M    /var/log/installer

$ sudo find /var/log -type f -size +1G -exec ls -lh {} \;
-rw-r----- 1 syslog adm 120G Aug  3 10:09 /var/log/syslog
-rw-r----- 1 syslog adm 346G Aug  2 00:00 /var/log/syslog.1

syslog.1 covers a single rotation period (~24 h). The root filesystem ran out of space.

Environment

| | |
|---|---|
| Claude Desktop version | 1.24012.9 |
| Install method | Official Anthropic apt repository (downloads.claude.ai/claude-desktop/apt/stable) |
| OS | Ubuntu 22.04 LTS, x86_64 |
| Kernel | 6.8.0-110-generic |
| Session type | X11 |
| Desktop | GNOME |
| GPU driver | NVIDIA 580.173.02 |
| libva | libva2 2.14.0-1 (Ubuntu 22.04 stock; VA-API interface version 1.14) |
| Hardware acceleration | Default; never manually disabled |

Log output

Excerpt from /var/log/syslog:

[5538:0727/095517.198730:ERROR:media/gpu/vaapi/vaapi_wrapper.cc:1680] Installed VAAPI version is too old. min supported version: 1.17 installed version: 1.14
[5500:0728/101429.991060:ERROR:content/browser/network_service_instance_impl.cc:703] Network service crashed or was terminated, restarting service.
[5500:0728/101429.995143:ERROR:content/common/zygote/zygote_communication_linux.cc:291] Failed to send GetTerminationStatus message to zygote
[5500:0728/101429.999710:ERROR:content/browser/gpu/gpu_process_host.cc:992] GPU process launch failed: error_code=1002
[5500:0728/101430.000568:ERROR:content/browser/gpu/gpu_process_host.cc:992] GPU process launch failed: error_code=1002
[5500:0728/101430.000790:ERROR:content/browser/gpu/gpu_process_host.cc:992] GPU process launch failed: error_code=1002
[5500:0728/101430.000943:ERROR:content/browser/gpu/gpu_process_host.cc:992] GPU process launch failed: error_code=1002
[5500:0728/101430.001087:ERROR:content/browser/gpu/gpu_process_host.cc:992] GPU process launch failed: error_code=1002
... (identical lines continue)
[5500:0728/101430.003903:ERROR:content/browser/gpu/gpu_process_host.cc:992] GPU process launch failed: error_code=1002

30 consecutive gpu_process_host.cc:992 lines span 3.3 ms (101430.000568 → 101430.003903). At ~110 bytes per line this is approximately 1 MB/s written continuously.

No GPU process isn't usable. Goodbye. line appears anywhere in the log — the retry sequence did not terminate on its own.

Measurements

Share of total syslog volume, sampled over the last 200,000 lines:

$ sudo tail -n 200000 /var/log/syslog | awk '{print $5}' | sort | uniq -c | sort -rn | head -5
 194833 com.anthropic.Claude.desktop[420280]:
   1546 kernel:
    788 /usr/libexec/gdm-x-session[1463]:
    748 /usr/libexec/gdm-x-session[3370]:
    465 systemd[1]:

97.4% of sampled lines come from the app. Each line carries a distinct microsecond timestamp, so rsyslog's message repeated N times deduplication does not apply and every attempt is written out in full.

Expected behavior

The retry sequence terminates after a bounded number of failures, and repeated identical errors are not written once per attempt.

Actual behavior

Retries continue at ~9,000/sec for the lifetime of the process, each writing a log line, until the app is closed or the disk fills.

Impact

  • /var/log reached 469 GB; the root filesystem ran out of space.
  • Recovery required truncate -s 0 /var/log/syslog (rm does not release the space while rsyslog holds the file descriptor).

What Should Happen?

The retry sequence terminates after a bounded number of failures, and repeated identical errors are not written once per attempt.

Error Messages/Logs

Please see attached file.

Steps to Reproduce

Not yet isolated to a reliable trigger. The conditions under which it was observed:

  1. Ubuntu 22.04 (kernel 6.8.0-110-generic), X11/GNOME, NVIDIA driver 580.173.02,

stock libva2 2.14.0-1 (VA-API 1.14).

  1. Claude Desktop 1.24012.9 installed from the official apt repository, launched

normally and left running. Hardware acceleration at its default setting.

  1. The GPU process fails to launch with error_code=1002 and the launch is retried

continuously (see Log output).

  1. Observed across two separate app sessions on different days (PIDs 5500 and 5538,

07/27 and 07/28), so it is not a one-off.

To check whether a given machine is affected:

sudo tail -n 100000 /var/log/syslog | grep -c "gpu_process_host"

A non-trivial count here indicates the same loop.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.24012.9 （claude-desktop)

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

syslog_tail.txt

View original on GitHub ↗

4 Comments

userajr · 2 months ago

Reproduced on a very different stack, which suggests the retry loop (not "old libva") is the core factor

Hit this on hardware and a software stack that differ from the original report on almost every axis (Intel iGPU instead of NVIDIA, Wayland instead of X11, and a current libva/VA-API that is well above the 1.17 minimum). Same error_code=1002, same never-terminating retry, same disk-filling outcome.

| Component | This report | Original report |
|---|---|---|
| GPU | Intel UHD 770 (Alder Lake-S GT1), i915 | NVIDIA (580.173.02) |
| OS | Ubuntu 26.04 LTS | Ubuntu 22.04 LTS |
| Kernel | 7.0.0-29-generic (HWE) | 6.8.0-110-generic |
| Session | Wayland / GNOME | X11 / GNOME |
| Mesa | 26.0.3 | (not noted) |
| libva / VA-API | 2.23.0 (VA-API 1.22), above the 1.17 min | 1.14, below min |
| Claude Desktop | 1.26832.0 | 1.24012.9 |

Why this may be relevant: the "Installed VAAPI version is too old" explanation does not apply here, since my VA-API (1.22) exceeds the stated 1.17 minimum, yet the loop is identical. The failure reproduces independently of the libva version, on a different GPU vendor and display server.

Observed impact:

  • Retry rate ~7,000/sec (measured 100,000 log lines spanning 14.3 s of timestamps).
  • syslog.1 reached 177 GB in a single ~24 h rotation; live syslog at 18 GB when caught, so root fs hit 100% full.
  • On 1.26832.0 the source line is content/browser/gpu/gpu_process_host.cc:1011] GPU process launch failed: error_code=1002 (was :992 on 1.24012.9). During the incident essentially 100% of syslog lines were this message.

Correction to an earlier version of this comment. I previously reported --disable-gpu plus a journald SystemMaxUse cap as a working mitigation. After a recurrence, both turned out to be wrong on this build, so here is the corrected information:

  • --disable-gpu does not stop the loop on 1.26832.0. With the flag present on the main process, the GPU process is still spawned and still fails at error_code=1002 in the same tight loop, and it also pins a CPU core. There is no hardware-acceleration setting persisted in ~/.config/Claude to toggle either.
  • The process does not exit on window close. The offending process had been running for nearly 3 days after its window was closed, still looping and writing to syslog the whole time. This compounds the disk fill and matches #86105.
  • A journald SystemMaxUse cap does not protect /var/log/syslog. That cap bounds the systemd journal only (which stayed at ~2 GB as configured). The 190+ GB was /var/log/syslog, written by rsyslog, which the journald setting does not govern.

What actually bounds the disk usage here is an rsyslog rule that drops the repeating message, independent of app behavior:

# /etc/rsyslog.d/00-drop-claude-gpu-spam.conf
if $programname startswith 'com.anthropic.Claude' and $msg contains 'GPU process launch failed' then stop

Then sudo systemctl restart rsyslog. Verified that this drops the flood while still allowing normal Claude Desktop log lines through. It protects the disk but does not stop the CPU spin, so the practical workaround on this build is to avoid running the desktop app and fully quit any lingering process (pkill -x claude-desktop) rather than just closing the window.

j0ruge · 1 month ago

Same bug here, on a different environment. Confirms it is not specific to NVIDIA/VAAPI.

Environment: Ubuntu 24.04, Intel UHD 770 (AlderLake), Claude Desktop 1.26832.0 (latest at the time), X11/GNOME.

Different trigger: our GPU process was killed by the kernel OOM killer (memory pressure: 4 GB swap at 100%, four OOM events in cascade 00:19-00:35 on 2026-08-18). Claude Desktop then entered the same infinite retry loop, error_code=1002, writing through journald to /var/log/syslog.

Measured impact:

  • ~200k-500k identical ERROR lines per minute (gpu_process_host.cc:992)
  • syslog grew ~13 GB/h; 45 GB to 48 GB in about 3 hours before containment
  • host became unresponsive under the I/O flood, disk nearly full
  • internal log (~/.config/Claude/logs/main1.log): Network Service process exited with 'killed' outside app quit at 00:35:08, right after the OOM kill

Suggested fix: detect external SIGKILL on the GPU/network service child and do not auto-restart in a tight loop; rate-limit identical error lines with exponential backoff; fall back to software rendering instead of retrying GPU launch forever.

Workaround that worked: pkill -f claude-desktop (SIGTERM to the app stopped the flood immediately). The bug persists in 1.26832.0, released well after this report.

rsembera · 28 days ago

Fourth environment, and a fourth distinct trigger — still present in 2.110.1

Same error_code=1002, same unbounded retry. Worth noting this reproduces on a major version newer than the reports above (2.110.1 vs 1.24012.9 / 1.26832.0), so it survived the 1.x → 2.x transition.

| Component | This report | #1 (OP) | #2 (userajr) | #3 (j0ruge) |
|---|---|---|---|---|
| GPU | Intel Arrow Lake-U [8086:7d41], xe | NVIDIA 580 | Intel UHD 770, i915 | Intel UHD 770 |
| OS | Debian 13 (trixie) | Ubuntu 22.04 | Ubuntu 26.04 | Ubuntu 24.04 |
| Kernel | 6.12.107+deb13-amd64 | 6.8.0-110 | 7.0.0-29 | — |
| Session | Wayland / GNOME 48.7 | X11 | Wayland | X11 |
| Mesa | 25.0.7 | — | 26.0.3 | — |
| Claude Desktop | 2.110.1 (Electron 44.2.0) | 1.24012.9 | 1.26832.0 | 1.26832.0 |
| Trigger | ozone/Vulkan incompatibility | libva too old | (not identified) | OOM kill |

The trigger here is self-diagnosed by Chromium, which makes the retry loop harder to defend than in the cases above:

[ERROR:ui/ozone/platform/wayland/gpu/wayland_surface_factory.cc:249]
'--ozone-platform=wayland' is not compatible with Vulkan.
Consider switching to '--ozone-platform=x11' or disabling Vulkan

Immediately followed by the familiar loop:

[ERROR:content/browser/gpu/gpu_process_host.cc:1029]
GPU process launch failed: error_code=1002

So the app detects the incompatibility, prints the remedy, and then retries the identical failing launch indefinitely rather than applying either suggestion or falling back to software rendering.

Measured scale: ~50,000 failures/minute. 193,637 in a single boot; 890,477 over six days (10–16 Sept). Journal grew to 1.4 GB in that period — smaller than the 346 GB above only because Debian's journald caps by percentage and this machine has a large root filesystem.

User-visible symptom: the app hangs on launch with a spinning cursor and never opens. It is a race — some launches initialise before the conflict bites and work normally — so it presents as intermittent. The only remedy found is killing all claude-desktop/electron processes and relaunching until one wins.

Workarounds that do NOT work, for the record:

  • ELECTRON_OZONE_PLATFORM_HINT=x11 — the variable is correctly inherited (verified in child processes), but the app passes --ozone-platform explicitly from its own code, which overrides the hint. The GPU process still launches with --ozone-platform=wayland.
  • Editing ~/.local/share/applications/com.anthropic.Claude.desktop — the app rewrites it on every launch (X-Claude-Generated=true). See #93688.

Request: a supported way to pass --ozone-platform or --disable-features=Vulkan, and a bounded retry with software fallback.

rsembera · 28 days ago

Still present in 2.2553.0 (released 17 Sept). Unchanged: GPU process launches with --ozone-platform=wayland, same Vulkan incompatibility warning, same unbounded retry — 54,997 failures in the ~18 minutes between installing the update and a launch finally succeeding.

Affected versions now: 1.52386.6, 2.110.0, 2.110.1, 2.2553.0.

Showing cached comments. Read the full discussion on GitHub ↗

Related Claude Code issues

Matched on shared title terms, labels, topic and reported release — ranked so issues with real discussion come first.

Browse by topic

Browse all Claude Code issue topics →