Daemon bg job wedged in 'blocked' after safety-classifier API error, then silently resumes 4 days later and runs tools on stale context

Summary

A daemon-backed background job (template: "bg") whose model turn was killed mid-flight by an API safety-classifier rejection got stuck in state: "blocked" indefinitely, invisibly. Four days later the daemon silently resumed the session with no user action, delivered the orphaned background-task notification, and the model continued the conversation and executed tools against a filesystem state that was four days out of date.

Environment

• Claude Code v2.1.220, backend: daemon, job template: bg
• Windows 11 Pro (10.0.26200), PowerShell 5.1
• Model: claude-fable-5, --permission-mode auto
• respawnFlags: --reply-on-resume --effort xhigh --permission-mode auto --model claude-fable-5

Timeline (reconstructed from the job's timeline.jsonl / state.json)

1. 2026-07-30T16:55Z — model starts a PowerShell command; user manually backgrounds it via the UI.
2. 2026-07-30T16:57Z — when the harness re-invoked the model to process the task event, the API request was rejected by model safeguards:

API Error: Fable 5's safeguards flagged this message (https://www.anthropic.com/legal/aup) ... Claude Code can't respond to this message with Fable 5 ... Request ID: req_011CdYbV5EXqo9HSZL7YEYrh
The turn died and the job entered state: "blocked" with the raw API error string as its detail.

1. User closed the terminal believing the session was over. The daemon job survived (expected for the bg template — but nothing surfaced that it was wedged rather than done).
2. No timeline events for 4 days.
3. 2026-08-03T19:21Z — the daemon resumed the session (no user action; likely on daemon restart) per --reply-on-resume, delivering a <task-notification> for the long-dead background command ("No completion record was found for this background shell command from the previous session..."). The model then continued the 4-day-old conversation and ran commands against directories that had been deliberately deleted (in other sessions) days earlier — and started "investigating" their disappearance.

Problems

1. A safeguards-rejected turn wedges bg jobs. There is no retry, no terminal state, and no user-visible signal in the bg/fleet UI beyond the raw error string buried in detail. From the user's perspective the session just went quiet, so they assumed it was closed.
2. Silent resume days later on stale context. --reply-on-resume plus an orphaned task notification means a job can wake arbitrarily late and immediately execute tools on a world-model that is days stale. The injected notification says "previous session" but nothing tells the model how much wall-clock time elapsed, and nothing asks the user before tool execution resumes.

Expected behavior

• A turn killed by an API safeguards rejection should move the job to a clearly surfaced "needs attention" / failed state in the fleet UI instead of an indefinite blocked.
• A daemon resume after a long gap should surface the elapsed time prominently to the model (e.g., "4 days elapsed since last activity — re-verify external state before acting"), and arguably require a user nudge before tools run again.

Impact

Harmless in this instance — the model only ran read/list commands and attempted empty-directory deletions on paths that no longer existed. But the same pattern (resume on stale context → "discover" discrepancies → auto-correct them) could easily produce destructive actions on a machine whose state legitimately moved on.