feat: move plugin loading to dedicated hidden BrowserWindow (Phase 1)

[jackkav]

Summary

Moves all plugin loading and execution out of the UI renderer into a dedicated hidden `BrowserWindow` with `nodeIntegration: true`. The renderer communicates with the plugin window exclusively over IPC.

What changed

• New hidden plugin window (`src/plugin-window.html` + `src/entry.plugin-window.ts`) — loads and executes all plugin code with Node.js access
• Preload for plugin window (`src/entry.plugin-window-preload.ts`) — provides `window.app.getPath` via `ipcRenderer.sendSync` so plugins can resolve `userData`
• Main process manager (`src/main/plugin-window.ts`) — creates the window; routes IPC via a pending-request map (UUID correlation, 10s ready timeout, sender validation, crash drain on close)
• IPC database proxy (`src/main/database.plugin-window.ts`) — plugin window reads from the main process NeDB connection via IPC instead of opening a second connection; services are initialized before the window signals readiness
• Serializable type boundary (`src/plugins/bridge-types.ts`) — all data crossing IPC is serializable; context modules run in the plugin window, not the renderer
• Renderer bridge (`window.main.plugins.*`) — all plugin execution replaced with bridge calls
• Build — two new esbuild entry points added; dev `buildCount` threshold updated from 3 → 6

Architecture

Renderer
  window.main.plugins.executeAction({ type, pluginName, label, projectId, domainData })
    └─ ipcRenderer.invoke('plugins.executeAction', args)
         └─ ipcMain.handle → invokeInPluginWindow('executeAction', args)
              └─ pluginWindow.webContents.send('plugin-invoke', { id, method, args })
                   └─ entry.plugin-window.ts: finds action, builds context, calls action(ctx, domainData)
                        └─ ipcRenderer.send('plugin-invoke-result', { id, result })
                             └─ main pendingRequests.get(id).resolve(result)
                                  └─ renderer Promise resolves

What's bridged (Phase 1 complete)

Feature	Status
Theme listing	✅
Plugin listing / reload	✅
Bundle plugin listing (`getBundlePlugins`)	✅
Request / RequestGroup / Workspace / Document actions (list + execute)	✅
Template tag listing (`getTemplateTags`)	✅
Template tag action execution (`runTemplateTagAction`)	✅
Elevated plugin main actions (`executePluginMainAction`)	✅
Request hooks / Response hooks	✅
Sandbox hardening	⏳ Phase 2 — `contextIsolation: true` once API surface is stable

Hook bridging design

Request and response hooks mutate their context objects by reference, which only works within a single process. To cross the IPC boundary the plugin window receives a serialized copy of the request/response, runs all registered hooks against it, and returns the fully mutated object — matching the same pattern used by pre-request scripts.

The built-in default-headers hook runs in the renderer without any IPC (it has no plugin dependency). A `hasRequestHooks`/`hasResponseHooks` result is cached in the main process after the first check and cleared on `reloadPlugins`, so requests incur zero plugin-window round-trips when no user plugins have hooks registered.

Non-renderer process handling

`_applyRequestPluginHooks` and `_applyResponsePluginHooks` guard on `process.type !== 'renderer'` before using the IPC bridge. In the Electron main process (OAuth token exchange) and in the inso CLI (Node.js), hooks are applied directly via `plugins.getRequestHooks()` / `plugins.getResponseHooks()` without any IPC.

Intentionally remaining in renderer

• `applyColorScheme` / `getColorScheme` — CSS/DOM manipulation, not plugin execution
• `createPlugin` — filesystem plugin scaffolding, not plugin execution

Security fixes (from review)

• `plugin-window-ready` and `plugin-invoke-result` validate `event.sender === pluginWindow.webContents`
• Persistent `ipcMain.on` listener (registered once) replaces `ipcMain.once` — plugin window re-arms correctly after reload
• `waitForReady()` has a 10s timeout and listens to `did-fail-load`
• Request IDs use `crypto.randomUUID()` instead of a guessable counter
• Non-Error plugin hook throws are wrapped into `Error` instances before attaching `.plugin` metadata

Playwright fixture

The plugin window is created after the main window's `did-finish-load` event, so Playwright's `firstWindow()` always returns the main app window. No fixture fallback or polling is needed.

Test plan

• All 1900 unit tests pass (`npm test -w packages/insomnia`)
• TypeScript: no errors (`tsc --noEmit`)
• E2E: `plugin-bridge.test.ts` — writes a test plugin, reloads via bridge, verifies the request action appears in the dropdown (16.7s, passes)
• Manual: themes settings panel — themes should populate
• Manual: reload plugins via keyboard shortcut — should complete without error
• Manual: plugin settings tab — installed plugins should list
• Manual: right-click a request — plugin actions should appear and execute
• Manual: cloud credentials settings — Azure auth flow should work

