[Windows Desktop 26.825] Custom (config.toml) ignores default_permissions = ":danger-full-access" and launches restricted sandbox

What version of the Codex App are you using (From “About Codex” dialog)?

Current version at the time of filing: 26.825.51511

Bundled CLI observed from the running Desktop app:

codex-cli 0.151.0-alpha.7.2

What platform is your computer?

Windows 11 x64, native Windows Codex Desktop execution.

What issue are you seeing?

Custom (config.toml) no longer honors a user-level configuration that requests full access:

default_permissions = ":danger-full-access"
approval_policy = "never"

[shell_environment_policy.set]
WORKSPACE_ACCESS_MODE = "FULL_ACCESS"

[windows]
sandbox = "elevated"

[projects.'c:\workspace']
trust_level = "trusted"

There is no sandbox_mode entry in the active config.

When the permission selector is left on Custom (config.toml), a brand-new task receives a restricted/read-only Windows sandbox instead of danger-full-access:

• $env:WORKSPACE_ACCESS_MODE is correctly injected as FULL_ACCESS from the same config.toml.
• Reading an existing Workspace file is denied.
• Creating a disposable file inside the Workspace is denied.
• Creating a disposable file outside the Workspace in a machine-local temp/cache directory is denied.
• The shell also reports restricted-language / Constrained Language Mode behavior, e.g. Method invocation is supported only on core types in this language mode.

The exact same probe succeeds immediately when I explicitly switch the Desktop composer permission selector from Custom (config.toml) to the built-in Full access option and start a fresh task.

This means the machine/SMB/filesystem access itself is healthy, and the Desktop app is clearly loading at least part of config.toml (the environment variable is injected), but the configured default_permissions = ":danger-full-access" is not being applied to the runtime permission profile.

Timeline / update clarification

The same machine and configuration were definitely working with full access roughly 15 hours before the failure was noticed.

During debugging, Codex Desktop received another update, but the bug had already reproduced before that update, so that update is not the trigger for the failure described here.

There may have been an earlier Desktop update sometime between the last-known-good state and the first observed failure, but I do not have reliable evidence of that timing. Therefore this report should not attribute the regression to a specific app update or build transition.

What steps can reproduce the bug?

1. On Windows Codex Desktop, use a user config containing:

   default_permissions = ":danger-full-access"
   approval_policy = "never"
   
   [shell_environment_policy.set]
   WORKSPACE_ACCESS_MODE = "FULL_ACCESS"
   
   [windows]
   sandbox = "elevated"
   

2. Ensure there is no active sandbox_mode setting.

3. Leave the composer permission selector on Custom (config.toml).

4. Start a brand-new task.

5. Ask it to perform a harmless permission probe, for example:

   1. Report $env:WORKSPACE_ACCESS_MODE
   2. Read C:\Workspace\Elysian\WORKSPACE-SETUP.md
   3. Create/delete C:\Workspace\Elysian\artifacts\codex-full-access-probe.tmp
   4. Create/delete C:\0.TempDevCache\codex-full-access-probe.tmp
   

6. Observe under Custom (config.toml):

   WORKSPACE_ACCESS_MODE: FULL_ACCESS
   Workspace read: access denied
   Workspace create/delete: blocked by policy
   Temp/cache create/delete: blocked by policy
   

   The shell may also report PowerShell restricted-language errors.

7. In Settings, enable the availability of the built-in Full access option if necessary. (The Settings dialog explicitly says this only adds Full Access to the permissions menu; it does not activate it.)

8. In the composer permission menu, explicitly select Full access.

9. Start another brand-new task and run the exact same probe.

10. Observe that all four checks now succeed, including writes outside the Workspace.

Additional diagnostics already performed

Normal PowerShell under the same Windows user can read both the local Workspace view and its backing UNC share without issue.

The active user config contains:

default_permissions = ":danger-full-access"
approval_policy = "never"

A recursive check found no project-level .codex/config.toml overriding those values.

No local managed requirements/config files are present at:

C:\ProgramData\OpenAI\Codex\requirements.toml
C:\ProgramData\OpenAI\Codex\config.toml
%USERPROFILE%\.codex\managed_config.toml

The running Desktop codex.exe app-server command line contains no --sandbox override.

So far the reliable workaround is to explicitly select the built-in Full access profile in the composer, rather than use Custom (config.toml).

What is the expected behavior?

When Custom (config.toml) is selected and the resolved user configuration contains:

default_permissions = ":danger-full-access"
approval_policy = "never"

the effective runtime should use danger-full-access semantics, equivalent to the built-in Full access selection unless another higher-precedence requirement explicitly forbids it.

If Desktop intentionally does not allow Custom (config.toml) to resolve to :danger-full-access, it should make that explicit in the UI/config diagnostics rather than silently launching a restricted sandbox while still applying other values from the same config.

The selected/configured permission source and the effective runtime permission profile should remain consistent and inspectable.

Related issues

This looks related to the wider Windows permission-state/config synchronization problems in:

• #32338 — permission dropdown/runtime profile desynchronization; specifically mentions Custom unexpectedly producing a strict read-only policy.
• #38535 — Custom/config handling around never + danger-full-access.
• #40698 — effective permission state degrading/desynchronizing from unchanged config.toml.

This report is narrower: on the current Windows Desktop, a fresh task consistently reproduces Custom (config.toml) + default_permissions = ":danger-full-access" -> restricted sandbox, while explicitly selecting the built-in Full access profile makes the same fresh-task probe pass immediately.

Start at the Windows Desktop composer permission selector and the running codex.exe app-server, then trace how Custom (config.toml) resolves default_permissions into the effective runtime profile. Reproduce the listed PowerShell permission probe with the supplied config.toml and compare it with built-in Full access. Done means Custom applies equivalent danger-full-access behavior or clearly reports why it cannot.