MiMo Code v0.1.3 on Windows: RangeError Out of memory at stringify - TUI and /agent endpoint both crash on startup

[shicheng1]

MiMo Code v0.1.3 on Windows: "RangeError: Out of memory at stringify" — TUI and /agent endpoint both crash on startup

Summary

MiMo Code v0.1.3 consistently crashes with RangeError: Out of memory on Windows when starting the TUI (mimo) or accessing the /agent HTTP endpoint (mimo serve). The crash occurs inside Bun's JSON.stringify during TUI bootstrap / agent payload serialization. None of the documented workarounds (increased memory, --pure, clean reinstall, disabling MCP servers) can bypass it.

Environment

• OS: Windows 11 (x64)
• MiMo Code: @mimo-ai/cli@0.1.3 (also reproduced on 0.1.2)
• Node.js: v20.x
• Physical RAM: 16 GB (12+ GB free at crash time)
• Install method: npm install -g @mimo-ai/cli
• Project: small (~10 files) — issue is not project-size dependent

Steps to Reproduce

1. npm install -g @mimo-ai/cli (clean install, no prior ~/.local/share/mimocode data)
2. cd <any project>
3. mimo --trust

Actual Result

INFO  service=history.backfill sessions=2 backfill complete
ERROR service=server error=Out of memory failed
ERROR service=server-proxy error=[object Object] tui bootstrap failed
INFO  service=server-proxy worker shutting down

Crash stack (from mimo v0.1.2 TUI mode):

{
  "name": "UnknownError",
  "data": {
    "message": "RangeError: Out of memory\n    at stringify (unknown)\n    at json (B:/~BUN/root/chunk-s8t74q0s.js:2:68525)\n    at processTicksAndRejections (native:7:39)"
  }
}

Headless mimo serve partially works but /agent OOMs

$ mimo serve --port 4096
mimocode server listening on http://127.0.0.1:4096
# Server stays up, but GET /agent crashes:
ERROR service=server error=Out of memory failed

Web UI shows: {"error":"Web UI is temporarily unavailable."}

What I Tried (none worked)

Attempt	Result
NODE_OPTIONS=--max-old-space-size=8192	❌ mimo.exe is a Bun binary, ignores NODE_OPTIONS
--pure flag (disable plugins)	❌ Still OOM
Removed all 3 MCP servers from ~/.claude.json (mcpServers: {})	❌ Still OOM
mimo uninstall --force + full wipe of ~/.local/share/mimocode, ~/.cache/mimocode, ~/.local/state/mimocode + reinstall	❌ Still OOM (mimo rebuilds models.json + skills automatically)
Deleted ~/.cache/mimocode/models.json (2.3 MB model catalog)	❌ Still OOM (re-downloaded automatically)
Renamed ~/.local/share/mimocode/compose (60 SKILL.md files, 479 KB total)	❌ Still OOM (re-extracted automatically)
Downgraded to @mimo-ai/cli@0.1.2	❌ Same RangeError: Out of memory at stringify
BUN_JSC_forceRAMSize=8589934592 env var	❌ Still OOM
Launched mimo.exe directly (bypassing the Node launcher) with Bun env vars	❌ Still OOM

What Does Work

• mimo run "<message>" (non-interactive single-shot mode) — succeeds, including tool use (ls, file reads, etc.) in the project directory. This bypasses the TUI bootstrap and /agent endpoint entirely.

Hypothesis

The /agent HTTP endpoint (consumed by both the TUI and Web UI) serializes a large object via JSON.stringify. Based on the mimo debug config output, this payload likely combines:

• models.json (~2.3 MB model catalog from MiMo API)
• 60 SKILL.md files (~479 KB total) from ~/.local/share/mimocode/compose
• Session history, agent state, and other config

Even on a machine with 12+ GB free RAM, Bun's default heap (256 MB) cannot hold the serialized string + parsed object + AST simultaneously, and the resulting RangeError: Out of memory at stringify is not caught — it propagates up and kills the TUI bootstrap / /agent handler.

The fact that:

• --pure doesn't help
• Clean reinstall doesn't help
• Disabling MCP servers doesn't help
• BUN_JSC_forceRAMSize doesn't help

…suggests the OOM is not actually about total heap size, but about JSON.stringify hitting a V8/Bun internal string-length limit (V8 strings have a max length of ~512 MB on 64-bit, but Bun may have a smaller practical limit), or a circular reference causing unbounded serialization.

Suggested Fixes

1. Investigate the /agent payload size. Log the byte length of the object passed to JSON.stringify in the /agent handler before serializing.
2. Stream the response instead of building one giant JSON string in memory.
3. Paginate / lazy-load the model catalog and skill list rather than embedding all of them in every /agent response.
4. Catch RangeError in the TUI bootstrap path and fall back to a minimal agent payload (so users at least get a working TUI).
5. Expose a MIMO_MAX_AGENT_PAYLOAD_MB env var so users can cap or disable large payload sections.

Impact

MiMo Code is currently unusable on Windows for TUI and Web UI workflows. Only mimo run (single-shot) works, which defeats the purpose of an interactive terminal agent.

Given Windows is one of the largest developer platforms, this is a critical regression. Would love to see a fix in v0.1.4.

Workaround for Other Windows Users

Until fixed, Windows users can use single-shot mode:

mimo run "your question here"
mimo run --continue "follow-up message"

Logs

Full startup log (TUI mode) attached:

INFO  service=server status=completed method=GET path=/session
INFO  service=provider init
INFO  service=provider providerID=mimo found
INFO  service=provider providerID=xiaomi found
INFO  service=provider status=completed state
INFO  service=server status=completed method=GET path=/provider
INFO  service=server status=completed method=GET path=/config/providers
INFO  service=history.backfill sessions=1 backfill complete
INFO  service=installation method=npm target=0.1.3 stdout=changed 1 package in 3s stderr=upgraded
INFO  service=bus type=installation.updated publishing
ERROR service=server error=Out of memory failed
ERROR service=server-proxy error=[object Object] tui bootstrap failed
INFO  service=server status=completed method=GET path=/agent
INFO  service=server-proxy worker shutting down

Happy to provide more diagnostics (mimo debug config, mimo debug agent, file listings, etc.) on request.