🤖 Generated with Claude Code

closes INS-2466

[Copilot]

Pull request overview

This PR moves plugin enumeration/loading for the UI renderer behind a dedicated hidden Electron BrowserWindow (with Node integration) and routes renderer-side plugin interactions through a typed IPC bridge, as the first phase toward renderer hardening.

Changes:

• Added a hidden “plugin window” (HTML + entry + preload) and a main-process manager that proxies plugin API calls over IPC.
• Updated UI codepaths (themes, plugin reload, settings plugins list) to call window.main.plugins.* instead of importing the plugin runtime directly.
• Introduced serializable bridge types plus new unit tests covering plugin behaviors and plugin hook handling; updated build/esbuild entrypoints to ship the new window scripts.

Reviewed changes

Copilot reviewed 24 out of 24 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
packages/insomnia/src/ui/renderer-listeners.ts	Route plugin reload through window.main.plugins.reloadPlugins()
packages/insomnia/src/ui/hooks/use-global-keyboard-shortcuts.ts	Route plugin reload shortcut through the plugins bridge
packages/insomnia/src/ui/hooks/theme.ts	Fetch themes via plugins bridge instead of direct plugin API call
packages/insomnia/src/ui/components/settings/plugins.tsx	Use SerializablePlugin and fetch plugin list via bridge
packages/insomnia/src/root.tsx	Reload plugins via bridge during theme install/apply flow
packages/insomnia/src/plugins/index.ts	Add test helper to control in-memory plugin list
packages/insomnia/src/plugins/bridge-types.ts	Define serializable plugin/theme/action metadata boundary + bridge API
packages/insomnia/src/plugins/tests/themes.test.ts	Add baseline tests for built-in theme list + plugin theme merge behavior
packages/insomnia/src/plugins/tests/index.test.ts	Add broad unit tests for plugin exports (hooks/actions/tags/themes) and errors
packages/insomnia/src/plugin-window.html	Add HTML host for hidden plugin window script
packages/insomnia/src/network/network.ts	Export internal hook-application helpers for unit testing
packages/insomnia/src/network/tests/plugin-hooks.test.ts	Add unit tests around request/response plugin hook behavior
packages/insomnia/src/main/window-utils.ts	Create plugin window during window initialization; export destroy helper
packages/insomnia/src/main/plugin-window.ts	Implement plugin window lifecycle + IPC proxying + pending request map
packages/insomnia/src/main/ipc/main.ts	Add plugins bridge type to main IPC surface; register plugin IPC handlers
packages/insomnia/src/main/ipc/electron.ts	Extend IPC channel type unions for new plugin channels
packages/insomnia/src/entry.preload.ts	Expose window.main.plugins.* bridge methods in renderer preload
packages/insomnia/src/entry.plugin-window.ts	Implement plugin-window-side dispatcher and result serialization
packages/insomnia/src/entry.plugin-window-preload.ts	Provide minimal window.app shim to support plugin path resolution
packages/insomnia/scripts/build.ts	Copy plugin-window HTML into production build output
packages/insomnia/esbuild.entrypoints.ts	Add esbuild entrypoints/watchers for plugin window + preload bundles
packages/insomnia/PLUGIN_SYSTEM_POC.md	Add architecture/plan documentation for the plugin system POC
packages/insomnia-smoke-test/playwright.config.ts	Change local reporter configuration
AGENTS.md	Add guidance on minimizing command output and cx navigation

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ryan-willis]

clean 👍🏻

[ryan-willis]

I'd prefer to keep this in Confluence

[jackkav]

Its easier for the llm to reference here. I'll get rid of it once the work is done though and can add it to confluence for posterity.

[ZxBing0066]

Some plugin APIs that rely on the main window (e.g., showAlert, showWrapper) will trigger errors following this change. These APIs may require bridging to the main window to maintain functionality.

And if the previous plugins depend on some of the window APIs, like height and width, they also break. As well as if the plugins are trying to append DOMs. Is this acceptable?

[jackkav]

feedback concern:
chome web apis that show UI will need bridges, or be excluded from supported features.
await window.showOpenFilePicker();

templating now runs in main, which means templating has access to nodejs again, temporarily.

injecting custom UI, in to the DOM won't work anymore, because it was using ambiant renderer libraries like React. We could add these to the plugin context and build bridges but this would be securable.