Skip to main content
This page describes Mini App interfaces available in official releases and their error handling, with version differences noted in the relevant sections. Method signatures are in Client API, Node API, and Agent API.

Identify the error shape first

Do not depend on instanceof or a concrete Error subclass across process boundaries. Use message for display or diagnostics and code for Node business branches.

miniapp tool

These errors belong to the Agent tool used for init, publish, open, inspect, restart, and stop, rather than Node context.tool.error.retryable is a host recovery hint. Retrying capacity_busy does not free a slot. Even when PREPARATION_FAILED suggests a retry recovery, satisfy the condition in its hint first.

Publishing diagnostics

error.diagnostic has { stage, reasonCode, recovery, hint }. stage is workspace, runtime, mcp, connector, or host; recovery is edit_workspace, retry, or user_action. The following are public publishing reasonCode values, not top-level error.code values.

Node outcomes and retries

Host Connector and the unified tool entry share these error fields:
  • not_dispatched: nothing was sent to the target; address the cause before considering a retry.
  • provider_reported: the provider returned a failure. Interpret its business outcome; this does not prove that no write occurred.
  • unknown_after_dispatch: the call may have executed. Read business state first and do not repeat a write based only on an error name or retry hint.
  • invocationId correlates the call and may be absent. diagnostic.issues contains safe field paths, constraints, and limits, not user argument values.

Host Connector

See Node API for signatures and result structures.

Node unified tool entry

context.tool uses the Node error shape above. Calling a Connector tool can also retain Host Connector codes.When nobody can approve Node request(names), it rejects with TOOL_APPROVAL_REQUIRED and attaches a permissions snapshot for display. With only tool:call switched off, request() succeeds with every name mapped to deny and shows no prompt; this differs from a rejected call(). An MCP result with isError: true is a tool-reported business failure, not a rejected Promise.See Node API for signatures and result unions.

Agent API

Node reads error.code, error.retryable, and possibly error.reason with BUSY. Pages read Error.message; this table is the host mapping, not a lowercase transformation of Node names.Node BUSY.reason is session_busy, queue_full, rate_limited, or observer_limit. whenBusy handles follow-ups to busy sessions, not other limits. Pages may also receive busy for a duplicated in-flight requestId; do not rely on an attached page reason, because the bridge only guarantees the error message.Page transport failures also depend on the method: bridge failures for run, answer, reply, open, models, agents, and create may yield result_unknown; failures for observe, sessions, and session yield runtime_unavailable. Not every read-only method uses the same transport error.See Agent API for methods, returned error fields, and events. A fulfilled run() with status: 'error' differs from a rejected Promise; handle result status as well as catch.

Page APIs

Pages do not read Node code, retryable, or disposition. The following codes are thrown or rejected Error.message values. capabilities.has() is synchronous and returns a boolean; see Capability detection.

message.append

Window handle

The table describes v3.1.10 window behavior. Differences in v3.1.9 are noted below it.not_found is an internal window response and is not exposed as a page code; the page receives result_unknown. See Client API for methods and writable fields.In v3.1.10, cancelling confirmation for a transfer that rebuilds the page resolves update() with the current state and the original mode, without user_cancelled or busy; inspect the returned mode. Active page requests or subscriptions no longer block a transfer by themselves. After confirmation, they are cancelled or cleaned up when the old page ends. Promises and listeners from the old document do not survive; see Page rebuilds and confirmation.In v3.1.9, active requests, observation subscriptions, permission prompts, or capture can also make a transfer return busy. A page with a microphone grant has a separate transfer confirmation, where cancellation also returns busy. Do not apply the v3.1.10 cancellation rule to these older hosts.

Tool preauthorization

With only tool:call switched off, page tool.request() succeeds with all names mapped to deny; it does not reject with not_permitted. Unlike Node’s method, page failure exposes only the code. Do not depend on error.permissions, even if the host response contained a snapshot. See Client API.

Speech transcription

Transcription returns text and does not cancel or stop the page’s capture stream. See Client API for format, results, and onPartial. Standard microphone and camera capture errors, such as NotAllowedError, come from the browser API rather than this transcription table.

Camera and system notifications

These capabilities are officially supported from MiniMax Code v3.1.9. They use standard browser APIs and have no additional host error codes.If getUserMedia() fails, read the browser exception’s name, such as NotAllowedError. Handle notifications through the standard Notification API: check Notification.permission and the result of requestPermission(), and listen for the notification object’s error event. Actual display also depends on system notification settings. Do not interpret these results as the speech transcription error codes above. See Page device APIs for declarations and usage.

Capability detection

capabilities.has(name) synchronously returns boolean; an unknown name returns false. It has no host error code or rejected Promise. Older hosts may omit the object, so check with optional chaining. Calling a missing object produces a JavaScript error, not a Mini App permission failure. See Client API for names and surfaces.

Startup and runtime diagnostics

inspect exposes diagnostics.failure.code, diagnostics.run.failure.code, and log code fields for runtime investigation. They are different layers from the lifecycle tool’s error.code and diagnostic.reasonCode. For example, a low-level READINESS_TIMEOUT helps locate listener/readiness problems, while the public publishing diagnostic uses RUNTIME_NOT_READY.Check that the entry exports start(context), binds the assigned port with node:http, and returns after the listener and routes are installed. Keep missing exit, time, and failure details unknown; a diagnostic name alone does not prove process exit. See Node API, Port authentication, and Publishing and troubleshooting.