Codex App UI freezes: worker crashes, massive git/worktree errors, and concurrent orphaned app-server processes

Open 💬 9 comments Opened Feb 8, 2026 by sizumita

💡 Likely answer: A maintainer (miraclebakelaser, contributor) responded on this thread — see the highlighted reply below.

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

260206.1448 (565)

What subscription do you have?

Pro

What issue are you seeing?

The Codex App UI occasionally becomes unresponsive and stops accepting input.

Observed symptoms around freeze windows:

Worker crashes: Worker exited { code: 1 }
Agent loop failure: agent loop died unexpectedly
Large volumes of git/worktree errors:
git-origins ... ENOENT
git-origin-and-roots Failed to resolve origin
Worktree has a branch checked out
Temporary concurrent codex app-server processes (older orphaned processes remain alive)

Date observed: 2026-02-08 (local logs, macOS)

Relevant log points:

agent loop died unexpectedly:
log/codex-tui.log:106966 (01:42:30)
log/codex-tui.log:107280 (12:04:39)
Same-day counts:
git-origins ... ENOENT: 1905
git-origin-and-roots Failed to resolve origin: 1905
Worktree has a branch checked out: 308
Worker exited { code: 1 }: 8

Additional process-level observation:

Multiple codex app-server processes with different start times were alive simultaneously.
All observed with PPID=1 (orphaned), suggesting cleanup did not complete after parent exit.
Multiple app-server processes were opening the same rollout JSONL at the same time.

Note:

Most observable failures were in worker/app-server/git-worktree paths.

What steps can reproduce the bug?

Run Codex App on macOS with apps = true, collab = true, shell_snapshot = true.
Use multiple repositories/projects (including paths that may become unavailable over time).
Continue regular usage until git/worktree sync errors start repeating.
During that period, observe worker restarts/exits and occasional agent loop died unexpectedly.
In some sessions, codex app-server from previous generations remains alive while a new one starts.
UI eventually becomes unresponsive.

Environment specifics from affected setup:

Config file: ~/.codex/config.toml
Previously had non-existent project paths in config (later removed):
Two stale local project paths (redacted)

What is the expected behavior?

Codex App UI should remain responsive even if git/worktree discovery fails.
codex app-server should be single-instance, and old instances should be reliably cleaned up on parent exit/restart.
Worker crashes should be isolated and should not lead to a UI freeze.

Additional information

Actions already taken:

Removed non-existent project paths from ~/.codex/config.toml.
Checked repositories with:
git worktree list --porcelain
git worktree prune --dry-run
No stale worktree registrations were found.

Suspected root-cause chain (hypothesis):

Parent process crash/restart sometimes leaves orphaned app-server.
New startup spawns another app-server, causing temporary multi-instance execution.
Rollout/state writes and worker management may contend.
Continuous git/worktree exception churn amplifies instability and contributes to UI freeze.

View original on GitHub ↗

9 Comments

miraclebakelaser contributor · 6 months ago

etraut-openai contributor · 6 months ago

We've made a lot of perf improvements over the past week. Are you still seeing these issues with the latest version?

miraclebakelaser contributor · 6 months ago

Performance is dramatically better for me but I still get these orphaned processes that idle in Activity Monitor despite quitting Codex App.

sizumita · 6 months ago

I'm in the same situation. In my environment, the zsh process exists in isolation.

miraclebakelaser contributor · 6 months ago

^ This too.

dorukardahan · 5 months ago

I can confirm orphaned children after quit on macOS

@miraclebakelaser and @sizumita i saw the same "closed the app, old processes still there" part. On my machine it was not only app-server or zsh. I had leftover MCP-side processes too.

My environment

Codex.app 26.311.21342 (build 993)
macOS Darwin 25.3.0, Apple Silicon
app had been open around 2.5 days

What quit cleaned and what it missed

When I used Cmd+Q on March 17, 2026, about 90 Codex child processes died. But a smaller orphan set stayed alive under PID 1 / launchd:

2x `chrome_crashpad_handler`
2x orphaned `playwright-mcp`
1x orphaned `twitterapi` MCP

The dates on those leftovers matched older Codex sessions:

March 9, 2026    -> still had a crashpad + Playwright survivor
March 14, 2026   -> still had a crashpad + Playwright survivor
recent session   -> big cleanup happened, but one TwitterAPI-side survivor still escaped

That last part is why this looks racey to me. It was not “all of one generation stayed” or “all died”. Most of the batch died on quit, but one sibling from the same family still escaped.

So i think there may be two bugs mixed together:

