claude-code - 💡(How to fix) Fix Orphaned Claude Code process enters 100% CPU busy loop when parent terminal is closed [2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#47872Fetched 2026-04-15 06:39:55
View on GitHub
Comments
2
Participants
2
Timeline
9
Reactions
0
Timeline (top)
labeled ×6commented ×2closed ×1

When the terminal (iTerm2) window/tab that launched a Claude Code desktop app session is closed, the claude process becomes orphaned (reparented to launchd PID 1) and enters a 100% CPU busy loop instead of gracefully terminating.

Error Message

  • Process consumed 101% CPU for 17+ hours after the parent terminal was closed
  • SIGTERM was ignored — only SIGKILL terminated it
  • sample output showed the main thread in a tight loop with no I/O waits — pure busy spinning
  • A zombie child process (<defunct>) was present, suggesting lifecycle management broke down
  • No network connections were open — the process was not communicating with the API

Root Cause

When the terminal (iTerm2) window/tab that launched a Claude Code desktop app session is closed, the claude process becomes orphaned (reparented to launchd PID 1) and enters a 100% CPU busy loop instead of gracefully terminating.

Code Example

PID:     65585
PPID:    1 (launchd — orphaned)
Command: claude --output-format stream-json --verbose --input-format stream-json
         --effort high --model claude-opus-4-6[1m]
         --resume 3ab1600e-95fd-4443-b5a2-e8170967ef5c
         --permission-mode acceptEdits --allow-dangerously-skip-permissions
Started: Mon Apr 13 18:57:49 2026
Uptime:  17h 35m at time of kill
CPU:     101% (constant)
RAM:     ~474 MB peak
State:   R (running, not sleeping)
Children:
  - glab mcp serve (PID 65593, healthy, 0% CPU)
  - <defunct> zombie (PID 65650)
RAW_BUFFERClick to expand / collapse

Description

When the terminal (iTerm2) window/tab that launched a Claude Code desktop app session is closed, the claude process becomes orphaned (reparented to launchd PID 1) and enters a 100% CPU busy loop instead of gracefully terminating.

Steps to reproduce

  1. Launch Claude Code from the desktop app (Claude.app) — it spawns a claude CLI process
  2. Close the terminal/tab that hosts the session (or close the desktop app window)
  3. The claude process does not terminate — it gets reparented to launchd (PPID=1)
  4. The process enters a CPU-bound busy loop consuming ~100% of one core indefinitely

Observed behavior

  • Process consumed 101% CPU for 17+ hours after the parent terminal was closed
  • SIGTERM was ignored — only SIGKILL terminated it
  • sample output showed the main thread in a tight loop with no I/O waits — pure busy spinning
  • A zombie child process (<defunct>) was present, suggesting lifecycle management broke down
  • No network connections were open — the process was not communicating with the API

Expected behavior

The claude process should detect that its parent terminal/stdin is gone and either:

  • Gracefully shut down, or
  • At minimum, stop consuming CPU (idle/sleep)

It should also respond to SIGTERM.

Environment

  • OS: macOS 26.2 (Darwin 25.2.0), Apple M5
  • Claude Code version: 2.1.92
  • Terminal: iTerm2 3.6.x
  • Launch method: Claude.app desktop → CLI process with --output-format stream-json

Process details (from investigation)

PID:     65585
PPID:    1 (launchd — orphaned)
Command: claude --output-format stream-json --verbose --input-format stream-json
         --effort high --model claude-opus-4-6[1m]
         --resume 3ab1600e-95fd-4443-b5a2-e8170967ef5c
         --permission-mode acceptEdits --allow-dangerously-skip-permissions
Started: Mon Apr 13 18:57:49 2026
Uptime:  17h 35m at time of kill
CPU:     101% (constant)
RAM:     ~474 MB peak
State:   R (running, not sleeping)
Children:
  - glab mcp serve (PID 65593, healthy, 0% CPU)
  - <defunct> zombie (PID 65650)

extent analysis

TL;DR

The claude process likely needs to be modified to handle the case when its parent terminal is closed, to prevent it from entering a CPU-bound busy loop.

Guidance

  • Investigate how the claude process handles SIGHUP signals, which are typically sent when a terminal is closed, to determine why it is not terminating as expected.
  • Review the code for any potential issues with signal handling, such as ignoring SIGTERM or not properly handling SIGHUP.
  • Consider adding a mechanism for the claude process to detect when its parent terminal has been closed, such as by checking for the existence of the terminal or its file descriptor.
  • Look into the zombie child process (<defunct>) to understand why it is not being properly cleaned up, which may be related to the lifecycle management issue.

Example

No code snippet can be provided without more information about the claude process's codebase.

Notes

The issue seems to be specific to the claude process and its handling of terminal closure, so any solution will likely require modifications to the process itself.

Recommendation

Apply a workaround to handle the case when the parent terminal is closed, such as by sending a SIGTERM signal to the claude process when the terminal is closed, until a proper fix can be implemented in the claude process code.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The claude process should detect that its parent terminal/stdin is gone and either:

  • Gracefully shut down, or
  • At minimum, stop consuming CPU (idle/sleep)

It should also respond to SIGTERM.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING