fix(v1): serialize restricted borrowed runtimes

[xeophon]

Overview

Serialize borrowed rollouts that share a network-restricted runtime while preserving concurrency for unrestricted runtimes.

Details

Restricted runtimes expose one sandbox-wide network policy. Concurrent borrowers can otherwise replace that shared policy during another rollout, so a borrower now holds a runtime-level lock from setup through cleanup.

The lock is released from both normal close and abort paths, including partial setup failures. Unrestricted borrowed runtimes keep their existing concurrent behavior.

---

Note

Medium Risk
Changes rollout teardown ordering and concurrency for shared restricted sandboxes; incorrect lock release could deadlock concurrent borrowers, but release paths mirror existing cleanup.

Overview
Borrowers of a network-restricted runtime now take a shared borrow_lock for the whole rollout so concurrent agents cannot race on sandbox-wide network policy during setup (with_env / prepare_execution).

A runtime-level asyncio.Lock is added in Runtime.__init__. During Rollout.open, if the rollout borrows a restricted runtime, it acquires that lock before applying per-task env; _borrow_lock tracks ownership. Release happens in both abort() (including partial setup) and close() via finally, so failures and cancellations do not leave the lock held. Unrestricted borrowed runtimes are unchanged and can still run concurrently.

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ff7b988e9b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Avoid waiting for the borrow lock while holding the agent gate

When an episode starts a second interaction or run on the same restricted borrowed runtime while the first interaction is open between turns, the second operation holds _EpisodeAgent._gate and blocks here. The first interaction already owns borrow_lock, but its next turn() or close() must reacquire that gate (agent.py:173 and agent.py:227); with the default max_concurrent_agents=1, neither can progress. Acquire the serialization lock before the agent gate, or release the gate while waiting for it.

Useful? React with 👍 / 👎.

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit ff7b988. Configure here.}

[cursor]

Close can skip lock release

High Severity

close releases _borrow_lock only after several cancellable awaits in the same finally, and suppress(Exception) does not swallow CancelledError. Cancellation mid-cleanup skips the release. abort correctly nests release in its own finally, but callers such as interaction that tear down via close alone can leave borrow_lock held forever and stall every later restricted borrower.

Additional Locations (2)

• verifiers/v1/rollout.py#L497-L533
• verifiers/v1/rollout.py#L441-L445

 

^{Reviewed by Cursor Bugbot for commit ff7b988. Configure here.}

[cursor]

Open can leak borrow lock

Medium Severity

After borrow_lock is acquired, open's except Exception path calls fail, which can re-raise when a borrowed runtime was stopped, instead of returning false or calling abort. That exception leaves open with the lock still held. interaction awaits open outside its cleanup try/finally, so neither close nor abort runs and the shared lock is leaked.

Additional Locations (1)

• verifiers/v1/rollout.py#L335-L338

 

^{Reviewed by Cursor Bugbot for commit ff7b988. Configure here.}

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR changes production concurrency and cleanup behavior for restricted borrowed runtimes by holding a shared lock across the rollout lifecycle. Unresolved comments identify plausible deadlock and lock-leak paths, requiring human review before merge.

Not approved because:

• Monthly spending limit reached (workspace setting). Approvability relies on correctness review in order to determine eligibility

^{Review your spending limits in Billing settings. You can add or adjust custom eligibility rules. Learn more.}