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:
cloudd requests an upload to the GCS storage endpoint
nsurlsessiond provides the cached (broken) HTTP/3 session
The TLS handshake succeeds, but the body upload dies mid-transfer (err=T, requestDuration=-1.000, responseHeaderBytes=0)
cloudd retries with a new connectionUUID — but nsurlsessiond still 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:
Before Kill
After Kill
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 over protocol=h3
After kill cloudd + nsurlsessiond: immediate flush via protocol=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.000 failures
CloudKit/NSURLSession: Expose a pool invalidation API like [NSURLSession invalidatePoolEntryForEndpoint:]
cloudd: Self-healing retry — create a fresh NSURLSession after 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)