PR #69276: fix(cron): dispose bundled-MCP subprocesses after isolated cron agent runs (#68623)

• Repository: openclaw/openclaw
• Author: stainlu
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/69276

Description (problem / solution / changelog)

Summary

• Problem: When mcp.servers is configured and a cron job spawns an isolated agent session that uses an MCP tool, the MCP child subprocess (e.g. Lightpanda) is spawned fresh every run and never terminated. Each cron fire leaks one MCP process.
• Why it matters: A daily cron job that touches an MCP tool accumulates one orphaned process per day indefinitely. Reporter's Lightpanda workload demonstrates the leak on v2026.4.9 and the gap persists on current main.
• What changed: Pass cleanupBundleMcpOnRunEnd: true into the runEmbeddedPiAgent call in the isolated-cron executor. The embedded runner already has the disposal hook (disposeSessionMcpRuntime(params.sessionId)) wired at src/agents/pi-embedded-runner/run.ts:2047-2053, but it is opt-in via cleanupBundleMcpOnRunEnd, and the cron executor never opted in.
• What did NOT change (scope boundary): The CLI-provider cron path at runCliAgent (src/agents/cli-runner.ts:123) already disposes its prepared backend in its own finally block — that path was not leaking. This PR only plugs the gap in the embedded-Pi cron path.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Gateway / orchestration
• Integrations

Linked Issue/PR

• Closes #68623
• This PR fixes a bug or regression

Root Cause

• Root cause: src/cron/isolated-agent/run-executor.ts:144 calls runEmbeddedPiAgent({ ... }) without cleanupBundleMcpOnRunEnd. The dispose hook in the embedded runner is gated on that flag (default false), so for isolated cron turns the MCP runtime for that sessionId is never torn down. The subprocess spawned by bundled-MCP prep stays alive after the turn completes, and the next cron fire spawns a new one without disposing the previous.
• Missing detection / guardrail: No regression test existed for the cron executor's MCP disposal wiring. The embedded-runner dispose path has coverage (src/agents/pi-embedded-runner.e2e.test.ts:486-535), but nothing asserted that the cron entrypoint opts into it.
• Contributing context: The CLI-path cleanup in src/agents/cli-runner.ts:123 works differently (it runs the preparedBackend.cleanup in a finally), so manual testing of CLI-backed cron runs could give a false sense of coverage.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: new src/cron/isolated-agent/run.mcp-cleanup.test.ts via the existing run.test-harness.ts
• Scenario the test should lock in: runCronIsolatedAgentTurn must pass cleanupBundleMcpOnRunEnd: true (and trigger: "cron") to runEmbeddedPiAgent. Captures the exact params object passed to the mocked embedded runner.
• Why this is the smallest reliable guardrail: The bug is a single missing flag on a single call site. An assertion on the call args of runEmbeddedPiAgentMock is enough to catch any future regression that drops the flag.

User-visible / Behavior Changes

None user-visible. Removes a silent memory leak on cron + MCP workloads.

Diagram

Before:
isolated cron fire → runEmbeddedPiAgent({ ...no cleanupBundleMcpOnRunEnd })
                   → spawn MCP subprocess for sessionId
                   → run completes
                   → dispose hook gated on flag → no-op
                   → next cron fire → new MCP subprocess, previous one orphaned

After:
isolated cron fire → runEmbeddedPiAgent({ ..., cleanupBundleMcpOnRunEnd: true })
                   → spawn MCP subprocess for sessionId
                   → run completes
                   → disposeSessionMcpRuntime(sessionId) → subprocess terminated
                   → next cron fire → fresh session, clean slate

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No (subprocess lifecycle only)
• Data access scope changed? No

Repro + Verification

Environment

• OS: Linux (Debian-derived in reporter's case)
• Runtime: OpenClaw gateway v2026.4.9 (bug persists on current main)
• Model/provider: any embedded-Pi provider (non-CLI)
• Integration: MCP server registered via mcp.servers.<name>.command
• Relevant config: sessionTarget: "isolated" cron with payload kind: "agentTurn" that calls an MCP tool

Steps

1. Configure mcp.servers.lightpanda with a command pointing at a Lightpanda binary.
2. Register a cron job with sessionTarget: "isolated" whose payload calls a Lightpanda MCP tool.
3. Let the cron fire a few times.
4. Observe with ps or pgrep lightpanda that one Lightpanda process remains per cron fire, never cleaned up.

Expected

Each isolated cron turn disposes its MCP runtime on completion. pgrep lightpanda stays at 0 (or at the long-lived main-session count, unchanged across cron fires).

Actual (before fix)

One orphaned Lightpanda per cron fire, growing indefinitely until manual kill.

Evidence

• Failing test/log before + passing after

New test run.mcp-cleanup.test.ts asserts runEmbeddedPiAgent receives cleanupBundleMcpOnRunEnd: true. Would have failed on current main.

Human Verification

• Verified scenarios:
  • pnpm tsgo clean on changed files
  • pnpm test src/cron/isolated-agent/run.mcp-cleanup.test.ts — passes
  • pnpm oxlint src/cron/isolated-agent/run-executor.ts src/cron/isolated-agent/run.mcp-cleanup.test.ts — 0 warnings, 0 errors
• Edge cases checked:
  • The CLI-provider cron path (earlier branch at line ~136 in the same file) already disposes via runCliAgent's own finally block; no change needed there.
  • The dispose call swallows errors (.catch(log)), so a dispose failure never cascades into the agent turn result.
  • cleanupBundleMcpOnRunEnd: true is the same flag the gateway openclaw agent command uses for local-only runs (src/commands/agent-via-gateway.ts:185), confirming the intended disposal semantic.
• What I did NOT verify:
  • Live Lightpanda-driven repro. The unit-level assertion + the traced dispose path is sufficient evidence; the hook is already exercised by existing e2e tests in src/agents/pi-embedded-runner.e2e.test.ts.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

No new config surface. A single run-time flag was flipped on an already-existing call path.

Risks and Mitigations

• Risk: disposeSessionMcpRuntime could disrupt a shared MCP runtime that other concurrent sessions depend on.
  • Mitigation: the dispose call is keyed on params.sessionId, which for isolated cron turns is uniquely owned by the turn's cron session entry (params.cronSession.sessionEntry.sessionId). It cannot collide with a main session's runtime. The same pattern is already used safely by the openclaw agent --local path.

Changed files

• src/cron/isolated-agent/run-executor.ts (modified, +6/-0)
• src/cron/isolated-agent/run.mcp-cleanup.test.ts (added, +99/-0)