feat: add Harbor eval runner - #9138
Conversation
898b0f3 to
bb81748
Compare
bb81748 to
7f316b3
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f316b345e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
7f316b3 to
964598b
Compare
DOsinga
left a comment
There was a problem hiding this comment.
Hey! The core idea here is solid — the agent adapter in goose_binary.py is the real substance and handles the container setup well (profile routing, non-root ownership, secrets handling).
The main feedback: config.py and its tests feel like generated blubber. You have a 156-line module whose entire job is building a dict and writing it as JSON, with a dataclass that duplicates argparse, single-use 3-line helpers extracted into named functions, a separate validator, a separate writer — all called exactly once. Then 130 lines of tests asserting that the mapping function maps correctly.
Just inline it into runner.py. Parse args, build the dict, write it. That's 30 lines, not a module. Kill the tests that are just asserting the code is implemented the way it's implemented (validation raises ValueError, static method returns a string, write_text writes a file). Keep the tests that cover actual logic: resume detection, mismatch handling, the chown fix, the heredoc avoidance.
Ask yourself for each abstraction: is this called from more than one place? Does it have a branch worth testing? If no to both, inline it.
e50a0b9 to
aee0a95
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: aee0a9541e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
0f43739 to
31c1d91
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 31c1d91ba7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
31c1d91 to
8f0c80f
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8f0c80f83f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
8f0c80f to
2ec561a
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 2ec561a2ff
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
49670a5 to
f1c3f83
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: f1c3f83e3a
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
f1c3f83 to
245883d
Compare
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 245883d186
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
245883d to
82fbbfc
Compare
* main: (38 commits) [Prompt injection mitigation] Update pattern-based detection to reduce FPs (#9350) feat: add Harbor eval runner (#9138) chore(release): bump version to 1.35.0 (minor) (#9150) Include request URL in provider error messages (#9232) fix(databricks): ensure parallel tool image responses don't interleave tool results (#9241) Surface resolved Databricks model metadata (#9206) Add unified thinking effort control across all providers (#9242) Add Linux desktop Vulkan packages (#9323) chore: update canonical model registry (#9331) feat: slash commands (built-in, skill, recipe) in acp server (#9238) feat: add /goal command for agent self-evaluation before finishing (#9069) Feat/summon subagent instructions (#9325) feat: open-plugins generalization + skills (#9112) feat(hooks): PreToolUse denial (#9304) Add support for optional api_key configuration for declarative openai-engine providers (#9202) fix(cli): use plain '> ' prompt instead of goose emoji (#9305) flag for login shell PATH (#9313) Remove popular chat topics from new chat screen (#9307) fix: stop killing goosed when a window closes (#9302) Remove vendored Windows binaries (#9318) ...

Summary
This is another attempt at adding a way to run Terminal-Bench 2.0 on goose locally.
The approach in #9092 mostly worked, but was a little flawed in that goose still kinda thought it was running outside the benchmark container; even though we gave it tools that took action within the container, its system prompt would still think it was running outside the container (i.e., the "current directory" would be one outside the container). Also, the idea of needing to create custom MCP servers for every file tool that we want to give goose as part of a benchmark doesn't seem like the best long-term approach; ideally it should just work, without needing any additional work for new tools.
So here's another approach. I wouldn't say it's strictly better than the previous one, but the nice thing is that we're not doing anything janky to get tool calls to work within the container. Here, we just take in an already built goose Linux executable as input to a script, and use it to run any Harbor task, which includes Terminal-Bench 2.0. The main downside is that this requires a build step.
For now, this is a script that's separate from the CLI, in the
evalsfolder, more in the style of the existing "open model gym". If/when we do want to add this to the CLI as agoose benchcommand, that should be fairly easy (only thing is we'll need to bundle the Python files into the executable usinginclude_str!or something). Whether that should be done is a different question, which is why I haven't done this as part of this PR. (For example, one could argue benchmarking is purely a dev tool that shouldn't be exposed to end users through the CLI.)Testing
I'm currently doing a run of Terminal-Bench using Qwen3.6-27B as the model (via OpenRouter), and the tasks are running successfully (the failures that I do see seem to be model failures and not an issue with how we're running the benchmark)
To test this yourself, the following should work:
Related Issues
N/A
Screenshots/Demos (for UX changes)
N/A