feat(native-messaging): Add Native Messaging Host with MCP Server for external script management

[icacaca]

Summary

This PR adds Native Messaging support to ScriptCat, enabling external tools (AI assistants, CLI tools) to manage user scripts through the MCP (Model Context Protocol).

Architecture

AI ←HTTP/SSE→ [MCP Server :3333] ←EventEmitter→ [NativeHost → stdio → Browser Extension]

Changes

• Extension Side: NativeMessageHandler in Service Worker handles Native Messaging connections

  • 6 operations: list_scripts, get_script, install_script, uninstall_script, enable_script, disable_script
  • Proactively connects to native host on startup via chrome.runtime.connectNative()
  • Bidirectional message passing with error handling

• Native Host Side: packages/native-messaging-host/ unified process

  • NativeHost: stdio protocol (4-byte LE length-prefixed JSON) for browser communication
  • MCP Server: HTTP+SSE transport on port 3333 for AI/CLI integration
  • Internal message bus via EventEmitter
  • Port conflict handling (EADDRINUSE graceful skip)

• ScriptService: Added getScriptAndCode() for retrieving script metadata + source code

• manifest.json: Added nativeMessaging permission

• PROTOCOL.md: Complete JSON message protocol documentation

Use Case

This enables AI coding assistants (like Cursor, Claude, etc.) to directly manage ScriptCat user scripts through the MCP protocol — installing, updating, enabling/disabling scripts without manual browser interaction.

Test Plan

• Build extension successfully
• Native Messaging connection established between extension and native host
• MCP Server responds to initialize, tools/list, tools/call JSON-RPC requests
• End-to-end test: install/list/get/enable/disable/uninstall scripts via MCP
• Port conflict handling verified

Files Changed (12 files, +1379 lines)

File	Change
src/manifest.json	Added nativeMessaging permission
src/app/service/service_worker/index.ts	Initialize NativeMessageHandler
src/app/service/service_worker/native_msg.ts	New: Native Messaging message handler
src/app/service/service_worker/script.ts	Added getScriptAndCode() method
packages/native-messaging-host/src/index.ts	New: Unified Native Host + MCP Server
packages/native-messaging-host/PROTOCOL.md	New: Protocol documentation
packages/native-messaging-host/manifest.json	New: Native Host registration manifest
packages/native-messaging-host/install.ps1	New: Windows registry installation script
packages/native-messaging-host/package.json	New: Package config
packages/native-messaging-host/tsconfig.json	New: TypeScript config
packages/native-messaging-host/launch.js	New: Launch helper
packages/native-messaging-host/launch.mjs	New: ESM launch helper

[CodFrm]

Thank you very much. I’m also planning to provide MCP for ScriptCat, and the communication protocol should be similar to this PR. However, I haven’t yet decided on the exact form of how to provide it — let me think it over a bit more.

[cyfung1031]

ScriptCat will build the skills (e.g. the six skills you mentioned) required inside the extension.
If you allow Native Messaging connections to let external to call ScriptCat's commands, it might become a security weak point to ScriptCat and to your PC. (Your extension or any web app can use the MCP address to let ScriptCat to install and run the malware coding)

This will also make Chrome Store, Edge Store to reject ScriptCat's publications.

[cyfung1031]

Review of PR #1465

Verdict: this PR should not be merged in its current form. The feature direction is useful, but the implementation creates a broad unauthenticated local control plane for installing, reading, enabling, disabling, and deleting user scripts. That is too sensitive for a browser extension that executes user-provided JavaScript.

The PR adds nativeMessaging permission, starts a NativeMessageHandler from the service worker, and exposes six operations: list_scripts, get_script, install_script, uninstall_script, enable_script, and disable_script. It also adds a native host that runs an MCP HTTP/SSE server on 127.0.0.1:3333, forwarding requests to the extension over native messaging.

Discussion summary

CodFrm’s maintainer comment is cautious rather than rejecting the idea outright: ScriptCat may provide MCP support in the future, and the protocol could be similar, but the official integration form has not been decided yet.

The security criticism is the key blocker: exposing ScriptCat commands through Native Messaging plus a local MCP endpoint becomes a security weak point. A local web app, local process, or compromised MCP client could potentially instruct ScriptCat to install and run malicious userscript code. There is also a serious risk that Chrome Web Store and Edge Add-ons review may reject the extension because of this expanded external execution/control surface.

Major blockers

1. No authentication or authorization on the MCP endpoint

The native host exposes HTTP/SSE on localhost and uses broad CORS behavior. The implementation does not show a secret token, session authorization, user confirmation, origin allowlist, or capability negotiation before privileged actions.

For read-only tools, this might be manageable. For install_script, enable_script, and disable_script, it is not.

2. install_script can install arbitrary code

The extension-side handler accepts either a URL or raw code, then calls script installation APIs. This gives an external MCP client a direct path to add executable userscript code into ScriptCat.

A safer first version should probably be read-only: list_scripts and possibly get_script, with write operations gated behind explicit in-extension confirmation.

3. Service worker proactively connects to the native host

The service worker starts native messaging automatically when connectNative exists. That changes ScriptCat’s baseline behavior for all users and builds with the permission, rather than making MCP an opt-in developer feature.

This should be opt-in, probably disabled in store builds, and controlled by a setting with clear security warnings.

4. Store review risk is real

Adding nativeMessaging to the manifest is a substantial permission increase. Combined with a local server that allows external tools to install scripts, it creates a hard-to-explain review story: the extension can be controlled by a native app, and that native app exposes script installation to other local clients.

Even if technically allowed, this needs a polished threat model, user consent UX, and store-review justification. The current PR reads more like an experimental developer bridge.

5. Hardcoded and environment-specific native host manifest

The native host manifest includes a Windows path under C:\Users\Administrator\... and a specific extension origin. That is not portable and should not be committed as-is. The install script mutates the manifest, but the checked-in default is still environment-specific.

6. The protocol is too permissive for a first integration

The PR’s stated use case is AI assistants directly managing ScriptCat scripts, including installing, updating, enabling, and disabling scripts. That is exactly the high-risk case. MCP tools can be invoked by agents that may be prompt-injected or confused by malicious webpage content. A bridge that lets them install browser-executed scripts needs stronger controls than ordinary local developer tooling.

Recommended path forward

Suggested response:

Thanks for the contribution. The protocol direction is close to what ScriptCat may want, but this implementation exposes privileged script-management operations through a local MCP/native-messaging bridge without an authorization model, user confirmation, or store-review threat model. In particular, install_script with raw code/URL and automatic native-host connection are too risky for ScriptCat as a browser extension.

A better next step would be a design proposal first. A safe initial scope could be read-only MCP tools, disabled by default, with no nativeMessaging permission in the main store build. Write operations should require explicit in-extension user approval, capability-scoped tokens, origin/client allowlisting, audit logs, and possibly a separate developer build or companion app.

Practical merge recommendation

Request changes / do not merge. The maintainer’s “let it be considered before deciding the official form” position is appropriate, and the security objection is strong. The PR should be redesigned as an opt-in, capability-scoped, user-confirmed integration rather than merged as a broad external control interface.