Critical: VS Code Codex extension blocks network access and returns persistent sandbox errors even with danger-full-access
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?
- 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. - On AlmaLinux 9 (x86_64), create the configuration file below in
~/.codex/config.toml. - Restart VS Code to ensure the configuration is loaded.
- 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
curlor 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.
12 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Currently we actually do not read or write our
network_accessandsandbox_modeto config.toml but only themodelandmodel_reasoning_effortsettings.network_accessandsandbox_modein config.toml is only consumed by the CLI tool. We will plan to support accessing the mentioned configs. Thanks for reporting!@shijie-oai Hi, I’ve also noticed that the
[otel]table inconfig.tomlis 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 inconfig.tomlis not supported by the VS Code extension, is there any plan to add support for it, given that the CLI tool already does?The https://github.com/openai/codex/issues/4390 issue is probably related too
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.
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._
from shijie.rao:
from shijie.rao:
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" />
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" />
I installed Codex – OpenAI’s coding agent in VS Code on Windows with WSL. It also told me that it cannot access the internet:
I noticed that there is a specific IDE setting (
@ext:openai.chatgpt) in VS Code for this:Run Codex In Windows Subsystem For Linux
After restarting VS Code, the session still showed no internet connectivity and displayed this message:
I enabled it and I added the following in my Codex settings (
config.toml):Afterwards, it had internet access.
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"
````