Symptom
Every build — both the Xcode IDE and command-line xcodebuild — hangs indefinitely at "Pre-planning"/"Planning N/M", before any compilation starts. The build log freezes for
40+ minutes with no progress and no error.
Inspecting the stuck processes:
The clang feature-detection probes (clang -v -E -dM -c /dev/null) sit at 0% CPU, blocked in write().
SWBBuildService is idle in swift_task_asyncMainDrainQueue → mach_msg — it never reads the probe output.
Root cause: collapsed pipe buffers
On this machine, anonymous pipe buffer capacity has dropped to 512 bytes (a healthy macOS pipe starts at 16 KB and expands to 64 KB on demand).
SWBBuildService runs the clang feature-detection probe and reads its ~15 KB of output lazily (via Swift concurrency). With only a 512-byte buffer, the pipe fills instantly,
clang's write() blocks forever, and the build deadlocks before it begins.
swift build (SwiftPM) is unaffected because it drains subprocess pipes continuously in small reads — confirming the problem is the pipe buffer size, not the toolchain or
compiler.
The key detail — it's progressive, not constant (looks like a kernel pipe-KVA leak)
This is the part that points at a kernel bug rather than a fixed config:
Right after a reboot, a fresh os.pipe() measures 65536 bytes, and builds succeed normally.
After ~50 minutes of normal build activity, the same measurement has monotonically degraded to 512 bytes, and builds hang again.
So pipe capacity appears to leak down as pipe kernel-virtual-address (KVA) accounting accumulates during use. Notably, kern.ipc.maxpipekva does not exist as a sysctl OID on
26.5, so there's no tunable to raise the pool.
Minimal diagnostic anyone can run
import os, fcntl, errno
r, w = os.pipe()
fcntl.fcntl(w, fcntl.F_SETFL, os.O_NONBLOCK)
total = 0
try:
while True:
total += os.write(w, b"x" * 256)
except OSError as e:
if e.errno != errno.EAGAIN:
raise
print("pipe capacity:", total, "bytes")
Healthy machine: 16384+ (usually 65536). Affected machine: 512. When it reads 512, every xcodebuild will hang.
What did NOT fix it (ruled out)
Downgrading Xcode — tested Xcode 26.4.1 (17E202) via DEVELOPER_DIR: hangs identically. The trigger is the OS, not Xcode/Swift.
Raising kern.ipc.maxpipekva — the OID doesn't exist on 26.5.
Memory pressure (64 GB, 94% free, 0 swap), /etc/sysctl.conf / boot-time overrides, NVRAM boot-args, MDM/configuration profiles (not enrolled), third-party security/AV/DLP software (none installed), the project/packages, derivedData location, user Xcode prefs (clean HOME still hangs), connected devices.
File-descriptor exhaustion — only ~87 pipe FDs were open, so it's not a count limit; it's per-pipe capacity.
What does help
Reboot restores 64 KB pipes — but only buys ~1 build before they degrade again. Temporary.
Full in-place reinstall of macOS 26.5 resets pipe capacity (the incremental OTA may have left the system inconsistent), but the leak recurs with use.
Staying on / reverting to macOS 26.4 is the only durable fix found, since 26.5 is the trigger.
Question for Apple / others seeing this
Has anyone else on 26.5 (25F71) confirmed pipe capacity degrading over time with the Python snippet above? This looks like a kernel pipe-KVA accounting leak introduced in
26.5. A separate, smaller issue is that SWBBuildService drains the clang probe pipe lazily, which turns a small pipe buffer into a hard deadlock instead of just slow I/O — a
continuous-drain read would make Xcode resilient to it.
Environment
Mac Studio (Apple Silicon), 64 GB RAM
macOS 26.5 (build 25F71) — problem began immediately after an incremental OTA update from 26.2 → 26.5
Xcode 26.5 (also reproduced on Xcode 26.4.1 / 17E202 — see below)
