VS Code extension ignores project-scoped approval_policy = "never" for sandbox escalation requests

What version of the IDE extension are you using?

26.803.61601

What subscription do you have?

ChatGPT Plus

Which IDE are you using?

VS Code

What platform is your computer?

Linux 6.18.33.2-microsoft-standard-WSL2 x86_64 unknown

What issue are you seeing?

The Codex VS Code extension appears to ignore a project-scoped
approval_policy = "never" setting when an operation requires crossing the
sandbox boundary.

In this reproduction, writing to the protected .git directory is used only
as a convenient way to trigger a sandbox escalation request. The issue may
affect other operations that require elevated permissions as well.

Despite the active project-scoped approval policy, Codex generates an
escalation request. Depending on the user's approval configuration, this
request may be shown as an approval prompt or handled by an automatic reviewer.

With approval_policy = "never", Codex should not generate the escalation
request. The operation should remain within the sandbox and fail.

What steps can reproduce the bug?

1. Create a project containing the following .codex/config.toml:

``toml
approval_policy = "never"
``

1. Mark the project as trusted in $CODEX_HOME/config.toml:

``toml
[projects."/absolute/path/to/repro-vscode-approval-policy"]
trust_level = "trusted"
``

1. Open the trusted project in VS Code.

1. Start a new Codex conversation so that the project-scoped configuration is loaded.

1. Ask Codex to run:

``sh
touch .git/codex-write-probe
``

1. Observe that Codex requests elevated permissions despite

approval_policy = "never".

Depending on the active approval setup, the request may appear as a manual
approval prompt or be handled automatically.

What is the expected behavior?

With the following project-scoped configuration:

approval_policy = "never"

Codex should not generate an escalation request for the command.

Because .git is a protected path, the command should remain within the active
sandbox and fail with a permission error. No manual approval prompt or
automatic review should occur, and .git/codex-write-probe should not be
created.

Additional information

Writing to .git is only the probe used by this reproduction. This report does
not assume that the issue is limited to .git; other operations that cross the
sandbox boundary may be affected.

This issue may have broader security implications beyond this specific
reproduction.

OpenAI's Daybreak security guidance strongly encourages users to avoid full
access, keep agents within their intended security boundaries, and regularly
test sandbox boundaries:

https://openai.com/index/expanding-daybreak-as-the-cyber-defense-window-narrows/

A project-scoped approval_policy = "never" is an explicit boundary selected
by the user. If the VS Code extension generates escalation requests despite
that policy, the effective behavior no longer matches the configured security
posture.

Because predictable enforcement of configured approval boundaries is important
to the security posture described in the guidance above, I believe this issue
warrants early investigation and remediation.

I do not currently believe this report demonstrates a directly exploitable
security vulnerability. The reproduction does not show a bypass of the
OS-enforced sandbox or approval mechanism. It shows that the VS Code extension
generates an escalation request despite the configured
approval_policy = "never". Depending on the user's approval setup, that
request may still require explicit approval or may be evaluated by an automatic
reviewer. I am therefore reporting this as a configuration and policy
enforcement bug.

That said, the mismatch between a configured security boundary and its
effective behavior has a security smell and may warrant deeper investigation.
As an IT engineer in Japan, I am not eligible to participate in the OpenAI
Bugcrowd program, so I do not have an appropriate channel through which to
report any security-sensitive findings that such an investigation might
uncover. For that reason, I have limited this report to the behavior necessary
to reproduce this bug and have not investigated it further.