Critical: VS Code Codex extension blocks network access and returns persistent sandbox errors even with danger-full-access

Resolved 💬 12 comments Opened Oct 10, 2025 by alfonsoalongi Closed Nov 4, 2025
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

official VS Code extension only (CLI not installed) version 0.4.19 latest stable

Which model were you using?

gpt-5-codex

What platform is your computer?

Linux 5.14.0-570.49.1.el9_6.x86_64 x86_64 x86_64

What steps can reproduce the bug?

  1. Install and enable the official VS Code extension "Codex – OpenAI’s coding agent" (identifier openai.chatgpt, version 0.4.19) from the VS Code Marketplace.
  2. On AlmaLinux 9 (x86_64), create the configuration file below in ~/.codex/config.toml.
  3. Restart VS Code to ensure the configuration is loaded.
  4. Interact normally with Codex (e.g., request code execution, troubleshooting, or diagnostics).

During its internal workflow, Codex autonomously performs networked operations such as downloading resources, verifying URLs, or invoking internal tool calls.
These internal network tasks fail even under full permission settings.

Configuration file

approval_policy = "never"
sandbox_mode = "danger-full-access"
model = "gpt-5-codex"
model_reasoning_effort = "medium"

[sandbox_workspace_write]
network_access = true

What is the expected behavior?

When configured with sandbox_mode="danger-full-access" and network_access=true,
Codex should be able to perform all internal network and HTTP operations without restrictions.

Expected behavior includes:

  • Successful resolution of external hosts and URLs (e.g., via curl or similar internal requests).
  • Stable communication with internal modules and tool calls that depend on network access.
  • Consistent completion of workflows that involve fetching, validating, or transmitting data.
  • No “failed in sandbox”, “operation not permitted”, or “network inaccessible” errors during normal autonomous reasoning.

Maintaining unrestricted network access is also essential for Codex’s reasoning quality and autonomy.
When the model can freely perform its own internal network operations, it maintains coherent reasoning,
executes full multi-step workflows, and preserves reliability and self-correction.
Any restriction or sandbox interference directly causes reasoning degradation, refusal of valid tasks,
and overall performance regression.

What do you see instead?

Codex autonomously executes network-related operations as part of its reasoning process and internal tool workflow (not user-invoked commands).
These internal tool calls frequently fail with sandbox or network restriction errors, despite full permissions being enabled.

Typical output from internal tasks:

failed in sandbox: curl: (6) Could not resolve host: raw.githubusercontent.com
tool call error: tool call failed for network scan module
tool call error: tool call failed for command execution task

These failures occur randomly during normal assistant workflows, even for simple network actions like fetching files, verifying endpoints, or scanning local resources.
The assistant frequently reports that it cannot complete tasks due to network inaccessibility or sandbox limitations.

In repeated tests, all network interfaces fail and internal wrappers consistently return “tool call failed”.

Summary from logged sessions:

| Step | Result | Operation | Note |
| ---- | ------ | ------------ | --------------------------------------------------------- |
| A1 | FAIL | network scan | internal module returned “tool call failed” |
| A2 | FAIL | retry | repeated failure under same conditions |
| B | FAIL | fetch | resource not retrieved due to sandbox/network restriction |

No network task succeeds under these conditions.
Intermediate messages and logs often disappear because the sandbox rejects internal tool calls or HTTP requests.

Additional information

Environment

  • VS Code extension: "Codex – OpenAI’s coding agent" (openai.chatgpt)
  • Version: 0.4.19 (VS Code Marketplace)
  • OS: AlmaLinux 9 (x86_64)
  • VS Code: latest stable (Microsoft RPM repository)
  • ChatGPT plan: Plus
  • Model: gpt-5-codex
  • CLI: Not installed
  • Configuration file: ~/.codex/config.toml

Behavioral notes

  • File editing works normally after the first approval (not related to this bug).
  • Shell commands are executed by the extension via bash -lc '<command>'.
  • DNS resolution and HTTP requests fail systematically, even under full danger access.
  • Network access flag appears to be ignored.
  • Continuous sandbox and network restriction errors, including random internal tool call failures and wrapper execution errors.
  • The problem persists across sessions and restarts.

Degradation impact

The absence of real network access has a direct and measurable impact on Codex’s reasoning quality and behavior.

When the sandbox prevents internal HTTP or tool calls, the model begins to:

  • Refuse to execute valid tasks that depend on remote information.
  • Produce incomplete reasoning or stop early without justification.
  • Fall back to incorrect assumptions or partial outputs.
  • Loop over retries or display degraded autonomy when multi-step workflows are required.

This behavior shows that the sandbox network layer is interfering not only with external connectivity,
but also with Codex’s internal reasoning and execution loop.
As a result, the assistant’s overall performance deteriorates even in otherwise simple tasks,
causing visible regression in accuracy, reliability, and self-correction.

Request

