Codex Autoresearch
A Codex plugin that chooses between a direct fix and measured experiments, then records which attempts helped and why
- Status
- v3.0.0 released
- Works in
- Local Git repositories
- Distribution
- Codex plugin marketplace
- License
- Apache 2.0
Overview
What it is
Codex Autoresearch helps decide whether an improvement needs a direct fix or a sequence of measured experiments. Version 3.0.0 routes ordinary implementation work directly and uses an experiment loop when a useful measurement can guide repeated attempts.
You give it a goal, a benchmark, correctness checks, and an edit boundary. It measures a baseline, runs small attempts, keeps the useful results separate from dead ends, and writes a durable ledger that another session can resume without reconstructing the story.
The loop works for repeatable performance metrics and for source-backed quality-gap checklists. It is intentionally local and Git-aware; the optional dashboard reads the evidence but never becomes the control plane.
Capabilities
What it does
- 01
Checks whether experiments fit
Uses repeated experiments when a benchmark or accepted quality checklist can guide the work. One-shot fixes, reviews, and writing stay direct.
- 02
Starts with a boundary
Records the goal, metric, benchmark, checks, time or attempt budget, and the exact files an experiment may change.
- 03
Establishes a baseline
Measures the current result before changing code and checks that the benchmark can be trusted.
- 04
Makes each attempt reviewable
Runs one measured attempt at a time and records the command, result, score, changed files, and notes.
- 05
Remembers what worked
Keeps improvements, discards regressions, and records the reasoning in a durable project ledger. Retries stop at the limit agreed for the experiment.
- 06
Hands off deliberately
Shows review-branch candidates before changing branches, so finalization begins as a read-only decision.
- 07
Makes the evidence visible
Offers an optional read-only dashboard for metric history, blockers, next actions, and finalization state.
Under the hood
Engineering decisions
- Hardest constraint
Make the loop resumable without hiding state
An experiment can span several attempts, Git states, processes, and Codex sessions. The difficult part is preserving enough state to resume safely without letting old measurements or half-finished mutations pass as current evidence.
- Design decision
Keep the ledger, not the dashboard, in charge
The append-only local ledger is authoritative; the dashboard only reads and explains it. That makes parsing and recovery stricter, but a browser tab can never become a second control plane or the only place the experiment still makes sense.
- Verification
Test the decision loop end to end
Every candidate has to beat its declared baseline and pass correctness checks before it is kept. The plugin’s operator-task benchmark and hostile-workflow tests exercise the same decisions across setup, runs, recovery, and finalization.
Project links