Brie turns a browser bug into a shareable report with the context attached
Capture screenshots, console errors, network issues, and user actions, giving developers full context instantly.
At a glance
- What is it?
- briehq/brie-extension is a React and Vite browser extension that captures screenshots, console errors, network failures and user actions, then produces a report link a developer can open. The client is open source under Apache-2.0, the backend is not, and the last push was on 2026-06-15.
- Who is it for?
- brie-extension fits a product team that keeps losing time to bug reports that say only that something broke, and it fits an engineer who wants to extend an existing browser extension rather than build a capture tool from scratch. It does not fit a team that needs to self-host the capture service, because this repository contains the extension client and the package is marked private, so the service side is not here to run.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 129 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 20, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A bug report that carries the browser state with it
The problem Brie addresses is not screenshot capture, it is the gap between a screenshot and a diagnosis. A user sends a picture of a broken screen, and the developer has to guess which endpoint failed, what the console said and what the user had just clicked. The extension is built to close that gap by collecting those things automatically and attaching them to the report.
The described feature set is four things: screenshots, console errors, network issues and user actions. The wording of the project is that Brie auto-captures console logs, network errors and user actions so developers get full context instantly, and the aim is to record exactly what went wrong without the back-and-forth of unclear reports and messy screenshots.
The output is a link. The quickstart describes sending the generated report link by email, by Slack or through any other platform, which is the detail that makes the tool work in practice. The person who hit the bug does not write anything, they click one icon, and the person who fixes it opens a link that already contains the context.
The trade-off is implicit in the design and worth stating plainly. The extension watches the page continuously so that it can capture what happened, and what it captures is then packaged into something you share with a third party service. Teams with credentials, personal data or internal hostnames in their logs should read the documentation on the service side before rolling this out to end users.
The quickstart is three steps inside the browser
Installation is not a build step for the end user. The documented flow is to add Brie from the project website, then pin the extension so it is easy to reach, click the Brie icon to capture and annotate a screenshot, and send the generated report link by email, Slack or any platform.
Two details in that sequence carry the design. Pinning is recommended, which tells you the extension is expected to be used while browsing, not opened after noticing a problem. And the capture step is described as taking a screenshot and annotating it, so the human adds what the automatic capture cannot know, which intent the user had, which button they meant to press.
The annotation is what makes the report a report rather than a dump. Console output and a network failure list are evidence, and a person drawing a circle around the part of the screen that is wrong is telling the developer which of those is the cause.
The project also publishes a documentation site at a separate address, and a Discord community. The documentation section in the repository README is present but commented out, so the live site is the place to look for the details of what is captured and what is sent.
A pnpm and Turborepo monorepo with two browser targets
The repository is a monorepo built on pnpm workspaces and Turborepo, with the extension living under `chrome-extension/`, shared code in `packages/`, marketing or landing pages in `pages/`, and end-to-end tests in `tests/`. The `packages/i18n/locales` directory holds the translations, and there is a `turbo.json` at the root that drives the task graph. The stack is React with Vite, and the project credits the Chrome extension boilerplate for React and Vite that it is built on.
The build scripts in `package.json` show the shape of the pipeline. There is a single zipper step for Chrome and one for Firefox, and a matching end-to-end test command for each:
"zip": "pnpm build:chrome:production && pnpm -F zipper zip",
"zip:firefox": "pnpm build:firefox:production && pnpm -F zipper zip",
"e2e": "pnpm zip && turbo e2e",
"e2e:firefox": "pnpm zip:firefox && turbo e2e",Two browser targets are therefore first class, which is unusual for an extension of this size and tells you the maintainers expect Firefox users to be a real audience.
The local development loop is driven by environment variables set through a helper script rather than by editing files. The Chrome local run sets `CLI_DEV`, `CLI_FIREFOX` and `CLI_ENV` before starting the dev build, and a `postinstall` hook copies the environment file into place, with `bash-scripts/` holding those helper scripts. Version bumps are also scripted, through `bash-scripts/update_version.sh`, and Husky is wired up as the `prepare` script for git hooks.
Contributions and fourteen README translations
The project invites contributions from people who are not customers, and points them at the issues labelled as good first issues, the contributing guide in `docs/CONTRIBUTING.md` and the `docs` folder as a whole. That is the entry point for anyone who wants to work on the extension itself.
The localisation surface is the other obvious contribution area, and it is unusually broad. The README is published in fourteen languages, with the Spanish, French, Romanian, Ukrainian, German, Simplified Chinese, Korean, Japanese, Italian, Russian, Arabic, Hindi and Tagalog versions living in the `docs/readme` directory. The instructions for adding another language are precise: add the locale under `packages/i18n/locales`, add the readme under `docs/readme`, and open a pull request.
The names of the two people behind the project are given in the README, Ion and Luminita, with a contact address, and they are also the two contributors listed in the package metadata. The repository carries a `CODE_OF_CONDUCT.md`, a `SECURITY.md` and a `CLAUDE.md`, which places it among projects that expect outside tooling and automated agents to work in the tree.
The licence is Apache-2.0, with the text in `LICENSE.md`, so the client code can be reused and modified under the usual conditions, including the requirement to keep the notices and state your changes.
What the open source repository does not include
The most important limitation is structural. The `package.json` sets `"private": true`, so the package is not published to a registry, and the release workflow in `.github/workflows/build-zip.yml` produces a zip for the browser stores rather than a library. What is open source here is the extension client, its build and its translations. The service that receives the captured data and serves the report link is not part of this repository.
That is a reasonable arrangement for a commercial product, and it also sets the boundary for anyone evaluating it. If your requirement is a self-hosted bug capture tool that runs on your own infrastructure, this repository does not get you there, because the report link has to point at a service that is not here.
A second point is about data, and the documentation is not detailed in the repository itself. Nothing in the project description says what is redacted before a report is sent, and the documentation section of the README is commented out, so the answer lives on the documentation site. Given that the extension captures console output, network errors and user actions, that question is worth answering before a customer-facing rollout rather than after.
The third point is timing. The last push was on 2026-06-15, and the newest releases are 0.6.60 from 2026-04-23, 0.6.50 from 2026-03-17 and 0.5.27 from 2025-11-20. The repository is not archived, but the open source side has been quiet for several months, which is a reasonable thing to weigh against a client that talks to a hosted service that can change its API.
Editorial conclusion
brie-extension fits a product team that keeps losing time to bug reports that say only that something broke, and it fits an engineer who wants to extend an existing browser extension rather than build a capture tool from scratch. It does not fit a team that needs to self-host the capture service, because this repository contains the extension client and the package is marked private, so the service side is not here to run. Check three things before you adopt it: that the report link your user will send is acceptable to share with a third party service, that the captured data is acceptable to leave the browser, and which version you pin, since the newest release is 0.6.60 from 2026-04-23 while the last push was on 2026-06-15, and neither the repository nor its releases have moved since.
Frequently asked questions
How do I install the Brie browser extension?
Add it from the project website, then pin the extension for quick access. The quickstart then has you click the Brie icon to capture and annotate a screenshot and send the generated report link by email, Slack or any other platform.
What does the Brie extension capture automatically?
The project describes automatic capture of console logs, network errors and user actions, alongside screenshots that you annotate yourself, so the report arrives with the browser context attached rather than as a bare image.
Does the Brie extension support Firefox?
Yes, there are separate build and end-to-end test scripts for Firefox, namely `zip:firefox` and `e2e:firefox`, alongside the Chrome equivalents in the package scripts.
Can I build the Brie extension from source?
The repository is a pnpm and Turborepo monorepo, and the scripts cover a development build, production builds, zipping and end-to-end tests. Local runs are configured through environment variables such as `CLI_DEV`, `CLI_FIREFOX` and `CLI_ENV`, set by a helper script in the bash-scripts directory.
What licence does the Brie extension use?
The repository is licensed under Apache-2.0 with the text in the LICENSE.md file, and the package metadata declares the same licence. The package itself is marked private, so the build is distributed as a zip rather than published to a registry.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/briehq-brie-extension)