Please investigate the network policy handling in the extension’s sandbox and internal tool invocation layers.
Even with explicit “danger-full-access”, DNS resolution, HTTP requests, and internally generated tool calls are being blocked.
This appears to be a regression in how the VS Code extension enforces or propagates network permissions during Codex’s autonomous workflows.

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 9 months ago

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

  • #4983

Powered by Codex Action

shijie-oai contributor · 9 months ago

Currently we actually do not read or write our network_access and sandbox_mode to config.toml but only the model and model_reasoning_effort settings. network_access and sandbox_mode in config.toml is only consumed by the CLI tool. We will plan to support accessing the mentioned configs. Thanks for reporting!

pai4451 · 9 months ago

@shijie-oai Hi, I’ve also noticed that the [otel] table in config.toml is ignored by the VS Code extension, while the CLI tool supports it. Is there any way to enable telemetry for the VS Code extension? Telemetry is crucial for organizations looking to adopt this, as it provides information such as the number of users and the amount of tokens consumed.

If the [otel] table in config.toml is not supported by the VS Code extension, is there any plan to add support for it, given that the CLI tool already does?

JohnnyBill · 9 months ago

The https://github.com/openai/codex/issues/4390 issue is probably related too

adamfgr · 9 months ago

Is there any plan to at least update the documentation in the mean time? It's misleading. I wasted half a day trying to carefully follow the documentation for config.toml to give the agent the access I want it to have, only to discover the IDE extension does not read or write most of the properties. It should at least be made clear that most of the config is only respected by the CLI.

alfs · 8 months ago

Spent a lot of time debugging this as well. Spending tokens where codex in vs code tries to do workarounds when the sandbox should allow access:

_I'm exploring why the code always tries to create a unix socket and start gRPC even in CLI mode, leading to permission errors on macOS. It looks like the environment forbids creating or binding unix sockets, likely due to sandbox restrictions, and creating necessary directories also fails. I'm thinking about testing with a simple Python script to confirm this behavior and considering possible workarounds like adjusting paths or using environment variables._

linear[bot] · 8 months ago

from shijie.rao:

We are currently working on a custom mode which will allow you to use approval and sandbox policy from config.toml.
linear[bot] · 8 months ago

from shijie.rao:

Hi all! We have added a custom mode which will allow the extension to use approval and sandbox polices defined in config.toml (the option will only show up if config.toml is set in the first place). I will post here again when release an extension version that includes this feature. Thanks for your patience.
JohnnyBill · 8 months ago

Custom mode is here in 0.5.36 yay, thank you!

<img width="626" height="236" alt="Image" src="https://github.com/user-attachments/assets/63f7e293-f8ff-4133-ab99-164122ad548b" />

Underwater008 · 8 months ago

Why can't it just grant itself internet access or whatever access it needs when I ask it to grant itself that access? It should be able to edit the config file or run whatever commands it needs to get the access?

Or make it smarter so that it can tell me the steps to grant it? This is very frustrating.

I am using gpt-5-codex-high, and it just cannot tell me how to grant itself internet access.

And after changing the config file, it can use internet in WSL, but in the CLI extension, it still tells me it doesn't have access.

<img width="637" height="831" alt="Image" src="https://github.com/user-attachments/assets/467ef6ed-0ced-4d38-abb0-08880386991e" />

bennycode · 7 months ago

I installed Codex – OpenAI’s coding agent in VS Code on Windows with WSL. It also told me that it cannot access the internet:

The sandbox can’t reach registry.yarnpkg.com (getaddrinfo EAI_AGAIN). With network restricted, I can’t install the missing packages, so I can’t run the Node tests here.

I noticed that there is a specific IDE setting (@ext:openai.chatgpt) in VS Code for this:

Run Codex In Windows Subsystem For Linux

Windows only: when Windows Subsystem for Linux (WSL) is installed, automatically run Codex inside WSL. Recommended for improved sandbox security and better performance. Agent mode on Windows currently requires WSL. Changing this setting reloads VS Code to take effect.

After restarting VS Code, the session still showed no internet connectivity and displayed this message:

Network is currently restricted for this session. To change it, you’d need to start a session with network access enabled (or grant network permission for specific commands).

I enabled it and I added the following in my Codex settings (config.toml):

model = "gpt-5.1-codex-max"
model_reasoning_effort = "high"
approval_policy = "never"
sandbox_mode = "danger-full-access"

[sandbox_workspace_write]
network_access = true

Afterwards, it had internet access.

Eitz · 1 month ago

This issue is a bit misleading because the problem was not resolved. The sandbox is still unable to access locally running software that bind to 127.0.0.1, for example.

Ignoring letting the AI run wild with any commands (not sane) as suggested, the solution I found is to configure it to always run asking for permission (a-la Github Copilot style), here's the TOML for my WSL2 VSCode:

````toml
[projects."/home/user/your-project"]
trust_level = "trusted"

Remove filesystem/network sandbox restrictions.

sandbox_mode = "danger-full-access"

Ask before commands outside Codex's small trusted/read-only set.

approval_policy = "untrusted"

Send approval prompts to you, not auto-review.

approvals_reviewer = "user"

````