Background tasks report 'completed' but output files are missing or empty

Description

Background tasks launched via the Bash tool frequently report as "completed (exit code 0)" in task notifications, but the output file referenced in the notification is either missing from disk or contains 0 bytes. This makes it impossible to verify task results, leading to duplicate work and potential duplicate side effects (e.g., duplicate API calls, duplicate posts to external services).

Environment

• Claude Code version: 2.1.71
• OS: macOS 26.3 (Darwin 25.3.0)
• Hardware: Apple M4 Max, 128GB
• Shell: zsh

Steps to Reproduce

1. Launch a long-running background command (>30s) via the Bash tool — e.g., a Python script that loads a large ML model and runs inference
2. Wait for the task notification indicating completion
3. Attempt to read the output file at the path provided in the notification

Expected Behavior

The output file at the path specified in the task notification should contain the full stdout/stderr of the completed command.

Actual Behavior

• Task notification says completed (exit code 0) ✓
• Output file path is provided in the notification ✓
• Output file is missing from disk or exists but is 0 bytes ✗

Example notification received:

<task-notification>
<task-id>bru15s956</task-id>
<output-file>/private/tmp/claude-501/.../tasks/bru15s956.output</output-file>
<status>completed</status>
<summary>Background command "..." completed (exit code 0)</summary>
</task-notification>

Then:

$ cat /private/tmp/claude-501/.../tasks/bru15s956.output
# empty / file not found

Observations

• Short tasks (2-3s) work fine — output files exist and contain expected content
• Long tasks (>30s), especially those with heavy memory usage (loading ML models, GPU operations), consistently lose output
• The issue correlates with task duration and/or memory pressure, not command complexity
• Phantom 0-byte output files sometimes appear with unrecognized task IDs
• Writing output to a separate log file (inside the script) confirms the process runs and produces output — the issue is in the task output capture layer, not the command itself
• Multiple task IDs from the same session can all show this behavior

Impact

• Duplicate work: If output can't be verified, the natural response is to re-run the task
• Duplicate side effects: For non-idempotent operations (API calls, social media posts, file writes), re-running causes real harm
• Workaround tax: Users must implement their own file-based logging inside scripts to capture output reliably, defeating the purpose of the task system

Workarounds

1. Write output to a known file path inside the script (bypassing the task output system entirely)
2. Run long commands in foreground instead of background (blocks the conversation)
3. Implement idempotency guards (lockfiles, dedup checks) for commands with side effects

Previous Report

This was also reported on March 6, 2026 (issue may already exist). The behavior persists as of v2.1.71.

---
🤖 Generated with Claude Code