RuntimeVault captures the full runtime state the instant an error fires — stack, variables, network, DOM — and hands it to Claude Code, Cursor, or any MCP-compatible agent. No more debugging from a bare stack trace. Free plan forever. How it works: 1. Install SDK (2 lines) 2. Error fires → snapshot captured 3. Run `rv replay snap_id` → local environment restored What makes it different from Sentry/LogRocket: we don't just show you what happened — we let you replay the exact state locally.
No reviews yetBe the first to leave a review for RuntimeVault
Maker
📌
Hey PH! 👋
I built RuntimeVault because I was tired of reproducing bugs from stack traces alone.
The core idea: when an error fires, freeze the entire runtime state — variables, network requests, DOM, storage — and let developers (or AI agents) replay it locally.
It's like git for runtime. `rv replay` restores your app to the exact moment it broke.
Free plan, open source SDK, works with any MCP agent.
Would love feedback on the DX. What would make you actually use this?
Report
one thing that would make this even more useful for our team: the ability to redact sensitive fields before the snapshot leaves the browser. stuff like auth tokens, user emails, and form inputs can end up in captured state, and right now it looks like everything goes to the AI agent as-is. a simple allowlist or regex mask in the SDK config would let us ship this to production without worrying about leaking customer data through the replay.
Report
The `rv replay snap_id` workflow is such a sharp move. Treating a runtime snapshot like a git checkout makes it obvious how to use it, and tying it into MCP means the agent already has the context it needs without me explaining anything.
Report
the local replay idea is genuinely clever, that's the part that hooked me. one thing i'd love to see is a way to scrub through the captured state timeline before the error, so i can see what the app looked like a few seconds earlier, not just the exact crash moment. would make flaky bugs way easier to chase down
Report
the replay command idea is genuinely sharp, turning a snapshot into something you can actually poke at locally instead of just staring at feels like a real workflow upgrade over Sentry's read-only context.
one thing that would make this even more useful for our team: the ability to redact sensitive fields before the snapshot leaves the browser. stuff like auth tokens, user emails, and form inputs can end up in captured state, and right now it looks like everything goes to the AI agent as-is. a simple allowlist or regex mask in the SDK config would let us ship this to production without worrying about leaking customer data through the replay.
The `rv replay snap_id` workflow is such a sharp move. Treating a runtime snapshot like a git checkout makes it obvious how to use it, and tying it into MCP means the agent already has the context it needs without me explaining anything.
the local replay idea is genuinely clever, that's the part that hooked me. one thing i'd love to see is a way to scrub through the captured state timeline before the error, so i can see what the app looked like a few seconds earlier, not just the exact crash moment. would make flaky bugs way easier to chase down
the replay command idea is genuinely sharp, turning a snapshot into something you can actually poke at locally instead of just staring at feels like a real workflow upgrade over Sentry's read-only context.