Background process termination crashes Claude Code in Docker containers

Status Open
Maintainer reply None cached
Activity 16 comments · opened Jan 3, 2026

When running Claude Code inside a Docker container, killing background processes (either manually with k or when Claude autonomously decides to kill them) causes Claude Code itself to crash with exit code 137 (SIGKILL).

Environment

  • Claude Code v2.0.76
  • Running inside Docker container (python:3.12-slim base)
  • Container started via docker exec -it <container> /bin/bash

Steps to Reproduce

  1. Run Claude Code inside a Docker container
  2. Start a background process using Claude's built-in background feature:

``
> start the backend server
● Bash(uvicorn api:app --port 8000) timeout: 10m
⎿ Running in the background (↓ to manage)
``

  1. Press to view background tasks, then k to kill the process
  2. Claude Code exits/crashes immediately

Expected Behavior

Claude Code should kill only the background process and continue running.

Actual Behavior

Claude Code crashes with exit code 137 (SIGKILL). The signal sent to kill the background process also kills Claude itself.

Root Cause Analysis

The issue appears to be that Claude Code and its spawned background processes share the same process group. When Claude sends a signal to kill the process group (e.g., kill -PGID), it kills itself too.

Workaround

Manually using setsid to isolate background processes works:

setsid uvicorn api:app --port 8000 > /tmp/server.log 2>&1 &

However, this loses Claude's background process monitoring and notification features.

Suggested Fix

Claude Code should spawn background processes in isolated process groups using setsid or setpgid() internally, while maintaining its monitoring wrapper. This would prevent signal propagation while preserving the background task management UI.

Additional Context

  • Tried docker run --init - doesn't help since Claude runs via docker exec
  • Tried script -q -c "claude ..." /dev/null - still crashes
  • Tried setsid claude ... - Claude loses terminal input
  • Only setsid on the child processes works, but loses monitoring

View original on GitHub ↗

16 Comments

github-actions[bot] · 6 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

jauco · 6 months ago

This issue is still occurring

dalaing · 5 months ago

This is still occurring.

gigi81 · 5 months ago

This is still occurring

bwbuchanan · 4 months ago

Still occurring, happens when running claude using docker sandbox

kcarriedo · 3 months ago

+1 on the diagnosis — shared process group between parent (Claude Code) and spawned background tasks is the root cause, and setsid / setpgid on the children is the right shape of fix.

One nuance worth calling out for anyone landing here: once you isolate children into their own pgid, the kill path also has to change. kill -<PID> (negative PID, kill-by-pgid) on the child's new group is what you want; a plain kill <PID> will only hit the immediate child and leave MCP grandchildren / npx wrappers behind as orphans (which is the other failure mode tracked in #22612 and #33947).

In Rust, that maps to:

  • spawn with Command::process_group(0) (or pre_exec(|| { libc::setsid(); Ok(()) }) on older toolchains)
  • on cancel/timeout, libc::killpg(pgid, SIGKILL) — never kill(child_pid, ...)

That combination keeps the parent alive, contains the blast radius to the child tree, and avoids the orphan-MCP accumulation that shows up under PPID=1 on macOS / docker-init on Linux. The setsid uvicorn … workaround you found works for the same reason — it's just doing the pgid isolation by hand at the shell level, at the cost of losing the monitoring UI hooks.

jellzone · 2 months ago

still has this issue

ariel-bloch · 1 month ago

The issue is still triggering constantly.

niravnegong · 1 month ago

This issue is still occurring

evgenijohngong · 1 month ago

+1 daily

nir-megery · 1 month ago

+1 happening frequently without any clear reason

alegmalinovsky · 1 month ago

been living with it for months! happy to see someone found the root cause - now please lets fix it

Rocky-Gong · 1 month ago

still happens

AdamNitzan911 · 1 month ago

Still bugging me

tehila-gilboa · 1 month ago

still has this issue

ngeorgak-gong · 1 month ago

for me too.. :(