BugProof
Executable bugs, not bug reports
Start new thread

BugProof - Executable bugs, not bug reports

by•
BugProof captures software failures as portable, reproducible .bug artifacts. Instead of sharing screenshots, logs, and lengthy bug reports, developers can package the exact failure including source state, environment metadata, execution context, and failure fingerprints into a single file that anyone can replay. Cross-platform, open source, AI-agent ready, and no Docker required.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt! 👋 I'm Siddharth, the creator of BugProof. BugProof started from a problem I've seen over and over again while working on software projects: A bug gets reported. Someone shares a screenshot, a stack trace, or a few terminal logs. Another developer spends hours trying to reproduce the same failure before they can even begin fixing it. The bug isn't usually the hard part. Reproducing it is. That led me to a simple question: Why do we have portable artifacts for source code (Git) and environments (containers), but not for software failures ? BugProof is my attempt to explore that idea. It captures a failing command into a portable `.bug` artifact containing the source state, execution context, environment metadata, and failure fingerprint. Another developer can replay that artifact and reproduce the failure on their own machine. A few things that make BugProof different: • One-command capture and replay • Cross-platform support (Windows, Linux, macOS) • GitHub Actions integration for CI failures • Cryptographically signed artifacts • MCP support for AI coding agents • No Docker or additional infrastructure required The project is open source and still evolving, so I'm looking for honest feedback from developers, maintainers, platform engineers, and anyone who has ever lost hours trying to reproduce a bug. I'd love to hear your thoughts: Do you think software failures should be treated as portable artifacts ? Thanks for checking out BugProof ❤️ My DMs are always open, and if this idea resonates with you, I'd love to connect and build something interesting together.

Congratulations on the launch. Every bug report I've ever come across has missing steps. Every single one. How do you handle the environment state piece — that's usually where reproduction breaks down even when the steps are right.

Maker

 That's exactly the problem we're trying to solve.

BugProof captures more than just the steps it snapshots the environment schema, runtime versions, command invocation, relevant source state, and failure fingerprint into the .bug artifact. On replay, it compares the captured environment against the current machine and surfaces mismatches (missing dependencies, different Node/Python versions, OS differences, etc.).

It's not perfect for every possible stateful system yet, but the goal is to move from "here are the steps I think I ran" to "here's the exact failure context that produced the bug." That's where most reproduction time gets lost today.

How do you share and store them safely, like can you redact secrets before exporting the file?

Maker

 Yes. Before BugProof packages the `.bug` file, it automatically scans your computer's environment variables for anything that looks like a secret — API keys, tokens, passwords. It catches them two ways:

1. By name — if a variable is named `API_KEY`, `SECRET`, `PASSWORD`, etc., it's flagged.

2. By pattern — if a value looks random and high-entropy (like `sk-proj-AbCdEf...`), it's flagged.

When you share the `.bug` file, the secret values are stripped out. The person on the other end can see that a secret existed and what it was named, but never gets the actual value. Your credentials stay on your machine.

I can definitely relate to this. Sometimes an AI agent is doing useful work and you don't want to be stuck at your desk waiting for it to finish. Being able to check in from your phone feels like a natural next step.