[Feature]: Support extensions in the integrated browser #13979

I'd like to add an extension-development use case to this request, and I'd be happy to contribute a PR once we agree on the direction and scope.

I regularly develop Chrome extensions. I'd like the agent to build and test them inside T3 Code, with the same tool access it has to the preview browser today. The extension lifecycle and debugging need to be available through agent tools so the agent can complete the development loop without me manually loading extensions or switching to another browser.

The workflow

The agent should be able to:

• Load an unpacked extension from the project and list loaded extensions, their IDs, and status.
• Reload it after code changes and a build, and enable, disable, or remove it.
• Open and interact with its popup and options page, and test its content scripts on a target page.
• Inspect extension logs and errors, including its background page or Manifest V3 service worker, and access the relevant debugging targets.
• Use the preview browser's existing interaction and screenshot tools to check the result.

The loop would be: edit code → build → reload the extension → interact with it → inspect failures → fix and repeat. Full agent operation is the core requirement for me, including cleanup when testing is done.

A possible first scope

I'd start with unpacked local extensions in the desktop preview browser, scoped to a browser profile, with the agent tools needed for the workflow above. Chrome Web Store installation could stay outside that first version.

Electron's partial support for Chrome extension APIs is something we would need to establish up front, especially for Manifest V3 background workers and extension UI. I'd want us to agree on a tested set of supported capabilities and make unsupported cases explicit, rather than promise compatibility with every Chrome extension.

Before starting a PR

Would you be open to a contribution with this scope? Are there parts you would change, or technical checks you'd want to see before approving the direction?

I'm happy to help with a focused compatibility investigation first, then contribute the implementation, tests, and a recorded example of the agent completing the development loop.

+1, and I'd add an everyday-use case alongside testing. Without extensions the built-in browser is hard to use as a browser at all:

