[BUG] Cloud scheduled Cowork task completes and generates final message but hangs indefinitely at "Sending notification" — push/email never delivered
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?
A cloud scheduled task in Cowork (recurring daily briefing) reliably finishes all of its work — including generating the full final message that is meant to be delivered — but the run then hangs indefinitely on the delivery step, showing "Invio notifica in corso…" / "Sending notification" spinning forever. The push notification and email are never delivered. Meanwhile the run appears stuck in the sidebar under Scheduled with the spinner still active.
The workaround (and the diagnostic tell) is that simply opening the stuck session from the Scheduled sidebar unblocks it: within about a minute of opening it, the "Sending notification" step completes. So the work product is fine — it's purely the automated delivery/notification hand-off at the end of the session that stalls.
This is intermittent: same daily task, same prompt, same connectors. It hung on 2026-07-15, 2026-07-16 and 2026-07-20, but delivered normally on 2026-07-17, 2026-07-18 and 2026-07-19. Because the task runs remotely (cloud), this is independent of the local machine, the desktop app, or whether the computer is awake — it was observed entirely from the web UI on a machine that had nothing to do with the run.
Task details:
- Type: cloud scheduled Cowork task, cadence daily 08:30 Europe/Rome
- Connectors used by the task: Gmail (read) + web search
- Affected session id (one of the stuck runs):
cse_01QRBnv5q4KNhfwJ3vVNsDFe - The stuck runs left no visible error message — just the perpetual "Sending notification" spinner.
What Should Happen?
When a scheduled task finishes generating its final message, delivery should complete on its own — the push notification and email should be sent without the user having to open the session. If delivery genuinely fails, it should surface a visible error and retry automatically, rather than hanging indefinitely on "Sending notification" with no feedback and no timeout.
Error Messages/Logs
Steps to Reproduce
- Create a recurring cloud scheduled task in Cowork (e.g. a daily briefing at a fixed time) whose prompt ends by producing a final message intended to be delivered as a push notification / email. In this case the task also uses the Gmail connector (read) plus web search.
- Let it run automatically on its schedule without opening the session.
- Observe some runs: the session does all the work and generates the complete final message, then the run stalls on "Invio notifica in corso…" / "Sending notification" and stays there indefinitely (observed 3+ hours). No push and no email are delivered.
- Open the stuck session from the Scheduled sidebar → within ~1 minute the "Sending notification" step completes (i.e. opening it unblocks delivery).
Note: intermittent — with the identical task it failed to deliver on 2026-07-15, 07-16 and 07-20 but delivered normally on 07-17, 07-18 and 07-19.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
N/A — not Claude Code CLI. This is a cloud-hosted Cowork scheduled task run from claude.ai (web), which has no CLI version.
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
The task is otherwise healthy: it runs on schedule, reads Gmail, runs web searches, and produces a correct final briefing every time. The only failure is the automated notification/delivery hand-off at the very end of the session, which intermittently never completes. Related note: no delivery email for this task is present in the connected Gmail account for any of the past ~10 days (including days that delivered successfully), which may or may not be relevant to where notifications are being routed.
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Not a duplicate. All three suggested issues concern the Claude Code CLI's in-session agent/task notification plumbing on macOS:
<task-notification>enqueued but never dequeued after the owning subagent returned (CLI 2.1.207)This report is a different surface and mechanism: a cloud-hosted Cowork scheduled task on claude.ai (web) — no CLI involved — whose run completes and generates the final message, but the end-of-run user-facing push/email delivery hangs indefinitely at "Sending notification", and is unblocked simply by opening the session from the Scheduled sidebar. The triage labels already reflect the distinction (this issue:
area:claude-code-web,area:cowork,area:routines,platform:web; the suggested ones:platform:macos,area:agent).Keeping this open.
Seeing what looks like the same underlying problem on Windows, but stalling at the opposite end of the run — which may mean this isn't specific to the notification step.
Setup: Claude Desktop (Windows), cloud scheduled task ("Require this computer" OFF), weekday cadence, Microsoft 365 connector used read-only. Daily briefing task, same general shape as yours.
Symptom: the run stops almost immediately, right after the first connector call (get_me) returns — long before any real work is done. It sits at "Awaiting input" with the yellow hand icon. No permission prompt, no dialog, nothing indicating what it wants. Clicking into the task from the Scheduled list resumes it instantly with nothing approved, and it then completes normally in about seven minutes. That "opening the session unblocks it" behavior is identical to what you describe.
Because the run is parked it never reaches its final step, so the completion push notification doesn't fire on schedule — and wouldn't fire at all unless I happen to open the app. The end result matches yours (no notification when expected), but for the opposite reason: yours completes the work and hangs on delivery, mine never reaches the work until I click.
Differences from your report that may help narrow it:
Key data point: my machine sits at the Windows login screen overnight — I restart at 5:00 PM and don't log in until morning, so the Claude desktop app should not be running during any of these runs (Run on startup is set to launch it at login, and I don't log in until morning). Two other cloud scheduled tasks on the same account (5:00 AM and 6:00 AM, same Microsoft 365 connector) complete successfully under exactly those conditions. One runs on Sonnet, one on Opus, and one of them also generates a file (Excel).
So cloud scheduled tasks clearly can run to completion with no client attached and no user session, and this is specific to neither the model nor to document/shell tooling. Only this one task parks, and it does so on every run.
Impact is the same as yours: the failure is silent. A 1:00 AM run sat parked until 7:02 AM and was only found by opening the app. There's no upper bound on how long it can go unnoticed, which defeats the purpose of an overnight task.
The common thread between our two reports seems to be that a parked session releases the instant the session is opened — at either end of the run. Since other cloud tasks on my account complete unattended just fine, it doesn't look like a blanket limitation so much as certain runs entering a state they can't exit without a client.