[Bug][Windows] 3.0.0 local runtime fails to start: opencode.exe cannot open B:\~BUN\locales\en_US.json

Commencez par reproduire l’échec depuis le répertoire installé resources/opencode avec opencode.exe --version et --help, puis examinez le chemin de packaging Windows pour le système de fichiers virtuel de Bun et l’asset locales. C’est terminé lorsque le runtime inclus peut lire locales, que les deux commandes se lancent correctement et que l’application de bureau ne signale plus que le service local est indisponible.

Version / 版本号

v3.0.0

Platform / 平台

Windows

OS version / 系统版本

Windows 11, build 10.0.26200, x64

Issue area / 问题类型

Startup / install / update

Upload ID / 日志上传 ID

client-logs//hilo-logs--2026-08-20T11-52-05.zip

What happened? / 问题描述

Summary

opencode.exe, the local AI runtime shipped inside MiniMax Design 3.0.0, exits with code 1 immediately on launch. It fails while reading its locale file at B:\~BUN\locales\en_US.json, a path inside the Bun virtual filesystem. Because the runtime never becomes healthy, the per-workspace gateway also exits, and the desktop app is left permanently showing "Local service unavailable" and "Reconnecting to runtime".

The failure occurs before command-line arguments are parsed. It reproduces with nothing but opencode.exe --version in a clean shell, with the desktop app closed. It is therefore independent of the app, the workspace, the project path and the gateway.

Impact

The application is unusable. No workspace can be opened. Every project open attempt fails at the same point. Cloud connectivity is unaffected, so the account and platform side are working normally; only the local runtime is dead.

Environment

Item | Value -- | -- App version | 3.0.0 (production, channel prod, region overseas) Installer | Velopack, full-only transport OS | Windows 11, build 10.0.26200, x64 Electron / Node / Chrome | 43.1.0 / 24.18.0 / 150.0.7871.47 System locale | en-GB Machine | 16 CPU, 97 GB RAM, ample free disk and memory

Install path referenced throughout as C:\Users\<USER>\AppData\Local\com.minimax.hub.global\.

Reproduction

cd "C:\Users\<USER>\AppData\Local\com.minimax.hub.global\current\resources\opencode"
.\opencode.exe --version

Result:

Error: Unexpected error
EUNKNOWN: unknown error, open 'B:~BUN\locales\en_US.json'

--help produces the identical error, confirming the read happens during startup rather than as part of handling a specific command.

Diagnosis

The locale filename is derived from the LANG environment variable, and the value is parsed as a POSIX locale string. Setting LANG=en changes the failing path to locales\en.json. Setting LANG=C:/some/path/en yields locales\C.json, and LANG=../../locales/en yields locales\.json, so the value is split on : and . with the first fragment retained.

Two conclusions follow. First, the default resolution to en_US fails, and en_US.json is the file that should be present in any correct build, so the locales directory appears to be absent from the compiled bundle entirely. Second, no client-side configuration can work around this, because the resolved name is always joined to the binary's own virtual directory.

Note also that the reported path is B:\~BUN\locales\... with no root segment, whereas Bun's embedded filesystem is normally rooted at B:\~BUN\root\. That may indicate the code resolves the locale directory relative to a prefix that the packaging step does not populate.

Already ruled out

• Reinstall. A clean reinstall of 3.0.0 reproduced the fault identically. Only com.minimax.hub.global-3.0.0-full.nupkg is present in the packages directory, so no local rollback is possible.
• Antivirus. A Microsoft Defender folder exclusion for the install directory changed nothing. The failure also reproduces outside the app in a bare shell.
• Drive letter collision. No B: drive exists on this machine, and no subst mappings are active. Note that Windows reserves A: and B:, and subst refuses to map them, so a user-side shim at that path is not possible either.
• Network and cloud. Calls to platform.minimax.io/backend/group/list succeeded repeatedly throughout, before, during and after the failures. Proxy and VPN checks were clean.
• Resources. Memory, disk and CPU were all well within limits.

Log evidence

From the desktop main log:

[09:36:37.051] [opencode] Starting generation=1 at port 56574 from
  C:\Users\<USER>\AppData\Local\com.minimax.hub.global\current\resources\opencode\opencode.exe
[09:36:42.722] [opencode] EUNKNOWN: unknown error, open 'B:\~BUN\locales\en_US.json'
[09:36:42.744] [opencode] Process exited UNEXPECTEDLY: generation=1, pid=29360, code=1, signal=null
[09:36:43.226] [workspace-runtime] opencode.startup_failed severity=error kind=early_exit
[09:36:43.664] [gateway-manager] Gateway exited: pid=22716, code=1, signal=null
[09:36:43.667] [workspace-startup] failed phase=opencode_start diagnosis=runtime_start_failed

Diagnostics reported workspaceLifecycleStates: failed and runtimeHealth.error: gateway_pid_missing for the affected workspace, while the app-level gateway on port 8001 remained healthy.

Two secondary issues appear in the same logs and may be worth a look while you are in there:

• The gateway logs three failures at startup against a directory that does not exist: ENOENT: no such file or directory, realpath 'C:\Users\<USER>\AppData\Roaming\@hilo\MiniMax Hub Global\output_files', affecting upload commit recovery, staged upload pruning and ledger pruning.
• The connection diagnostics panel reports the local service failure as a network problem, listing "Cloud service responded but needs attention" and "Issue reporting may be blocked" alongside it. In this case the cloud was entirely healthy and the fault was a local process crash. The panel's framing sent me looking at connectivity for some time before the logs made the real cause clear.

Logs

Logs have been uploaded from the client five times on 2026-08-20: three automatically on reaching the error threshold (08:37:02, 08:40:23 and 08:55:55 UTC) and two manually (09:47:56 and 11:52:05 UTC).

The most recent manual upload is the most complete: 2026-08-20T11-52-05, uploadPath=main_direct, 399,586 bytes. That timestamp and size should be enough to locate the object.

The full locator embeds my account ID, so I have not posted it here. Happy to send it directly if that is easier than looking it up.

Possibly related open issues

These describe Windows startup and service failures that may share this root cause, though none identifies the locale file:

• MiniMax-AI/Mini-Agent #99 — 服务启动失败 (background service install or start failure)
• MiniMax-AI/Mini-Agent #101 — desktop app returns "Forbidden: request was blocked by a gateway or proxy" intermittently on Windows
• MiniMax-AI/Mini-Agent #107 — MiniMax Code 3.0 on Windows, desktop app opens briefly then crashes after login

Questions

1. Is the locales directory included in the 3.0.0 Windows build of opencode.exe? The evidence suggests it is not.
2. There is a .betaId file in the packages directory. Is this installation on a beta track, and if so, is a stable build available that does not carry this fault?
3. Is there any supported way to obtain an earlier version while a fix is prepared? Your update policy feed cites 2.0.4 as the minimum supported version but publishes no archive.
4. Is there a client-side workaround at all, given that the locale path is resolved inside the binary's own virtual filesystem?

Steps to reproduce / 复现步骤

1. Open Minimax Design
2. Issues manifest immediately

Expected behavior / 预期行为

1. Open Minimax Design
2. Application is usable

Actual behavior / 实际行为

1. Open Minimax Design
2. Application is unusable

Logs or crash report / 日志或崩溃信息

Screenshots / 截图

Before submitting / 提交前确认

• I have searched existing issues.
• I am using the latest version available to me.
• I have removed sensitive information from logs/screenshots.