Summary

Background exec runs launched with pty: true appear to rely on in-memory-only ownership. If the gateway restarts or otherwise loses run state, the PTY-backed worker tree can remain alive while OpenClaw no longer knows about it. In practice this looks like orphaned Codex/OMX/MCP helper trees continuing to consume memory even when process list reports no running sessions.

Observed behavior

On a live macOS install, I observed repeated helper-process families rooted under a long-lived Codex worker, including:

• repeated npm exec mcp-remote https://mcp.firecrawl.dev/...
• repeated npm exec mcp-remote https://mcp.exa.ai/mcp
• repeated npm exec mcp-remote https://api.ref.tools/mcp
• repeated OMX sidecars such as:
  • oh-my-codex/dist/mcp/code-intel-server.js
  • trace-server.js
  • state-server.js
  • memory-server.js
  • team-server.js

At one point the repeated remote MCP fingerprints showed 12 copies each for Firecrawl / Exa / Ref, all under a Codex-rooted worker tree, while OpenClaw runtime state did not show a corresponding tracked run:

• ~/.openclaw/subagents/runs.json was empty ({"version":2,"runs":{}})
• process(action="list") returned No running or recent sessions.

That combination strongly suggests a live worker tree can outlive tracked ownership.

Why this looks like an OpenClaw lifecycle bug

The supervisor implementation currently documents orphan reconciliation as a deliberate no-op:

• src/process/supervisor/supervisor.ts
  • reconcileOrphans(): Promise<void>
  • comment: Deliberate no-op: this supervisor uses in-memory ownership only. Active runs are not recovered after process restart in the current model.

Relevant launch-path differences:

Generic exec PTY path

• src/agents/bash-tools.exec-runtime.ts
  • runExecProcess(...)
  • when usePty is true, this spawns with mode: "pty"
• src/agents/bash-tools.exec.ts
  • background runs can end up with effectiveTimeout = null when backgroundTimeoutBypass applies
• I do not see the same explicit scope-replacement semantics here that the CLI-runner path uses

CLI-runner path

• src/agents/cli-runner/execute.ts
  • uses mode: "child"
  • passes scopeKey
  • passes replaceExistingScope: Boolean(useResume && scopeKey)
  • passes noOutputTimeoutMs

Process visibility path

• src/agents/bash-tools.process.ts
  • process list is driven from in-memory session/registry state
• src/agents/bash-process-registry.ts
  • running/finished sessions are also in-memory maps

So if the gateway restarts, reloads, or otherwise loses that state, OpenClaw can truthfully report no running sessions while the actual PTY child tree is still alive.

Why this matters

This can produce a bad failure mode for long-lived Codex/OMX workers launched through generic background PTY exec:

1. worker is launched and tracked only in memory
2. gateway restarts or loses run state
3. worker tree survives
4. OpenClaw forgets it
5. Codex/OMX inside that still-living worker can reopen/reconnect MCP helpers over time
6. helper processes accumulate and total memory climbs

Even if Codex/OMX has its own cleanup bug, OpenClaw currently appears to make that failure mode much worse by allowing PTY-backed background workers to become unowned.

Proposed fix direction

Minimum viable fix

1. Persist active background exec metadata for PTY-backed runs
   • run id
   • pid
   • scope key
   • session id
   • backend id
   • started at
2. Implement real reconcileOrphans() on startup
3. On startup, kill or re-register stale PTY-backed runs from a previous gateway epoch
4. Remove persisted records on normal finalize

Additional hardening

1. Add explicit scope replacement for long-lived PTY background runs where a stable scope exists
2. Add a default noOutputTimeoutMs / watchdog for background PTY runs instead of letting them drift forever when no explicit timeout is set
3. Add lifecycle logging around:
   • PTY spawn
   • scope replacement / cancellation
   • finalize
   • orphan sweep results

Files / code points inspected

• src/process/supervisor/supervisor.ts
• src/process/supervisor/adapters/pty.ts
• src/process/supervisor/adapters/child.ts
• src/process/supervisor/registry.ts
• src/agents/bash-tools.exec-runtime.ts
• src/agents/bash-tools.exec.ts
• src/agents/bash-tools.process.ts
• src/agents/cli-runner/execute.ts
• src/agents/bash-process-registry.ts

Important note

I am not claiming the entire leak is only OpenClaw. It is possible Codex/OMX is also failing to clean up helper bundles inside a still-running worker. But OpenClaw currently appears to have a real ownership / cleanup gap for background PTY exec runs that can leave those workers alive but untracked after restart or session-state loss.

If helpful, I can open a follow-up PR once there is agreement on whether the preferred behavior is:

• kill stale PTY exec orphans on startup, or
• attempt to reattach / re-register them.