Reference oracle and required build output share ./executable, causing agents to overwrite the oracle

Start by inspecting the ProgramBench harness and standard instructions around compile.sh, ./executable, and the proposed PROGRAMBENCH_REFERENCE_EXECUTABLE entry point. Reproduce the overwrite sequence, then verify that repeated candidate builds leave the reference independently executable and reserve ./executable for the candidate.

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:

1. ./executable is the reference oracle that the agent must probe.
2. 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

1. Start a ProgramBench task and probe the supplied ./executable.
2. Write an ordinary compile.sh that compiles the candidate with output
   ./executable.
3. Run compile.sh during development to test the candidate.
4. 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