Background Workflow runs are killed at a ~13-min task timeout with no completion/death signal

Summary

A long-running background Workflow run is terminated at roughly 13 minutes of wall-clock by what appears to be a host task timeout, and the parent agent receives no completion or death notification — the run just goes silent. The orchestrating agent only discovers the death by manually inspecting process state / output-file activity. resumeFromRunId does recover (cached completed agents), but absent manual detection the work is silently stranded, and a re-run hits the same boundary.

Environment

• Claude Code: 2.1.160 (Claude Code)
• Platform: macOS (darwin, Apple Silicon)
• Feature: the Workflow tool launched with run_in_background (background/detached run)

What happens

1. Launch a multi-agent Workflow whose total wall-clock exceeds ~13 min (e.g. a heavy cross-cutting phase).
2. At ~13 min elapsed, the background process terminates mid-run.
3. No completion notification / task-finished signal fires to the parent. The run is neither reported done nor reported failed — it's just gone.
4. The only way to notice is manual ps / output-file-mtime inspection. (Observed to recur at the same ~13-min mark on a retry.)

Expected

A background Workflow whose runtime exceeds the limit should either (a) complete, or (b) deliver an explicit timeout/death event to the parent so it can resume — not terminate silently. Today silence is indistinguishable from "still running."

Impact

Long multi-agent workflows (the exact case background runs are for) can't complete in a single background run and require out-of-band death-detection + manual resumeFromRunId.

Suggested fixes (any one would resolve it)

• (a) Raise/remove the task timeout for background Workflow runs (or make it configurable).
• (b) Emit an explicit timeout/death event so the parent is re-invoked instead of silently stranded.
• (c) Have the Workflow runner checkpoint + auto-resume across the timeout boundary.

Current workaround

Register a fallback wake-up sized to the run, then on wake mechanically classify the run from its on-disk journal/agent-activity (completed vs. silently-died) and resumeFromRunId if dead. Works, but it's manual scaffolding around a missing platform signal.