Roadmap

Last reviewed 17 September 2026, and reviewed quarterly.

What is missing, in priority order

These are the gaps a reader of the comparison page will have noticed. The order was set before we read the public reviews that produced that page's feature list, and the reviews agreed about which gaps matter most. What we have decided to do about each one is ours, and the reviews say nothing about it.

1. Capturing what happened before you pressed record

Today Bugpacker needs you to press record first, which loses every bug you did not expect, and that is most of them. This is the largest functional gap in the product. Closing most of it does not need a buffer running on every page you visit, and a product on the comparison page shows how.

BugShot keeps the last 30 seconds of a tab while its side panel is open. The feature is off by default and starts when you open the panel, so it reaches back to that moment, not before it. What lets it keep going when you navigate to a different site is the permission it takes at install, <all_urls>, which its privacy policy says Chrome shows as "Read and change your data on all sites." Chrome's activeTab grant ends at a cross-origin navigation, and without that permission an extension stops seeing the tab there. That is the whole trade, and it is now shown by a shipped product rather than argued.

We intend the same shape without the install-time permission: an armed session. Opening Bugpacker on a tab grants activeTab, the content script goes in, and a ring buffer of semantic events starts: console messages, network requests and failures, actions, and form field transitions. If you then record or capture, what has happened since you armed the tab is in the package. The buffer holds events rather than video or DOM, and snapshots on interaction, navigation, a thrown error or a failed request, never on a timer.

Where BugShot follows you to another site without asking, Bugpacker stops at the crossing. The recording ends there and the package records that it left the site, with no prompt in it.

The limit is worth stating plainly: this gives you retroactivity from the moment you armed the tab, not from nothing, and the same is true of BugShot's replay. A bug you stumble into on a site you were not thinking about is still lost. That case is the one Jam's Instant Replay covers and ours will not.

2. Filing into Jira, Linear and GitHub

Today you attach the file yourself. Every product on the comparison page files the issue for you.

This one adds the first outbound requests the extension has ever made, to api.linear.app, api.github.com and *.atlassian.net. That is a real change to the claim on the security page, and it will be described in full: requests to a tracker you named, carrying a report you reviewed, and nothing to us.

3. Video

Every product on the comparison page records screen video. Bugpacker takes screenshots.

Recording it is the easy part. Competitors hand you a hosted link; Bugpacker has to hand you a file a human can attach to a ticket. Tracker attachment limits are small, and Jira's default is the binding one. So the requirement is video that fits inside an attachment, which means hard limits on length, framerate and resolution.

Not planned

Slack. Chat integration needs a persistent connection to somewhere, which is the one thing this product does not have and does not want.

What we want to build that nothing else here can

Speculative work, not designed or costed. It is on this page because everything above it is catching up.

All three follow from a single fact. Bugpacker's output is a structured file on your own machine, and every competitor's is a link to a video on their server. A file with a published schema can be diffed and inspected. A hosted video cannot.

Compare two captures

"It worked last Tuesday." Attach Tuesday's package and today's and get the difference: what changed in the environment, which requests are new or newly failing, what appeared in the console, what changed in the page around the marked element, which field started being rejected.

Four of those five can be computed from the package as it is written today. Environment, form state and the marked element are each their own JSON file, and every instrumented request is a HAR entry, though subresource failures for script, img and link never reach the HAR and exist only as rendered text. The console is the exception. Console errors are structured and the rest of the console is not. An error reaches report.json as a step and as a finding, so it can be compared across two packages. A warning, a log line or a CSP violation exists only in the rendered console.log, as text laid out for a person to read. Two of those diffed against each other give you changed lines of text.

Closing that means adding the console to report.json rather than writing a smarter comparison. Until it is in the schema, a comparison cannot read it, and the schema is published so you can check what is there before believing any of this.

A bug report that arrives as a failing test

Bugpacker already talks to coding agents through MCP. The next step is the one only a local tool can take: the agent has your bug report and your repository open at the same time, so it can read how tests are written in your project and write the failing test that reproduces the bug.

A hosted tool hands an agent a link to a recording. That agent knows the bug and nothing about your codebase. Your bug report and your code sit in the same place only on your own machine.

Step through the bug, from the file, with nothing installed

The package already holds the page snapshot, the ordered actions and the full network session. One self-contained HTML file could let you scrub through what happened, seeing the page, the console and the network at each step, opened from disk with no server and no account.

The honest limit: Bugpacker strips inline scripts from the snapshot so that opening it can never run anything. This can never re-run your application's logic. What it gives you is deterministic inspection of what the browser showed.

What we have decided not to build

• A dashboard or triage board that we host. A server of ours would forfeit the only thing here a competitor cannot copy. If a team version ever exists it runs on the customer's own hardware or in their own cloud tenant, never on ours, and it is free like the rest of the product.
• A buffer that runs before you invoke Bugpacker. Watching a tab you have not invoked it on needs broad host_permissions or broad declarative content scripts. Either one produces the install-time warning about reading and changing your data on all websites, which would make the security page false. See item 1 above for what we intend instead.
• Any way to turn redaction off. Not a setting and not a per-site exception. The store listing, the privacy policy, the security page, the home page, the published schema and the README inside every package all say it cannot be disabled, and an exception would make each of them false.
• Recording links a customer can use without installing anything. Competitors do this well and it requires their cloud by definition. There is no local equivalent, so there is no plan.
• Capturing values typed into forms. Bugpacker records that a field was typed into, its length, its shape and why it was rejected. It never records the value. That is a deliberate ceiling on how much this product can ever tell you.

How to change what is on this page

Ask: hello@bugpacker.com. There is no upvote board and no public issue tracker yet, so a plain email carries more weight here than it would anywhere else. If something you need is in the "decided not to build" list, say so anyway.