Feature: Support loading additional extensions alongside main extension

[0xBigBoss]

Feature Request: Support loading additional extensions via additionalExtensions config

Repository: https://github.com/wxt-dev/wxt

Summary

Add support for loading additional extensions alongside the WXT extension during development via a new additionalExtensions config option in webExt.

Use Case

When developing browser extensions with WXT, developers often need to load multiple extensions simultaneously:

1. WebAuthn Testing: Extensions using WebAuthn require a virtual authenticator extension for automated testing
2. Debugging Tools: Loading React DevTools or Redux DevTools alongside the main extension
3. Integration Testing: Testing interactions between multiple extensions
4. Development Helpers: Loading helper extensions that provide test fixtures or mock APIs

Currently, developers must manually load additional extensions through chrome://extensions after WXT opens the browser, which:

• Breaks the development workflow
• Doesn't persist across browser restarts in dev mode
• Can't be automated in CI/Tilt environments

Proposed API

Add an additionalExtensions config option to the webExt configuration:

// wxt.config.ts
export default defineConfig({
  webExt: {
    startUrls: ['http://localhost:3000'],
    // New option: array of paths to additional extension directories
    additionalExtensions: [
      '/path/to/webauthn-extension',
      '/path/to/devtools-extension',
    ],
  },
})

TypeScript Types

interface WebExtConfig {
  // ... existing options

  /**
   * Additional extension directories to load alongside the main extension.
   * Useful for loading helper extensions like WebAuthn authenticators or debugging tools.
   * Only supported for Chromium browsers.
   */
  additionalExtensions?: string[];
}

Proposed Implementation

Pass the additionalExtensions array to web-ext-run as additionalSourceDirs:

// dist/core/runners/web-ext.mjs
const finalConfig = {
  ...userConfig,
  target: wxt.config.browser === "firefox" ? "firefox-desktop" : "chromium",
  sourceDir: wxt.config.outDir,
  // Pass additional extensions to web-ext-run
  additionalSourceDirs: wxtUserConfig?.additionalExtensions ?? [],
  noReloadManagerExtension: true,
  noReload: true,
  noInput: true,
};

Diff

