[nattiini45]

What it is

MiniMax Bot Bridge pairs a phone with the MiniMax Bot team on your desktop. It is the Mini App that runs on the desktop side of the pairing: it shows a single-use pairing code, keeps the list of paired phones, and carries the team's conversations and tool activity to the phone over a relay you operate.

  DESKTOP (this Mini App)  ──outbound──▶  RELAY  ◀──phone──  mobile client
        pairing code, team tools                                  (Expo app)

The desktop makes an outbound connection to the relay, so no desktop port is exposed to the internet. The relay is a Cloudflare Worker the operator runs; it is a connection service, not an agent hosted in the cloud, and it holds no MiniMax account credential.

This is an independent project, not an official MiniMax application. It does not modify or reproduce the official MiniMax Bot plugin: it calls the team tools the Host already exposes and leaves the desktop in charge.

What it needs

• The official MiniMax Bot plugin on the same desktop. The bridge calls that plugin's tools through the Host's tool API. Without it the bridge still starts, pairs and reports diagnostics, but it cannot show or drive the team.
• A relay you operate, plus a bridge credential minted for it — see docs/PAIRING.md. The relay Worker and the minting command live in the phone app's repository.

The phone itself is a separate project: https://github.com/nattiini45/minimax-bot-mobile (Expo / React Native, Android, iOS and web).

Contract notes

Declared	Why
agentAccess: ["session.run"]	The bridge runs a Bot turn through the Host Agent in a session it owns, and asks it for a model. It never reads your other conversations — session.read is not declared. The team conversation history it shows comes from the team tools, not from the session API.
toolAccess: ["call"]	The bridge calls the minimax-bot team tools the Host exposes (mcp__minimax-bot__…) to read the team, its groups and its conversation history, and to send messages. Every call is judged by the user's permission rules.
surface.window	The pairing surface is a small panel; it pops out into its own window on request.
not declared	No microphone, no getUserMedia, no speech.transcribe, no host connector providers, no MCP servers, no skills, no subagents.

Other things the reviewer asked about:

• Writes stay inside context.dataDir: bridge-config.json, bridge-token (owner-only mode) and ledger.json (turn, tool and permission records — counters and identifiers, not message text), plus one rooms/<hash>/ledger.json per room. No other file on the machine is read or written; the Host's own files are not touched.
• Network: the relay address the operator configures, over HTTPS/WSS only. A cleartext http:///ws:// address is accepted only for a loopback relay, and wss:///https:// name the same relay so the credential never crosses between them.
• Processes: none. The bridge is one Node process with no child processes.
• stdout: the Node entry logs through context.logger; no console.* or process.stdout.write in the payload.
• Routes: /bridge for the surface and /api/* for its own endpoints. Nothing under /__mavis/.
• Payload: self-contained — Node's standard library only, with the shared protocol vendored into miniapp/node/protocol/. No node_modules, no network imports.

Testing

• npm test inside the package: 344 tests, 343 pass, 1 skipped, 0 fail. No dependencies to install, no network, no fixtures outside the OS temporary directory.
• node scripts/validate.mjs plugins/nattiini45/minimax-bot-bridge → OK, no errors and no warnings.
• npm run check at the repository root → repository: OK, 87 tests pass.
• Installed and opened in MiniMax Code 3.1.10 on Windows 11 with the official MiniMax Bot plugin, and paired against a live relay.

Notes

• The icon is MiniMax's mascot artwork, MIT-licensed by MiniMax — the terms are in LICENSE-MINIMAX.txt, kept with the package.
• docs/PROTOCOL.md and docs/PAIRING.md document the wire contract and the credential flow. Paths that point into the original workspace were rewritten to absolute links into the source repository.
• README.md and README.zh-CN.md describe what the app does, how to install and open it, the tested environment, and exactly what it reads, writes, calls and stores.

---

^{Open in [code]smith · Need help on this PR? Tag @codesmith-bot with what you need.}

[MyPrototypeWhat]

Thanks for this contribution. It's a large, carefully built package: the bridge token sits in its own owner-only file, it's sent only to an HTTPS or WSS relay, the local surface checks a per-process secret before changing settings, allowAlways is refused, and the tests are thorough. A few things need to change before it can merge.

Must fix

1. The name and icon look official. Community plugins can't use "MiniMax" in the name, id or display name, since users read that as an official product. minimax-bot-bridge / "MiniMax Bot Bridge" appears in .minimax-plugin/plugin.json, package.json, both READMEs, the folder name and the catalog rows in the root READMEs. An mmx- prefix such as mmx-bot-bridge is fine, and saying it works with the MiniMax Bot plugin is fine too. The icons (icon.png, icon-dark.png) are the MiniMax Bot mascot, so please use your own and drop LICENSE-MINIMAX.txt with them.

2. It reads another plugin's private data. miniapp/node/desktop-team.mjs:47-49 builds the MiniMax Bot plugin's data path from this plugin's dataDir, then reads its messages (:150), state.json (:166) and avatars (:319) directly, and sends messages, Bot instructions, roles and avatars over the relay (bridge.mjs:1167, :1194, :1464, agent.mjs:191-193). Please get teams, groups, history and avatars only through the team tools you already call with toolAccess, and drop whatever they don't offer.

3. It reads user files outside its data directory. miniapp/node/capabilities.mjs:31-35 walks up from dataDir and reads installed skills (:103-128), plugin manifests (:140-177), agent settings (:189-205) and the whole MCP server config (:217-237), which can hold credentials. desktop-team.mjs:253 reads plugin cache folders the same way. This contradicts README.md:82 ("no Host files, no other plugins' files"). Please remove these reads, and leave the capability list out or limit it to what the declared APIs give you.

4. The relay can act on the desktop, and the README doesn't say so. bridge.mjs:853 trusts the relay's from field, with no check that a frame came from a paired phone. Whoever runs the relay, or holds its signing secret, can start Agent turns, answer permission prompts with "allow once" (bridge.mjs:862-881), and create, edit or delete Bots, groups and schedules (bridge.mjs:976-993). README.md:96-101 only says the operator can read conversations. Please say plainly in both READMEs that the operator can also act on the desktop, including approving tool calls. Better still, have the phone sign its operations with a key set up at pairing.

Optional

• Pairing codes and token ids can fall back to Math.random (protocol/pairing.js:56, protocol/auth.js:118, config.mjs:205). Use crypto.getRandomValues or crypto.randomUUID wherever they're generated on the desktop or relay.
• Pairing safety also depends on the relay limiting tries on the six-digit code, which lives in another repo. A link to that code in docs/PAIRING.md would help users check it.
• "it is useful without nothing else" in the README should probably read "it needs nothing else".

Verified

• npm run check passes on Node 22 at c487abc, and the plugin's own node --test passes (344 tests).
• The tests stay inside the plugin folder, and repo CI is untouched.
• No GitHub check has run on this head yet.