Repository navigation
macOS Desktop 26.803.41515 removes Custom permissions and forces managed workspace profile #37437
Description
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:
sandbox_mode = "danger-full-access" approval_policy = "never"
-
Confirm with the bundled
codex doctorthat the configuration parses and resolves to unrestricted filesystem/network access with approval Never. -
Launch Desktop
26.803.41515(build6321). -
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(build6234) - 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:
Activity
github-actions commentedon Aug 7, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
alexander-dreyzen commentedon Aug 7, 2026
Additional cross-host and existing-task evidence from the same regression:
26.803.41515(build6321) and CLI0.147.0-alpha.6.5.approval_policy = "never",sandbox_mode = "danger-full-access", and workspace network access enabled./etc/codex/requirements.tomlor/etc/codex/managed_config.toml, and none has the macOS MDMconfig_toml_base64orrequirements_toml_base64keys.There is also a client-consistency failure on one existing task:
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 commentedon Aug 8, 2026
I have a matching Windows reproduction with before/after UI evidence.
Timeline:
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.
samtuke commentedon Oct 15, 2026
We observed a related configuration-to-runtime mismatch on macOS on 15 October, on installed Desktop 26.1007.30912 (build 20156), runtime 0.162.0-alpha.17.2, macOS 27.0.1 arm64.
The local config inspected during this investigation contains approval_policy="never" and sandbox_mode="danger-full-access". A parent chat's turn_context records never / danger-full-access / disabled, but a newly delegated child started at 00:15:29 UTC with on-request / workspace-write / network_access=false / managed profile / active profile :workspace. The parent still recorded unrestricted permissions at 00:24:45 UTC.
The child required approval for a read-only GitHub query after a network failure and for writing its already-authorized evidence outside the workspace. This interrupted unattended work.
The same child later received a Full Access settings update at 00:55:41 UTC, and its next direct user turn recorded never / danger-full-access / disabled. Subsequent network reads succeed without escalation.
This confirms a related effective-permission mismatch on a newer build; it does not reproduce the missing Custom option, establish that an update caused it, or show permanent failure to recover. Cross-task delegation is the distinguishing context in this observation. No raw logs, credentials, private paths, or project details are included.