MiniMax-AI / MiniMax-AI/minimax-code
[Bug][Windows] 3.0.0 local runtime fails to start: opencode.exe cannot open B:\~BUN\locales\en_US.json
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 1.3k
- Forks
- 141
- Avg merge
- 2h 45m
- Merged PRs (30d)
- 46
Description
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 memoryInstall 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.nupkgis 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
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. - Network and cloud. Calls to
platform.minimax.io/backend/group/listsucceeded 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 WindowsMiniMax-AI/Mini-Agent#107 — MiniMax Code 3.0 on Windows, desktop app opens briefly then crashes after login
Questions
- Is the
localesdirectory included in the 3.0.0 Windows build ofopencode.exe? The evidence suggests it is not. - There is a
.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? - 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 / 提交前确认
- I have searched existing issues.
- I am using the latest version available to me.
- I have removed sensitive information from logs/screenshots.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the failure from the installed resources/opencode directory with opencode.exe --version and --help, then inspect the Windows packaging path for the Bun virtual filesystem and the locales asset. Done means the bundled runtime can read locales, both commands start successfully, and the desktop app no longer reports the local service as unavailable.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- bun, electron, node.js, typescript
- Domain
- build-system, desktop, operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 42/100