Skip to main content

​
Publishing flow

A Mini App never runs straight from its installation directory. When publishing, the host:
1

Stages

Copies the package to a host-managed staging area. Dependency directories aren’t published. After copying, it rereads the manifest and file digests, and publishing fails if they changed.
2

Installs

Moves the previous version into quarantine, atomically swaps the staged copy into the installation directory, and checks the digests again.
3

Starts

Makes a separate runtime copy from the installation directory, verifies its identity, and starts it in its own process. The old process stops first, and the new one takes over only once it is ready.
If any install step fails, the previous version moves back from quarantine and the installation directory is restored. If the old process has stopped and the new one fails to start, the host doesn’t revive the old process; run open, publish, or restart again. Skills and ordinary MCP in the package are unaffected. See Updating a running Mini App.

​
Check runtime status

inspect is read-only and never starts or restarts the service. It mainly returns:
  • source: official or local, set by the host from its install records.
  • diagnostics.run: the current or latest run, with preparation and readiness times and any confirmed exit details.
  • diagnostics.failure: the failure the host currently reports.
  • diagnostics.logs: host records of startup, readiness, failures, and exits, with a size limit.
Diagnostics live only in host memory and are cleared when the host restarts. Treat missing times, exit codes, and failure reasons as unknown; don’t guess.

​
Debug the page

Run open first, then use the built-in browser’s inspect, query, click, and type actions to check structure, text, controls, and state. Lifecycle actions (publish, restart, stop) always go through the miniapp tool, never through browser actions.

​
Common problems

See Error codes for the full list.