›_ Codex Issues
Codex Issues / #37220

Permission mode selector disabled in all local chats after Desktop 26.730.61639 update

Open 💬 2 comments Opened Aug 6, 2026 by antonreshetov

Summary

After updating the stable ChatGPT Desktop app on macOS, the permission mode selector in the Codex composer is disabled in every local chat. The current mode, Ask for approval, is displayed but cannot be clicked or changed.

Environment

  • ChatGPT Desktop: 26.730.61639 (stable app build, bundle build 6234)
  • Bundled Codex core reported in session metadata: 0.147.0-alpha.1.2
  • macOS: 26.5.1 (25F80)
  • Architecture: Apple Silicon (arm64)
  • Task type: Local

Regression

The selector worked before the latest stable Desktop update. It is now disabled in all existing and newly created local chats.

For comparison, older local sessions used bundled core versions 0.146.0-alpha.3.1 and 0.146.0-alpha.9.2. The effective permission configuration is unchanged:

{
  "approval_policy": "on-request",
  "approvals_reviewer": "user",
  "permission_profile_type": "managed",
  "sandbox_type": "workspace-write"
}

There is no approval_policy, default_permissions, or sandbox_mode override in the user config.toml, and the affected repositories are trusted.

Steps to reproduce

  1. Open ChatGPT Desktop 26.730.61639 on macOS.
  2. Open any local Codex chat, or create a new local chat.
  3. Locate the permission mode control below the composer.
  4. Try to click Ask for approval.

Expected behavior

The permission mode menu opens and allows selecting another available mode.

Actual behavior

The control is visibly disabled and does not respond to clicks. This occurs in every local chat after the update.

Additional notes

This does not appear to be a per-thread configuration issue: the same backend permission profile was present in older sessions where the selector was interactive. The regression appears limited to the Desktop UI or its handling of the permission profile.

View original on GitHub ↗

2 Comments

antonreshetov · 22 days ago

Confirmed temporary workaround

Downgrading to the previous stable macOS build restores the permission mode selector and makes it interactive again.

Official OpenAI archive for Apple Silicon:

https://persistent.oaistatic.com/codex-app-prod/ChatGPT-darwin-arm64-26.727.51351.zip

Steps:

  1. Fully quit ChatGPT with Cmd+Q.
  2. Download and extract the archive above.
  3. Move the current /Applications/ChatGPT.app aside as a backup instead of deleting it.
  4. Move the extracted ChatGPT.app into /Applications.
  5. Start ChatGPT and verify that the version is 26.727.51351 (build 6119).

The downgrade does not remove local Codex tasks or configuration stored under ~/.codex.

This is only a temporary workaround while the regression is being fixed. The built-in updater may offer or reinstall the newer build again; consumer installations do not currently have supported version pinning.

antonreshetov · 13 days ago

Root cause found and local workaround

The issue still reproduces after updating to:

  • ChatGPT Desktop 26.810.41047 (bundle 6570)
  • bundled Codex core 0.148.0-alpha.9

I found what appears to be a persisted UI-state schema migration bug. In ~/.codex/.codex-global-state.json, under electron-persisted-atom-state, the affected installation contained:

"composer-permission-mode-visibility": false

The current Desktop frontend expects this value to be an object instead:

"composer-permission-mode-visibility": {
  "guardian-approvals": true,
  "full-access": true
}

When the persisted value is the boolean false, the frontend treats the optional modes as hidden. This leaves only Ask for approval, and the dropdown disables itself because it has only one visible option. The user config.toml, repository trust settings, and bundled core permission profiles were not restricting these modes.

A working local workaround is:

  1. Fully quit ChatGPT Desktop with Cmd+Q.
  2. Back up ~/.codex/.codex-global-state.json.
  3. Replace the boolean value above with the expected object.
  4. Restart the app.

If Full access should remain hidden while keeping the approval selector enabled, this also works:

"composer-permission-mode-visibility": {
  "guardian-approvals": true,
  "full-access": false
}

It is important to quit the app before editing the file. If the file is changed while Desktop is running, the old boolean value is written back from memory. After changing the value while the app was closed and restarting, the permission selector became interactive again.

This suggests the update needs to migrate the old boolean value or reject non-object persisted values and fall back to the current defaults.