[macOS App] Sole named permission profile masks built-in selection in existing tasks

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

ChatGPT/Codex desktop 26.908.70816, build 9275 (installed bundle metadata).

What subscription do you have?

Not included; the observed failure is in the local permissions picker.

What platform is your computer?

macOS 26.2, Apple Silicon (arm64).

What issue are you seeing?

With exactly one named permission profile configured, existing local tasks can display that profile as selected even after choosing Approve for me or Ask for approval. Clicking a built-in option appears to do nothing because the named-profile label/checkmark remains.

This was observed on two existing tasks in separate local Git worktrees. The only named profile extended :read-only, so the display misleadingly suggested that both editing tasks were read-only. Quitting and reopening the app did not resolve it.

The actual task permissions can still allow workspace edits. This report concerns a misleading permission display; it does not establish a sandbox enforcement failure or an unauthorized increase in access.

What steps can reproduce the bug?

The following uses generic profile names in place of the original local names:

1. Have existing local tasks, including a planning task and editing tasks.

2. Configure one named profile in the user configuration, with an explicit built-in default:

   default_permissions = ":workspace"
   
   [permissions.planning-readonly]
   description = "Read-only planning"
   extends = ":read-only"
   

   No legacy sandbox_mode or sandbox_workspace_write settings are present.

3. Select the named read-only profile in the planning task.

4. Open an existing editing task and select Approve for me or Ask for approval.

5. Reopen the permissions menu. The sole named profile can remain shown as selected, making the built-in selection appear ineffective.

6. Quit and reopen the app and retry. In the observed installation, the symptom persisted.

What is the expected behavior?

The label and checkmark should reflect the task's effective selection. A built-in selection should display its own label. Merely having exactly one named profile in the configuration should not make it appear selected.

If a requested selection cannot be applied, the UI should explain that instead of silently retaining a misleading label.

Additional information

Validation and scope

• After correcting an earlier missing default_permissions setting, app logs showed successful config/read and permissionProfile/list responses. The menu problem persisted with the valid configuration above and after restart.
• Read-only inspection of saved task context showed workspace write access and automatic approval review for the editing tasks despite the reported read-only-profile label.
• Isolated profile checks confirmed that the named read-only profile blocked writes and the workspace profile permitted writes in the intended workspace. These checks validate the profiles, not the menu state.
• No app source, private runtime state, or feature flags were modified.

Source-level diagnosis

A permission-dropdown implementation shipped in this build computes the displayed named selection with this fallback:

B = Ye ?? (!He && Ce.length === 1 ? Ce[0].id : null)

Here, Ye is the explicit non-built-in profile selection, He is shouldSendPermissionOverrides, and Ce is the list of non-built-in named profiles. An existing-task path returns shouldSendPermissionOverrides: false, including when the actual profile is built-in. With exactly one named profile, the fallback therefore chooses its label, which takes precedence over the built-in-mode label.

This source path matches the observed symptom; the app also ships another dropdown implementation, so runtime feature-flag routing should be checked by maintainers.

Observed workaround

Add a second named profile:

[permissions.worker-edit]
description = "Workspace editing"
extends = ":workspace"

After the additional profile was loaded, the user confirmed that both editing tasks could visibly switch to the named editing profile and to Approve for me. Keeping the second profile available avoids the single-profile display fallback; it need not be selected. Removing it again has not been tested in the live app.

Related reports

#29915 and #32338 concern related permission-selection/state problems. This report isolates the exactly-one-named-profile display fallback on macOS.

Private project names, paths, task IDs, full logs, and session contents have been omitted.

Locate the permission-dropdown implementation containing the named-selection fallback expression and inspect the alternate dropdown implementation and runtime feature-flag routing. Reproduce the existing-task path with exactly one named profile, then verify that built-in labels and checkmarks reflect the effective selection instead of the sole named profile.