[BUG] Claude Code process exits with code 143 (SIGTERM) every exactly 5 minutes in Desktop app & VS Code extension — terminal CLI unaffected

Open 💬 5 comments Opened May 25, 2026 by SharedAccKaT

Bug description

Claude Code child process spawned by the Desktop app (and VS Code extension) is killed with SIGTERM (exit code 143) at exactly 300-second intervals. The terminal CLI (claude in shell) works perfectly — the issue is exclusive to the Desktop app and VS Code extension wrapper.

Evidence from logs (~/Library/Logs/Claude/main.log)

Crash pattern — exact 5-minute intervals

2026-05-25 17:13:57  → crash
2026-05-25 17:18:58  → crash (gap: 300s)
2026-05-25 17:23:58  → crash (gap: 300s)
2026-05-25 17:28:58  → crash (gap: 300s)
2026-05-25 17:38:58  → crash (gap: 300s after manual restart)
2026-05-25 17:43:58  → crash (gap: 300s)
2026-05-25 17:48:58  → crash (gap: 300s)
2026-05-25 17:53:59  → crash (gap: 300s)
2026-05-25 17:58:59  → crash (gap: 300s)
2026-05-25 18:03:59  → crash (gap: 300s)

Same pattern observed on May 4, May 15, and May 22 — not a one-time occurrence.

Error from main.log

[error] Session local_8de989a6-... query error: Claude Code process exited with code 143 {
  stack: 'Error: Claude Code process exited with code 143
    at d4i.getProcessExitError (.../app.asar/.vite/build/index.js:459:8311)
    at ChildProcess.i (.../app.asar/.vite/build/index.js:459:11562)
    at Object.onceWrapper (node:events:631:26)
    at ChildProcess.emit (node:events:521:24)
    at ChildProcess._handle.onexit (node:internal/child_process:295:12)'
}

CycleHealth shows it's a timer, not response timeout

Some queries complete successfully in 60–93s, while others get killed at the exact 5-minute mark regardless of progress:

17:23:12 healthy cycle (68s, hadFirstResponse=true)    ← OK
17:26:33 healthy cycle (64s, hadFirstResponse=true)    ← OK
17:51:16 healthy cycle (93s, hadFirstResponse=true)    ← OK
17:28:58 unhealthy cycle (62s, reason=system_error)    ← killed at 5-min mark
17:58:59 unhealthy cycle (34s, reason=system_error)    ← killed at 5-min mark

Not macOS Jetsam / OOM

  • macOS system log (log show) shows zero Jetsam/memorystatus/kill entries for Claude processes
  • memory_pressure reports 39–48% free after closing background apps
  • Crash persists regardless of memory state

Not OAuth/auth issue

Logs showed [remoteManagedSettings] fetch returned 401 concurrently, but re-login fixed the 401 errors while 143 crashes continued unchanged at the same 5-minute interval.

Reproduction steps

  1. Open Claude Desktop app (v1.8555.2) on macOS
  2. Start or resume a Claude Code session (tested with ~115 transcript messages, 126 tools, 11 MCP servers, 4 plugins)
  3. Use the session normally — send messages, run tools
  4. Observe: process exits with code 143 every exactly 300 seconds
  5. Session auto-resumes but crashes again at the next 5-minute mark
  6. Run the same session via terminal CLI (claude --resume <session-id>) → no crash

Expected behavior

The Claude Code child process should not be killed by a 300-second timer while actively processing or idle. The process should remain alive until explicitly terminated by the user or by a legitimate resource constraint.

System information

  • Claude Desktop app: v1.8555.2
  • Claude Code CLI: v2.1.149
  • macOS: 26.5 (Build 25F71)
  • Chip: Apple M3
  • RAM: 16 GB
  • Model: claude-opus-4-6 with --effort max

Session details

  • Session had 115 transcript messages at time of crashes
  • 126 tools loaded, 11 MCP servers, 4 plugins (skills, remote, 2 local LSP)
  • CLI session ID: a9c4e41e-c8d3-491b-8124-54833635b2d1

Possibly related

  • #45717 — Bash tool timeout SIGTERM propagation kills parent process
  • #53136 — claude --print -p exits 143 after ~14 tool round-trips

Workaround

Use the terminal CLI instead of Desktop app / VS Code extension for long or heavy sessions.

View original on GitHub ↗

This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