Claude and Antithesis catch SQLite's WAL-Reset bug in 15 minutes
Carl, who says he works with Antithesis and previously taught Claude to use the platform, describes reproducing a long-standing bug in SQLite's Write-Ahead Logging subsystem, known as the WAL-Reset bug. The bug had existed since 2010; SQLite fixed it earlier this year in version 3.51.3. In its own release notes, quoted in the post, the SQLite team described it as a data race with tight timing constraints, unlikely to occur in common use, that its developers had never been able to reproduce organically; they had to add special testing logic to SQLite just to trigger the bug and confirm the fix worked.
Carl set up SQLite 3.51.2, the still-buggy version, inside Antithesis and instrumented the code with Antithesis assertions. He then asked Claude to write a workload exercising the WAL insert and checkpoint code. The workload was deliberately generic: concurrent writes and checkpoints, the kind of activity that happens in production all the time. The assertions were generic too, standard checks like "no lost committed writes" and SQLite's own integrity check, not anything specific to this bug. On the first run, Antithesis caught the bug in 15 minutes. Carl then repeated the same workload and instrumentation against SQLite 3.51.3, and the run came back clean.
Carl connects the find to a separate blog post from Tailscale, whose shaky uptime in 2025 turned out to be caused by the same bug. Tailscale suffered six months of shaky uptime; it and the SQLite team then spent weeks hunting the bug together, shipped an interim fix that broke something else and rolled it back, and had to wait two more months to confirm that the eventual fix in 3.51.3 actually worked. To find the root cause, Tailscale wrote a new transaction logging pipeline and a new debugging shim for SQLite's virtual filesystem layer. Carl contrasts that effort with Antithesis's causality analysis, which he says can pinpoint an issue to within a fraction of a second in one click, alongside deterministic, time-travel debugging for what-if and destructive analysis. He quotes the Tailscale team describing the six-month hunt as an immensely frustrating experience for both customers and staff.
Carl frames the whole exercise as proof that Claude's agent skills for Antithesis work well: he says he found and verified the bug in about an hour, from his phone, sitting outdoors on a road trip, using only the public description of the bug that the SQLite team had already published.
Key facts
- SQLite fixed a WAL-Reset data race that had existed since 2010, releasing version 3.51.3 earlier this year.
- Carl used Claude, running Antithesis's agent skills, to instrument SQLite 3.51.2 and run a generic concurrent write/checkpoint workload; Antithesis caught the bug on the first run in 15 minutes.
- A rerun of the same workload against SQLite 3.51.3 came back clean, confirming the fix.
- Carl says the entire exercise, done from his phone, took him about an hour.
- Tailscale's 2025 uptime problems were caused by the same bug: six months of shaky uptime, weeks of joint hunting with the SQLite team, a broken interim fix, and a two-month wait to confirm the real fix worked.
Why it matters
This is a concrete case of an AI agent, Claude, directed at a specialized testing platform, Antithesis, reproducing in 15 minutes a concurrency bug that eluded SQLite's own developers for 15 years and that cost a production user, Tailscale, six months of unreliable service to diagnose. It is a data point for how deterministic simulation testing paired with an AI agent can compress bug hunting from months of manual effort to minutes, at least for the class of intermittent data-race bugs SQLite's team called unlikely to occur in common use.
Who it affects
Database maintainers and teams running SQLite in production at scale, Tailscale being one documented example, especially those chasing intermittent, hard-to-reproduce concurrency bugs. It also concerns developers evaluating Antithesis or similar deterministic-simulation testing tools, and anyone building on or using Claude's agent skills for engineering work.
How to use it
Carl's setup, at a high level: instrument the target code, here SQLite 3.51.2, with Antithesis assertions, write a generic concurrent workload of writes and checkpoints, and let the agent drive it inside Antithesis's simulation environment. The assertions were standard ones any database project could reuse, such as "no lost committed writes" and SQLite's built-in integrity check, not anything bug-specific. The post links to the instrumented code and to the Antithesis run report showing the bug caught in 15 minutes. The source gives no pricing or licensing details for Antithesis.
How solid is it
The account comes from Carl, who by his own description works with Antithesis and taught Claude to use it, so this is a vendor-side case study rather than independent verification. The underlying facts are checkable: the SQLite team's own release notes, quoted in the post, confirm the bug's existence, its data-race nature, and that it required special testing logic to reproduce, and SQLite 3.51.3 is the released fix Carl reran his workload against. The Tailscale reference adds an independent account of the bug's real-world impact, though Carl does not name the author of the Tailscale post or give its publication date.
Risks and caveats
The post does not explain the technical mechanism of the WAL-Reset race beyond calling it a data race with tight timing constraints, so it is hard to judge from this account alone how representative the bug is of concurrency bugs generally. It is a single anecdote from someone with a commercial interest in both Antithesis's tooling and in Claude's agent skills performing well, and no independent reproduction is cited. Carl also does not give an exact release date for SQLite 3.51.3, only "earlier this year."
“The bug is a data race with tight timing constraints. It is unlikely to occur in common use. The developers have never been able to reproduce the bug organically and had to add special testing logic to SQLite that deliberately triggers the circumstances of the bug in order to verify that the issue has been fixed.”
— the SQLite team