Electron MCP Server

@yawlabs/electron-mcp

One click adds this to your local Yaw MCP config so it's available in every Yaw Terminal session. Or install manually below.

Make your AI assistant actually good at Electron. 18 tools for the stuff AI models hallucinate about: context isolation, preload bridges, fuses, CSP, signing, auto-updates, breaking changes between majors, and the 20 official security recommendations.

This is not a runtime debugger. It is a development-intelligence layer that turns "write me some Electron code" from hit-or-miss into correct-on-the-first-try.

Built and maintained by Yaw Labs.

Why this one?

Other Electron MCP servers give your model a shell and hope. This one doesn't.

• IPC that isn't a security hole — electron_scaffold_ipc_channel generates main handler + typed preload bridge + contextBridge exposure + renderer usage in one call. No nodeIntegration: true, no direct ipcRenderer on window.
• The official security recommendations, enforced — electron_audit_security checks your BrowserWindow config, preload scripts, and CSP against 19 of the 20 items from electronjs.org/docs/latest/tutorial/security that can be verified from static inputs. (The 20th, session permission handling, needs runtime context and is flagged in the report footer.) Not a vibe check.
• Version-aware migration — electron_migrate_version knows the breaking changes from v28 through v41 and tells you exactly what will break when you bump. electron_check_deprecated_apis scans your code for APIs that were removed.
• Build errors, explained — electron_diagnose_build_error parses electron-builder/forge output and identifies root causes: Apple signing, Windows code signing, native module rebuilds, ASAR packaging, entitlements, path quoting.
• Modern production hardening — electron_configure_fuses generates the @electron/fuses block for disabling unused runtime features (cookie encryption, Node CLI flags, legacy load behaviour). electron_configure_csp generates a CSP that actually works with your bundler and framework instead of blocking your own assets.
• Knowledge freshness is declared, not assumed — every response includes a _Knowledge last verified YYYY-MM-DD (Electron vN stable)_ footer. Call electron_knowledge_version to get the metadata directly. If your Electron is newer than the footer, the tool tells you.
• Read-only, no side effects — every tool declares readOnlyHint, destructiveHint: false, idempotentHint: true, so MCP clients can skip confirmation. The tools never touch your filesystem, never run code, never call exec.
• Zero runtime dependencies — ships as a single bundled file. No 5-minute node_modules install, no electron or electron-builder installed as dependencies to inflate your project. The published package's dependencies is {}; Dependabot alerts on this repo are against devDependencies. Most of that surface (the MCP SDK's HTTP transport: hono, express, ip-address, qs) is not in the bundle — this server uses stdio only — but fast-uri, which the SDK's default JSON Schema validator (ajv) needs, is inlined into dist/index.js, so an advisory against it is cleared by a new release, not by reinstalling.

Quick start

No API keys. No environment variables required. Just install it.

1. Create `.mcp.json` in your project root

macOS / Linux / WSL:

{

"mcpServers": { "electron": { "command": "npx", "args": ["-y", "@yawlabs/electron-mcp@latest"] } } }

Windows:

{

"mcpServers": { "electron": { "command": "cmd", "args": ["/c", "npx", "-y", "@yawlabs/electron-mcp@latest"] } } }

