[Bug]: [Windows] Computer Use broken since 3.1.4 — CuaUtility exits before ready; failure misreported as 'Device restricted (parental controls)' #548

Product or interface

Desktop app

Version

3.1.4.127 (Electron 42.8.0), Windows x64

Platform

Windows

OS version and architecture

Windows 10 x64 (build 26200)

Issue area

Tool call / permission / sandbox

Steps to reproduce

1. On Windows 10 x64, MiniMax Code Desktop 3.1.4.127 (hot-updated from the previous 3.1.x build on 2026-10-23 17:36), open the plugin marketplace and enable the official Computer Use plugin (computer-use v1.0.1).
2. The authorization dialog appears. Both the "Screen Recording" and "Accessibility" rows show 「设备受限（家长控制）」 ("Device restricted (parental controls)"), and the dialog only offers a "Use" button — no "Open System Settings" action.
3. The conversation provides no computer_* tools at all.
4. Check %APPDATA%\MiniMax\logs\main-computer-use.log: every activation forks the CuaUtility helper, which exits with code 1 about 0.5 s later — computer_utility_exited_before_ready. This has happened on every attempt since the update (79 occurrences as of 2026-10-26); the last successful start was 2026-10-21 14:17 on the previous build (utility_ready, driverVersion=0.22.1, sdkSource=upstream-package).

Expected and actual behavior

Expected: on Windows, the plugin enables and the computer-use runtime starts; the authorization dialog either shows a Windows-appropriate state ("no permission required") or a real diagnostic when startup fails.

Actual:

1. The dialog renders the macOS TCC model (Screen Recording / Accessibility) on Windows and labels the failure "Device restricted (parental controls)", sending users to check Screen Time / MDM / system permission toggles — none of which are involved.
2. The CuaUtility helper never becomes ready, so Computer Use is completely unavailable.

Code-level root cause (verified by extracting and reading the shipped app.asar):

• The utility entry (cua-entry.js) resolves its data directory as dataDir: process.env.MINIMAX_DATA_DIR ?? '' and swallows every startup error: .catch(() => process.exit(1)).
• The main process forks it via utilityProcess.fork(...cua-entry.js, [], { env: { ...process.env, MAVIS_CUA_GENERATION, MAVIS_CUA_DIAGNOSTICS }, stdio: 'pipe' }) — the data directory is only inherited through the main process's transient process.env state (MINIMAX_DATA_DIR is a temporary override prepared for local-runtime forks and deleted by restoreLocalRuntimeDataDirOverride()), never injected explicitly for this child.
• startCuaUtilityServer → prepareDesktopComputerUseComponent(dataDir) → prepareInstalledPackagedComponent validates as its first check: if (!path.isAbsolute(input.dataDir) || !path.isAbsolute(input.packagedRoot)) throw new ComputerUseError('computer_component_invalid', ...). A missing/empty MINIMAX_DATA_DIR therefore fails before anything else; the rejection is swallowed by .catch(() => process.exit(1)), and the main process only logs exitCode: 1.
• The UI then maps any probe failure to the fallback: blocked() = { accessibility: 'restricted', screenRecording: 'restricted', captureReady: false }, rendered by i18n (cu_status_restricted) as 「设备受限 (家长控制)」. The win32 success branch of snapshot() would return { accessibility: 'not-required', screenRecording: 'not-required', captureReady: true } — so on Windows, restricted always means "probe failed", never "parental controls".

All other failure modes were verified clean, so the dataDir handoff is the only surviving candidate:

The packaged component is also healthy in isolation: minimax-computer-use.exe doctor --json reports "ok": true (UI Automation CoCreateInstance(CUIAutomation) succeeds, interactive desktop attached, EnumWindows returns visible windows), and the install directories ~/.minimax/computer-use/components/0.34.1/win32-x64 and ~/.minimax-computer-use do not exist — confirming prepareInstalledPackagedComponent has never completed.

Regression timeline: 2026-10-21 14:17 start succeeded on the previous build (npm upstream-package path, no packaged-component preparation involved); hot-update to 3.1.4 on 2026-10-23 17:36 switched to the "packaged component + signed release token" path; every activation since 2026-10-23 19:58 fails identically.

Redacted error summary

[2026-10-23 19:58:01.553] [info] [CuaUtility] forked generation=1 pid=unknown
[2026-10-23 19:58:02.145] [warn] [CuaUtility] child lifecycle ended generation=1 pid=24692 {"exitCode":1}
[2026-10-23 19:58:02.145] [warn] [CuaUtility] startup unavailable; continuing without Computer Use: computer_utility_exited_before_ready

Repeated on every activation. Note there are no utility_output lines at all before the exit — the failure happens before the first log-capable stage, consistent with the first-line path validation in prepareInstalledPackagedComponent.

Suggested fixes

1. On Windows, don't render the macOS TCC items (Screen Recording / Accessibility). When the probe fails, surface the actual error code (e.g. computer_component_invalid / computer_utility_exited_before_ready) instead of 「设备受限（家长控制）」.
2. Inject dataDir explicitly into the CuaUtility utilityProcess.fork() (or pass it through the cua-connect message) instead of depending on the main process's transient process.env.MINIMAX_DATA_DIR state.
3. Log the real errorCode to main-computer-use.log when the utility fails to start — today only exitCode=1 is recorded, which is what made this regression so expensive to diagnose.

Before submitting

• I have searched existing issues.
• I have included my version and removed sensitive information.