Thanks for the detailed write-up and the constructive suggestions. One correction worth flagging for anyone finding this thread later: on macOS 26.4.1, disabling QUIC via defaults write … CFNetworkHTTP3Enabled -bool false does not suppress HTTP/3 for nsurlsessiond's BackgroundConnectionPool. I tested this as part of ruling out root-cause hypotheses — the deadlock still reproduces with h3 as the negotiated protocol. So unfortunately there is currently no user-facing off-switch for QUIC on the iCloud Drive path; the only recovery that works is killing the user-level cloudd and nsurlsessiond processes. On packet capture and pre/post state snapshots — good call, both gaps in my evidence so far. I'll add them to the collection the next time the pool poisons and post a follow-up if anything diagnostic turns up.

Quick update — tried to reproduce the deadlock again today, 2026-04-18, same Mac (macOS 26.4.1, build 25E253), same iCloud Drive account. No reproduction. The change is server-side. Comparing 2026-04-11 → 2026-04-18: Upload host: gcs-eu-00002.content-storage-upload.googleapis.com (GCS) → eu-irl-00001.s3.dualstack.eu-west-1.amazonaws.com (AWS S3 Ireland) Protocol: h3 (QUIC) → http/1.1 Large CKAsset body (~20–26 MB): 6 × err=T with requestDuration=-1.000 → single err=F in 1.4–3.0 s This routing change is specific to the CKAsset body-upload path — other cloudd flows (e.g. metadata requests to gateway.icloud.com) continue as before. The underlying CFNetwork BackgroundConnectionPool stale-QUIC-session behavior is still in the stack — no macOS update has shipped in between (still on 26.4.1 build 25E253). It's just not being exercised, because h3 isn't negotiated to the new endpoint. If h3 returns on the CKAsset-upload path (AWS enabling it on this endpoint, or Apple routing back to an h3-capable endpoint), the deadlock would likely return.