Codex sandbox blocks DNS/SSH sockets; git push fails with "Could not resolve hostname github.com"

Resolved 💬 6 comments Opened Feb 26, 2026 by trstoyan Closed Feb 26, 2026

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.104.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.2-codex

What platform is your computer?

Linux 6.18.9-arch1-2 x86_64 unknown

What terminal emulator and version are you using (if applicable)?

Alacritty

What issue are you seeing?

Inside Codex sandbox, outbound networking and socket creation appear blocked.
Git operations to GitHub fail before authentication due to DNS failures.

Command:
git push origin --delete <REDACTED_BRANCH>

Output:
ssh: Could not resolve hostname github.com: Temporary failure in name resolution
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

DNS / network checks in sandbox:
getent hosts github.com && ssh -T git@github.com
<no output>

nslookup github.com || true; ping -c 1 github.com || true
net.c:136:try_proto(): socket(): Operation not permitted (1)
net.c:136:try_proto(): socket(): Operation not permitted (1)
(null): can't find either v4 or v6 networking
ping: socktype: SOCK_DGRAM
ping: socket: Operation not permitted

SSH agent:
ssh-add -l
Error connecting to agent: Operation not permitted

ssh-agent -s
Couldn't prepare agent socket
Operation not permitted

What steps can reproduce the bug?

1) Start Codex CLI in any git repo that has an SSH remote (git@github.com:...).
2) Run:
getent hosts github.com
git push --dry-run
3) Observe DNS/socket failures (Operation not permitted) and git push failure.

What is the expected behavior?

git push should proceed to authentication or fail with a normal SSH auth error,
not fail due to DNS/socket restrictions inside the Codex environment.

Additional information

This is NOT the “Bad owner or permissions on /etc/ssh/ssh_config.d” issue.

In this environment, /etc/ssh and ssh_config.d are owned by root and
ssh -G github.com parses cleanly.

The failure appears to be sandbox socket/network restrictions.
When elevated execution was explicitly approved, git push/delete succeeded.
/etc/resolv.conf contains a nameserver entry, but DNS lookups still fail in

sandbox.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 6 months ago

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

#10856
#12572
#12845

Powered by Codex Action

trstoyan · 6 months ago

Hi @etraut-openai ,

Update: Network Issue Resolved (Not a Codex Bug)

After deeper testing, the earlier git push failure (Could not resolve hostname github.com) was not a Codex CLI defect.

Root cause: network access was disabled in the sandbox configuration.

Initial symptoms:

socket(): Operation not permitted
DNS resolution failures
SSH/HTTPS Git transport failing

After enabling:

[sandbox_workspace_write]
network_access = true

Minimal validation confirmed:

AF_INET socket creation succeeds
Raw TCP connectivity works
DNS resolution works
git push --dry-run succeeds

Conclusion: behavior was consistent with sandbox policy (network disabled by default), not a bug in Codex CLI.

Lesson learned: perform layered validation (socket → raw TCP → DNS → transport) before reporting a defect.

Thank you for the time taken to review and investigate this.

sstklen · 6 months ago

Apologies — my previous comment asked you to provide reproduction steps when you had already included extremely detailed ones. That was unhelpful. Here's the actual analysis:

What's happening: Codex CLI runs agent tasks inside a sandboxed environment that restricts system calls — including socket(). This is intentional: the sandbox blocks outbound network access by default to prevent unintended side effects.

The specific mechanism varies by platform:

Linux: uses seccomp + landlock to restrict socket creation
macOS: uses Apple Seatbelt (sandbox-exec) for similar restrictions

Either way, the result is the same: socket(): Operation not permitted when anything tries to make a network call, including DNS resolution (UDP socket) and SSH (TCP socket).

Why git push worked when you explicitly approved elevated execution: That's the intended flow — Codex temporarily lifts sandbox restrictions for that specific command when you approve it. That approval is the user's consent gate for network operations.

The correct workflow for git operations in Codex:

Let Codex handle all local file changes inside the sandbox (no network needed for code edits)
When Codex proposes to run git push, approve the elevated/network operation when prompted
Alternatively, run git push yourself outside the Codex session after reviewing the changes

This is by design, not a bug — but your feedback is valid: the error message could be clearer. Instead of a raw socket(): Operation not permitted, it should say something like "Network access blocked by sandbox — approve this operation to continue." That would be a good UX improvement to request.

The root issue (confusing error messages + unclear approval flow for network ops) is worth filing as a separate feature request for better sandbox UX.

Hope this helps\! 🦞

_Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying._

trstoyan · 5 months ago

@sstklen Thanks for replying back, and no worries regarding the missed details, the important is that both have learn something from this. I'm new on the task to contribute publicly and I will try my best to do it better.

phpguru · 2 months ago

For future readers, if you have started your session with

codex --ask-for-approval never

and included prompts to git push or aws cloudwatch ... and running into DNS Issues in the sandbox, try ctrl-c and create a new session with slightly lower permission level:

codex --ask-for-approval on-request

You may be thinking it would be convenient to give Codex a list of commands it's allowed to do without asking. That has been discussed a lot in 3085 and let me save you sifting through the comments to find the Rules mechanism so you can customize it.

flying-joe · 18 days ago

For future readers, if you have started your session with `` codex --ask-for-approval never ` and included prompts to git push or aws cloudwatch ... and running into DNS Issues in the sandbox, try ctrl-c and create a new session with slightly lower permission level: ` codex --ask-for-approval on-request `` You may be thinking it would be convenient to give Codex a list of commands it's allowed to do without asking. That has been discussed a lot in 3085 and let me save you sifting through the comments to find the Rules mechanism so you can customize it.

This fixed it! Thank you