| 1 | # Codewhale harness for Verifiers |
| 2 | |
| 3 | This local package runs Codewhale v0.9.4 as a Prime Intellect Verifiers v0.2 |
| 4 | harness. Verifiers owns the task, rubric, model interception, and rollout |
| 5 | runtime. Codewhale owns the coding-agent loop and its tools. |
| 6 | |
| 7 | The adapter is intentionally pre-publication. It is checked in and tested with |
| 8 | Codewhale, but it is not uploaded to PyPI or the Prime Environments Hub. |
| 9 | |
| 10 | ## What it guarantees |
| 11 | |
| 12 | - Every rollout gets an isolated `CODEWHALE_HOME`; ambient Codewhale sessions, |
| 13 | project config, memory, and credentials are not reused. |
| 14 | - Model traffic is pinned to Verifiers' OpenAI-compatible interception endpoint |
| 15 | with the per-rollout session secret. The secret is kept in the child |
| 16 | environment and never placed in argv or receipt metadata. |
| 17 | - Verifiers toolsets are written as a rollout-local MCP config. |
| 18 | - Codewhale runs non-interactively with telemetry disabled. It never runs setup |
| 19 | and does not require a telemetry key. |
| 20 | - Local subprocess evaluation stays `workspace-write`; Docker, Prime, and Modal |
| 21 | use their already-isolated runtime as Codewhale's external sandbox. Neither |
| 22 | path authorizes Codewhale's sandbox-elevation flag. |
| 23 | - Successful runs must end with the exact Codewhale exec-stream v1 terminal |
| 24 | receipt. A bounded, non-content receipt is copied to |
| 25 | `trace.info["codewhale"]`; malformed or incomplete streams fail closed. |
| 26 | |
| 27 | ## Install locally |
| 28 | |
| 29 | From the Codewhale checkout: |
| 30 | |
| 31 | ```bash |
| 32 | uv pip install -e integrations/verifiers-codewhale |
| 33 | ``` |
| 34 | |
| 35 | Then select the package as a Verifiers v1 harness: |
| 36 | |
| 37 | ```bash |
| 38 | uv run eval <taskset> \ |
| 39 | --harness.id codewhale-harness \ |
| 40 | --harness.version 0.9.4 \ |
| 41 | --harness.runtime.type docker |
| 42 | ``` |
| 43 | |
| 44 | The default setup downloads all three release runtime companions from |
| 45 | the pinned Codewhale tag and verifies each byte against the release checksum |
| 46 | manifest. Before v0.9.4 is published, use an installed candidate for a local |
| 47 | subprocess rollout: |
| 48 | |
| 49 | ```bash |
| 50 | uv run eval <taskset> \ |
| 51 | --harness.id codewhale-harness \ |
| 52 | --harness.version 0.9.4 \ |
| 53 | --harness.binary-path /absolute/path/to/codewhale \ |
| 54 | --harness.runtime.type subprocess |
| 55 | ``` |
| 56 | |
| 57 | `binary_path` is a path inside the selected runtime. A host path is therefore |
| 58 | appropriate only for the subprocess runtime unless it has also been mounted or |
| 59 | installed into a container/sandbox. |
| 60 | |
| 61 | ## Authority boundary |
| 62 | |
| 63 | The adapter opts into Codewhale's headless auto-tool path so ordinary coding |
| 64 | work can proceed. Explicitly denied tools, protected actions, and sandbox |
| 65 | elevation remain fail-closed. A headless request that genuinely needs human |
| 66 | input must terminate with a typed input-required failure; it must never wait on |
| 67 | an invisible prompt. |
| 68 | |
| 69 | No provider or Prime credentials are required by this repository's tests. |
| 70 |