macOS: intermittent loopback connect EPERM under an explicit localhost-only sandbox

Summary

Synthetic local tests launched through the Codex desktop app intermittently fail with connect EPERM despite explicit localhost allowances.

The tests also use a custom sandbox-exec profile. We have not established whether that profile, another effective policy, or their interaction causes the denial.

Observed behavior

On September 11, 2026:

• Application failure: 17:02:02.477 UTC
• Error: connect EPERM, errno -1
• Endpoint: 127.0.0.1:50838
• Process PID: 89715
• A kernel network-outbound denial matched the PID and target port at 17:02:02.574523 UTC, approximately 98 milliseconds later.

The kernel event did not identify the denying profile/rule or contain a literal loopback address.

The Miniflare/D1 runtime started successfully and completed synthetic setup. Of 1,590 logical operations started, 1,589 succeeded and one failed. Scheduling stopped at the first failure, with no retries. Cleanup completed.

An earlier native HTTP test showed the same error class with another closely correlated kernel denial, so the observation is not limited to Miniflare.

Environment

• macOS; Codex desktop app
• Node: 24.15.0
• Miniflare: 5.20260910.0-alpha
• workerd: 1.20260910.1
• Undici: 7.29.0

The profile includes these network clauses:

(version 1)
(allow default)
(deny network*)
(allow network-outbound (remote ip "localhost:*"))
(allow network-inbound (local ip "localhost:*"))
(allow network* (local unix-socket))

Additional file restrictions protect credential/configuration files, canonical source, and historical evidence. The test environment contains no inherited credentials.

Requested guidance

How can we identify the exact effective profile/rule responsible and determine the supported minimum correction while preserving non-loopback network restrictions and protected-file restrictions?

We are not requesting sandbox removal or unrestricted execution. A redacted diagnostic packet is available. No credentials, customer data, raw logs, or full conversation contents are included in this issue.

No repository file or test is named. Start with the available redacted diagnostic packet and correlate the kernel network-outbound denial with the effective sandbox profile and listed timestamps; done means identifying the denying rule and the supported minimum correction while preserving non-loopback and protected-file restrictions.