I’m observing **inconsistent behavior when executing the same network command (`curl`) in Codex CLI vs Codex App**, even though **web search is enabled in my Codex CLI configuration**. Specifically: * In **Codex CLI**, `curl` can successfully access external websites (e.g. `www.baidu.com`). * In **Codex App**, the same `curl` command fails at the **DNS resolution stage** with `Could not resolve host`. --- ## Environment ### Codex CLI * `web search` enabled in `config.toml` * Commands are

codex app can't touch web , but codex cli can

Open 💬 5 comments Opened Feb 6, 2026 by yukinotech

I’m observing inconsistent behavior when executing the same network command (curl) in Codex CLI vs Codex App, even though web search is enabled in my Codex CLI configuration.

Specifically:

In Codex CLI, curl can successfully access external websites (e.g. www.baidu.com).
In Codex App, the same curl command fails at the DNS resolution stage with Could not resolve host.

---

Environment

Codex CLI

web search enabled in config.toml
Commands are executed in the local machine environment
Network access works as expected

Codex App

Commands appear to run in a sandboxed execution environment
Network / DNS behavior differs from CLI

---

Steps to Reproduce

1. Codex CLI (web search enabled)

Input in Codex CLI:

Please curl Baidu and describe the response.

Codex CLI executes:

curl -i https://www.baidu.com

Result:

Request succeeds
HTTP response headers and HTML body are returned normally

---

2. Codex App

Input in Codex App (semantically equivalent):

I will directly execute a curl request to Baidu and describe the response.

Codex App executes:

curl -I -L https://www.baidu.com

and:

curl -L https://www.baidu.com | head -n 30

Result:

curl: (6) Could not resolve host: www.baidu.com

Failure occurs at the DNS resolution stage
No TCP/TLS connection is established
No HTTP response is received

---

Expected Behavior

Either:

Codex App and Codex CLI use equivalent network/DNS capabilities, or
The difference in execution environment and network limitations is made explicit to users

If web search is enabled, it should be clear:

Which environments it applies to (CLI only vs App as well)
Whether it affects command execution or only model-level browsing

---

Actual Behavior

Codex CLI can resolve and access external domains
Codex App fails DNS resolution for the same domains
The App still reports “command executed”, which can be misleading when the environment itself is restricted

---

Questions / Clarification Needed

Does the web search configuration apply only to Codex CLI, and not to Codex App?

View original on GitHub ↗

5 Comments

yukinotech · 6 months ago

On repeating the same prompt a second time in Codex App, an additional interaction appeared.

Codex App prompted me to confirm whether the command is allowed to escape the sandbox’s restricted network environment (i.e. whether broader / unrestricted network access should be granted for this execution).

yukinotech · 6 months ago

This feels a bit strange to me. My understanding was that for Codex App, once the configuration is loaded, the web search capability should be enabled by default, rather than requiring an additional prompt to allow access to the restricted network.

Neokil · 6 months ago

same issue for me. I have a task markdown that I am using to generate some summaries and post them to slack. in the codex-cli it works fine but in the codex-app it shows "could not resolve host".

thedarkcder · 6 months ago

Fix

Put this in ~/.codex/config.toml:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

sstklen · 6 months ago

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: Codex App runs commands in a network-isolated sandbox by default (blocks DNS/outbound). Codex CLI with web_search enabled runs on host with full network. The sandbox's default policy denies all network, causing 'Could not resolve host'.

What worked for us:

The proposed fix is already very comprehensive, offering both a permanent configuration change and a preferred per-session approval method. No significant improvement needed.

The provided code fix for option A is correct and directly usable. No improvement needed for the patch itself.

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

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

---
<sub>🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.</sub>