macOS: global-state read EPERM falls back to empty project registry while SQLite projects survive #46919

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

26.915.31945, build 9922 (read from the installed app's Info.plist; startup logs also identify build 9922).

What subscription do you have?

Not specified in this report.

What platform is your computer?

macOS 26.2 (25C56), Apple Silicon / arm64. The installed application is ChatGPT.app with the Codex desktop surface.

What issue are you seeing?

All 13 saved local projects disappeared from the Projects list. Existing tasks remained available, and the source folders that were checked still existed. A live list_projects call returned zero local projects, while the local SQLite database still contained all 13 project definitions and their root paths.

The relevant startup failure was EPERM while reading both the primary desktop global-state file and its backup. After startup, both files contained an empty local-projects registry. This is a read failure, rather than the atomic-rename write failure reported in some Windows issues.

Sanitized log excerpts (UTC, 2026-09-21):

00:38:32.581Z warning [global-state] Failed to load global state
  errorCode=EPERM
  errorMessage="EPERM: operation not permitted, open '<USER_HOME>/.codex/.codex-global-state.json'"

00:38:33.321Z warning [global-state] Failed to load global state
  errorCode=EPERM
  errorMessage="EPERM: operation not permitted, open '<USER_HOME>/.codex/.codex-global-state.json.bak'"

00:38:36.733Z info [host-app-server-projects]
  Local app-server project migration completed projectCount=13

Read-only inspection before recovery found:

• state_5.sqlite: 13 rows in projects, with corresponding project_roots records and legacy ID mappings in project_idempotency_keys.
• .codex-global-state.json and its .bak: local-projects: {} and selected-project: null.
• The legacy-to-server project ID map and project ordering were absent from global state.
• The migration state reported projectsMigrated: true and threadAssignmentsMigrated: false.
• Restarting the app did not restore the local project list, despite another migration log reporting projectCount=13.

What steps can reproduce the bug?

This is an observed incident, not a reliably reproduced EPERM trigger:

1. Have saved local projects in the desktop app.
2. Launch/restart the app. In this incident, startup could not read either the primary global-state file or its backup, with the errors above.
3. Observe that all local projects are missing from the sidebar and from list_projects.
4. Inspect the persisted global state and SQLite database: the desktop registry is empty, but the database still has the project definitions.
5. Restart the app again; the list remains empty.

The underlying cause of EPERM is unknown. I have not established that an app update, macOS permissions change, or another process caused it.

What is the expected behavior?

A failure to read existing state should not silently become a successfully loaded empty state that is later persisted over both the primary file and its backup. The app should preserve recoverable state, surface the loading error, and retry or recover safely.

When the app-server project store contains the projects, the desktop project list should be rehydrated consistently, or a clear recovery path should be offered.

Additional information

Inspecting the installed bundle's state-loading path indicates that failure to read both files falls back to an empty in-memory map. Combined with the observed empty files after startup, this suggests that subsequent persistence replaced the project registry with defaults. This is the suspected failure chain; there is no filesystem trace proving which exact write first replaced it.

Recovery was successful after backing up the state and database, fully exiting the app, and reconstructing only the desktop project registry, ordering, and legacy-to-server ID map from the surviving database records. After reopening, list_projects returned all 13 local projects with their original legacy IDs. The database itself was not modified by recovery. This verifies project-list recovery only, not complete recovery of historical task assignments or other settings.

Related reports: #41428 (macOS empty Projects sidebar) and #42739 (Windows projects survive in SQLite while the desktop registry is empty). This report adds the paired global-state read EPERM errors and the empty-state fallback evidence; please link or merge it if it shares the same underlying bug.

Personal paths, project names, task content, account identifiers, and raw state/database files are intentionally omitted.