The second key for AI-written C/C++ and firmware
We unfix your fix —
to prove it.
Your AI agent says it's fixed. Unfix doesn't write code — it reproduces the bug, applies the fix, re-runs the evidence, then pulls the fix back out and checks the bug returns. Then it gives one deterministic verdict: VERIFIED or REJECTED.
Watch it on real hardware
AI wrote a fix. Is it real?
1 min 46 s · sound on · recorded under the working name cplus
-
01 · A REAL BUG
Unfix builds the firmware, flashes the NUCLEO board and runs the test. It fails 3 of 3: the counter should be 42, it's 41.
-
02 · A FAKE FIX
The "fix" turns unity_fail into unity_pass. CI would go green. Unfix says REJECTED and points to the line.
-
03 · AN HONEST FIX
Eight independent checks on the board — bug before, gone after 3 of 3, nothing else broken, back on revert. VERIFIED.
The problem
Green tests are not proof. In C and C++, a "fix" can hide the bug and still pass.
Memory errors, races and flaky failures are exactly where AI coding agents — and tired humans — take shortcuts. The agent reports success; the bug ships.
Sanitizers switched off
The crash disappears because ASan or TSan no longer runs — not because the memory error is gone.
Tests weakened
An assertion is loosened or a failing case is skipped, so the suite turns green around the bug.
Delays instead of fixes
A sleep makes a race rarer on one machine. It still fails in the field, on the real board.
How it works
A verifier that is independent of whoever wrote the fix.
See it run
One real bug, on a real board, from first run to verdict.
A firmware project on an STM32 NUCLEO-F401RE. Unedited screenshots of the terminal app.
It finds your project, your board and your tests.
Project type, connected board, ST-Link probe and the sandbox are checked before anything runs. One key to start.
Build, flash, fail. Three times out of three.
Firmware is built for ARM in a container and flashed to the board. The bug must fail every run — otherwise there is nothing to prove.
Eight independent checks, live on the board.
Tests not weakened. Bug there before, gone after. Everything else still passes. And the bug comes back when the fix is pulled out.
VERIFIED in 31 seconds — with the proof attached.
Apply it to your folder, make a branch, or export an HTML report. If the fix had cheated, you'd see REJECTED instead — like at the top of this page.
Where it runs
Inside the tools your team already uses.
On every pull request
A GitHub check posts the verdict and the evidence right in the PR. Reviewers see whether the fix is real before they merge — not after the bug comes back.
Real comments from our demo repository (posted under the working name cplus).
In your AI agent
An MCP tool for Claude Code, Codex and other agents. The agent fixes; Unfix decides whether it's done.
In the terminal
A simple command-stream app with /bug, /fix and /check — for setup, investigation and demos.
On the real board
Flash, run and check on your hardware rig — for teams that test on the board, not on a host.
Public benchmark
An AI agent fixed 10 real bugs. Unfix accepted 4.
We took real bugs from well-known open-source C/C++ projects, let a current coding agent fix them, and had Unfix judge each fix against the maintainers' own reference tests — hidden from the agent. The rule for picking those tests is fixed before the agent runs, and anti-cheat tests guard against gaming.
Bug types covered: memory errors under ASan, a concurrent-flush race under TSan, edge cases and logic errors — including a pure-C case close to firmware code.
Firmware
Verified on your board, not just on a laptop.
Most embedded teams test on hardware. Unfix drives your existing flashing and test tooling on the real rig and separates three outcomes that usually blur together.
Running today on STM32 NUCLEO boards via ST-Link.
Built for regulated teams
For medtech and other teams where "the agent said so" is not an answer.
Deterministic
The verdict comes from builds, tests and sanitizers — no language model decides it. Same input, same answer.
Evidence you can file
Each run leaves a report: what was reproduced, what was run, what changed. Useful for an IEC 62304-style change record.
Runs in your environment
Works in closed and offline setups. Your source code stays on your machines.
Questions
Frequently asked
What is Unfix?
Unfix is an independent verifier for bug fixes in C, C++ and firmware. It does not write code. It checks whether a fix — written by a developer or an AI coding agent — really removes the bug, and returns VERIFIED or REJECTED with evidence.
How does Unfix verify a fix?
It reproduces the bug on the base version (it must fail every run), applies the fix and re-runs the tests with sanitizers, checks that other tests still pass, then removes the fix and confirms the bug comes back. It also scans the diff for masking: disabled sanitizers, weakened or deleted tests, added delays.
Why "unfix"?
Because the strongest proof that a fix works is to take it out again: if the bug does not come back when the fix is removed, the test never proved anything.
Does Unfix use an LLM to decide the verdict?
No. The verdict comes from builds, tests, sanitizers and hardware runs. Same input, same answer.
Does it work with firmware and real boards?
Yes. Unfix can build firmware, flash a real board (today STM32 NUCLEO via ST-Link), run the tests on the hardware and tell apart FIXED, BROKE and RIG FLAKY.
Where does Unfix run?
As an MCP tool inside AI coding agents such as Claude Code and Codex, as a GitHub pull request check that posts the verdict as a comment, in the terminal, and on your hardware rig. It can run in closed and offline environments.
What did the public benchmark show?
An AI coding agent fixed 10 real bugs from open-source C/C++ projects (fmt, spdlog, zlib-ng, cpp-peglib). Judged against the maintainers' own hidden reference tests, Unfix verified 4 fixes and rejected 6.
Who is Unfix for?
C/C++ and embedded teams of roughly 20–200 engineers, starting with medtech and other regulated products where "the agent said so" is not an acceptable answer.
Design partner program
Bring one real bug. We'll verify the fix with you.
We're working with a small number of C/C++ and embedded teams — 20 to 200 engineers — to run Unfix on their own code and hardware.