Secure Pool harness binary cache

[xeophon]

Motivation

• Prevent a malicious Pool run from poisoning a shared cached executable and enabling persistent code execution in later rollouts by removing the predictable /tmp cache.
• Ensure the Pool CLI is installed into a verifier-owned, per-rollout workspace and that install checks/locks are properly quoted and scoped.

Description

• Change the cache location from "/tmp/vf-pool-{version}" to a per-rollout path at ".vf-pool/bin-{version}" by updating POOL_DIR in verifiers/v1/harnesses/pool/harness.py.
• Harden the setup step by quoting generated paths with shlex.quote and using a rollout-local lock file (install.lock) so installation and existence checks operate only inside the rollout workspace.
• Add a comment documenting the security rationale that a shared /tmp cache would let one rollout tamper with the executable trusted by later rollouts.

Testing

• Ran uv run pre-commit install which completed successfully in the environment where it could run.
• Ran uv run ruff check --fix verifiers/v1/harnesses/pool/harness.py and python -m py_compile verifiers/v1/harnesses/pool/harness.py, both of which passed for the modified file.
• Pre-commit hooks that require fetching external packages failed in this environment due to network tunnel issues, so full hook execution could not be completed here.

---

Codex Task

---

Note

Medium Risk
Touches the Pool harness install/execution path, which is security-sensitive because rollouts can run with model-approved tools. The change is small and clearly reduces cross-rollout binary poisoning risk.

Overview
Hardens Pool binary install so a malicious rollout cannot poison a shared executable used by later runs.

Moves the cached pool binary from shared /tmp/vf-pool-{version} to a per-rollout path at .vf-pool/bin-{version}, and scopes the install lock to that workspace. Also quotes install paths with shlex.quote and documents why a shared /tmp cache was unsafe.

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

Note

Move Pool binary cache from /tmp to workspace-local .vf-pool/bin-{version} and shell-quote paths

• Changes POOL_DIR in harness.py from /tmp/vf-pool-{version} to .vf-pool/bin-{version} relative to the current workspace, scoping the cache per project.
• Shell-quotes all dynamic paths in PoolHarness.setup (binary path, install directory, lockfile) to handle directories with spaces or special characters.
• Behavioral Change: the Pool binary is no longer shared across workspaces via /tmp; each workspace maintains its own cache directory.

^{Macroscope summarized 83d78c2.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 83d78c2f9d

ℹ️ 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]

Isolate the cache from sibling subprocess rollouts

For Pool runs on SubprocessRuntime, this relative path does not create verifier-owned isolation: every rollout workdir is an enumerable /tmp/vf-* directory and its processes run as the same host user (verifiers/v1/runtimes/subprocess.py:43-55). Since Pool runs with its sandbox disabled and completed run_program descendants are not tracked by cleanup() (which only terminates _background, lines 105-113), a malicious rollout can leave a detached watcher that overwrites .vf-pool/bin-*/pool in subsequently created workdirs before launch. The persistent cross-rollout code-execution issue therefore remains for the subprocess runtime; use OS-level isolation/a dedicated user or reject that runtime for Pool rather than treating a workspace-relative path as a security boundary.

Useful? React with 👍 / 👎.

[macroscopeapp]

Approvability

Verdict: Needs human review

This security-focused change modifies binary cache isolation to prevent cross-rollout tampering. An unresolved P1 review comment questions whether the approach achieves its security goal for SubprocessRuntime, and security-sensitive code warrants human review.

^{You can customize Macroscope's approvability policy. Learn more.}