[BUG] macOS bg sessions inherit XPC_FLAGS=0x2 from daemon, breaking getaddrinfo DNS (curl/git "Could not resolve host") for all Bash tool commands

Summary

Background sessions (daemon-spawned, sessionKind: bg) randomly lose DNS resolution for every Bash tool command: curl, git, gh, npm, ping all fail with Could not resolve host, while dig/host on the same hostname in the same shell keep working. Interactive sessions on the same machine are never affected.

Root cause: the Claude daemon (claude daemon run) is spawned by launchd with XPC_FLAGS=0x2 in its environment and propagates it to every bg-pty-host, bg-spare, session process, and ultimately every shell the Bash tool spawns. On macOS, a process whose environment carries XPC_FLAGS with bit 0x2 set cannot use getaddrinfo (the libinfo/mDNSResponder mach path). Direct-UDP tools like dig are unaffected, which produces the confusing split signature.

Interactive sessions inherit XPC_FLAGS=0x0 from the terminal app, which is why they never fail.

Environment

• Claude Code 2.1.233
• macOS 26.5.1 (build 25F80), Darwin 25.5.0, Apple Silicon
• Daemon lineage: launchd -> claude daemon run -> bg-pty-host -> bg-spare / session process -> /bin/zsh -c (Bash tool)

Minimal repro (no Claude Code needed)

$ env -i PATH=/usr/bin:/bin XPC_FLAGS=0x2 dscacheutil -q host -a name github.com
(empty)

$ env -i PATH=/usr/bin:/bin dscacheutil -q host -a name github.com
name: github.com
ip_address: 20.233.83.145

Value sensitivity: 0x2, 0x3, 2, 3 all break resolution; 0x0, 0x1, and unset are fine. So it is specifically bit 0x2.

Evidence from a live install

• ps ewwo command= -p <daemon pid> shows XPC_FLAGS=0x2 on the daemon, on every bg-spare, and on a bg session process. My interactive terminal shells have XPC_FLAGS=0x0.
• Over 3 days of transcripts: 84 DNS failure events across 17 sessions, 100% sessionKind: bg, 0 interactive.
• Failure signature inside an affected session (single Bash command):

``
host github.com -> 20.233.83.145 (raw UDP, works)
dscacheutil -q host -a name github.com -> empty
ping github.com -> cannot resolve github.com: Unknown host
curl github.com -> curl: (6) Could not resolve host: github.com
``

• Ruled out by direct test on the affected session:
• Bash tool sandbox: dangerouslyDisableSandbox: true fails identically.
• mDNSResponder state: a full sudo killall -9 mDNSResponder (fresh daemon PID) did not fix the affected session, and did not harm healthy ones.
• Causation proof: replaying the affected session's environment (65 vars) in a healthy process reproduced the failure; delta-debug bisection isolated XPC_FLAGS as the sole culprit; env -u XPC_FLAGS in the affected session's shell cures it immediately, no session restart needed.

Impact

Any macOS user running background agents gets intermittent, hard-to-diagnose Could not resolve host failures in git/gh/curl/package managers inside bg sessions. Agents typically respond by building elaborate workarounds (GODEBUG=netdns=go, custom cert bundles, --resolve pinning) or giving up on network-dependent tasks. The failure survives DNS cache flushes and mDNSResponder restarts, which sends investigation in the wrong direction.

One puzzle I could not close: failures were intermittent even though the env var is constant in the daemon lineage, so mDNSResponder appears to reject 0x2-flagged clients only in certain states. The env var is deterministically sufficient to break dscacheutil in the minimal repro above, and stripping it deterministically fixes affected sessions, so it is the actionable cause either way.

Suggested fix

Sanitize XPC_FLAGS (and arguably XPC_SERVICE_NAME) out of the environment when the daemon spawns children, or when the session process spawns Bash tool shells. These launchd-context variables are meaningful only to the process launchd set them for and should not be inherited by arbitrary user commands.

User-side workaround (verified)

Append to ~/.zshenv (the Bash tool runs commands via /bin/zsh -c, which sources it):

case "${XPC_FLAGS:-}" in
  0x2|0x3|2|3) unset XPC_FLAGS ;;
esac

This cured a stuck live session mid-flight with no restart.

Possibly related

• #59065 (bg-pty-host children and macOS attribution issues)
• #67739 (sandbox DNS resolution failures)