The Codex rows in the leaderboard were produced with this adapter, not with Harbor's
built-in codex agent. Harbor's agent installs the Codex CLI and registers MCP servers,
but it has no way to point Codex at the gateway that serves these models; this adapter
writes that provider block into $CODEX_HOME/config.toml and delegates everything else.
The file is byte-identical to the adapter the reported runs used:
sha256 2859af086445f97fcfb328c0fa4a64aa221d8e9cfb69e8e769fecfb9818abdd4
Editing it changes the agent under test. If you must change it, record the new hash in the run receipt and do not compare the result to rows produced with this one.
The adapter reads config.toml from the directory it lives in and refuses to start when the
provider block does not select the provider it names, read the env key it names, use
wire_api = "responses", or end base_url in /v1. The block is deployment state and is not
shipped with the repository: build it in the run directory from the adapter's _PROVIDER_NAME,
_KEY_NAME and _build_register_skills_command.
STAGE=/path/to/run/auth/codex
mkdir -p "$STAGE"
cp scripts/agents/sciencevision_codex.py "$STAGE/"
# write "$STAGE/config.toml" with the provider block the adapter validates
chmod 600 "$STAGE/config.toml"The gateway URL and the API key stay out of the repository. Pass the key through the environment, never on the command line:
export UNIAPI_KEY_SCIENCEVISION=...
export PYTHONPATH="/path/to/repo:$STAGE"
harbor run --path <task-tree> \
--agent sciencevision_codex:ScienceVisionUniAPICodex \
--model gpt-6.1-sol \
--ak reasoning_effort=max_ALLOWED_MODELS in the adapter is the model allow-list. A model outside it raises at
construction time rather than silently running a different agent.
Task timeouts, retries, concurrency, MCP registration and image digests are recorded in
docs/evaluation.md. The receipt from a compatible
run records the adapter hash, model, route, reasoning effort, image id and digest, and the
timeout multipliers.