A useful agent result is often buried when the chat moves on. MiniMax Code Mini Apps address that problem with a live page and backend that stay attached to the Agent, but the current trade-off is significant: Mini Apps run in local sessions inside the MiniMax Code desktop app, not in cloud, SSH, or remote-control sessions.
What MiniMax Code Mini Apps actually add
MiniMax Code Mini Apps are plugin-like applications with a frontend and backend. MiniMax’s official announcement says the Agent and the Mini App can call each other, so a page can hold an ongoing workflow instead of serving as a one-off generated artifact.
That makes a Mini App closer to a small operational tool than a saved answer. It is also tightly coupled to MiniMax Code, which limits where the result can run.
Mini App versus a normal generated webpage
The practical test is not whether the Agent can produce HTML. The new piece is the persistent surface: a right-hand panel can keep the result visible while the Agent continues handling tasks in the same local environment.
A normal generated webpage may be a finished file. A Mini App is intended to remain open, receive state, and hand work back to the Agent.
The first constraint is where Mini Apps run
MiniMax describes Mini Apps as a feature of the MiniMax Code desktop application and says they currently run in local desktop sessions. In a follow-up clarification, MiniMax Code’s Ronny confirmed that cloud, SSH, and remote-control sessions do not start Mini Apps.
| Environment | Mini App status | What that means |
|---|---|---|
| MiniMax Code desktop, local session | Supported | Build, open, and iterate beside the Agent |
| MiniMax Code web app | Not confirmed as supported | Do not assume a web task can host the same runtime |
| Cloud session | Not supported currently | A cloud task does not launch the Mini App |
| SSH session | Not supported currently | Remote repository work cannot use the Mini App runtime |
| Remote-control session | Not supported currently | Phone access does not make the desktop runtime portable |
This is the deciding limitation for teams. A Mini App can improve a local workflow without being a deployable internal tool. Treat the first release as a desktop companion, not as a general hosting target.
How the build loop works
The documented entry point is the /miniapp-creator skill. MiniMax describes a workflow in which a plain-language request becomes a Mini App package, which can then be installed as a plugin and opened in the desktop interface.
- Start with a bounded page, such as a task queue, token dashboard, or project checklist.
- Ask MiniMax Code to create the frontend and backend through
/miniapp-creator. - Open the generated page and check the first render before adding automation.
- Add one narrow action that reads local state or calls the Agent.
- Test failure behavior and permissions before putting real credentials or sensitive files in the workflow.
Begin with reversible data and make the Agent ask before destructive operations. A live page with Agent access has a larger action surface than a static HTML export.
What the early examples reveal
The strongest evidence so far is practical rather than benchmark-shaped. The official MiniMax Code Mini Apps repository lists examples such as token-usage dashboards, model managers, route planners, and Git history viewers. Those examples point to a narrow but useful category: a persistent interface for work already happening in MiniMax Code.
A content and research workspace
Early user @chesny showed a Mini App organized around Inbox, Ideas, Research, and Drafts. The user reported that the first version loaded blank, then the Agent found and fixed its own bug before checking the files: the build report.
“The first version loaded blank. It found its own bug, fixed it, and checked every file before handing it back.” — @chesny, X
A small interactive app
Another early user, @ClubAiworld, reported a playable game with a first version in 10 minutes, followed by UI changes and bug fixes through messages: the example. This shows how quickly the loop can produce a visible artifact, but it is not a reliability benchmark. One small game does not establish performance across larger applications.
The official Mini App overview is the right place to check the current specification. The repository is useful for inspecting examples and the expected shape of shared Mini Apps.
What Mini Apps do not solve yet
Runtime boundary: A Mini App that only works in a local desktop session cannot currently serve a distributed team, a headless CI job, or a developer who works primarily over SSH.
Early integration: A user reported being unable to talk with the Chief agent inside a Mini App: the issue report. Test the handoff in your workflow because the page may exist while the expected Agent connection does not.
Portability: The official materials describe a MiniMax Code plugin and MiniMax runtime, not a standalone package designed for another coding agent. Build one as a MiniMax Code workflow unless the documentation explicitly adds export or migration support.
Security and evidence: Use sample data first, review file access, and keep actions reversible. The feature is new, so the current materials do not establish a long record of production reliability.
Who should use MiniMax Code Mini Apps now
Mini Apps are worth testing when the work is local, repetitive, and easier to understand through a persistent page than through a transcript. They are a poor fit when the central requirement is remote execution or portability.
| Use case | Fit today | First test |
|---|---|---|
| Personal local task dashboard | Good | Build a read-only queue from sample files |
| Research or content pipeline | Good with review | Track stages from inbox to draft and test a failed handoff |
| Small interactive prototype | Good for exploration | Make a tiny app, then inspect every generated file |
| Shared team operations dashboard | Limited | Confirm whether local-only runtime blocks the team workflow |
| SSH or cloud development | Poor today | Wait for remote-session support or use a separate web tool |
| Production automation with secrets | Too early | Prove permissions and approval behavior with fake credentials |
My recommendation is to treat Mini Apps as a local workflow experiment, not as a replacement for a hosted internal application. If the desktop restriction is acceptable, start with a read-only dashboard and add Agent actions one at a time. If the workflow must follow you into SSH, cloud sessions, or another tool, the feature is not ready for that job.
FAQ
Are Mini Apps available in the web version?
The official launch describes Mini Apps in the MiniMax Code desktop app. Current materials do not establish equivalent web support, so do not plan around it without current product confirmation.
Can a Mini App run over SSH or in a cloud session?
No, not in the current documented behavior. MiniMax has confirmed that Mini Apps run in local desktop sessions and do not start in cloud or SSH sessions.
Can Mini Apps call the Agent?
Yes. MiniMax describes bidirectional calls between the Agent and the Mini App. Test the specific handoff in your workflow because an early user reported a problem talking with Chief from inside a Mini App.
What should I build first?
Build a read-only task queue, token dashboard, or project checklist with sample data. These expose rendering, state, and file-access problems without giving an early prototype permission to change production systems.
Are Mini Apps portable to other agent tools?
The current documentation presents them as MiniMax Code plugins. Portability to other agents or hosted runtimes is not established, so assume the application is tied to MiniMax Code unless official documentation says otherwise.