Summary
On Ubuntu 26.04, the ChatGPT/Codex Linux desktop app refused to launch because the Codex profile was reported as being in use by another process, even though the referenced PID no longer existed and no chatgpt or codex processes were running.
Removing only the stale Chromium/Electron singleton files under ~/.config/Codex/ immediately fixed the problem and the app launched successfully.
Environment
- Ubuntu 26.04 (Resolute Raccoon) x86_64
- Kernel: Linux 7.0.0-29-generic
- GNOME 50.1
- Mutter / Wayland
- CPU: AMD Ryzen 7 5800X3D
- GPU: NVIDIA RTX 3080
- Codex app-server after successful launch:
0.147.0-alpha.6.6
- Launch command:
chatgpt
Context: this occurred after updating the NVIDIA driver and rebooting. I do not know whether the driver update caused the stale lock; it may simply have coincided with an unclean app/session shutdown.
Actual behavior
Launching chatgpt failed with:
ERROR:chrome/browser/process_singleton_posix.cc:365] The profile appears to be in use by another Codex process (199157) on another computer (jyoush-To-Be-Filled-By-O-E-M). Codex has locked the profile so that it doesn't get corrupted. If you are sure no other processes are using this profile, you can unlock the profile and relaunch Codex.
ERROR:chrome/browser/ui/views/message_box_dialog.cc:200] Unable to show message box: Codex - The profile appears to be in use by another Codex process (199157) ...
The app exited instead of recovering or presenting a usable unlock flow.
Verification
The PID referenced by the lock did not exist:
$ ps -fp 199157
UID PID PPID C STIME TTY TIME CMD
No ChatGPT/Codex processes were running:
$ pgrep -af 'chatgpt'
$ pgrep -af 'codex'
$ pgrep -af 'chatgpt|codex'
The stale singleton files were still present:
/home/jyoush/.config/Codex/SingletonSocket
/home/jyoush/.config/Codex/SingletonLock
/home/jyoush/.config/Codex/SingletonCookie
Workaround that fixed it
rm -f ~/.config/Codex/SingletonSocket ~/.config/Codex/SingletonLock ~/.config/Codex/SingletonCookie
chatgpt
After removing those three files, the app launched normally. The bundled Codex process spawned and initialized successfully, including:
[StdioConnection] stdio_transport_spawned ... executablePath=/usr/lib/chatgpt/resources/codex
[AppServerConnection] Current reported app-server version: currentVersion=0.147.0-alpha.6.6
[AppServerConnection] Codex CLI initialized
[window-manager] window ready-to-show
Expected behavior
If the owner PID recorded by the singleton lock no longer exists, the Linux desktop app should detect that the lock is stale and recover automatically, or provide a working prompt/action to unlock the profile. It should not remain permanently unable to launch until the user manually deletes SingletonLock, SingletonSocket, and SingletonCookie.
Additional note
The log also shows Unable to show message box, so the intended recovery UI may itself be failing on Linux/Wayland.
Summary
On Ubuntu 26.04, the ChatGPT/Codex Linux desktop app refused to launch because the Codex profile was reported as being in use by another process, even though the referenced PID no longer existed and no
chatgptorcodexprocesses were running.Removing only the stale Chromium/Electron singleton files under
~/.config/Codex/immediately fixed the problem and the app launched successfully.Environment
0.147.0-alpha.6.6chatgptContext: this occurred after updating the NVIDIA driver and rebooting. I do not know whether the driver update caused the stale lock; it may simply have coincided with an unclean app/session shutdown.
Actual behavior
Launching
chatgptfailed with:The app exited instead of recovering or presenting a usable unlock flow.
Verification
The PID referenced by the lock did not exist:
No ChatGPT/Codex processes were running:
The stale singleton files were still present:
Workaround that fixed it
After removing those three files, the app launched normally. The bundled Codex process spawned and initialized successfully, including:
Expected behavior
If the owner PID recorded by the singleton lock no longer exists, the Linux desktop app should detect that the lock is stale and recover automatically, or provide a working prompt/action to unlock the profile. It should not remain permanently unable to launch until the user manually deletes
SingletonLock,SingletonSocket, andSingletonCookie.Additional note
The log also shows
Unable to show message box, so the intended recovery UI may itself be failing on Linux/Wayland.