Running sudo codex can make ~/.codex root-owned and leave desktop app stuck on startup
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?
- On macOS, use Codex CLI and Codex/ChatGPT desktop app with the same normal user's
~/.codexdirectory. - Run Codex as root, for example:
``bash``
sudo codex
This is sometimes tempting because Codex may need to perform privileged local operations.
- Let that root-run Codex session read/write config, auth, plugin, cache, or app-server state under the normal user's
~/.codex. - Exit
sudo codex. - Launch the ChatGPT/Codex desktop app normally as the GUI user.
- Observe that the app may get stuck on the startup/loading screen.
- 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.tomlis not readable by the current user~/.codex/auth.jsonis not readable by the current user- some files under
~/.codexare owned by a different user - running
sudo codexwith the normal user'sHOMEcan 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