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.
With kind regards
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:
./executableis the reference oracle that the agent must probe.compile.shmust produce the candidate as./executable.A normal iterative build therefore replaces the reference oracle. Every later probe of
./executableinvokes 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
./executable.compile.shthat compiles the candidate with output./executable.compile.shduring development to test the candidate../executableagain.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
./executableto 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
Suggested fix
Separate the paths in the harness before the agent starts:
/opt/programbench-reference/executable.PROGRAMBENCH_REFERENCE_EXECUTABLE../executableexclusively for the candidate producedby
compile.sh.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.shcan freely recreate./executableas the candidate submission.With kind regards