Why the extra step on Windows? Since Node 20, child_process.spawn cannot directly execute .cmd files (that's what npx is on Windows). Wrapping with cmd /c is the standard workaround.

2. Restart and approve

Restart Claude Code (or your MCP client) and approve the Electron MCP server when prompted.

That's it. Now ask your AI assistant:

"Add a file picker to my Electron app"

"Audit my BrowserWindow config for security issues"

"My electron-builder is failing with a signing error — here's the output"

"Generate a CSP for my Vite + React renderer"

"What breaks if I upgrade from Electron 32 to 41?"

Alternate MCP clients

Use the same JSON block shown above in any of these.

Runtime and sandbox

The launcher prefers the oam runtime when a current one (0.19.1 or newer) is installed, and falls back to the Node that is already running it. Nothing to configure; both serve the same server.

Opt-in sandbox. With oam, the server can run under --permission with no grants at all: no filesystem, no child processes, no network, no environment. This server needs none of them (every tool computes over its arguments and returns markdown), so the sandbox costs no capability and turns anything the server merely happens not to use into a runtime refusal. Add an env block to whichever config block you used above (npx on macOS / Linux / WSL, cmd /c npx on Windows):

"env": { "ELECTRON_MCP_SANDBOX": "1", "ELECTRON_MCP_RUNTIME": "oam" }

The second variable is what makes the sandbox required: it needs a freshly spawned oam (0.19.1 or newer) to apply it, and with ELECTRON_MCP_RUNTIME=oam a missing or unusable oam is a startup error instead of an unsandboxed server. Under the default ELECTRON_MCP_RUNTIME=auto the launcher still serves in that case, without --permission, and prints a line on stderr saying so and how to fix it. Use auto when you want the sandbox where available; use oam when you want to be sure.

How to tell it took: every path that serves without the sandbox after it was asked for prints an electron-mcp: line on stderr containing runs WITHOUT --permission, plus how to fix it (most MCP clients show server stderr in their logs). When the sandbox is applied there is no such line. To confirm from a shell:

ELECTRON_MCP_SANDBOX=1 ELECTRON_MCP_RUNTIME=oam npx -y @yawlabs/electron-mcp@latest --version

The version on stdout, exit 0, and no WITHOUT --permission line means a sandboxed oam served it; with ELECTRON_MCP_RUNTIME=oam set, a missing oam is an error instead.

It is off by default because it is a behaviour change: a future version that legitimately needs a capability should fail in review, not in your session. Two more things to know:

• If the launcher itself is already running under oam (Yaw MCP does this), the sandbox spawns a second oam (the host's own binary, if nothing newer is installed), because only a fresh one can apply a process-level flag. That adds one runtime boot to startup, plus a --version probe per oam binary the launcher finds.
• Request the sandbox through the variable, not by putting --permission on the host command: a launcher running under bare --permission cannot read its environment, so every ELECTRON_MCP_* setting would be ignored. A host that also grants --allow-env (with --allow-child-process) does let them through; then a handoff to Node (ELECTRON_MCP_RUNTIME=node, or a host oam below the floor) runs node --permission with no grants, because oam otherwise copies the host's --permission / --allow-* flags into Node's NODE_OPTIONS and Node refuses oam-only ones such as --allow-env= (exit 9, nothing served); the launcher prints one electron-mcp: line saying so. (The direct, no-launcher form is oam --permission run /dist/index.js.)

Both values are case-insensitive and trimmed. A value the launcher does not recognise is never a silent no-op: it is treated as the default (auto; sandbox off) and named on stderr, so a typo cannot quietly turn "sandbox required" into "sandbox if convenient".

Tools (18)

IPC & process architecture (5)

• electron_scaffold_ipc_channel — Generate a complete IPC round-trip: main handler, preload bridge, contextBridge exposure, TypeScript types, renderer usage.
• electron_generate_preload_bridge — Generate a secure preload.ts with contextBridge for multiple API methods.
• electron_audit_ipc_security — Analyze preload/main/renderer code for IPC security issues (direct ipcRenderer, missing sender validation, channel injection).
• electron_generate_window_manager — Multi-window management with lifecycle tracking and inter-window communication.
• electron_explain_process_model — Version-aware explanation of Electron's multi-process architecture (main vs renderer vs utility, what lives where).

Security (4)

• electron_audit_security — Audit against 19 of the 20 official security recommendations that can be detected from static inputs: BrowserWindow, preload, CSP, remote content, sandbox. (Session permission handling is the 20th; it needs runtime context and is flagged in the report footer.)
• electron_configure_fuses — Generate @electron/fuses config for production hardening (disable cookie encryption fallback, Node CLI flags, legacy load behaviour).
• electron_configure_csp — Generate a Content Security Policy aware of your bundler (Vite/webpack/Parcel) and framework (React/Vue/Svelte).
• electron_lint_security — Static analysis for dangerous patterns: shell.openExternal with untrusted input, @electron/remote, enableBlinkFeatures, etc.

Build & distribution (4)

• electron_diagnose_build_error — Parse electron-builder/forge errors and identify root causes: code signing, native modules, ASAR, entitlements, path quoting.
• electron_configure_auto_update — Generate complete electron-updater setup with events and platform-specific signing concerns.
• electron_configure_deep_linking — Custom protocol registration across Windows/macOS/Linux.
• electron_scaffold_project — Generate a secure, modern Electron project scaffold (contextIsolation: true, sandbox: true, preload, TypeScript, chosen framework).

Migration & compatibility (2)

• electron_migrate_version — Migration checklist between Electron versions with breaking changes, deprecated APIs, platform support changes.
• electron_check_deprecated_apis — Scan source for APIs deprecated or removed in the target Ele