Summary
On macOS 26.4.1 (25E253), iCloud Drive file uploads can enter a silent deadlock where every upload attempt fails at the transport layer. No error is surfaced anywhere — not in Finder, not in System Settings, not in the iCloud status panel. The upload queue simply stops.
Other iCloud services (Photos, Mail, App Store) continue to work normally through the same networking infrastructure at the same time.
Root Cause
The issue is a stale HTTP/3 (QUIC) session cached in the user-level nsurlsessiond process's BackgroundConnectionPool.
The deadlock cycle:
clouddrequests an upload to the GCS storage endpointnsurlsessiondprovides the cached (broken) HTTP/3 session- The TLS handshake succeeds, but the body upload dies mid-transfer (
err=T,requestDuration=-1.000,responseHeaderBytes=0) clouddretries with a newconnectionUUID— butnsurlsessiondstill routes through the same poisoned QUIC session- This repeats indefinitely
Killing cloudd alone does not help — nsurlsessiond retains the poisoned pool. Only killing both the user-level cloudd and nsurlsessiond clears the pool and forces a fresh protocol negotiation.
The Smoking Gun
After killing both daemons, the system falls back to HTTP/1.1 for the stuck uploads — and they complete instantly:
| Protocol | h3 (QUIC) | http/1.1 (TCP) |
| Largest upload | Failed at partial offsets | 26 MB in 1.6 seconds |
| Server response | 0 bytes | 596 bytes (normal) |
Same endpoint, same files, same network interface (en5), same power state. The only change was the protocol negotiation after a fresh nsurlsessiond.
Reproduction
Reproduced 3 times on April 11, 2026 using a standardized set of 8 test files (8 bytes to 20 MB) in a non-shared iCloud Drive folder. Each run showed the identical pattern:
- Small files (<100 KB) squeeze through before the QUIC session stalls
- Larger files trigger the deadlock every time
- 5–6 retries with fresh
connectionUUIDs, all failing overprotocol=h3 - After
kill cloudd + nsurlsessiond: immediate flush viaprotocol=http/1.1
An automated evidence-collection script (collect_h3_deadlock_evidence.sh) captures paired before-kill / after-kill logs. Included in the Feedback report.
Symptom Check (for others hitting this)
/usr/bin/log show --predicate 'process == "cloudd"' --last 5m 2>&1 \
| grep "putContainer.*err=T.*requestDuration=-1.000.*protocol=h3" | wc -l
Output > 0 = this deadlock. Output = 0 = different issue.
Recovery (one-liner)
kill $(ps -axo user,pid,command | awk -v u="$USER" \
'($1==u && /CloudKitDaemon.framework.*cloudd/ && !/--system/) \
|| ($1==u && /\/usr\/libexec\/nsurlsessiond/ && !/--privileged/) \
{print $2}')
Both daemons respawn within 1–2 seconds. Do not use killall nsurlsessiond — it would also kill the privileged system instance.
What was ruled out
- Network connectivity (Photos uploaded 8 MB through the same pool simultaneously)
- iCloud account (metadata operations succeeding, only body uploads failing)
- File type/content (random data, correlation is with size, not type)
- Storage quota (1.65 TB free)
- CFNetworkHTTP3Enabled=false (key is ineffective in 26.4.1)
Suggested fixes (from the Feedback report)
- CFNetwork: Invalidate the QUIC session after N consecutive
requestDuration=-1.000failures - CloudKit/NSURLSession: Expose a pool invalidation API like
[NSURLSession invalidatePoolEntryForEndpoint:] - cloudd: Self-healing retry — create a fresh
NSURLSessionafter M consecutive deadlock-signature failures - Finder: At minimum, surface the stuck state to the user instead of failing silently
Filed as
FB22476701 — includes full reproduction timelines, request/connection UUIDs, sysdiagnose, and a 12-page investigation PDF with architecture diagrams and protocol comparison tables.
If you're experiencing the same issue, please file a duplicate referencing FB22476701 — Apple prioritizes by duplicate count.
System
- MacBook Air, macOS 26.4.1 (25E253)
- iCloud Drive with Desktop & Documents sync
- en0 (WLAN) + en5 (USB-LAN via Studio Display)
