Keep MCP services alive in Prime runtimes

[eligotts]

Summary

• launch Prime background services through start_background_job() without an additional detached shell
• use exec so the service occupies the SDK-managed job process
• require a live sandbox and translate SDK submission failures to SandboxError

Root cause

PrimeRuntime.run_background() previously ran a nested sh -c "nohup ... &" through the normal command path. That inner shell exited immediately after spawning the service. Verifiers MCP servers enable PR_SET_PDEATHSIG, so the shell's exit could kill the colocated MCP service while leaving the Prime sandbox itself alive.

Submitting exec <service> > <log> 2>&1 as the SDK background job removes that short-lived parent and keeps the service attached to the SDK-managed job for the sandbox lifetime.

This is infrastructure lifecycle hardening only; it does not change evaluation logic, rewards, task behavior, or Worldsims pipelines.

Validation

• uv run ruff check verifiers/v1/runtimes/prime.py — passed
• uv run pre-commit run --all-files — passed
• pre-push Ruff, formatting, and ty hooks — passed

Note

Keep MCP services alive in Prime runtimes using SDK background jobs

• Rewrites PrimeRuntime.run_background in prime.py to call self._client.start_background_job instead of spawning a detached shell via sh -c 'nohup ... &'.
• The new implementation constructs an exec <argv> command with stdout/stderr redirected to the provided log file, passing working_dir and env to the SDK call.
• Behavioral Change: run_background now raises SandboxError immediately if the client or sandbox ID is missing, or if the SDK call fails.

Changes since #2261 opened

• Replaced pre-validation guards with exception-based error handling in PrimeRuntime.run_background method [abad82c]

^{Macroscope summarized c357ba1.}

---

Note

Medium Risk
Changes only Prime sandbox background service lifecycle, but mis-launch or job API behavior could break colocated MCP/tool servers during eval rollouts.

Overview
Prime run_background no longer spawns a detached nohup shell that exits right after starting colocated tool/MCP servers.

It now submits exec <argv> with stdout/stderr redirected to the log path through start_background_job, with working_dir and env passed to the SDK, so the service runs as the SDK-managed job process for the sandbox lifetime. That avoids a short-lived parent shell exiting and (with MCP servers using PR_SET_PDEATHSIG) tearing down the child while the sandbox stays up.

SDK submission failures are wrapped as SandboxError with a prime background launch failed message instead of checking exit code from a nested sh -c run.

^{Reviewed by Cursor Bugbot for commit abad82c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[mikasenghaas]

remove comment

[mikasenghaas]

remove this conditional