Release on CodeInstances.com

CodeInstances Adds a Self-Hosted Store, Push and Pull by ID, and Bug Reports That Reproduce

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.5.0 is about getting a run from where it failed to where someone can fix it. A test fails in CI at 3 a.m. The run is kept, but it’s sitting on a build machine that’s gone in an hour. This release adds a small store of your own to keep runs in, push and pull to move them by id, and report, which writes the bug report you paste into the issue.

CodeInstances Forks a Run at Any Step, to Run On Live or Try a What-If Answer

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.6.0 adds fork. Replay runs a program against the whole recording. Fork runs it against the recording up to a step you pick, then lets it carry on from there. You get the past exactly as it happened, and a new future.

Two uses pull this in. The first is picking up where a run went wrong. An agent ran for twenty minutes, called a dozen APIs, and on call nine it got an answer that sent it the wrong way. You don’t want to spend another twenty minutes and another dozen calls getting back to call nine. codeinstances fork -at 9 run.instance answers calls one to eight from the recording in a moment, then sends call nine for real, against today’s servers.

CodeInstances Groups Failing Runs by Fingerprint So Repeats of One Bug Show as One

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.4.0 adds the sixth verb, group. Point codeinstances group at a folder of instances and it tells you how many different ways your program failed, how often each one happened, and when it was first and last seen.

The problem is a familiar one. A nightly job fails 40 times in a week. A flaky suite leaves a pile of red runs. Each failure gets its own instance now, which is good, but 40 files isn’t an answer. Usually it’s two or three bugs, repeating. Somebody has to open the files, squint at the errors and sort them into piles, and the piles drift, because the messages carry request ids, timestamps and ports that change every time.

CodeInstances Launches as an Open Source Tool That Keeps Program Runs and Replays Them

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.1.0 is out. It’s a small command-line tool that keeps a run of any program as a file and replays it later, with the network replaced by what was recorded. It’s open source under the Apache License 2.0 and comes as a single static binary for Linux, macOS and Windows.

The problem it goes after is an old one. Code is kept with great care, in version control, reviewed and tagged. Runs are thrown away. A test fails in CI, someone hits rerun, it passes, and whatever went wrong is gone along with the evidence. An API answers something strange once and never again. A job breaks on Tuesday, and by Wednesday the data it read has moved on.

CodeInstances Now Compares Two Runs and Shows Where the Failing One Went Wrong

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.2.0 is out, and it adds the third verb. The first release could keep a run and replay it. This one compares two of them: codeinstances diff passing.instance failing.instance.

The usual case goes like this. A job works on Monday and fails on Tuesday, or passes on your laptop and fails in CI. You have both runs as instance files, because you put codeinstances record in front of the command. Now you want to know what was different, and you’d rather not read two logs side by side and guess.

CodeInstances Runs Kept Instances on Demand, From a Store You Control

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.8.0 lets a store run what it keeps. Start it with serve -run, and anyone with the store’s token can ask it to replay a run, or fork one at a step, and get back how it went. codeinstances run 3f2a9c1e77b0 replays that run on the store. codeinstances run -at 4 -o what-if.instance 3f2a9c1e77b0 forks it at call 4 there and downloads the result.

Think of a function service, where code sits ready and a request runs it. Here the kept run is the function. A replay answers whether the program, as installed on that machine, still does what the run did. A fork tries the run again from a step, and nobody has to set the program up on their own laptop to do it. Every run is answered from the recording, so HTTP calls made through the proxy settings never go out.

CodeInstances Shrinks a Failing Run to the Answer That Breaks It and Keeps It as a Test

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.3.0 adds two verbs at once. codeinstances shrink takes a failing run and a passing one and finds which of the failing run’s answers actually cause the failure. codeinstances test replays a folder of instances as regression tests. They belong together: the first finds the bug’s smallest form, the second makes sure it stays fixed.

Here’s the problem shrink goes after. You’ve got a run that fails and one that doesn’t, and diff from the last release shows you how they differ. Often that’s dozens of answers: timestamps, ids, counters, prices that moved. One of them broke the program, and the rest is noise. Reading them one by one is slow, and it’s guesswork.

CodeInstances Signs Runs, So You Can Check Who Kept One and That Nothing Changed

Sun, 18 Oct 2026 00:00:00 +0000

CodeInstances v0.7.0 adds signing. Every instance already carried an id, the SHA-256 of its contents, so verify could tell you a file had been edited. What it couldn’t tell you is who made the file in the first place. Anyone can change a run and write a fresh id. Now a run can carry a signature, and verify -trust checks it against keys you’ve decided to trust.

That matters when a run is evidence. A CI job says the tests passed, an AI agent says what it did and what came back, a bug report says this is what happened. With a signed instance the person reading it doesn’t have to take the file’s word for it. They check the key.

How CodeInstances Was Tested Before Its First Release

Sun, 18 Oct 2026 00:00:00 +0000

A tool that claims to replay runs exactly has to be tested on exactly that. So most of the testing for v0.1.0 does the same thing over and over in different ways: record a program against real servers, shut the servers down, replay it, and check the replay came out the same. Then change something and check the replay notices.

Every number in this post comes from the result files in the code repository, in test/results. They were recorded on October 18, 2026, at commit c2a5975, on a Linux machine with an Intel Xeon processor at 2.10GHz and 2 CPUs, with Go 1.24.7. One script, scripts/record-tests.sh, runs everything and writes the files, so anyone can run it again.