About FailTrace
FailTrace is a local CLI and MCP server for coding agents investigating intermittent test failures. It preserves repeatable trial evidence to compare a captured failure with a proposed fix.
Key features
- 01Repeat tests and capture failure baselines
- 02Compare healthy and failing trials
- 03Search Git history with bisect
- 04Minimize reproducing inputs
- 05Verify patches against saved baselines
- 06Save replayable investigation bundles
Use cases
- 01Capture a flaky test before editing
- 02Check a proposed fix against the original failure
- 03Find a Git change associated with a regression
- 04Reduce an input to a smaller reproducer
MCP support
Its local stdio MCP server provides seven tools that use the same engine as the CLI for repetition, comparison, regression search, minimization, verification, and replay. MCP clients can also retrieve saved trial and log pages.
Configuration
Local server config is the same for every client. Copy it into your client’s MCP config file.
Tools
7Saved tool list · updated 3w ago
| Parameter | Type | Required | Description |
|---|---|---|---|
| cwd | string | No | Working directory; relative paths resolve from the server working directory. |
| env | object | No | Explicit environment overrides. null unsets an inherited variable. |
| args | array | No | Literal executable arguments, including an empty array, opt out of shell parsing. Minimize replaces only entire {input} arguments with each candidate path. Windows .cmd/.bat shims require shell mode. |
| repeat | integer | No | |
| command | string | Yes | Shell command when args is absent; executable when args is present. Command and arguments together are limited to 64 KiB. Executed with your local permissions. |
| predicate | any | No | |
| timeoutMs | integer | No | |
| captureEnv | array | No | Only these selected environment variables are recorded in metadata. |
| concurrency | integer | No | Maximum active run trials; default 1, at most 64. Shared ports, files, databases and resource contention can change failure probability. |
| artifactsDir | string | No | |
| captureContext | object | No | Capture declared regular input/setup/source file identities for verification. Source files select a files-only scope; without them, capture Git identity. Use captureEnv separately for relevant variable names. |
| captureContext.inputFiles | array | No | |
| captureContext.setupFiles | array | No | |
| captureContext.sourceFiles | array | No | |
| maxOutputBytes | integer | No | Combined stdout/stderr byte cap per trial; default 16 MiB. Limit outcomes are inconclusive. |
| maxTotalOutputBytes | integer | No | Combined output byte cap for this whole experiment, including all candidates; default 256 MiB. |
| executionRequirement | object | No | Optional checkpoint emitted after the intended check ran. Missing evidence makes classification/verification inconclusive; Verify inherits it from the baseline. |
| executionRequirement.stream | enum | Yes | stdout | stderr |
| executionRequirement.contains | string | Yes |
Details
From the project READMEFailTrace
Reproduce the failure. Check the fix.
A test fails intermittently. Your coding agent changes the code. One passing retry leaves you guessing.
FailTrace repeats the same check, saves a failing baseline, and checks the proposed fix against it. Use the CLI or MCP tools to get trial results, a smaller reproducer, and evidence your agent can inspect before accepting a patch.
Local execution. No AI API, account, or telemetry required. Keep your existing test runner and assertions.
Quick start
With Node.js 22.12+ and npm, run this in any working directory:
npx --yes failtrace demo

Static walkthrough · Static poster · Demo guide
The demo reduces six input items to ["BUG"], rejects a patch that crashes for another reason, and checks a working patch. It saves the evidence in .failtrace/ and prints a replay command.
For coding agents
Connect the local stdio MCP server through your client's configuration:
npx --yes [email protected] mcp --cwd "/absolute/path/to/your/project"
Copy the MCP configuration and check the connection →
Your client launches this command. Running it alone in a terminal waits for MCP requests. The guide includes Windows setup.
Then ask your agent:
Use FailTrace to capture this test failure before editing. Choose the exact test or failure message, save a bounded baseline, and inspect the matching trial. After the change, verify against that baseline and explain any unrelated errors or incomplete evidence.
The seven MCP tools share the CLI's Core engine. They retain the failure signature and investigation evidence across repetition, comparison, regression search, minimization, verification and replay. Agents can retrieve saved trial and log pages without rerunning the command. Shell-capable agents can also use the CLI with --json.

The agent can inspect the saved failure before checking the patch.
Recheck an existing unit test
Follow an exact NUnit or Unity test through a fix. Each attempt gets a fresh NUnit 3 report. Missing or skipped tests and unrelated failures stay inconclusive, so an agent cannot accept them as evidence that the selected test passed.
Connect your test or try the original EditMode example →
NUnit support is included in 1.3.0 through CLI and MCP. The documented Unity validation covers the Windows EditMode example.

The selected test stays the same; a skipped report is not accepted as a passing test.
Use it on your own failure
From your project, replace the command and message with your own:
npx --yes [email protected] run "npm test -- checkout" --repeat 20 --stderr-contains "checkout failed" --capture-context
Run this before editing in a Git project. --capture-context records source identity for Verify; outside Git, select files with --context-source. Each trial saves its output, and exit 1 can mean the target was captured successfully. Then edit and verify the patch →
| Your next question | Command |
|---|---|
| How often does this failure appear? | run |
| What differs between a healthy and failing trial? | compare |
| Which Git change introduced it? | bisect |
| What input is enough to reproduce it? | minimize |
| What happened after the proposed fix? | verify |
| How can I replay this investigation? | bundle |
Command reference · Literal executable arguments · Reusable project scripts

The demo's bundle reproduces its original failure with exit 1. Keep the source, input and replay together; supply the target's prerequisites when packaging your own investigation.
What the results establish
FailTrace reports observations under the chosen settings. Verify separates a target observed, a healthy sample without that target, and inconclusive evidence. Bisect reports a sampled first-parent boundary; minimization rechecks its result without promising the smallest possible input.
The demo shows controlled example outcomes, not performance measurements. A passing sample does not prove a bug is gone.
Commands run with your permissions, and process cleanup is best effort. Retained stdout/stderr is capped by default at 16 MiB per trial and 256 MiB per run or bisect/minimization. Previous investigations accumulate separately. Review logs, commands and selected files before sharing; bundles still require the target's dependencies and setup.
Result and exit-code reference · Resource limits · Storage inventory · Bundle guide
Availability and contributing
The quick start uses npm's latest release; the verified version is 1.5.0. MCP configuration and repeatable installation examples keep that exact version pinned: installation options, GitHub release, and MCP Registry entry.
Version 1.5.0 adds: short run references, Verify readiness and next-step guidance, and intermittent-minimization guidance. See the changelog.
Documentation: choose your next task →
Development instructions · Compatibility · Roadmap · Third-party notices
Comments
New to MCP?
From what the protocol is to installing your first server, these answers cover most first questions.
An open protocol that defines how AI applications connect to external tools and data in a uniform way. Clients talk to the model; MCP servers provide tools, resources and prompt templates. They exchange standard messages, so one server can be reused by many clients.