oathe / harnesses / codex
Open Codex on work that's already underway.
Most people open Codex because something else stopped. A limit, a crash, a closed laptop. The usual next step is pasting a transcript and hoping the summary is honest.
Oathe gives Codex the work instead. Your task arrives claimed, with what's already done, what's left, and the test that decides whether it's finished.
Start
Node 22 or newer.
npm install -g @oathe/oathe
cd your-project
oathe init # onboards your harnesses
oathe codex # normal Codex session, board firstCodex behaves exactly as it does on its own — same model selection, same approval modes, same sandbox. Oathe runs underneath it.
What Codex knows when it opens
Not a transcript. A compiled view of the work.
The previous agent's summary of its own work is an opinion, and a generous one. Codex gets the record instead: the task, who claimed it, the checkpoints, the evidence, and the definition of done that was fixed before anyone started. It reads the diff and reruns the test rather than taking the last agent's word.
Came from Claude Code or Cursor? Same task, same board.
Codex has limits too
Weekly caps catch people who never hit the shorter ones.
When Codex stops, your work doesn't need rescuing — it's already recorded. Open another harness in the same folder and keep going.
oathe claude # back to Claude Code
oathe agent # or Cursor's CLILet a different agent check the work
The agent that wrote the code is the worst judge of whether it's done.
Oathe records completion as an assertion. A verifier that didn't write any of it reads the recorded session traces and checks what happened against what you asked for. You can run that check in Claude Code while Codex did the work — or the reverse.
oathe done fix-login "guard rewritten, test added" src/auth.test.js
oathe verify fix-login # a non-author checks the traces
In-session, Codex can drive this itself through the oathe_* MCP tools.
Next
Oathe is open source (Apache-2.0) · What Oathe is · What's proven per harness today · Codex CLI