• Password managers (1Password, Bitwarden). Every sign-in in the panel is manual. Cookie import helps until a session expires, and it left saved passwords out of scope (feat(desktop): import browser cookies into a profile #7255).
• Ad and tracker blocking (uBlock Origin). Docs and search pages opened in the panel are much heavier than in my normal browser.
• Framework devtools (React DevTools, Redux DevTools, Vue DevTools) for the local previews the built-in browser is mostly used for.

Today the only workaround is switching to the system browser, which means losing the panel, annotations and agent automation.

Two shape suggestions:

1. Install from the Chrome Web Store or load unpacked, with an action-button slot in the panel toolbar for extension popups.
2. Agent-driven tabs default to extensions off, or follow a toggle, so an extension can't interfere with or observe preview_* automation unless the user opts in.

A password manager and uBlock working end to end would already cover most of the day-to-day value.

For anyone who wants extensions mainly to get Dark Reader–style dark pages in the integrated browser: Chromium's built-in auto dark mode covers that today, no extension needed. Start T3 Code with a Blink setting (macOS):

open -a "T3 Code (Nightly)" --args --blink-settings=forceDarkModeEnabled=true

(use "T3 Code" for the stable build). Light pages are recoloured dark; pages that already have their own dark theme keep it. I checked it on Electron 44.4.5, which current builds ship with.

Caveats: it only applies to a fresh launch (quit T3 first), it is on for every page until you relaunch without it, and an auto-update restart probably drops the flag. A "darken light pages" toggle in Settings → Browser that appends this switch at startup would make it permanent.

+1. Password manager support is the main thing I want here: 1Password, or Apple Passwords through its iCloud Passwords Chrome extension. Either would do. Right now every sign-in in the panel means copying and pasting from another app.

Related: on my macOS nightly (0.1.1-nightly.20261017.3272), 1Password and iCloud passkeys do not show up in the panel either. The system passkey path from #16952 looks like it is still waiting on the com.apple.developer.web-browser.public-key-credential entitlement, and the signed build does not include it yet.

+1 for the password-manager case, from daily web-app work in the desktop app (macOS).

I develop a web app in the built-in browser. Its session expires from time to time, and the browser cannot save or fill the password. Each time I must open another app, copy the password, and paste it into the panel. Cookie import from another browser helps only until the first logout.

Either of these would fix it for me:

• Load a password-manager extension (1Password, Bitwarden, or Apple Passwords) in a browser profile.
• Save and fill passwords per browser profile, with the values kept in the OS keychain.

The first option also covers the other cases in this thread, so I would prefer it.

+1 to @lukasbxy's extension-development scope. I ran into the same limit while developing an extension. Below is what current main does, plus an out-of-app comparison, to help settle the compatibility questions above.

Use case

I maintain a Manifest V3 extension built with WXT:

• A service worker that uses runtime.onMessage with an async response, IndexedDB, and host-permission fetch.
• A content script that replaces images on a third-party site.
• An action popup.

My project requires checking the real extension through its production entry points. A fixture or a passing build doesn't count. The agent can't do any part of that in the T3 browser today, so every verification pass means leaving T3.

What main does today (at 05b697f)

• Nothing loads extensions. apps/ and packages/ have no session.extensions.loadExtension / loadExtension call, and there's no setting, flag or env var that adds one.
• Profiles map to Electron partitions in apps/desktop/src/preview/BrowserSession.ts. Default and user-created profiles use persist:t3code-preview-…, while Incognito uses the in-memory t3code-preview-ephemeral-…. Electron loads extensions only into persistent sessions, so Incognito can't host one even in principle.
• The agent can see only the page target. In apps/desktop/src/preview/CdpRelay.ts, Target.getTargets returns a single target, and Target.attachToTarget rejects anything else with "Only this preview tab's page can be attached." Even if an extension were loaded, its service worker would be invisible to the tools.
• preview_evaluate runs in the page's main world (packages/contracts/src/previewAutomation.ts). It can observe a content script's DOM changes but not its isolated world.
• The server browser is chrome-headless-shell. As far as I know it doesn't support extensions, so this request seems limited to the desktop preview.

The same loop works outside T3, in a separate browser

• Chrome Stable 155: I used a dedicated --user-data-dir, --remote-debugging-port and chrome-devtools-mcp 1.11 with --categoryExtensions. The agent installed the unpacked build over CDP (Extensions.loadUnpacked), triggered the real action popup, listed the service-worker target and evaluated code in it. Branded Chrome 137 and later ignores --load-extension, but CDP loading still works.
• Playwright 1.63 with Chrome for Testing 153: with --load-extension, the agent loaded the build, ran code in the service worker, and found the content script's isolated execution context on the target site.

This works, but it gives up the reason I'd want it inside T3. There's no shared collaborative tab, panel or annotations, and every agent harness needs another MCP server configured separately.

Suggested first scope

This narrows the proposal above.

1. Unpacked extensions on persistent user-created profiles only. Profiles already exist in packages/contracts/src/browserProfile.ts. Default and Incognito stay extension-free, so ordinary agent tabs aren't affected or observed by an extension, which covers @tokyo-s's concern. No Chrome Web Store.
2. Load when the profile's session is created, since Electron must reload extensions on every launch. Report load errors and manifest warnings per extension instead of failing silently.
3. Agent operations: list (id, name, version, enabled, last error), load, reload and remove. Reload matters most, for the edit → build → reload → retest loop.
4. Debugging targets:
   • Expose an extension's service worker as a target, either in the relay or through a separate tool if the relay should stay single-target.
   • Let evaluation target that worker or the extension's isolated world on the current page.
   • Surface service-worker console errors the way page console entries are surfaced now.
5. Extension pages: opening chrome-extension://<id>/popup.html or the options page in a preview tab is enough for a first version. A toolbar action slot can come later. One known limitation should be documented: a popup opened as a tab isn't identical to a real action popup. For example, runtime.onMessage sees a sender.tab from the tab, and extensions that check the sender can behave differently.
6. An explicit compatibility list: Electron implements only part of the chrome.* APIs, and its documentation doesn't guarantee full support for MV3 service workers. A short tested list (content scripts, runtime messaging, storage.local, MV3 service worker, host-permission fetch), with everything else marked untested, would avoid an implied promise of Chrome compatibility.

Safety

• Off by default, opt-in per profile.
• Loading an unpacked extension gives code host permissions inside T3's browser. Agent-initiated loads could be limited to paths inside the thread's workspace, with other paths added only by the user in Settings.
• Unloading or removing an extension should clear its service worker and its storage for that profile.

Questions for maintainers

• Profile-scoped (Settings → Browser) or project-scoped (a workspace-relative path in project settings)? A project-scoped path fits the development case better; a profile-scoped one fits the password-manager case in this thread.
• Should loading extensions be a separate agent capability, alongside the existing browser-access capability?
• Would you rather extend CdpRelay to more targets, or add dedicated extension tools?

Environment

T3 Code Nightly 0.1.2-nightly.20261021.3499 (Electron 44.9.3, Chromium 152.0.7977.167), macOS 27.0.

I'm happy to test a candidate build against a real MV3 extension (service worker, content script and popup) and report which APIs work.

+1 to this, could also help with chrome extension development!

+1 for the password-manager case, at fleet scale.

With agents on several machines (macOS desktop + Linux servers), every sign-in in the integrated browser means copying a password from another app, per environment. Being able to install a password-manager extension (Bitwarden/Vaultwarden in our case, also 1Password) once and have it available in every environment's browser would solve most of it: the vault is already the synced source of truth, so T3 wouldn't need to sync credentials itself.

Pairs well with secret-reference filling (#25408) for agent-driven logins: the extension for humans, secretRef for agents.

+1 for the password-manager

I too need to be able to manage password and the integrated browser is borderline-unusable with the passwords I need.

Even just a native password manager would be enough to get by.

+1. I'd like a Browser extensions section in Settings to add an unpacked extension folder, turn each one on or off, and remove it, with the extensions staying loaded across restarts. My main use a custom chrome extension that I use.

+1 from macOS (T3 Code 0.1.7). My main case is 1Password.

I let agents work in a persistent browser profile on sites that need a login. Right now every sign-in means copying the password out of 1Password by hand. Cookie import helps until the session expires.

What would cover it for me:

• Chrome extensions in persistent profiles only, incognito stays clean.
• Native messaging, so the extension can unlock through the 1Password app. According to feat(desktop): run Chrome extensions such as 1Password in the preview browser maschwenk/t3code#3, 1Password only trusts code-signed apps added under Settings → Browser, so that part would only work in the signed build anyway.

maschwenk#3 and jakubzzak#50 show that it can run on Electron 44, with a shim for the extension APIs Electron is missing.

Related: the system passkey sheet from #16952 would also bring 1Password passkeys into the panel. In 0.1.7 it is still off (browserPasskeys: false), since it waits for Apple's approval.

@juliusmarminge is this realistic at some point, or is there something against it, e.g. security (extensions can see every page the agent opens) or the planned extension host? I'm not planning a PR, just want to know if it's worth waiting for.

+1