Sandboxed DNS resolution intermittently fails for external Postgres endpoints while same command succeeds when escalated

Summary

When running a CLI command that talks to an external Postgres backend from the Codex desktop app in the default sandbox, DNS resolution for the database endpoint intermittently fails with a no such host error. Re-running the exact same command with escalated permissions succeeds immediately.

I'm intentionally omitting the exact hostname because this appears to be a sandbox/network-resolution bug rather than a service-specific problem.

Environment

• Codex desktop app
• macOS
• workspace-write sandbox / restricted network by default
• Command used a Postgres DSN pointing at a managed external database

Reproduction

1. Run a CLI command inside the default sandbox that connects to an external Postgres backend using a DSN.
2. Observe intermittent DNS failure (no such host) while opening the backend connection.
3. Re-run the exact same command with escalated permissions.
4. Observe that the command succeeds against the same backend without changing arguments or credentials.

In my case this happened repeatedly with a work-order CLI that talks to a shared Postgres-backed store. create sometimes succeeded while later relate operations failed in the sandbox and then succeeded immediately once rerun escalated.

Expected

• DNS resolution should behave consistently between sandboxed and escalated runs, or
• the sandbox should fail deterministically with a clearer networking restriction error instead of surfacing as intermittent hostname lookup failure.

Actual

• Sandboxed run intermittently fails with no such host while opening the Postgres connection.
• Escalated run of the same command succeeds immediately.

Why this matters

This creates duplicate-risk and wasted tokens/time for agent workflows that write to shared backends, because the model has to poll, retry, and manually verify whether the previous write partially succeeded before attempting the operation again.

Possibly related

• #10390
• #12996
• #14221
• #15309

If helpful, I can provide the exact command shape and the full sanitized error string, but I wanted to avoid posting provider-specific hostnames in the public issue.