electron-browser-shell: a tabbed Electron browser built as a Chrome extension testbed

A tabbed browser that exists to host extension support

electron-browser-shell is described as a minimal, tabbed web browser with support for Chrome extensions, built on Electron. The description is accurate but understates why the project is interesting. The README is explicit that the shell package is a minimal, tabbed web browser used as a testbed for development of Chrome extension support. In other words, the browser is the fixture, not the product. Electron ships with a Chromium runtime, so the hard part of running a Chrome extension is not the browser shell with tabs, it is the extension API surface, the packaging, the installer and the update path. This repository is where that work is assembled in one place, in TypeScript, with the browser app sitting alongside the packages that make extensions possible.

Four packages, split by the capability each one adds

The workspace layout explains the architecture more clearly than any prose would. The root package.json declares four workspaces: packages/shell, packages/electron-chrome-extensions, packages/electron-chrome-context-menu and packages/electron-chrome-web-store. The shell is the browser application itself. electron-chrome-extensions adds the additional API support that Chrome extensions expect from Electron, and it is the package that carries the tests, since the root test script delegates to the extensions package test target. electron-chrome-context-menu supplies a Chrome-style context menu for Electron browsers, and electron-chrome-web-store handles downloading extensions from the Chrome Web Store. The build scripts mirror that split, with separate build:context-menu, build:chrome-web-store, build:extensions and build:shell targets, and the root build script chains them in that order.

Running it from source takes a clone and two yarn commands

The README documents a source workflow rather than a packaged download, and there is no install command beyond the package manager itself:

# Get the code
git clone [email protected]:samuelmaddock/electron-browser-shell.git
cd electron-browser-shell

# Install and launch the browser
yarn
yarn start

The launch script is not a thin wrapper. The start script builds the context menu, the extensions package and the Web Store package, and then runs the shell package's own start target, so a first run compiles three packages before the window opens. Several debug variants exist for development work: start:debug sets DEBUG to the electron scope, start:electron-dev points Electron at a locally built distribution and enables Electron logging, and start:skip-build runs the shell without rebuilding the workspace packages. Formatting is handled by prettier over js, jsx, ts, tsx, json and css files, and husky is wired in as the prepare script for git hooks.

Three ways to get an extension into the browser

Extension loading is where the checked items on the roadmap sit, and there are three distinct paths. The first is the unpacked extension loader, which is the one that matters for development. The README says to test local unpacked extensions by including them in the ./extensions directory and then launching the browser, so an extension under development is placed in a folder inside the repository rather than installed through any UI. The second is the .CRX extension loader, which covers the packaged form Chrome used before the Web Store. The third is the Chrome Web Store extension installer, provided by the electron-chrome-web-store package, and the README states that the workflow for a user is simply to navigate to the Chrome Web Store and install an extension, with the browser handling the download. Automatic extension updates are also listed as done, which means the installer path is not a one-off copy into a directory.

The roadmap is candid about the Chrome APIs still missing

The roadmap is more useful than the feature list, because the unchecked boxes define what will break. Under Current, the completed items include browser tabs, the unpacked loader, an initial chrome.tabs extension API, initial extension popup support, the .CRX loader, the Chrome Web Store installer, automatic extension updates and Manifest V3 support, which is annotated as pending on electron/electron#44411. The open items are telling. Support for common chrome.* extension APIs is not done, improved extension popup support is not done, and respecting extension manifest permissions is not done. That last one matters for anyone evaluating the project seriously: an extension can be installed and run without the shell enforcing the permissions its manifest declares. Further out sit extension management with enable, disable and uninstall, an installation prompt experience, a Microsoft Edge Add-ons installer and full chrome.* API coverage.

Licensing is split across the packages and the repository

The licence story has two layers and people often conflate them. The repository metadata reports GPL-3.0, while the README states that most packages in the project use MIT with the exception of electron-chrome-extensions, which is the package that adds the extension API support. A commercial path also exists: for proprietary use the README asks people to contact the author or sponsor them under the appropriate tier to acquire a proprietary-use licence, with the terms in LICENSE-PATRON.md, and explains that those contributions make the maintenance work sustainable. On top of that sits a contributor licence agreement, under which sending a pull request grants a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright licence over the contribution, and grants the project owners the right to relicense the contributed code and its derivative works. Read those files before embedding the packages in a product.

No GitHub releases, and the last push was on 2026-09-01

There are no GitHub releases for this repository, so there is no tagged artifact to point at, and the version field in the root package.json reads 1.0.0 while the package is marked private. That combination means the project is best consumed from source, exactly as the README workflow does, and that there is no upgrade path to speak of beyond pulling the master branch. The last push was on 2026-09-01, which puts the work roughly seven weeks back from the present without making the repository stale, since Electron and the extension APIs move quickly and this code tracks both. The practical upgrade cost is therefore a git pull and a rebuild of the workspace packages, and the risk to plan for is that the pending Manifest V3 dependency on electron/electron#44411 can change behaviour in either direction when that upstream change lands.

Editorial conclusion

electron-browser-shell fits someone building Chrome extension support inside Electron, or anyone who wants a tabbed Electron browser that can load extensions from a Chrome Web Store account. It does not fit a team shipping a consumer browser, because the roadmap still lists common chrome.* API support, improved extension popup handling and manifest permission enforcement as unfinished, and Manifest V3 support is marked pending on an upstream Electron issue. Before adopting it, read the licensing split, since the repository carries GPL-3.0 while most packages are MIT, and confirm that the extension APIs your target extension calls are covered by the implemented items rather than the pending ones.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. samuelmaddock/electron-browser-shell on GitHub