macOS desktop / CLI 0.153.4: explicitly allowed Unix HTTP destination returns blocked-by-allowlist; how to verify effective policy?

Environment

• Codex desktop experience on macOS / iMac.
• Bundled executable reports codex-cli 0.153.4.
• A custom profile inherits a restricted filesystem profile. Its network block sets enabled=true and mode="limited"; an exact temporary Unix socket is listed as allow under permissions..network.unix_sockets.
• Saved project config includes [features] network_proxy=true. HTTP_PROXY is present. These are saved/configuration observations, not proof of the effective merged policy.
• App restart and manual profile selection did not change the observed failure.

Observations

A synthetic diagnostic, through the existing HTTP_PROXY with x-unix-socket naming the exact allowlisted but absent Unix destination, returns:

• GET: HTTP 403, blocked-by-allowlist.
• Empty POST: HTTP 403, blocked-by-method-policy.

The POST denial is expected in limited mode and is not the reported bug. The GET allowlist denial is the unresolved question. Separately, creating a synthetic AF_UNIX listener inside a sandboxed command fails EPERM; we do not assume a destination allow rule permits listening.

No production service, real credential, external publication, or real payload was involved. No successful real route is claimed. The destination path and profile name are omitted for privacy; they were exact-match in the local test. This report is an observed diagnostic, not yet a standalone maintainer reproducer.

Clarification requested

1. Does the installed desktop build support the x-unix-socket HTTP destination route implemented in upstream codex-rs/network-proxy? We send HTTP to the existing Codex proxy and ask it to reach a Unix destination; we are not replacing the sandbox proxy or configuring an upstream proxy transport.
2. What supported diagnostic exposes the selected task/session's effective proxy enforcement and inherited Unix allowlist? We cannot establish this from saved config or environment variables alone.
3. Could a higher-priority policy or profile application/persistence issue explain this response? What minimal sanitized evidence should be supplied for triage?

Upstream reference: https://github.com/openai/codex/tree/main/codex-rs/network-proxy and its http_proxy.rs. Upstream main is not assumed identical to this installed binary. AI-assisted Help Center support directed this technical report to GitHub; it did not issue a support case number or verify the root cause.

We need to preserve filesystem containment and external-domain denial. Please identify a supported diagnostic/configuration route without requiring unrestricted access.

Start with codex-rs/network-proxy and its http_proxy.rs, then determine whether the installed desktop build supports the x-unix-socket route. Look for a supported diagnostic of the selected task/session's effective proxy policy and inherited Unix allowlist. Done means identifying a supported sanitized verification path or the minimal evidence needed to explain the GET denial.