FableCodex: Evidence Gates for Codex Workflows
🗿 FableCodex is a Codex-style coding agent workflow that plans like Fable.
At a glance
- What is it?
- FableCodex is a Codex plugin that adds goal ledgers, review findings and verification checkpoints to agent sessions. It improves process discipline, not model capability, and the README is explicit about that boundary.
- Who is it for?
- Adopt FableCodex if your Codex sessions involve migrations, CI failures, security-sensitive edits or reviews where an unresolved finding must block completion, and you are willing to type the scope and stopping rules into each prompt. Skip it for short answers, single-file edits and brainstorming, where the README itself says the ledger process costs more than the work.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 54 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 17, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem FableCodex targets: agents that declare victory early
A coding agent that edits files, runs nothing and reports success is the failure mode this project addresses. FableCodex is a Codex plugin that layers a stricter procedure onto a session: classify the task, inspect the workspace, use Codex-native tools rather than memory, track goals with evidence checkpoints, track review findings behind a final gate, and verify with tests, lint, typecheck, screenshots, command output, source inspection or connector readback. The README frames the audience in one line: it is useful when the cost of a missed step is higher than the cost of a little process. That is a narrow but real audience. Migrations, release work, CI debugging and security-sensitive changes fit. Short answers and tiny single-file edits do not, and the README says so directly. Note the boundary the project draws around itself: it does not clone, unlock or replace the Fable 5 model, and it cannot change model weights, context length, training or hidden safety systems. What it ships is workflow guidance, local ledgers, examples, coverage accounting and optional routing docs. If you are looking for a model, this is the wrong repository.
How the skill, the ledgers and the gate fit together
The mechanism is procedural, and the state lives on disk in two JSON files. Invoking `@codex-fable5` makes Codex read the skill and follow its steps. Two ledgers carry the state across a long session: `.codex-fable5/goals.json` for multi-step work and `.codex-fable5/findings.json` for accepted review issues. Goals are created with a brief and a list of `--goal` entries written as `name::description`, then advanced one at a time. A completed goal needs evidence text, and the final goal additionally requires a verification command and its output. Findings are separate: each one records a title, a severity, a source, a file location and evidence. Resolving a finding requires resolution evidence plus a verification command and verification evidence. The gate is the enforcement point. `codex-fable5 findings gate` fails while any finding remains in `open` or `blocked` state, and final goal completion also fails while blocking findings remain. That coupling is the interesting design choice: the ledger is not a log you write after the fact, it is a precondition the agent has to satisfy before it can claim the work is finished. The weak spot is equally clear. Evidence is free text supplied by the same agent that did the work, so the gate checks that a claim was recorded and a command was named, not that the command proves what the claim says.
Installing FableCodex from the plugin marketplace
The README gives a two-command install pinned to the stable release tag v0.5.1, followed by a Codex restart. The second command adds the plugin under the name `codex-fable5@fablecodex`.
codex plugin marketplace add baskduf/FableCodex --ref v0.5.1
codex plugin add codex-fable5@fablecodexAfter restarting Codex, the skill is invoked from the prompt rather than from a menu. A first real use is to ask for an implementation with the ledger and the findings gate switched on, which is the strictest of the prompt patterns the README lists.
@codex-fable5 Run this strictly.
Use a goal ledger, record any review findings, and do not finish until tests and findings gate pass.What you should see is Codex classifying the task, inspecting files before editing, and writing state into `.codex-fable5/`. The command-line helper is what makes that state inspectable. It is not on `PATH` by default, so the README prepends the checkout's bin directory.
export PATH="$PWD/plugins/codex-fable5/bin:$PATH"
codex-fable5 goals create --brief "Migration" \
--goal "inspect::Find current behavior and tests" \
--goal "change::Implement the migration" \
--goal "verify::Run tests and inspect output"
codex-fable5 goals nextThe README also notes that the checkout helper can be run directly as `plugins/codex-fable5/bin/code` without touching `PATH`, and that `codex-fable5 version` reports the installed plugin version, paths and git checkout state. That last command is the one to run first when something behaves unexpectedly, because it tells you which checkout Codex is actually reading.
Where the evidence model breaks down
The gate is only as strong as the evidence string behind it. `codex-fable5 goals checkpoint` accepts a `--status` of complete, failed or blocked along with free-text `--evidence`, and the final goal adds `--verify-cmd` and `--verify-evidence`. Nothing in the described interface checks that the verification command is relevant to the goal, that it was actually executed, or that its output matches the evidence text. An agent that writes a plausible sentence and names a test command satisfies the same gate as one that ran the suite and read the failures. Treat the ledger as a discipline aid and an audit trail for a human reviewer, not as proof. The second limitation is prompt dependence. The README states plainly that the user controls the skill through the prompt, and that scope, strictness, verification and stopping rules must be explicit. There is no configuration file that enforces strict mode by default, so a session where nobody typed the strict instruction gets the lighter path. Third, the process has a real cost on small work: the README lists short answers, tiny single-file edits and brainstorming as cases to skip, and the reason is that the ledger overhead exceeds the task. If your team lives on one-line fixes, this plugin adds ceremony without changing outcomes.
FableCodex compared with plain Codex instructions
The obvious alternative is not another plugin but the built-in route: an `AGENTS.md` file in the repository plus a well-written prompt. The repository ships `examples/AGENTS.md`, so the project itself concedes that convention-based guidance is a legitimate way to steer a coding agent. The difference is persistence and enforcement. Instructions in a file are read and then interpreted; nothing stops an agent from drifting mid-session, and nothing fails when a review issue is quietly dropped. FableCodex moves the state out of the prompt and into `.codex-fable5/goals.json` and `.codex-fable5/findings.json`, and adds a command whose exit status is a hard stop. That is the whole trade: you accept two JSON files, a helper binary on `PATH` and a stricter prompt style in exchange for a completion check that does not depend on the agent remembering. If your work is exploratory, or if you already run your own CI gate that blocks merges on failing checks, the plugin duplicates a control you own. If your agent sessions are long, multi-step and reviewed by humans who need to see which claim rests on which command, the ledger gives that reviewer something to read.
Maintenance, releases and the AGPL-3.0 licence
The last push to the default branch was on 2026-07-26, and the most recent release listed is v0.5.1 from 2026-06-18, preceded by v0.5.0 and v0.4.4 on the same day. The repository is not archived. The README documents `codex-fable5 update`, which updates the checkout or plugin package to the latest stable `v*` tag, so upgrading is a single command rather than a manual reinstall. The repository carries a CHANGELOG.md and a ROADMAP.md, which is where release-by-release behaviour changes should be checked before an upgrade. On licensing: the badge and the repository state AGPL-3.0-or-later, and the README installs the plugin from a public marketplace by tag. AGPL-3.0 is a strong copyleft licence with a network-use clause, which matters more than usual here because a Codex plugin is code that runs alongside your own. Whether your distribution or hosting arrangement triggers obligations is a question for your own counsel; the README does not discuss licence implications, and nothing in the repository description addresses commercial use. The practical point is that this is not a permissive licence, and teams that cannot accept copyleft should resolve that before building a workflow around the plugin.
Editorial conclusion
Adopt FableCodex if your Codex sessions involve migrations, CI failures, security-sensitive edits or reviews where an unresolved finding must block completion, and you are willing to type the scope and stopping rules into each prompt. Skip it for short answers, single-file edits and brainstorming, where the README itself says the ledger process costs more than the work. Before relying on it, verify two things: that `codex-fable5 findings gate` actually fails while a finding sits in `open` or `blocked` state in your checkout, and that the AGPL-3.0-or-later licence is acceptable for how you distribute or host the plugin.
Frequently asked questions
What is FableCodex and does it replace the Fable 5 model?
It is a Codex plugin that adds a stricter workflow to Codex sessions: task classification, workspace inspection, goal ledgers, review findings and verification before completion. The README states that it does not clone, unlock or replace the Fable 5 model and cannot change model weights, context length, training or hidden safety systems.
Why is FableCodex so expensive to use?
The README does not discuss pricing, and the plugin is installed from a public marketplace at tag v0.5.1. What the README does describe is a process cost: strict mode adds a goal ledger and a findings gate, and the README advises skipping it for short answers and tiny single-file edits because the extra process would be heavier than the work itself.
How do I install FableCodex as a Codex plugin?
The README gives two commands: `codex plugin marketplace add baskduf/FableCodex --ref v0.5.1` and `codex plugin add codex-fable5@fablecodex`, followed by a Codex restart. After that the skill is invoked in the prompt as `@codex-fable5`.
What happens if a review finding is still open when the work finishes?
The gate fails. `codex-fable5 findings gate` fails while any finding remains in `open` or `blocked` state, and the README states that final goal completion also fails while blocking findings remain. Findings are resolved with `codex-fable5 findings resolve`, which requires resolution evidence plus a verification command and its output.
Where does FableCodex store its goal and finding state?
In two local JSON files: `.codex-fable5/goals.json` for the goal ledger and `.codex-fable5/findings.json` for review findings. The `codex-fable5 status` command shows findings and goal progress together.
Community notes