SkyComputerUseClient processes spawned for turn-ended events remain alive as PPID=1 orphans

Summary

Codex Desktop appears to leave SkyComputerUseClient helper processes alive after turn-ended / agent-turn-complete events. On my machine these processes accumulate as PPID=1 orphans and are not tied to active Computer Use work.

This is different from simply having many active sessions. The process command lines show that these helpers were launched with a turn-ended event payload, including type: "agent-turn-complete", client: "codex_exec", cwd, thread-id, turn-id, input-messages, and last-assistant-message.

The accumulated helpers coincide with degraded Codex Desktop responsiveness, including laggy output streaming, elevated renderer/app-server CPU, and large local state/log databases.

Related but distinct from #24510, which covers large active history/list behavior. This issue is specifically about helper process lifecycle / reap behavior for turn-ended event handling.

Environment

• App: Codex Desktop
• Version observed in process list: 26.527.31326 / Electron helper version 149.0.7827.54
• OS: macOS 26.4.1 25E253
• Machine: Apple Silicon Mac
• Local state paths involved:
• ~/.codex/state_5.sqlite
• ~/.codex/logs_2.sqlite
• ~/.codex/computer-use/Codex Computer Use.app/.../SkyComputerUseClient

Observed process state

At the time of investigation:

SkyComputerUseClient total: 287
PPID=1 orphans:        285
current app-server child: 1
other transient shell/rg match: 1

All meaningful orphaned processes had command lines shaped like:

/Users/.../.codex/computer-use/Codex Computer Use.app/.../SkyComputerUseClient turn-ended {
  "type": "agent-turn-complete",
  "thread-id": "...",
  "turn-id": "...",
  "cwd": "/Users/kangmin/cowork/onto-mcp",
  "client": "codex_exec",
  "input-messages": [...],
  "last-assistant-message": "..."
}

They were not active children of the current Codex app-server. Most were inherited by launchd:

by_ppid [(1, 285), (48524, 1)]
by_type [('agent-turn-complete', 285)]
by_client [('codex_exec', 285)]

Distribution by workspace

The stale helpers mostly came from high-volume codex_exec review runs:

/Users/kangmin/cowork/onto-mcp                         255 processes
/Users/kangmin/Documents/excel-workbook-editing         19 processes
/Users/kangmin/Documents/FCeditor-pipeline-stabilization 8 processes
/Users/kangmin/cowork/onto-mcp-claude                    3 processes

Time clustering also suggests they were created during turn-completion bursts rather than a single app crash:

Mon Jun 1 11:00 /Users/kangmin/cowork/onto-mcp  85
Mon Jun 1 14:00 /Users/kangmin/cowork/onto-mcp  58
Mon Jun 1 13:00 /Users/kangmin/cowork/onto-mcp  52
Mon Jun 1 12:00 /Users/kangmin/cowork/onto-mcp  38
Tue Jun 2 09:00 /Users/kangmin/Documents/excel-workbook-editing 12

The current Codex Desktop app instance had started later than most of these helpers, so they were not freshly created by the current session:

Current Codex app start: Wed Jun 3 09:58:03 2026
Orphan helper starts:    Sat May 30, Mon Jun 1, Tue Jun 2

Impact observed

During the same investigation window, Codex Desktop became visibly sluggish:

• assistant output streaming lagged in the UI
• renderer CPU spiked
• app-server CPU spiked
• GPU/service process also showed repeated CPU bursts

Example process samples:

Renderer PID 48668:   up to ~140% CPU, RSS ~1.7-1.8 GB
app-server PID 48524: up to ~190% CPU, RSS ~790-820 MB
GPU/service PID 48495: up to ~48% CPU
Codex main PID 48458: 10-20% range during the lag window

Local DB sizes were also large at the time:

~/.codex/state_5.sqlite  1.3 GB
~/.codex/logs_2.sqlite   2.0 GB
~/.codex/logs_2.sqlite-wal 33 MB

Active thread state had grown again:

active threads:      10,379
active preview:      188.64 MB
active text total:   566.38 MB
archived threads:    6,970
archived preview:    181.41 MB

Largest active contributors:

/Users/kangmin/cowork/onto-mcp
  3,052 rows / 128.77 MB preview

/Users/kangmin/cowork/wireframe_editor_v2-segment-split
  5,280 rows / 28.35 MB preview

The large active history likely contributes to UI/server pressure, but the orphaned SkyComputerUseClient processes appear to be a separate lifecycle leak.

How I inspected it

Representative commands:

pgrep -fl 'SkyComputerUseClient' | wc -l

ps -axo ppid,comm \
  | rg 'SkyComputerUseClient' \
  | awk '{count[$1]++} END{for (p in count) print p,count[p]}' \
  | sort -k2 -nr

ps -ww -axo pid=,ppid=,lstart=,etime=,rss=,command= \
  | rg 'SkyComputerUseClient'

ps -ww -axo command= \
  | rg 'SkyComputerUseClient' \
  | rg -o 'turn-ended|agent-turn-complete|codex_exec|client":"[^"]+"|cwd":"[^"]+'

I also sampled the app-server and renderer during the lag window:

/usr/bin/sample 48668 3 -file /tmp/codex-renderer-48668.sample
/usr/bin/sample 48524 3 -file /tmp/codex-app-server-48524.sample

The renderer sample was mostly V8/JS/string/stream related. The app-server sample showed many tokio-runtime-worker and sqlx-sqlite-worker threads with SQLite I/O mixed in.

Expected behavior

A helper spawned for turn-ended / agent-turn-complete should not remain alive indefinitely after the event is handled.

At minimum, one of the following should happen:

• the helper exits after successfully handling the event
• the parent app-server reaps it
• the helper has a lease/TTL and self-exits when stale
• the helper exits when its parent app-server is gone
• Codex Desktop startup reaps stale orphan helpers from prior runs

Actual behavior

The helpers remain alive for days with PPID=1, while still carrying their original turn-ended JSON payload in the command line.

This suggests one of:

• the event handler process is never exiting
• the parent loses ownership after spawning it
• cleanup is only implemented on normal paths and misses turn/event completion paths
• stale helper reaping is missing on app-server or app startup

Why this matters

This can silently accumulate across high-volume codex_exec workloads. In my case, hundreds of stale helpers were left behind, mostly from one workspace. Even if individual helpers are idle, the accumulation makes diagnosis hard and may contribute to degraded Desktop performance when combined with large local state/history.

The command-line payloads also contain large prompt and assistant-message data, so these orphan processes retain potentially large per-turn context in process arguments for much longer than needed.

Suggested fix direction

Treat SkyComputerUseClient event helpers as leased resources rather than fire-and-forget child processes:

• include an owner app-server/session/turn id
• ensure parent-death detection or explicit parent heartbeat
• add a short TTL for turn-ended handlers
• reap stale helper processes on Codex Desktop/app-server startup
• avoid keeping full input-messages / last-assistant-message in long-lived process argv if the helper can outlive the event

The key invariant should be:

A turn-ended helper may outlive the turn briefly, but it should not outlive its owner indefinitely.