Skip to content

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

Description

@Kibrahacha

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions