You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Reference oracle and required build output share ./executable, causing agents to overwrite the oracle #60
We ran into this a couple of times now, so I wanted to report the following:
Description
Summary
The standard ProgramBench instructions assign two incompatible roles to the same path:
./executable is the reference oracle that the agent must probe.
compile.sh must produce the candidate as ./executable.
A normal iterative build therefore replaces the reference oracle. Every later probe of ./executable invokes the candidate, potentially causing the agent to compare its implementation with itself while believing it is stil observing the reference.
This is not task-specific; it affects any ProgramBench task using this workspace contract.
Reproduction
Start a ProgramBench task and probe the supplied ./executable.
Write an ordinary compile.sh that compiles the candidate with output ./executable.
Run compile.sh during development to test the candidate.
Probe ./executable again.
The fourth step now runs the candidate. The original reference path has been lost.
Execute-only file permissions do not prevent this when the agent can modify the containing workspace directory: the pathname can still be unlinked and replaced.
We observed this independently in two private local trajectories. In one case, the agent later moved ./executable to preserve what it believed was the reference, but the path had already been overwritten by an earlier build. Subsequent reference comparisons were therefore not independent.
No benchmark score or unpublished evaluator behavior is needed to reproduce the problem.
Impact
Iterative candidate builds can destroy the only behavioral oracle.
Later “reference” probes may silently become candidate self-comparisons.
Agents can derive incorrect behavioral contracts from contaminate evidence.
Results may understate agent capability for reasons unrelated to the reconstruction itself.
Suggested fix
Separate the paths in the harness before the agent starts:
Preserve the reference at something like /opt/programbench-reference/executable.
Make that file executable but neither readable nor writable by the agent.
Keep it under a root-owned directory the agent cannot modify or unlink from.
Optionally expose its path through PROGRAMBENCH_REFERENCE_EXECUTABLE.
Reserve workspace-root ./executable exclusively for the candidate produced
by compile.sh.
Update the instructions so all oracle probes use the immutable reference
path.
This retains ProgramBench’s anti-copy/anti-smuggling boundary while allowing the agent to compile and test candidates repeatedly.
A prompt-only instruction telling the agent to move the reference before building would reduce the problem, but enforcing separation in the harness is more reliable.
Expected behavior
The reference oracle remains independently executable for the entire inference trajectory, while compile.sh can freely recreate ./executable as the candidate submission.
We hit this too, in a 300-run study on 20 tasks with zeroshot driving Codex CLI (https://theopenengine.com/blog/review-loop/). With the task unmodified, builders overwrote ./executable, and in our build-and-check loop the checkers were left with only the README, which contradicts the binary in places, so the loop gained nothing over a single run.
What worked: at image build time, move the reference to /reference/executable in a root-owned directory the agent can execute from but can't overwrite, move or delete, and point the task statement there. Agents still build their own ./executable at the upstream path. Implementation: benchmarks/programbench/agent/prepare-task.py on the benchmark/programbench branch of the-open-engine/zeroshot.
The runner now moves the oracle before the first agent step to /opt/programbench-reference/executable using a root Docker exec, sets the directory/file modes to 0711/0111, removes the workspace copy, exposes PROGRAMBENCH_REFERENCE_EXECUTABLE, and reserves workspace ./executable for candidate builds.
Validation includes a live Docker regression and a real published ProgramBench image. As the unprivileged agent user:
oracle execution succeeds;
reading, deleting, and replacing the oracle fail;
creating and executing candidate ./executable succeeds independently.
The ProgramBench repository itself currently handles task discovery and post-inference evaluation; the public inference setup and prompt live in mini-SWE-agent, so that is where the enforceable baseline change lands. Other inference harnesses will need the same pre-agent separation, or the reference path should eventually be baked into refreshed task images.
Activity
EivMeyer commentedon Oct 19, 2026
We hit this too, in a 300-run study on 20 tasks with zeroshot driving Codex CLI (https://theopenengine.com/blog/review-loop/). With the task unmodified, builders overwrote ./executable, and in our build-and-check loop the checkers were left with only the README, which contradicts the binary in places, so the loop gained nothing over a single run.
What worked: at image build time, move the reference to /reference/executable in a root-owned directory the agent can execute from but can't overwrite, move or delete, and point the task statement there. Agents still build their own ./executable at the upstream path. Implementation: benchmarks/programbench/agent/prepare-task.py on the benchmark/programbench branch of the-open-engine/zeroshot.
starboy-3 commentedon Oct 27, 2026
I reproduced this in the current published
task_cleanroom_v6image and opened a fix for the public mini-SWE-agent ProgramBench baseline:SWE-agent/mini-swe-agent#1029
The runner now moves the oracle before the first agent step to
/opt/programbench-reference/executableusing a root Docker exec, sets the directory/file modes to0711/0111, removes the workspace copy, exposesPROGRAMBENCH_REFERENCE_EXECUTABLE, and reserves workspace./executablefor candidate builds.Validation includes a live Docker regression and a real published ProgramBench image. As the unprivileged agent user:
./executablesucceeds independently.The ProgramBench repository itself currently handles task discovery and post-inference evaluation; the public inference setup and prompt live in mini-SWE-agent, so that is where the enforceable baseline change lands. Other inference harnesses will need the same pre-agent separation, or the reference path should eventually be baked into refreshed task images.