[Bug] Session terminates silently while awaiting long-running background processes

Technical note — Claude Code session state loss while awaiting long-running background processes

Distinct from prior bug report on line duplication in tool_use content generation. This note covers a separate, reproducibly observed failure mode.

Model: Claude Opus 4.7 in Claude Code
Platform: Windows, MINGW64 (Git Bash), pnpm monorepo workspace
Period: April 2026 (ongoing)
Severity: Silent loss of pending actions; user left uncertain whether committed work landed on disk. Low risk of data loss (Git is source of truth), but significant ergonomic and trust cost.

---

Observed behavior

When Claude Code (CC) waits on a long-running background process to complete before taking the next action — specifically pnpm build at workspace root, which takes approximately 8 minutes on the observed machine — and the user has pre-approved the next action, the session does not resume when the background process finishes.

Symptoms in chronological order:

1. User and CC agree on next action: commit and push.
2. User approves explicitly ("OK" in response to "Go for commit + push?").
3. CC acknowledges: "OK. I'll wait for the build completion notification before commit + push. I'll be notified automatically."
4. Background build continues in a separate shell (visible in the Claude Code UI footer as "1 shell still running").
5. No further message from CC. Session appears inactive.
6. Some time later, user returns, finds CC unresponsive, relaunches claude command.
7. New CC session starts with no memory of the pending commit.
8. User must prompt: "You stopped during the build..."
9. New session reconstructs state from scratch: git status, git log, re-runs pnpm typecheck, re-runs vitest, verifies the expected files exist on disk.
10. Eventually the new session proposes commit and push again — but the pre-approved commit from the previous session was never executed.

The files were all on disk correctly. The typecheck and tests still pass. Git is clean. But the commit action that the user approved was silently dropped when the session terminated.

Reproduction

Observed twice, identically, during the same WP on the same branch:

• First occurrence: commit 6 of a feature WP (package dependency addition + new builder function + unit test). Build was running at root level. Session terminated while awaiting completion. User relaunched manually, verified the build had completed correctly, all files on disk, and prompted CC to commit the prepared work.
• Second occurrence: commit 7 of the same WP (new synthesizer module + test file + package.json update). Identical sequence: build at root, CC acknowledges it will wait, session dies silently, user must relaunch.

Same sequence, same outcome, same branch. Unlikely to be incidental.

Likely trigger conditions

Based on the two occurrences sharing these features:

• Background process is long-running (estimated 8 minutes for workspace-level pnpm build)
• CC has explicitly committed to wait for completion via a statement like "I'll be notified automatically"
• User is idle during the wait (does not type anything)
• No intermediate progress messages from CC during the wait
• Session appears to enter a state where it no longer responds to background process completion signals

Hypothesis: the "notification" mechanism CC claims to use for background process completion is either not wired up, or is wired up but fails silently when the session is idle for long enough. The session may be terminated by a timeout, inactivity detection, or a watchdog that does not distinguish "user idle while process runs" from "session abandoned."

Pattern distinct from line duplication bug

This is not the same issue as previously reported. The line duplication bug is about corrupted tool_use content (payload generation). This bug is about session lifecycle and pending action persistence (control flow across session boundaries).

The two bugs may share common infrastructure in Claude Code, but they present very differently:

• Duplication: content is corrupted; session remains alive; user can observe the issue in rendered output
• Session loss: content is correct; session terminates; user cannot observe anything until they realize CC has stopped responding

Impact

Ergonomic and trust cost, rather than direct data loss:

• User must manually check branch state on return (git status, git log)
• User must decide whether to re-validate the pre-approved action or just execute it blindly in the new session
• User loses the "hands-off" promise that Claude Code makes for long async operations
• Pattern reduces confidence in CC for extended autonomous workflows — exactly the workflows where CC would provide the most value

For the user this happened to, the WP was a multi-day effort involving 14 atomic commits with cross-cutting dependencies. Each instance of session loss added 5-10 minutes of state reconstruction and re-verification. Over a 14-commit WP, that compounds.

Suggested investigation areas

1. Session liveness watchdog: is there a timeout on CC sessions that fires during user-idle intervals even when a legitimate background process is running? If yes, the watchdog should be aware of awaited processes.

1. Background process notification channel: when CC says "I'll be notified automatically" after kicking off a background process, is there actually a notification mechanism? If not, the message is misleading — CC should say it is polling or that the user should return and prompt completion.

1. Pending action persistence: actions the user has explicitly pre-approved (like the commit + push in this case) should survive session restart. Currently they do not. A minimal improvement would be to serialize the pre-approved action queue such that a new session can pick it up from where the previous one left off.

1. Progress feedback during long waits: CC could emit periodic progress pings ("Build still running, X minutes elapsed") to keep the session alive and reassure the user. This would address multiple issues at once: watchdog avoidance, user trust, and detection of silent process hangs.

Operational mitigation users can apply today

Until a fix is deployed:

• Avoid long background waits in CC: for operations that take several minutes, execute them in a separate terminal outside CC. Return to CC with the result. This is the opposite of the CC promise, but reliable.
• Never pre-approve actions behind long waits: approve only actions that will execute in the current session turn. If a build must precede a commit, wait for the build outside CC, then re-enter CC to commit.
• Always verify state manually after any idle period: git status, git log -5, check the branch locally before trusting that CC completed the expected work.

These mitigations significantly degrade the CC value proposition for agentic long-running workflows.

Availability for reproduction

The user is available to help reproduce. The specific context:

• Next.js 15 + pnpm monorepo
• Windows 11, Git Bash (MINGW64)
• 5 workspace packages with cross-dependencies
• Root pnpm build duration approximately 8 minutes
• Claude Code v2.1.114 (version at time of second occurrence)
• Branch with 6-7 accumulated commits prior to each occurrence

Happy to share a redacted transcript or screen recording of a reproduction attempt in a direct channel.

---

Priority recommendation: medium-high. This bug does not cause data loss (Git catches that), but it materially undermines the core CC value proposition of "reliable long-running agentic coding sessions." Users on multi-hour WPs with multiple long builds will encounter it regularly and lose trust fast.