Launcher hangs at 100% CPU forever (app never starts) due to O(n²) awk over an unbounded `launcher.log`

[juancourville-lang]

Summary

The launcher can get stuck before Electron ever starts, spinning one awk process at 100% CPU indefinitely. The app never opens and any tray/menu relaunch hangs the same way. Root cause is the GPU-fatal detection in launcher-common.sh reading the entire launcher.log with quadratic string accumulation, combined with the fact that launcher.log is never rotated/truncated and can grow to tens of MB (in my case 67 MB, flooded by WebRTC audio error spam).

Environment

• Package: claude-desktop 1.15200.0-2.0.22 (.deb)
• Electron: 41.5.0
• OS: Debian 13 (trixie), X11
• Display backend: X11 (XDG_SESSION_TYPE=x11)

Symptoms

• App stops launching; tray icon gone.
• A single awk child of /usr/bin/claude-desktop pegs one core at ~100% and never exits:

juan  82593  bash /usr/bin/claude-desktop
juan  82624  99.9  awk  '/^--- Claude Desktop (Launcher|AppImage) Start...  .cache/claude-desktop-debian/launcher.log

• launcher.log had grown to 67 MB / ~453k lines / 208 launch sections.

Root cause

_previous_launch_hit_gpu_fatal() (launcher-common.sh:196) runs:

{
    sections[section] = sections[section] $0 "\n"   # <-- O(n²) string growth
}

This accumulates the whole log file into in-memory section strings via repeated concatenation. Awk reallocates and copies an ever-growing string per line, so cost is quadratic in file size. At ~67 MB it effectively never finishes, and setup_electron_env (which calls it) blocks → Electron is never exec'd.

Two compounding problems make this reachable in normal use:

1. No log rotation. setup_logging() only does mkdir; launcher.log grows without bound across launches.
2. WebRTC audio spam. During sessions with audio/voice the log fills with thousands of lines/sec like:

   ERROR:.../neteq/comfort_noise.cc:50] No multi-channel support
   ERROR:.../neteq/neteq_impl.cc:826] audio_frame->samples_per_channel_ (480) != output_size_samples_ (480)
   

   A single long session bloats the penultimate section — exactly the one the awk targets.

Impact

Once the log is large enough, the app becomes unlaunchable until the user finds and kills the awk and clears the log. Nothing on screen explains why.

Suggested fixes

1. Don't scan the whole file. Only the previous launch section is needed. Read the log tail (e.g. last N KB, or seek to the second-to-last --- ... Start --- header) instead of accumulating every section. Even just tail -c <bytes> piped into the matcher would bound the cost.
2. Avoid O(n²) accumulation. Track only the current/previous section, or scan backwards; never build an unbounded concatenated string.
3. Rotate/truncate launcher.log. Cap size (e.g. truncate to last N lines if > a few MB) in setup_logging().
4. Tame the WebRTC audio error spam (or downgrade/suppress those Chromium ERROR lines), which is what drives the log growth in the first place.

Workarounds (for other users hitting this)

• Kill the stuck awk + launcher, back up and truncate ~/.cache/claude-desktop-debian/launcher.log.
• Set CLAUDE_DISABLE_GPU=0 in the launch environment. Because of the [[ -v CLAUDE_DISABLE_GPU ]] guard in setup_electron_env, defining the var makes the launcher skip _previous_launch_hit_gpu_fatal() entirely (and =0 keeps hardware acceleration on). A user-level ~/.local/share/applications/claude-desktop.desktop override with Exec=env CLAUDE_DISABLE_GPU=0 /usr/bin/claude-desktop %u makes the bypass stick for tray/menu launches and survives package upgrades.

[github-actions]

Automated draft — AI analysis, not maintainer judgment. This bot won't close issues, apply labels beyond triage routing, or claim fixes are shipped. Findings below are starting points; the code citations are what to verify first.

Looks like the launcher hang is caused by _previous_launch_hit_gpu_fatal running an unbounded O(n²) awk scan over launcher.log, which grows without limit across sessions because neither setup_logging nor run_electron_and_cleanup apply any size guard — blocking Electron from ever starting.

• Looks like _previous_launch_hit_gpu_fatal() accumulates every log line into an in-memory section string via repeated concatenation (sections[section] = sections[section] $0 "\n"), making awk cost quadratic in file size and effectively non-terminating on a large log. (scripts/launcher-common.sh:199-225)
• Likely the hang-before-launch flow is: deb launcher build_electron_args 'deb' → _previous_launch_hit_gpu_fatal → awk reading the full unbounded $log_file — blocking all code after it, so Electron is never exec'd. (scripts/packaging/deb.sh:171-171)
• Likely _previous_launch_hit_gpu_fatal() passes the full $log_file path to awk unconditionally, so awk reads the entire log rather than only the most recent sections needed for the check. (scripts/launcher-common.sh:225-225)
• Worth checking: run_electron_and_cleanup() appends all Electron stdout/stderr directly to $log_file with no size guard ("$@" >> "$log_file" 2>&1), meaning high-frequency Chromium error spam floods launcher.log during every session and feeds the quadratic scan. (scripts/launcher-common.sh:613-613)
• Appears to be a missing log-rotation or truncation step in setup_logging() — the function only does mkdir -p and sets log_file, so launcher.log grows without bound across all launches and Electron sessions. (scripts/launcher-common.sh:11-15)
• Appears that when CLAUDE_DISABLE_GPU is set in the environment (to any value, including 0), the [[ -v CLAUDE_DISABLE_GPU ]] guard short-circuits and _previous_launch_hit_gpu_fatal is never called — confirming the reporter's workaround mechanism. (scripts/launcher-common.sh:301-307)

Related: #583 — related

Full investigation artifacts (investigation.json, validation.json) are attached to the triage workflow run.

[angrysky56]

Important addition regarding a cascading failure with the in-app "Disable Hardware Acceleration" setting:

If users encounter this launch issue and mistakenly try to solve it by toggling off Hardware Acceleration from within the app's UI (if they managed to get it open once by killing the awk process), it causes the electron process itself to silently lock up, maxing out a single CPU core in the background before any window is drawn. Because it only pegs one core, users with modern multi-core systems likely won't even notice the CPU spike, they will just see the app silently fail to open.

When disabled via the UI, Claude writes "isHardwareAccelerationDisabled": true to ~/.config/Claude/claude_desktop_config.json. On many Linux environments, attempting to launch Electron with this flag causes the electron process itself to silently lock up at 100% CPU usage before any window is drawn.

Quick fix for users:

Because the electron process is the one hanging, the awk script never even enters the picture, meaning the CLAUDE_DISABLE_GPU=0 workaround alone won't fix it.
The user is completely locked out of the UI to toggle it back on.
Recovery steps for users stuck in this state: If your app is completely failing to launch and you recently toggled the hardware acceleration setting in the UI:

killall electron claude-desktop
Open ~/.config/Claude/claude_desktop_config.json
Manually change "isHardwareAccelerationDisabled": true back to false.
Apply the Exec=env CLAUDE_DISABLE_GPU=0 /usr/bin/claude-desktop %u workaround to your .desktop file as mentioned in the original post.