›_ Codex Issues
Codex Issues / #16312

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

Open 💬 2 comments Opened Mar 31, 2026 by ppiankov
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #15309
  • #14978

Powered by Codex Action

ppiankov · 5 months ago

Sanitized repro shape:

some-cli relate project-a 12 depends_on project-b 34 --dsn "$SHARED_POSTGRES_DSN"

Sanitized error shape:

Error: open postgres backend via --dsn: ping database: failed to connect to `user=<redacted> database=<redacted>`: hostname resolving error: lookup <redacted-managed-db-host>: no such host

Important detail:

The same command, with the same DSN and arguments, succeeds immediately when rerun with escalated permissions.

Repro pattern:

  1. Run a Postgres-backed CLI write command inside the default Codex desktop sandbox.
  2. Observe intermittent failure during backend open with a sanitized lookup <redacted-managed-db-host>: no such host error.
  3. Re-run the exact same command with escalated permissions.
  4. Observe immediate success against the same backend.

In the session where I hit this, some earlier writes succeeded while later ones failed, which made it look intermittent rather than like a clear, deterministic “network disallowed” policy failure.