Background task output files lost for long-running commands

Description

Background tasks started with run_in_background: true that run for >30 seconds (particularly those involving WebSocket connections) frequently lose their output files. The task completion notification arrives correctly (reporting exit code 0), but the output file referenced in the notification does not exist on disk.

Steps to Reproduce

1. Start a long-running background task (~60-90s) that involves WebSocket connections (e.g., publishing to Nostr relays with 25s delays between operations)
2. Wait for the task completion notification
3. Attempt to read the output file from the path in the notification
4. File is missing or a different file with an unrecognized task ID exists in the directory

Observed Behavior

• Task notification says completed (exit code 0) with a task ID (e.g., bkr2zm5sw)
• The output file /private/tmp/claude-501/.../tasks/bkr2zm5sw.output does not exist
• The tasks directory contains different files (e.g., bmrigf22a.output, bgzvlko02.output) that were never requested
• Phantom 0-byte output files appear with unrecognized task IDs
• TaskOutput tool also fails to find the task by ID

Short-lived background tasks (2-3 seconds) work correctly — output files persist and TaskOutput reads them fine.

Impact

When the output can't be verified, the natural response is to re-run the command. For non-idempotent operations (e.g., publishing posts to a social network), this causes duplicate side effects that can't be undone.

Workaround

We added a lockfile-based duplicate run guard in our scripts to prevent re-execution within a cooldown window. But the underlying issue is in Claude Code's task output file management.

Environment

• macOS (Darwin 25.3.0, Apple Silicon)
• Claude Code (latest as of March 6, 2026)
• Shell: zsh
• Model: Claude Opus 4.6