›_ Codex Issues
Codex Issues / #28604

Locked use toggle disabled and cannot be re-enabled after 26.611.61049 update

Open 💬 2 comments Opened Jun 16, 2026 by GGBondBlueWhale
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

After updating Codex Desktop to the latest version 26.611.61049, the Locked use setting was unexpectedly turned off. When I try to turn it back on, it fails and Codex shows an error toast:

Unable to update Locked use

This started immediately after the update.

Environment

  • Codex Desktop version: 26.611.61049
  • macOS: Tahoe 26.5.1
  • Device: MacBook Pro 16-inch, Apple M5 Max, 128 GB memory

Steps to reproduce

  1. Update Codex Desktop to version 26.611.61049.
  2. Open Codex settings.
  3. Go to Computer use.
  4. Observe that Locked use is turned off.
  5. Try to enable Locked use.

Expected behavior

If Locked use was previously enabled, it should remain enabled after updating. If it is off, the user should be able to turn it back on normally.

Actual behavior

Locked use is off after the update, and attempting to enable it fails with the error message:

Unable to update Locked use

Impact

This breaks an important Computer Use permission/setting after updating. Users who rely on Codex being able to use the Mac while it is locked can no longer enable the feature, which affects normal Codex Desktop workflows.

Please investigate why the Locked use setting is reset/disabled after updating and why enabling it fails in 26.611.61049.

<img width="1886" height="1112" alt="Image" src="https://github.com/user-attachments/assets/ccb80318-6d33-4acc-8a3a-9979ce360c90" />

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 months ago

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

  • #28600

Powered by Codex Action

Keesan12 · 2 months ago

This sounds like two bugs hiding behind one toast: migration lost or invalidated the prior Locked use preference, and the post-update write path cannot restore it.

The most useful telemetry would be previous setting value, migration result, entitlement check result, and the exact persistence/write failure after the toggle attempt. If those are logged as separate checkpoints, it becomes much easier to tell whether this is a settings migration regression or a runtime permission revalidation bug.