›_ Codex Issues
Codex Issues / #33552

macOS Codex Desktop 26.707.91948 still overrides custom profile with never/user

Open 💬 2 comments Opened Jul 16, 2026 by liby
💡 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 (From “About Codex” dialog)?

Codex Desktop 26.707.91948 (build 5440)

Bundled Codex CLI: 0.144.5

What subscription do you have?

Not included in this public report.

What platform is your computer?

Darwin 25.5.0 arm64 arm
macOS 26.5.2 (25F84)

What issue are you seeing?

After fully quitting and restarting Codex Desktop, a completely fresh conversation still overrides the separately configured approval policy and approval reviewer when using a named custom permission profile.

The configuration contains:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "<named custom profile>"

The first turn of the fresh Desktop conversation recorded:

originator = Codex Desktop
source = vscode
cli_version = 0.144.5
approval_policy = never
approvals_reviewer = user
permission_profile.type = managed
sandbox_policy.type = workspace-write

The managed permission profile itself was applied, including its configured additional writable roots. However, the independent approval settings were changed from on-request/auto_review to never/user.

The bundled codex doctor --json loads the same configuration successfully:

config.load.status = ok
config.load.summary = config loaded
sandbox.helpers.approval policy = OnRequest
filesystem sandbox = restricted
network sandbox = enabled

Because the fresh thread runs with approval_policy = never, escalation requests are unavailable and auto-review cannot run.

What steps can reproduce the bug?

  1. Configure approval_policy = "on-request", approvals_reviewer = "auto_review", and a valid named custom default_permissions profile.
  2. Fully quit Codex Desktop with Cmd-Q.
  3. Reopen Codex Desktop 26.707.91948.
  4. Create a completely new conversation.
  5. Ask the first turn to report the task-injected runtime values for approval_policy, approvals_reviewer, permission_profile.type, and sandbox_policy.type without reading config.toml.
  6. Inspect the first turn context.

The new conversation receives never/user/managed/workspace-write instead of the configured on-request/auto_review approval settings.

What is the expected behavior?

A named permission profile should control filesystem and network permissions without replacing the independently configured approval policy and reviewer.

The fresh thread should start with:

approval_policy = on-request
approvals_reviewer = auto_review
permission_profile.type = managed
sandbox_policy.type = workspace-write

Additional information

This is the macOS Codex Desktop counterpart to #33084. That issue was closed after the reporter confirmed the VS Code case appeared fixed in 26.707.91948, but the Desktop reproduction above still occurs on that exact version after a full restart.

Related broader Desktop report: #32338.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33084

Powered by Codex Action

liby · 25 days ago

Still reproducible in Codex Desktop 26.727.51351 (6119).

I traced the current Desktop request builder. It first derives { permissions, approvalPolicy, approvalsReviewer } from agentMode. Full Access maps to :danger-full-access/never/user. Selecting a named profile then replaces only the permission profile id, leaving the stale never/user values. This lets thread/start or turn/start send <named-profile>/never/user.

There is a separate reset gap. On a fresh thread/start, omitted approval fields fall back to effective config. On an existing thread, omitted/null fields are no-ops, so switching Full Access -> a named profile retains never/user.

The picker should apply these settings atomically: Full Access stays :danger-full-access/never/user; a named profile restores approval policy/reviewer from resolved effective config, including on existing threads. That likely requires an explicit reset-to-config operation rather than null.