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:
Questions
- Is the
locales directory included in the 3.0.0 Windows build of opencode.exe? The evidence suggests it is not.
- 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?
- 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.
- 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 / 复现步骤
- Open Minimax Design
- Issues manifest immediately
Expected behavior / 预期行为
- Open Minimax Design
- Application is usable
Actual behavior / 实际行为
- Open Minimax Design
- Application is unusable
Logs or crash report / 日志或崩溃信息
Screenshots / 截图
Before submitting / 提交前确认
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 atB:\~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 --versionin 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
Install path referenced throughout as
C:\Users\<USER>\AppData\Local\com.minimax.hub.global\.Reproduction
Result:
--helpproduces 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
LANGenvironment variable, and the value is parsed as a POSIX locale string. SettingLANG=enchanges the failing path tolocales\en.json. SettingLANG=C:/some/path/enyieldslocales\C.json, andLANG=../../locales/enyieldslocales\.json, so the value is split on:and.with the first fragment retained.Two conclusions follow. First, the default resolution to
en_USfails, anden_US.jsonis the file that should be present in any correct build, so thelocalesdirectory 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 norootsegment, whereas Bun's embedded filesystem is normally rooted atB:\~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
com.minimax.hub.global-3.0.0-full.nupkgis present in the packages directory, so no local rollback is possible.substmappings are active. Note that Windows reserves A: and B:, andsubstrefuses to map them, so a user-side shim at that path is not possible either.platform.minimax.io/backend/group/listsucceeded repeatedly throughout, before, during and after the failures. Proxy and VPN checks were clean.Log evidence
From the desktop main log:
Diagnostics reported
workspaceLifecycleStates: failedandruntimeHealth.error: gateway_pid_missingfor 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:
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.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[Bug]: macOS desktop update fails: "Code Signature Invalid" + XProtect blocks launch (rebranded MiniMax Agent on Intel) #99 — 服务启动失败 (background service install or start failure)MiniMax-AI/Mini-Agent[Feature]: 希望未来的cli版本能支持web模式 #101 — desktop app returns "Forbidden: request was blocked by a gateway or proxy" intermittently on WindowsMiniMax-AI/Mini-Agent[Feature]: linux什么时候支持呢? #107 — MiniMax Code 3.0 on Windows, desktop app opens briefly then crashes after loginQuestions
localesdirectory included in the 3.0.0 Windows build ofopencode.exe? The evidence suggests it is not..betaIdfile 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?Steps to reproduce / 复现步骤
Expected behavior / 预期行为
Actual behavior / 实际行为
Logs or crash report / 日志或崩溃信息
Screenshots / 截图
Before submitting / 提交前确认