Confirming this on macOS 26.5.2 — and I may have found what was actually eating the pipe budget on my machine: a third-party background agent (Logitech's, in my case), not (only) the kernel itself. Full story below, because the diagnostic path might help others here. Environment MacBook Pro (M1 Pro), macOS 26.5.2, Xcode 26.6 (17F113) Symptom identical to OP: xcodebuild (and the IDE) hangs at CreateBuildDescription → ExecuteExternalTool clang. Process samples showed the clang feature-detection probe blocked in write() at 0% CPU, SWBBuildService idle in mach_msg, never draining the probe's stdout. The same clang command finished instantly when run standalone in a terminal. What we ruled out first (several weeks of isolation before finding this thread) Project source: reproduced on a fresh Xcode-generated SwiftUI project and on a completely different repository. Not project-bound. User profile: created a brand-new Standard user (no iCloud, no prior DerivedData, no signing identities). swift test passed (64 tests — SwiftPM drains pipes continuously, matching OP's observation), but xcodebuild hung at the same clang probe. So it was system-wide, not per-user. Xcode itself: clean reinstall of Xcode from Developer Downloads (SHA-256 + signature verified, reboot after). Fixed it temporarily — then the hang returned. Also consistent with OP's finding that the trigger isn't the Xcode version. DerivedData / destinations: fresh DerivedData per run, simulator-by-UUID vs generic destination, CODE_SIGNING_ALLOWED=NO, clean subprocess env — none of it mattered once a session was in the bad state. MDM / EDR / AV: none installed, machine not enrolled. Safe Mode: PASSED consistently (clean user + same checkpoint, ~11s builds). This was the biggest clue that some normal-boot component was involved. App-level A/B/A of running background apps (Ollama, BetterDisplay; Proton VPN and Docker were inactive): quitting and restoring each app individually while the hang was reproducible changed nothing — 2/2 timeouts in every condition. No causal evidence at the app-quit level. One more data point: a second machine (iMac M1) on the same macOS 26.5.x builds the same checkpoints fine, repeatedly. Same OS, different installed-software set. That pointed us at a per-machine resident process rather than the OS version alone. Then we found this thread and ran your snippet During an active hang: pipe capacity: 512 bytes Exact match. The step that closed it for us: find who's holding the pipes Instead of only killing build helpers, we inventoried pipe FDs across all processes while the machine was in the degraded state: sudo lsof | grep PIPE | awk '{print $1}' | sort | uniq -c | sort -rn | head -15 Result on my machine: 1002 Logitech 39 Claude 20 logioptio 20 Google 18 LINE ... The Logitech agent (Logi Options+) was holding 1,002 pipe FDs — ~25x more than the next process. Classic accumulating leak: it apparently creates pipes continuously (device polling / reconnects?) and never releases them. Causal A/B, no reboot and no logout: Measured 512 bytes (fail state, builds hanging) pkill -f -i logi (killed all Logitech agents) Re-measured: capacity back to healthy (16K+) xcodebuild succeeded immediately With Logitech gone, the problem has not returned. Why I think this fits everyone's observations here Logout/login helping (as JustFoxLabs and tsherb-ig found) is exactly what you'd expect if the depletion is driven by user-level login agents: logout kills them and releases every pipe they hold. Reboot works for the same reason. Progressive degradation over ~50 minutes matches an agent leaking FDs at a steady rate, not only a kernel accounting drift. Killing SWBBuildService / sourcekit-lsp etc. not helping makes sense — the build helpers are victims, not the leaker. The leaker is whatever resident agent is quietly accumulating pipes. OP's ~87 open pipe FDs was measured per-user/process scope, I suspect. A full sudo lsof across all processes is what exposed the outlier for me. This doesn't rule out that 26.5 changed pipe/KVA accounting in a way that makes the system far more sensitive to such leaks (26.4 may simply tolerate the same leak — which would explain why reverting "fixes" it). But at least on my machine the proximate cause was identifiable, killable, and confirmable without a reboot. Suggestion for anyone hitting this: while the machine is in the 512-byte state, run the sudo lsof one-liner above and look for a process holding pipes in the hundreds or thousands. Kill just that one, re-run the capacity snippet, and see if it jumps back to 16K+. If we can collect which agents show up across machines (Logitech here — curious what it is on your Mac Studio), that's a much stronger Feedback report for Apple than "kernel leak, cause unknown."