Beware: Claude Code's Background Tasks Are Ge

You kick off a long build, test suite, or migration as a background task, walk away, and come back to a half-finished repo and a message that the task “ended unexpectedly.” No error, no stack trace — just a dead process and git complaining it can’t read its own index. If that sounds familiar, you may have been hit by a freshly reported, reproducible Claude Code crash.

The Issue

GitHub issue #76974 reports that background Bash tasks (run_in_background=true) are being sporadically SIGKILLed by the CLI’s own task supervision layer — roughly 1% of dispatches, on Linux. The kill happens mid-run, often while the task is writing files or mutating the working tree. Because the process is terminated with SIGKILL (not a graceful shutdown), partial writes are never rolled back. The reporter notes this can corrupt git state: an interrupted git operation leaves the index or object database in an inconsistent state that git status then flags as broken.

The bug is labeled bug, has repro, area:tools, and area:core — meaning the maintainers have confirmed they can reproduce it, and it touches the core task-execution path rather than a peripheral feature.

What 1% Really Means in Practice

A 1% failure rate sounds small until you realize that background tasks are often the longest-running operations in your workflow. If you dispatch 20 background tasks a day — builds, linting, migrations, test suites — you can expect one failure roughly every five working days. Over a month, that is six corrupted git states, each requiring manual diagnosis and recovery. For CI-adjacent workflows where background tasks run on every commit, the compounding risk is even higher.

Are You Affected?

If you run long or write-heavy background tasks, check your repos for silent corruption:

# Inspect git health in any repo where a background task ran
git status --porcelain --branch
git fsck --no-dangling 2>&1 | grep -i "error\|corrupt" || echo "git OK"

# Find background task supervisor processes still flagged as running
ps aux | grep -i "[t]ask" | grep -i "claude"

# Spot half-written files modified in the last 3 hours
find . -newermt "-3 hours" \( -name "*.tmp" -o -name "*.swp" -o -name "*.lock" \) 2>/dev/null

If git fsck reports corruption, or you see lock/.tmp files with no process holding them, a task was likely killed mid-write.

Signs You Were Hit But Didn’t Notice

Not all corruption is loud. Watch for these subtler symptoms:

git status shows changes you never made — a partial write left file content inconsistent with the index.
Merge conflicts on a branch you did not touch — the object database has mismatched parents from a mid-operation kill.
git stash apply fails with “index does not match” — stash operations depend on clean index state.
CI fails on a commit that passed locally — your local repo has hidden corruption that the clean CI checkout does not.

If any of these appear after a background task, run git fsck immediately.

The Fix

Immediate Actions

Avoid long write-heavy background tasks until a fix lands; run them in a foreground session or a separate tmux/screen shell the CLI does not supervise.
Commit before background work. A clean commit gives you a safe restore point: git stash or git reset --hard <sha> recovers a corrupted tree.
Run git fsck after every background task on shared or important repos.
Watch the issue #76974 for the patch.

Safe Background Task Workflow

Until the upstream fix ships, here is a defensive pattern that keeps background tasks from touching git state directly:

# 1. Commit all work before dispatching
git add -A && git commit -m "checkpoint before background task"

# 2. Run long operations in a detached tmux session (outside Claude's supervision)
tmux new-session -d -s bg-task "your-long-command && touch /tmp/task-done"

# 3. Re-attach and check result
tmux attach -t bg-task
cat /tmp/task-done 2>/dev/null && echo "Task completed cleanly"

# 4. Verify repo health after
git fsck --no-dangling 2>&1 | grep -i "error\|corrupt" || echo "repo clean"

This sidesteps the supervision layer entirely. The tmux session is independent of Claude Code’s process tree, so it cannot be SIGKILLed by the bug’s trigger path.

Recovering a Corrupted Repository

If git fsck does report corruption, follow this sequence:

# Identify broken objects
git fsck --no-dangling 2>&1

# Attempt automatic repair (safe — only touches loose objects)
git reflog expire --expire=now --all
git gc --prune=now

# If corruption persists, check the reflog for the last known good state
git reflog
git reset --hard HEAD@{1}

# Nuclear option: re-clone and cherry-pick clean commits
git log --oneline -20   # note the good SHAs
# In a fresh clone:
git cherry-pick <sha1> <sha2> ...

Why It Happened

The CLI’s task supervisor appears to enforce a timeout or resource cap by sending SIGKILL directly to the background child process. SIGKILL cannot be trapped, so in-flight git operations or file writes have no chance to clean up. A graceful SIGTERM (or supervisory hand-off to a detached process group) would let tasks shut down cleanly and avoid leaving the repository in a half-written state.

The root cause is likely in how the supervisor manages the child process group. On Linux, kill -9 targets the process but not its orphaned children, which may continue writing after the parent is dead — a classic orphan-process race. A fix would involve either sending SIGTERM first and waiting, or running background tasks in a properly isolated process group that gets cleaned up as a unit.

FAQ

Q1: Is my data permanently lost if git gets corrupted? Usually not. git fsck identifies the broken objects, and because git is content-addressed, unaffected commits remain intact. Restore from your last good commit (git reflog / git reset --hard <sha>).

Q2: Does this affect macOS or Windows users? The report is labeled platform:linux, but SIGKILL-style supervision could surface on any OS. Linux users are the confirmed affected group so far. On macOS, the equivalent is SIGKILL via kill -9, and on Windows, TerminateProcess — both are equally ungraceful.

Q3: Can I still use background tasks safely? Yes — with guardrails. Commit first, keep tasks read-mostly or short, and verify with git fsck afterward. Avoid background tasks that rewrite large trees or run long git operations.

Q4: What about git worktree — does it isolate the corruption risk? Partially. A worktree shares the same object database, so corruption in one worktree affects all of them. However, it does isolate the working tree and index, so a partial file write in a worktree will not corrupt the main checkout. Use worktrees as a quarantine layer, not a full shield.

Don’t overpay for AI tools. Check aiFiesta for exclusive pricing on coding agents.

Beware: Claude Code's Background Tasks Are Getting SIGKILLed Mid-Run — and Trashing Your Git State