Codex-created launchctl restart job becomes a keepalive loop that repeatedly terminates ChatGPT
What version of Codex CLI is running?
codex-cli 0.144.1
What subscription do you have?
ChatGPT subscription (the exact tier is not exposed by the CLI).
Which model were you using?
gpt-5.6-sol
What platform is your computer?
Darwin 25.5.0 arm64 arm — macOS 26.5 (25F71)
What terminal emulator and version are you using?
iTerm2 3.6.11, no multiplexer.
Codex doctor report
The full redacted report and logs were uploaded via /feedback.
Uploaded thread: 019f4f25-e935-7231-90c3-e2449d1b9bf7
Relevant summary:
{
"overallStatus": "ok",
"codexVersion": "0.144.1",
"app_server.status": {
"status": "ok",
"summary": "background server is not running",
"mode": "ephemeral",
"pid_file": "missing"
},
"installation": {
"status": "ok",
"summary": "installation looks consistent"
},
"network.websocket_reachability": {
"status": "ok",
"summary": "Responses WebSocket handshake succeeded"
}
}
What issue are you seeing?
ChatGPT/Codex desktop 26.707.31428 (build 5059, bundle ID com.openai.codex) exits within seconds of launching and opening a workspace or resuming a thread.
Each attempt leaves orphaned browser_crashpad_handler and bare-modifier-monitor processes. There is no Crashpad minidump and no conventional macOS crash report, so this looks more like an unintended clean exit or host shutdown than a normal native crash.
A desktop app-server orphan remained alive for hours and held the remote-control WebSocket. New desktop app-server launches then logged:
HTTP 409 Conflict
{"detail":"Remote app server already online"}
The same orphan was not reported by codex doctor --json, which said the background server was not running. Stopping only that orphan removed the 409, but the desktop app still exited immediately, so the conflict is real but not the entire failure.
There is also a launcher/rebrand mismatch: codex app <path> does not recognize the installed /Applications/ChatGPT.app despite its com.openai.codex bundle ID. It says “Codex Desktop not found,” downloads the installer, and still does not leave a usable desktop app. This overlaps with #31944; the stale remote-control behavior overlaps with #28862.
The impact is larger than a desktop crash because official Browser docs say Browser is available in ChatGPT web/desktop but not Codex CLI or the IDE extension. The Chrome extension/native host is installed, healthy, and has successfully connected as codex-chrome-extension-sidepanel, but a CLI session cannot use it. Once the desktop app exits, there is no supported browser-verification path.
What steps can reproduce the bug?
- Install and enable ChatGPT for Chrome.
- Launch ChatGPT desktop 26.707.31428 on macOS.
- Open a local workspace or resume an existing Codex thread.
- Observe the main desktop process exit within seconds.
- Repeat and observe additional orphaned crashpad and modifier-monitor helpers.
- Inspect Codex logs: when the stale app-server is present, the new desktop server receives
409 Remote app server already online. - Stop the stale app-server and repeat: the 409 disappears, but the main app still exits.
- Run
codex doctor --json: it reports no background server even when the orphan is active. - Run
codex app <workspace>: it fails to recognize/Applications/ChatGPT.appand attempts another installer download.
Uploaded diagnostic thread: 019f4f25-e935-7231-90c3-e2449d1b9bf7.
What is the expected behavior?
The desktop app should remain open, should own or reuse exactly one remote-control app-server, and should clean up its helpers on exit. codex doctor should detect any live desktop app-server that can cause a 409. codex app should recognize the ChatGPT-branded app by bundle ID. If Browser remains unsupported in CLI, CLI should immediately explain that limitation and provide a supported fallback instead of sending users through extension restart/reinstall loops.
Additional information
Environment:
- ChatGPT desktop: 26.707.31428, build 5059
- Codex CLI: 0.144.1
- Chrome: 150.0.7871.115
- ChatGPT for Chrome: 1.2.27203.26575
- macOS: 26.5 (25F71)
Related issues: #31944 and #28862.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