Secure devcontainer fails when DNS resolver returns CNAME records alongside A records

Open Beginner friendly
#22,471 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
docker, shell
Domain
devops, networking

Research direction

Start with the firewall initialization logic in post_start.sh and reproduce the resolver output with dig +short A auth.openai.com. Verify that CNAME lines are not processed as IPv4 addresses, then start or rebuild the secure devcontainer with a resolver returning both CNAME and A records to confirm startup succeeds.

Written by the indexing model from the issue text.

Description

bug codex-web
What issue are you seeing?

The secure devcontainer fails during post_start.sh when the DNS resolver returns CNAME records alongside IPv4 A records.

Observed with the secure devcontainer configuration from:

rust-v0.130.0

The startup aborts with:

ERROR: Invalid IPv4 address from DNS for auth.openai.com:
auth.openai.com.cdn.cloudflare.net.

The failure happens in the firewall initialization logic executed by post_start.sh.

The resolver output contains both the CNAME and the resolved IPv4 addresses, but the script currently expects every returned line to already be a valid IPv4 address.

What steps can reproduce the bug?
  1. Clone the openai/codex repository.
  2. Use the secure devcontainer configuration from rust-v0.130.0.
  3. Open the workspace using the secure devcontainer configuration.
  4. Start or rebuild the container.

The container startup fails during post_start.sh.

The issue can be reproduced on systems where:

dig +short A auth.openai.com

returns output similar to:

auth.openai.com.cdn.cloudflare.net.
104.x.x.x
172.x.x.x

The firewall initialization logic aborts when processing the CNAME entry.

What is the expected behavior?

The secure devcontainer should start successfully even when the DNS resolver returns CNAME records alongside IPv4 A records.

Non-IPv4 DNS responses should be ignored or filtered before processing them in the firewall initialization logic.

Additional information

I verified the issue locally and confirmed that filtering the resolver output to valid IPv4 addresses resolves the problem.

Minimal fix here:
https://github.com/openai/codex/commit/2bbc364bcd89127be35b8fc8147b140ac3fe8e33

The issue appears to depend on resolver behavior and may therefore only affect certain environments or DNS configurations.

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.