Skip to main content

​
Mini App runtime

A Mini App’s Node code runs locally as the current user, just like local plugins and MCP servers. It can read and write any file the user can access, start programs, and make network requests. Install Mini Apps only from sources you trust, and read the README before installing to see what data it accesses.The host doesn’t use operating-system sandboxes such as seccomp or seatbelt, mainly because of their cost to cross-platform support, debugging, and third-party dependencies. Instead, it strictly limits the capabilities it exposes to a Mini App, to guard against poisoned third-party Mini Apps and harmful code from Agent hallucinations.

​
Host security boundaries

​
Ports and credentials

A Mini App listens only on a local address, but other processes and browser pages on your machine can still reach its port, including malicious pages that use DNS rebinding. The host therefore checks the caller’s identity at the port:
Credential flow

The credential passes only between the host, the request guard, and the Agent's MCP client; the page, plugin code, and outside callers can't obtain it.

  • One credential per run. Each time the host starts the process, it generates a random 32-byte credential and gives it to the request guard in the child process, the host main process, and the Agent’s MCP client. The page never holds it.
  • The guard loads before plugin code. The child process receives an initialization message over IPC, and a missing or extra field fails startup. It then installs the guard at the request dispatch entry of Node’s built-in HTTP server, and only then loads plugin code. Every node:http server the plugin creates therefore receives requests only after the guard has checked them.
  • Host and credential checks. Host must equal 127.0.0.1:port exactly, which blocks DNS rebinding, and the credential is compared in constant time. WebSocket upgrades and CONNECT requests are checked the same way. Once a request passes, the credential is removed from its headers before plugin code sees it.
  • The host adds the credential to page requests. When the page sends a request, the host main process checks its real origin and then adds the header, overwriting any header with the same name the page set itself. When the Agent reaches the MCP endpoint, its MCP client carries the credential in request headers, never in visible configuration.
The request guard runs in the same process as plugin code, so it can only stop outside callers from posing as the host; it can’t isolate a malicious plugin.

​
Declarations and permission switches

Each Connector provider, Agent grant (session.run and session.read), toolAccess grant (call), and microphone, camera, and system notification permission has its own switch. Declared permissions start on, and users can turn them off in plugin details at any time. The declaration does not change, so the interface object stays present and code must handle refused calls. Every context.tool call also follows the user’s Agent tool permission rules, with a host prompt when confirmation is needed.Turning off Connector or tool access refuses new calls. Turning off session.run stops this Mini App’s active Agent turns; turning off session.read ends its session observers. Turning the switch back on allows new calls again.

​
Page device permissions

Microphone access requires microphone in the manifest’s deviceAccess and its permission switch to be on. Switching it off refuses the next getUserMedia or speech.transcribe call. The host does not forcibly stop a recording stream the page already holds; the page must stop its tracks.Camera and system notifications are officially supported from MiniMax Code v3.1.9, declared with camera and notifications respectively. Users can turn either permission off independently. Turning off camera access refuses new capture requests; the page must still stop video streams it already holds. Combined audio/video requests require both microphone and camera to be declared and enabled; disabling either refuses the whole request.Turning off notification access refuses new notification requests. Display also depends on the operating system’s notification permissions and settings. A notification click can be handled only by the page that created it while that page is still running; after the page closes or reloads, an old notification cannot reopen the Mini App. See Page device APIs for declarations, version requirements, and usage.Other unavailable page permissions, such as location, clipboard read, and screen capture, are denied by default. These gates apply to host-managed pages; they do not place Node code in an operating-system sandbox.

​
Limits of the Agent API

  • session.run lets the Mini App create and continue its own Agent sessions, handle tool approvals and questionnaires, and list models and agents. The host records ownership; this grant does not let it control the user’s other sessions.
  • session.read independently grants listing, reading, and observing the user’s visible sessions, including session details and final turn replies. It does not grant running turns, approving tools, or answering questionnaires. Neither grant implies the other.
  • message.append can change only the unsent input draft after confirmation. It cannot change sent messages or send on the user’s behalf.
  • These limits apply only to the host APIs; the Node process itself has no operating-system-level isolation.

​
User confirmation

  • message.append needs user confirmation every time, and the user sends the message. The host checks the caller against the real page that Electron reports.
  • Agent approvals offer only “allow once” and “deny”. A Mini App can’t change the user’s global permission rules, and approvals nobody can answer are denied. See Who can answer an approval.
  • context.tool uses the host’s own tool approval prompt, where the user can choose “allow once”, “always allow”, or “deny”. Only the user’s “always allow” choice in that prompt writes a global rule; a Mini App cannot answer it. See Unified tool entry.
  • Reading and observing user sessions requires session.read to be declared and enabled. message.append grants no read access and cannot change sent messages.

​
Known limitations

  • Port authentication only defends against other local processes and browser tabs, not against a malicious plugin itself.
  • The host manages only the entry Node process. The plugin must clean up any child processes it starts in dispose.
  • After a service restart, open tabs get 401 until they are refreshed or reopened.