macOS Desktop 26.803.41515 removes Custom permissions and forces managed workspace profile

Open 💬 3 comments Opened Aug 7, 2026 by svan71

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using?

ChatGPT/Codex Desktop 26.803.41515 (build 6321)

Bundled Codex CLI: 0.147.0-alpha.6.5

What platform is your computer?

macOS ARM64

What issue are you seeing?

This Desktop update introduced a severe permission-profile regression.

An existing user configuration contains:

sandbox_mode = "danger-full-access"
approval_policy = "never"
approvals_reviewer = "user"

The bundled codex doctor still loads and parses that configuration successfully and reports unrestricted filesystem access, enabled network access, and approval policy Never.

However, every new Desktop task is launched with different task-injected runtime values:

approval_policy = granular
permission_profile.type = managed
active_permission_profile.id = :workspace
sandbox_policy.type = workspace-write
network_access = false

At the same time, the composer permission picker no longer offers Custom. It only offers Ask for approval and Approve for me. Fully restarting the application does not restore Custom.

This blocks previously working SSH and network operations and silently overrides a valid local configuration.

What steps can reproduce the bug?

On macOS ARM64, configure:

``toml sandbox_mode = "danger-full-access" approval_policy = "never"``

Confirm with the bundled codex doctor that the configuration parses and resolves to unrestricted filesystem/network access with approval Never.
Launch Desktop 26.803.41515 (build 6321).
Start a fresh task.
Inspect the composer permission picker and first-turn runtime metadata.

Observed:

Custom is absent from the picker.
The task is forced to managed :workspace, workspace-write, restricted network, and granular approvals.
Restarting does not help.

Rollback proof

Rolling back to the immediately preceding official appcast build:

Desktop 26.730.61639 (build 6234)
Bundled CLI 0.147.0-alpha.1.2

immediately restores:

the Custom picker option;
permission_profile.type = disabled;
sandbox_mode = danger-full-access;
enabled network access;
approval_policy = never.

No configuration change is required between the broken build and the rollback. No administrator or workspace policy is involved.

What is the expected behavior?

Desktop should honor the validated local permission and approval configuration. If a policy intentionally overrides it, the UI should identify that policy and source explicitly. It must not silently replace the configured runtime profile or remove Custom from the picker.

Please fix the Desktop config-to-runtime permission-profile handoff and restore the Custom option.

Additional information

Feedback was also submitted through /feedback with no logs uploaded.

Feedback thread ID: 019fdc28-2b3f-7ef2-ae50-fd326953ca23

Related reports:

#29915
#33552

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 20 days ago

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

#36816
#36497

Powered by Codex Action

alexander-dreyzen · 20 days ago

Additional cross-host and existing-task evidence from the same regression:

Reproduced immediately after the update on three Apple Silicon Macs.
All three hosts run Desktop 26.803.41515 (build 6321) and CLI 0.147.0-alpha.6.5.
The permission-related user configuration remains unchanged and symmetric on all three: approval_policy = "never", sandbox_mode = "danger-full-access", and workspace network access enabled.
None of the three hosts has /etc/codex/requirements.toml or /etc/codex/managed_config.toml, and none has the macOS MDM config_toml_base64 or requirements_toml_base64 keys.
Existing, already-running Desktop tasks also changed posture after the update: they render Ask for approval, the Custom option is absent, and resumed turns receive a managed workspace-write runtime profile despite the unchanged local configuration.

There is also a client-consistency failure on one existing task:

On one Mac, the same task has returned to full access and continues normally.
On another Mac displaying that task, the UI remains trapped on a permission request. Deny is unavailable, Escape does nothing, and force-quitting/relaunching the app does not clear it.
The task itself is demonstrably live because it continues on the first Mac while the second client remains blocked.

This makes the failure deterministic across hosts and also shows that the injected permission state or approval overlay can diverge between clients for the same task. It appears to be an app-level config-to-runtime migration plus client-state reconciliation regression, not a machine-local configuration mutation.

grtninja · 19 days ago

I have a matching Windows reproduction with before/after UI evidence.

Timeline:

On July 16, 2026, Codex Desktop showed the gear-labeled Custom mode in the composer and it was selected.
I then did not use Codex for several days.
Windows updated the packaged app while it was idle.
On the first launch on August 8, Custom was gone. The permission picker now contains only Ask for approval, Approve for me, and Full access.

I did not switch modes or edit the configuration during that idle window. My local config.toml, model-instruction surface, backups, and recovery manifest still exist. Full access is not an acceptable substitute for Custom because it does not prove that the configured instructions, MCP/profile state, routing, and approval semantics are the effective runtime authority.

This makes the report look cross-platform and consistent with an app-level permission-profile migration / config-to-runtime reconciliation regression rather than a machine-local config mutation. The exact Windows AppX package version and state hashes are being captured now and can be added once the forensic restore run completes.

Please preserve and expose the user-defined Custom profile across app updates. If a migration cannot map the existing state safely, the app should fail closed and report the migration error instead of silently removing Custom or selecting a built-in preset.