[BUG] Background task completion notification can fail to arrive even though the task finished successfully

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title:
Background task completion notification can fail to arrive even though the task finished successfully

Body:
Description
When running a long-lived background agent task, the completion notification that's supposed to arrive in the orchestrating session can silently fail to be delivered — even though the underlying agent has already finished and written its output correctly.

Observed behavior

Launched a background agent task expected to take on the order of tens of minutes.
No completion notification arrived in the orchestrating session for several hours.
A direct filesystem check confirmed the agent had actually finished and written a complete, valid output file well before the multi-hour mark — the work was done, but the signal that would have informed the orchestrator never arrived.
Impact
Because the orchestrator has no way to distinguish "still running" from "finished, but the notification was dropped," it can only find out by proactively checking the filesystem/output — which most users and even the orchestrating model won't think to do unless they already suspect this failure mode. This makes it hard to trust "no notification yet" as a signal of task state.

Request
Could the notification delivery path be made more reliable (e.g., retry/re-check on the harness side), or could there be a supported way to poll/query actual task status directly rather than relying solely on push notification delivery?

Environment
Windows 11, Claude Code CLI. Sonnet 5.0.

What Should Happen?

When a background agent task finishes, the orchestrating session should reliably receive a completion notification. If notification delivery can't be guaranteed, there should be a way for the orchestrator to directly query actual task status on demand, rather than relying solely on push notification delivery for that information. Either way, the session's reported status ("still running") should never be able to lag the task's real state by hours with no way to detect the mismatch short of manually checking the filesystem.

Error Messages/Logs

Steps to Reproduce

This failure appears intermittent — I don't have a deterministic repro, just one confirmed occurrence. Steps as observed:

1. Launch a long-running background agent task (via the Agent tool, background/async execution).
2. Task runs and completes, successfully writing its output file to disk.
3. No completion notification is delivered to the orchestrating session.
4. The orchestrating session, having received no signal, continues reporting "still running" — this persisted for several hours in the observed case.
5. Directly checking the expected output file's existence and last-modified timestamp on disk confirms the task had actually finished hours earlier than the orchestrator's last "still running" report.

Note: I can't yet say what conditions trigger the dropped notification (task duration, task type, concurrency, etc.) — flagging as an intermittent reliability issue rather than a reproducible sequence.

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

4.6

Claude Code Version

Sonnet 5.0

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_