Codex Permission Selector Greyed Out on Windows? Repair Its State

If the Codex Desktop permission selector is greyed out on Windows even when the task is idle, first check for one specific stale-state defect. A verified report found the legacy value "composer-permission-mode-visibility": false where the current app expected an object. Fully exit the Codex app, back up the single state file containing that exact property, replace only the legacy boolean with the expected object, and relaunch.

Do not delete the whole application-state directory, reset every Codex setting, change Windows file ownership, or enable Full Access from a config file just to unstick the control. This repair applies only when the stored property is exactly the legacy boolean. If the property is absent, already contains an object, or the selector spins instead of staying disabled, stop and diagnose that different failure.

Confirm That You Have the Same Failure

The verified Windows report used Codex app 26.803.5235.0 on Windows 11. Match these boundaries before editing state:

• the permission label is visible but the selector itself cannot be opened;

• the selector stays disabled in new and existing local tasks, including while no turn is running;

• changing approval_policy, sandbox_mode, or related settings in config.toml does not make the selector interactive;

• a persisted app-state file contains the exact property "composer-permission-mode-visibility": false.

The same symptom does not prove the same cause. A separate macOS report describes a disabled selector after an app update without proving this stale boolean, and an older report describes an indefinite loading spinner. Do not apply this Windows state edit to either case unless you independently find the exact legacy value.

Also separate this UI failure from an effective-permissions failure. If the selector opens and changes modes but commands still run with the wrong sandbox or approval policy, the selector is not stuck. Review the active task, managed policy, and Codex Windows sandbox diagnosis instead.

Find the One Persisted State File

Update Codex through its normal installer first, then restart it once. If the selector remains disabled, open PowerShell and run this read-only search. It limits the scan to likely Codex, ChatGPT, and OpenAI application directories under your user profile:

$roots = @(
    $env:APPDATA
    $env:LOCALAPPDATA
    (Join-Path $env:LOCALAPPDATA "Packages")
) | Where-Object { $_ -and (Test-Path -LiteralPath $_) }

$stateCandidates = Get-ChildItem -LiteralPath $roots -Directory -ErrorAction SilentlyContinue |
    Where-Object { $_.Name -match "Codex|ChatGPT|OpenAI" } |
    ForEach-Object {
        Get-ChildItem -LiteralPath $_.FullName -File -Recurse -ErrorAction SilentlyContinue
    } |
    Select-String -SimpleMatch '"composer-permission-mode-visibility"' |
    Select-Object -ExpandProperty Path -Unique

$stateCandidates

Expected result: one plausible current application-state file. If there is no result, do not invent a path or create the property. If there are multiple results, inspect their parent directories and modification times; do not bulk-edit every match. Keep the exact selected path private because user and project information can live nearby.

Open the selected file in a plain-text editor and confirm the property is exactly:

"composer-permission-mode-visibility": false

Do not continue if the value is true, an object, malformed in another way, or embedded in a log rather than active state. The upstream report only verified the false to object repair.

Fully Exit Codex Before Editing

Close every Codex or ChatGPT Desktop window and use the application's normal Quit action. Then check for remaining package processes:

Get-Process -ErrorAction SilentlyContinue |
    Where-Object { $_.ProcessName -match "Codex|ChatGPT|OpenAI" } |
    Select-Object ProcessName, Id, StartTime

Expected result: no process belonging to the affected desktop app remains. If one remains, close it through Task Manager and rerun the check. Do not edit while the app is running. In the verified report, shutdown wrote the already-loaded false value back to disk and undid an in-process edit.

Back Up and Repair Only the Property

Set the path to the single active state file you verified, then create a timestamped sibling backup:

$statePath = "C:\replace\with\the\verified\state-file"
$backupPath = "$statePath.bak-$(Get-Date -Format yyyyMMddHHmmss)"
Copy-Item -LiteralPath $statePath -Destination $backupPath
$backupPath

Expected result: PowerShell prints the backup path and the original file remains unchanged. Open the original file in a plain-text editor. Replace only this value:

"composer-permission-mode-visibility": false

with this object:

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

Preserve the surrounding file structure and punctuation. Do not format, truncate, or replace the entire state file. Save the original path, leave the backup untouched, and relaunch Codex.

Verify the Repair Without Broadening Access

Open one local task and wait until it is idle. The permission selector should now open and show the modes allowed by your account and organization. Select the normal approval mode first and run one harmless read-only check inside a disposable folder.

Treat Full Access as a separate security decision, not as proof that the selector is repaired. OpenAI's security guidance describes sandbox mode and approval policy as different controls and marks unsandboxed full access as elevated risk. Keep the narrowest mode that completes the task, especially in an untrusted repository. See how to prevent destructive Codex changes for a safer operating boundary and Codex app versus CLI when you need a more explicit permission configuration.

If the selector is still disabled, fully exit the app again and confirm that the property remained an object. If it reverted to false, you edited the wrong file or another app process was still running. If it remained an object, restore the backup and attach a sanitized reproduction to the upstream issue instead of deleting more state.

To restore the backup, exit all app processes again and run:

Copy-Item -LiteralPath $backupPath -Destination $statePath -Force

Why the Repair Works

The current evidence comes from one detailed Windows report, not a confirmed OpenAI release note. The reporter inspected the installed app bundle and found that the current default is an object with guardian-approvals and full-access keys. The resolver used a nullish fallback, so the old boolean false passed through instead of being replaced. Downstream UI code then found neither visible mode.

Replacing only the legacy value after process exit restores the shape the current UI expects while preserving the rest of the app state. It does not change the effective sandbox or approval policy by itself. OpenAI should ultimately migrate or validate the persisted value so users do not need a manual repair.

Monitor the Upstream Fix With a Read-Only Action

After the selector works, Aident Loadout can monitor the relevant public issues without pasting a GitHub token into Codex. Give Codex the canonical setup instruction:

Follow https://aident.ai/SETUP.md

Then use this prompt:

Check my Aident Loadout account authentication and Vault status. Search the staging capability catalog for a connected read-only GitHub issue-search Action, inspect its schema, and preflight it. If the estimate is free, return the state, updated time, title, and URL for openai/codex issues 37423, 37220, and 24984. Do not comment, edit, close, label, publish, install, change files, start OAuth, or ask me for a GitHub credential.

Success is measurable: authentication and Vault checks complete; discovery, schema inspection, and preflight succeed; the three issue states return; and no GitHub write or credential exposure occurs. Set up Aident Loadout and monitor the permission fix.

Sources

• OpenAI Codex issue 37423: stale boolean disables the Windows permission selector

• OpenAI Codex issue 37220: disabled selector after a macOS app update

• OpenAI Codex issue 24984: permission selector stuck loading

• Official OpenAI Codex agent approvals and security guidance

• Official OpenAI Codex configuration reference

Refresh this guide when issue 37423 changes state, OpenAI ships a persisted-state migration or supported selector reset, the desktop app moves or renames this property, or a stable release makes the manual repair unnecessary.