Critical: VS Code Codex extension ignores approval_policy="never" and randomly asks for approval, even for identical shell commands in the same chat

[alfonsoalongi]

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?

Summary

The official VS Code extension "Codex – OpenAI’s coding agent" (identifier openai.chatgpt, v0.4.19) repeatedly asks for "Approve session" when executing shell commands, even with approval_policy="never" and sandbox_mode="danger-full-access" enabled.

File edits inside the workspace usually work after the first approval, but shell command execution is random and inconsistent. Even within the same chat session, identical or similar commands sometimes run silently and sometimes trigger another approval prompt.

This makes Codex unreliable for automation, scripting, and CI/CD workflows.

---

Environment

• Extension: Codex – OpenAI’s coding agent
  Identifier: openai.chatgpt
  Version: 0.4.19 (VS Code Marketplace)
  Published: 2025-03-06
  Last Updated: 2025-10-07
• Codex CLI: Not installed (codex --version = N/A)
• VS Code: latest stable from Microsoft RPM repo
• OS: AlmaLinux 9 (x86_64)
• ChatGPT plan: Plus
• Model: gpt-5-codex
• Configuration file: ~/.codex/config.toml

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

[sandbox_workspace_write]
network_access = true

---

Actual behavior

• Workspace file operations behave correctly after the first approval.
• Shell commands executed via bash -lc '<command>' behave inconsistently.
• Identical commands in the same chat may randomly trigger new "Approve session" dialogs.
• Starting a new chat resets all approvals, and every command must be re-approved.
• I keep getting responses like:
  Operation not permitted, sandbox restriction issues, network inaccessibility, interaction with MCP server configured in config.toml even if they use STDIO because I read limitations in the HTTP extension.

Example commands:

bash -lc 'grep -n "PATTERN" path/to/file'
bash -lc 'rg "SOME_REGEX" path/to/source'
bash -lc 'curl -s -w '\n%{time_total}' http://127.0.0.1:8888/health'

---

Persistent sandbox and network errors

I keep getting responses like:
Operation not permitted, sandbox restriction issues, network inaccessibility, interaction with MCP server configured in config.toml even if they use STDIO because I read limitations in the HTTP extension.

These errors occur continuously, not occasionally, and appear even when sandbox_mode="danger-full-access" and approval_policy="never" are active. They indicate that the sandbox and MCP integration layers are inconsistently enforcing restrictions, causing blocked shell and network operations.

---

Expected behavior

With approval_policy="never" and sandbox_mode="danger-full-access", all commands should run automatically without any manual approval, regardless of repetition or session state.

---

Impact

• Blocks non-interactive automation and CI/CD jobs.
• Breaks reproducibility because identical commands may behave differently.
• Resets approval state when a new chat starts.
• Continuous sandbox restriction or network errors even under full danger access.

This is a critical usability and reliability issue that makes Codex unsuitable for automated or trusted workflows.

---

Request

Please confirm whether this is a known bug in the shell execution layer (bash -lc) or a regression in approval state handling.
If unintentional, restoring consistent and persistent behavior for approval_policy="never" is essential for stable use.

What is the expected behavior?

Codex inconsistently requests "Approve session" dialogs when executing shell commands, even when the configuration explicitly disables confirmations.

• In the same chat session, identical commands sometimes run without approval and sometimes require it again.
• The pattern is completely random and does not depend on command content.
• When starting a new chat, all approvals reset and every command requires confirmation again.
• Workspace file edits generally work after the first approval.
• Some shell commands fail with failed in sandbox: even when full danger access is enabled.

This inconsistent and random approval behavior makes Codex unreliable and unusable for continuous or scripted workflows.

What do you see instead?

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 repo)
• ChatGPT plan: Plus
• Model: gpt-5-codex
• CLI: Not installed
• Config file: ~/.codex/config.toml (shown below)

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

[sandbox_workspace_write]
network_access = true

Behavioral notes

• File editing behaves correctly after initial approval.
• Shell commands behave randomly, even for identical inputs in the same chat.
• Approval state resets completely when a new chat is started.
• I keep getting responses like: Operation not permitted, sandbox restriction issues, network inaccessibility, interaction with MCP server configured in config.toml even if they use STDIO because I read limitations in the HTTP extension.
• CLI not installed, issue reproducible using only the VS Code extension.

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 repo)
• ChatGPT plan: Plus
• Model: gpt-5-codex
• CLI: Not installed
• Config file: ~/.codex/config.toml (shown below)

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

[sandbox_workspace_write]
network_access = true

Behavioral notes

• File editing behaves correctly after initial approval.
• Shell commands behave randomly, even for identical inputs in the same chat.
• Approval state resets completely when a new chat is started.
• I keep getting responses like: Operation not permitted, sandbox restriction issues, network inaccessibility, interaction with MCP server configured in config.toml even if they use STDIO because I read limitations in the HTTP extension.
• CLI not installed, issue reproducible using only the VS Code extension.

[github-actions]

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

• Version 0.42.0 - new required approvals breaks workflows #4351
• [windows] codex IDE extension - full access continues to request manual approvals #3993
• Windows approval “Allow for this session” isn’t remembered #4212
• There is a network request configuration in MCP with the sandbox_mode set to "danger-full-access", but it still fails to access the network. #4434
• Sandbox settings in config.toml profile are not respected #3034

Powered by Codex Action

[linear]

from shijie.rao:

Duplicate of #5041 - Closing this one out to centralize conversation there.

[alfonsoalongi]

This issue should not be closed.

It is not a duplicate of #5041.
Issue #5041 only covers the “approval prompt” UI behavior, while this report also documents:

• Repeated sandbox and network restriction errors (Operation not permitted, network inaccessibility, etc.) even with sandbox_mode="danger-full-access".
• Random failures of internal tool calls (bash -lc, curl, etc.) and degraded behavior across identical commands in the same session.
• Regression effects on Codex’s reasoning and task execution — the model begins to refuse valid tasks and degrade in reliability when its own internal operations are blocked.

This report contains a much broader and more critical set of symptoms, including sandbox policy enforcement and reasoning degradation, which are not mentioned in #5041 or any of the issues listed by the duplicate bot.

The closure as “not planned” also seems inaccurate because this is a regression bug, not a feature request.
It affects the core reliability of Codex and prevents automation, scripting, and consistent reasoning behavior.

Please reopen this issue or link it to a new tracking item covering the sandbox/network enforcement regression.

[linear]

from shijie.rao:

Hi! I have commented on #5041 that we do not consume the sandbox_mode and network_access properties set in config.toml for our extension and those only affects our CLI tool. We will investigate into consolidating the setting potentially. In the meantime, you choose Agent: full access in the VSC extension UI, it will achieve the same as the config that you have posted.