--- a/dist/core/runners/web-ext.mjs
+++ b/dist/core/runners/web-ext.mjs
@@ -50,6 +50,8 @@ export function createWebExtRunner() {
         target: wxt.config.browser === "firefox" ? "firefox-desktop" : "chromium",
         sourceDir: wxt.config.outDir,
         // Don't add a "Reload Manager" extension alongside dev extension, WXT
+        // Support loading additional extensions (requires web-ext-run support)
+        additionalSourceDirs: wxtUserConfig?.additionalExtensions ?? [],
         // already handles reloads intenrally.
         noReloadManagerExtension: true,
         // WXT handles reloads, so disable auto-reload behaviors in web-ext

Example Usage

// wxt.config.ts
const webAuthnExtensionPath = process.env.WEBAUTHN_EXTENSION_PATH;

export default defineConfig({
  modules: ['@wxt-dev/module-react'],

  webExt: {
    startUrls: ['http://localhost:5174'],
    ...(webAuthnExtensionPath ? {
      additionalExtensions: [webAuthnExtensionPath],
      // Optionally use persistent profile for auth state
      chromiumProfile: process.env.CHROME_PROFILE_DIR,
      keepProfileChanges: !!process.env.CHROME_PROFILE_DIR,
    } : {}),
  },
})

Dependencies

This feature requires web-ext-run to support loading multiple extensions. A corresponding feature request should be filed there for additionalSourceDirs support.

Upstream issue: (link to web-ext-run issue when created)

Notes

• Additional extensions are loaded via CDP Extensions.loadUnpacked (Chrome 126+) or --load-extension flag (older versions)
• Only the main WXT extension receives HMR/reload capabilities
• Additional extensions are loaded once at browser startup
• Only supported for Chromium browsers (Chrome, Edge, etc.)

Alternatives Considered

1. Using chromiumArgs with --load-extension: Doesn't work with Chrome 126+ which uses CDP instead of the flag
2. Post-launch CDP injection: Would require connecting to Chrome's debugging port separately, adding complexity

Real-World Use Case

We're building a Canton Network wallet extension that uses WebAuthn for authentication. During development and E2E testing with Playwright, we need to load a virtual WebAuthn authenticator extension alongside our main extension. This feature would enable:

# Tiltfile
if enable_webauthn:
    extension_env["WEBAUTHN_EXTENSION_PATH"] = webauthn_extension_path

Without this feature, we have to use complex workarounds involving CDP injection scripts that are fragile and don't integrate well with WXT's development workflow.

[0xBigBoss]

Feature Request: Support loading multiple extensions via additionalSourceDirs

Repository: https://github.com/wxt-dev/web-ext-run

Summary

Add support for loading additional extensions alongside the main extension during development. This enables scenarios where developers need to test their extension alongside helper extensions (e.g., WebAuthn authenticators, debugging tools).

Use Case

When developing browser extensions, developers often need to load multiple extensions simultaneously:

1. WebAuthn Testing: Testing extensions that use WebAuthn require a virtual authenticator extension
2. Debugging Tools: Loading React DevTools or other debugging extensions alongside the main extension
3. Integration Testing: Testing how multiple extensions interact with each other
4. Development Helpers: Loading helper extensions that modify browser behavior for testing

Currently, web-ext-run only supports loading a single extension via sourceDir. Developers must manually load additional extensions through chrome://extensions, which breaks the development workflow.

Proposed API

Add an additionalSourceDirs parameter to the run() function:

export default async function run({
  // ... existing parameters
  sourceDir,
  // New parameter
  additionalSourceDirs = [],
  // ...
}, options) {
  // ...
}

Proposed Implementation

The implementation is straightforward - add additional extensions to the extensions array that gets passed to the browser runner:

const runners = [];
// Build extensions array with main extension and any additional ones
const extensions = [{
  sourceDir,
  manifestData
}];

// Add additional extensions (Chromium only - no manifest validation needed)
for (const additionalDir of additionalSourceDirs) {
  const resolvedDir = path.resolve(additionalDir);
  log.info(`Adding additional extension from ${resolvedDir}`);
  extensions.push({ sourceDir: resolvedDir });
}

const commonRunnerParams = {
  extensions,
  // ... rest of params
};

Diff

--- a/lib/cmd/run.js
+++ b/lib/cmd/run.js
@@ -45,7 +45,9 @@ export default async function run({
   // Chromium CLI options.
   chromiumBinary,
   chromiumPref,
-  chromiumProfile
+  chromiumProfile,
+  // Additional extensions to load (array of source directories)
+  additionalSourceDirs = []
 }, {
   buildExtension = defaultBuildExtension,
   desktopNotifications = defaultDesktopNotifications,
@@ -91,12 +93,20 @@ export default async function run({
     }
   }
   const runners = [];
+  // Build extensions array with main extension and any additional ones
+  const extensions = [{
+    sourceDir,
+    manifestData
+  }];
+  // Add additional extensions (Chromium only - no manifest validation needed)
+  for (const additionalDir of additionalSourceDirs) {
+    const resolvedDir = path.resolve(additionalDir);
+    log.info(`Adding additional extension from ${resolvedDir}`);
+    extensions.push({ sourceDir: resolvedDir });
+  }
   const commonRunnerParams = {
     // Common options.
-    extensions: [{
-      sourceDir,
-      manifestData
-    }],
+    extensions,
     keepProfileChanges,
     startUrl,
     args,

Notes

• The ChromiumExtensionRunner already supports multiple extensions in its params.extensions array
• Additional extensions don't need manifest validation since they're assumed to be pre-built
• This only affects Chromium browsers (Chrome/Edge/etc.) - Firefox has different extension loading mechanisms
• The main extension retains full reload/watch capabilities; additional extensions are loaded once at startup

Alternatives Considered

1. Using --load-extension flag via args: Doesn't work with Chrome 126+ which uses CDP Extensions.loadUnpacked instead of the deprecated flag
2. CLI --source-dir multiple times: Would require significant CLI parsing changes

Related

• WXT feature request for additionalExtensions config (enables WXT users to use this feature)

[isaacherbst613]

+1 for this feature

for now I use this workaround in web-ext.config.ts

export default defineWebExtConfig({
  chromiumArgs: [`--load-extension=${path.resolve('.output', 'chrome-mv3-dev')},${filepath to your installed extension}`],
})

${path.resolve('.output', 'chrome-mv3-dev')} is for the wxt extension you're developing

[0xBigBoss]

+1 for this feature

for now I use this workaround in web-ext.config.ts

export default defineWebExtConfig({
  chromiumArgs: [`--load-extension=${path.resolve('.output', 'chrome-mv3-dev')},${filepath to your installed extension}`],
})

${path.resolve('.output', 'chrome-mv3-dev')} is for the wxt extension you're developing

I tried this, but didn't work for me. Recent version of chrome disabled that I thought. You need to use a different branded chromium.
mozilla/web-ext#3388
https://groups.google.com/a/chromium.org/g/chromium-extensions/c/aEHdhDZ-V0E/m/UWP4-k32AgAJ

[isaacherbst613]

Oh, that's correct. I had downloaded an older version of chromium and point wxt to that...

[PatrykKuniczak]

Sounds good, it won't affect current code base, because it'll be optional, i think you can implement it without hesitation, i hope @aklinker1 is open for new features like this :)