Running sudo codex can make ~/.codex root-owned and leave desktop app stuck on startup

Open 💬 1 comment Opened Jul 19, 2026 by sunjiajunsunjiajun

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

Unknown. The app was stuck on the startup/loading screen, so I could not open the About dialog.

What version of Codex CLI is running?

Observed with a recent Codex CLI / app-server build. The bundled desktop app-server reported 0.145.0-alpha.18 in logs after restart.

What subscription do you have?

N/A

What platform is your computer?

macOS, ChatGPT/Codex desktop app.

What issue are you seeing?

Using sudo codex can create or modify files under the normal user's Codex home (~/.codex) as root. After that, the ChatGPT/Codex desktop app, which runs as the normal GUI user, can no longer read those files and may remain stuck on the startup/loading screen without a clear user-facing error.

In my case, the desktop app window opened but stayed on the loading screen with the OpenAI logo. The process was running and the window existed, but the UI did not finish loading.

Local logs showed repeated config read failures like this, with the username/path redacted:

Failed to load desktop settings from config.toml
EACCES: permission denied, open '/Users/<user>/.codex/config.toml'

Failed to start local app-server sidecar after app-server initialization
failed to read configuration layers: Failed to read config file /Users/<user>/.codex/config.toml: Permission denied (os error 13)

Request failed ... method=config/read ...
failed to read configuration layers: Failed to read config file /Users/<user>/.codex/config.toml: Permission denied (os error 13)

Checking file ownership showed that these sensitive state/config files had become root-owned:

-rw-------  1 root  staff  ... /Users/<user>/.codex/auth.json
-rw-------  1 root  staff  ... /Users/<user>/.codex/config.toml

There were also many root-owned files under plugin/cache directories inside ~/.codex.

After fixing ownership back to the normal user and restarting the desktop app, the same config/read calls succeeded and the app was able to continue startup.

What steps can reproduce the bug?

  1. On macOS, use Codex CLI and Codex/ChatGPT desktop app with the same normal user's ~/.codex directory.
  2. Run Codex as root, for example:

``bash
sudo codex
``

This is sometimes tempting because Codex may need to perform privileged local operations.

  1. Let that root-run Codex session read/write config, auth, plugin, cache, or app-server state under the normal user's ~/.codex.
  2. Exit sudo codex.
  3. Launch the ChatGPT/Codex desktop app normally as the GUI user.
  4. Observe that the app may get stuck on the startup/loading screen.
  5. Inspect logs and file ownership.

What is the expected behavior?

Codex should avoid silently creating root-owned files in a normal user's Codex home when launched with sudo, or it should clearly detect and explain the problem.

At minimum, the desktop app and/or codex doctor should surface an actionable diagnostic such as:

  • ~/.codex/config.toml is not readable by the current user
  • ~/.codex/auth.json is not readable by the current user
  • some files under ~/.codex are owned by a different user
  • running sudo codex with the normal user's HOME can break later non-root desktop/CLI usage

What is the actual behavior?

The desktop app can remain stuck on the loading screen. The user-visible UI does not clearly say that the app is blocked by a permissions/ownership problem in ~/.codex.

The only clear signal was in local logs: repeated EACCES / Permission denied (os error 13) failures when reading ~/.codex/config.toml.

Additional information

A workaround is to repair ownership manually, for example:

sudo chown -R <user>:staff /Users/<user>/.codex

Going forward, users can avoid polluting the normal user's ~/.codex by not running bare sudo codex. If root-level Codex usage is truly needed, a separate root Codex home is safer, for example:

sudo -H codex

or:

sudo env CODEX_HOME=/var/root/.codex codex

However, this workaround is not obvious from the app behavior, and it may require separate authentication/configuration for the root-isolated Codex home.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