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

[sizumita]

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?

1. Run Codex App on macOS with apps = true, collab = true, shell_snapshot = true.
2. Use multiple repositories/projects (including paths that may become unavailable over time).
3. Continue regular usage until git/worktree sync errors start repeating.
4. During that period, observe worker restarts/exits and occasional agent loop died unexpectedly.
5. In some sessions, codex app-server from previous generations remains alive while a new one starts.
6. 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):

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

[miraclebakelaser]

Possibly related: #11000

[etraut-openai]

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

[miraclebakelaser]

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

[sizumita]

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

[miraclebakelaser]

^ This too.

[dorukardahan]

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:

1. Codex keeps too much child state alive while it runs
2. 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]

+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

1. Open Codex desktop app
2. Open multiple chats (each spawns a codex app-server --listen ws://127.0.0.1:0)
3. ⌘Q to quit the app (clean exit)
4. 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.