[Bug]: macOS Orca Helper leaves agent terminal processes running after app/runtime is closed

Operating system

macOS 15.5 (24F74), arm64

Orca version

1.4.126

Details

Summary

After closing Orca on macOS, orca status --json reported the app/runtime/graph as not running, but an Orca Helper daemon process remained alive and continued owning many terminal/agent descendants. The leftover process tree included claude, codex, amp, agy, cursor-agent, and their MCP/helper children.

This looks like the same lifecycle class as #3191, but reproduced on macOS with Orca Helper ... daemon-entry.js and login/zsh PTY sessions.

What happened

After the Orca UI was closed:

{
  "app": { "running": false, "pid": null },
  "runtime": { "state": "not_running", "reachable": false },
  "graph": { "state": "not_running" }
}

However, the process tree still had:

/Applications/Orca.app/Contents/Frameworks/Orca Helper.app/Contents/MacOS/Orca Helper \
  /Applications/Orca.app/Contents/Resources/app.asar.unpacked/out/main/daemon-entry.js \
  --socket ~/Library/Application Support/orca/daemon/daemon-v18.sock ...

Under that helper were many pseudo-terminal sessions of the form:

Orca Helper
  -> /usr/bin/login -flpq <user> /usr/bin/env SHELL=/bin/zsh /bin/zsh -l
    -> /bin/zsh -l
      -> claude --dangerously-skip-permissions
      -> codex --dangerously-bypass-approvals-and-sandbox
      -> amp --dangerously-allow-all
      -> agy --dangerously-skip-permissions
      -> cursor-agent ...
      -> npm/uv/node MCP helper processes

I counted roughly 189 descendants under the stale Orca Helper before cleanup. Since the Orca runtime was unavailable, orca terminal list --json could not manage or close them:

runtime_unavailable: Could not read Orca runtime metadata ... Start the Orca app first.

Impact observed

These stale agents were not zombies; they were sleeping/live processes. They kept memory and swap pressure around after the app was closed.

Before manually killing the stale agent processes:

/System/Volumes/VM: 9.0Gi
vm.swapusage: total = 9216.00M, used = 8388.94M
available disk: 34Gi

After killing the agent processes and their empty login/zsh PTY shells:

/System/Volumes/VM: 4.0Gi
vm.swapusage: total = 4096.00M, used = 3219.06M
available disk: 39Gi

There was also one smaller deleted file held by the remaining helper itself:

Orca Helper ... /private/var/folders/.../com.stablyai.orca.ShipIt.../Electron Framework

That was only ~188 MB, not the main issue; the main issue was the orphaned managed agent tree and VM/swap pressure.

How to reproduce

1. On macOS, start several Orca-managed agent terminals, e.g. Claude/Codex/Amp/Agy/Cursor Agent sessions.
2. Close/quit the Orca UI.
3. Run:

orca status --json
pgrep -fl 'Orca Helper|claude --dangerously|codex --dangerously|amp --dangerously|agy --dangerously|cursor-agent'

4. If an Orca Helper ... daemon-entry.js process remains, inspect its descendants:

root=<Orca Helper PID>
pgrep -P "$root"
# recursively inspect descendants, or use ps to show login -> zsh -> agent process chains

Expected behavior

Either:

• Closing/quitting Orca terminates the full process tree it owns: helper daemon, PTY login/zsh shells, agent CLIs, and helper/MCP children; or
• If keeping background agents alive is intentional, Orca should expose that state clearly after the UI closes and provide a reliable UI/CLI action such as "stop all background agents" / orca terminal stop --all that works even when the main runtime is not available.

Actual behavior

The UI/runtime can be gone while an Orca Helper daemon and its managed agent terminal process tree remain running. Once in this state, the normal Orca CLI reports the runtime as unavailable, so the user has to discover and kill the process tree manually.

Related

• #3191 reports a similar lifecycle bug on Windows: Orca/spawned Codex/agent children keep running after window close.