Claude Just Proved 123 Code Libraries Won't Crash (Not Tested. Proved.)

• Tests vs proofs
• What was proved
• The bugs
• Why trust it
• The catch
• How to try it

On October 22, 2026, Anthropic published a research write-up with a strong claim: Claude wrote machine-checked proofs that 239 fuzz tests across 123 open-source libraries can never crash, for any input under 64 MB. The proofs work on the compiled machine code itself, and a separate proof checker confirms every line, so nobody has to take Claude’s word for it.

Tests vs proofs

Software is usually checked with tests. A fuzzer is a test engine that throws huge numbers of random and mutated inputs at a program, looking for one that makes it crash. It finds a lot, but it can only try the inputs it happens to generate. Anthropic’s write-up notes that fuzzers usually cap inputs around 1 MB and can’t promise they’ve reached every path through the code.

A formal proof is different. It’s a mathematical argument that the program behaves correctly for every input in a defined range, not just the ones someone tried. Proofs have always been slow and expensive to write: Anthropic points out that the seL4 operating system kernel took 2 person-years to build and 20 person-years to verify. That cost is why formal verification has mostly been used for things like aircraft software.

What Claude proved

Anthropic worked with Theorem (theorem.dev), its collaborator on the project. They took fuzz tests from Google’s OSS-Fuzz project, compiled the libraries to RISC-V machine code, and turned each test into a statement to prove: “this test never crashes for any input under 64 MB.”

Over a few weeks, Claude:

• proved no crashes for 239 entry points across 123 libraries
• wrote about 180 million lines of proof in Rocq, a proof language, with a typical proof around 600,000 lines
• covered binaries with a median of 18,000 RISC-V instructions

Proving “this test never crashes” can prove more than it sounds. Some fuzz tests check that compressing and then decompressing gives back the original. If that test can never crash, the round trip always works.

The bugs it found

A proof only goes through if the code is actually correct, so every failed attempt points at a possible bug. When Claude hit one, it patched the code and kept proving. Anthropic says these attempts surfaced hundreds of bugs, including ones a fuzzer would be unlikely to find: an out-of-bounds write in a decompressor that only showed up on about 20 MB inputs with one rare layout, and an image-decoder read that needed a 64 MB input and over 2 GB of memory.

In separate verification experiments described in the same post, Claude found a logic bug in a widely used application that had gone unnoticed for more than a decade, and turned up as many security bugs in a PDF reader in one week as usually get reported in a year.

Why you don’t have to trust Claude

Nobody reads 180 million lines of proof. They don’t need to. The Rocq proof checker mechanically checks that each proof really proves the statement. What you still have to trust is short: the models of RISC-V and Linux, the exact statements that were proved, and the checker itself.

The catch

The guarantee is real but narrow, and Anthropic says so plainly: this “doesn’t mean these libraries contain no bugs.”

• It covers inputs under 64 MB, and assumes a single-threaded static program with a fixed memory budget on a RISC-V CPU running Linux, as modeled. That isn’t the exact build most people run.
• It proves “no crash” for the fuzz tests that were proved. Not every entry point was, and a logic bug that never crashes can still be there.
• These are Anthropic’s and Theorem’s own research results. They’ve published a subset of the proofs so others can check them, and held back proofs that could reveal unpatched bugs.
• It still doesn’t replace testing. Keep your tests and your fuzzers.

How to try it

If you maintain an open-source project, Theorem is offering to run the same pipeline for other projects, and it published a Claude Code skill called add-project in its oss-verify repository. The skill walks you and a coding agent through enrolling a project: it asks what “correct” means for your library, which inputs come from attackers, and how you want bug reports and patches, then builds the files and a pull request that you open.

If you just depend on open-source code, check whether the libraries your product relies on appear in Theorem’s published proofs, and watch for maintainers announcing verified releases.

Try this prompt

Before you enroll a project, answer the questions the skill will ask. Paste this into Claude or ChatGPT with your project’s README:

I maintain [project name], a [language] library that [what it does].
Help me prepare to enroll it in formal verification (Theorem's OSS Verify).
1. List the functions that read input an attacker could control (parsers, decoders, protocol handlers).
2. For each, say what a "correct" outcome looks like for bad input (error code, size limit, refusal).
3. Suggest the largest realistic input size for each.
4. List properties that should always be true besides "no crash", e.g. decode(encode(x)) == x.
5. Point out anything in my README that is unclear about what the library promises.
Ask me about anything you can't tell from the README. Don't guess.

What library would you want proved first?