Codex keeps too much child state alive while it runs
quit/restart teardown is not deterministic, so some children still escape

This feels close to the older orphan-after-exit reports like #6201, but here i was seeing it from Codex.app on macOS.

xiaodream551-a11y · 3 months ago

+1 — also reproducing the orphan app-server symptom on macOS, but without any of the other symptoms in this issue (no UI freeze, no agent loop died unexpectedly, no git/worktree errors, no worker crashes). May be a separate cleanup path worth isolating.

Repro

Open Codex desktop app
Open multiple chats (each spawns a codex app-server --listen ws://127.0.0.1:0)
⌘Q to quit the app (clean exit)
Children remain orphaned with PPID=1

Observed

After a clean ⌘Q:

$ ps aux | grep "codex app-server" | grep -v grep | wc -l
14

$ ps aux | grep -E "Codex\.app/Contents/MacOS|Codex Helper" | grep -v grep
(empty)

So the main UI is gone, the helpers are gone, but 14 codex app-server children persist with PPID=1.

Environment

Codex desktop app: 26.506.31421 (build 2620)
CodexBar: 0.25.1 (build 61)
macOS: 26.4.1 (25E253), Apple Silicon (Darwin 25.4.0 arm64)
Plan: ChatGPT Pro

Workaround

pkill -f "Codex.app/Contents/Resources/codex app-server"

Why I think it's a separate path

The OP attributes orphan accumulation to "parent process crash/restart" plus surrounding git/worktree churn. Here the parent exited normally via ⌘Q, no failure path was triggered (no Worker exited, no agent loop died unexpectedly, no git-origins ENOENT), and orphans still appeared. So there seems to be a general child-reaping bug on clean quit, independent of the crash/restart trigger documented above.

coconilu · 1 month ago

Still reproducible on Windows with Codex App 26.721.4979.0

I can reproduce the agent loop died unexpectedly / UI freeze pattern on a current Windows installation.

Environment

Codex App package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
Windows 11 Pro, x64, build 26200
64 GB RAM
Local mode, ChatGPT authentication

User-visible symptom

After a turn appears to finish, follow-up messages in that same thread can fail immediately with the inline banner:

Error submitting message

Once a thread enters this state, subsequent follow-ups continue to fail. Creating a new thread works, so the current workaround is to abandon the affected thread and continue in a new one.

Redacted desktop-log evidence

Two confirmed composer submission failures occurred on 2026-07-25. The relevant sequence is:

response_routed method=turn/start errorCode=-32603 durationMs=3
Request failed method=turn/start durationMs=11
error={"code":-32603,"message":"failed to start turn: internal error; agent loop died unexpectedly"}
[Composer] submit failed errorMessage="failed to start turn: internal error; agent loop died unexpectedly" followUp=local mode=local

The same exact agent loop died unexpectedly signature is present in desktop logs dated July 19, 21, 22, 23, and 25. I am not uploading the full logs because they contain local paths and thread metadata, but I can provide additional redacted excerpts if useful.

Performance/state snapshot at reproduction time

~/.codex/logs_2.sqlite: approximately 1.26 GB
logs_2.sqlite-wal: approximately 42.7 MB
Main desktop codex app-server: approximately 455 MB working set
Largest Electron renderer: approximately 928 MB working set
All ChatGPT/Codex desktop processes combined: approximately 3.0 GB working set

This resembles the large-DB/app-server pressure reported in #27395, but the failure mode here is different: turn/start fails almost immediately with -32603 because the thread's agent loop has died, rather than timing out after 30 seconds. The database size and memory pressure may be contributing factors, but I cannot establish causality from this snapshot alone.

This confirms that the agent loop died unexpectedly path remains reproducible on Windows in 26.721.4979.0, including the specific behavior where an affected thread can no longer accept follow-up messages while a new thread still works.

jorgen-k · 3 days ago

This appears reproducible in the VS Code Codex extension on macOS. We found 13 stale VS Code workspace-storage entries pointing to deleted research-kit-worktrees/* paths, while git worktree list showed only the main checkout.

During the failure, Codex logged repeated fs/readDirectory ENOENT errors. Git operations then blocked for 68–148 seconds, including git rev-parse, followed by config/read and turn/start 30-second timeouts and an unresponsive Composer. Disabling worktree support immediately removes the problem.

The likely fix is to treat a missing saved worktree/workspace path as stale metadata: invalidate or delete that reference, preserve the thread, and stop retrying it. Git/worktree discovery should also isolate the missing path so it cannot block the shared worker or UI.