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

Activity

1. github-actions

   added

   desktopMiniMax Code desktop appMiniMax Code desktop app

   on Oct 26, 2026
2. wittkung commented on Oct 31, 2026

   

   wittkung

   on Oct 31, 2026

   More actions

   Cross-linking the macOS instance of this failure family, since it is the same symptom with the same misreported label but a different error code.

   • macOS report with the code-level root cause and a verified workaround: [Bug]: [macOS] Computer Use never starts — CuaUtility exits with computer_runtime_directory_unsafe, and the failure is misreported as 「设备受限（家长控制）」 #572

   Three details that may help triage both:

   1. The error code differs per platform. Windows reports computer_component_invalid (empty/non-absolute dataDir); macOS reports computer_runtime_directory_unsafe, thrown by the shipped SDK's ancestor check in node_modules/@mavis/computer-use/dist/desktop-lock.js (mode & 0o022 === 0 is required for every existing ancestor of the runtime root, and the runtime root is hardcoded under $HOME).

   2. The honest label already exists but is unreachable. The renderer has settings.cu_status_unavailable = "Bridge unavailable" for exactly this case, but dist/main/modules/local-runtime/computer-use/component-permissions.js converts every exception into blocked() → restricted → "Restricted (parental controls)", so that branch is never reached when the runtime fails to start. On a machine without any device-management restriction, the label is simply wrong.

   3. A one-command workaround exists for the macOS case (not for the Windows one): the ancestor check passes as soon as the home directory is not group/world writable — chmod g-w,o-w ~ — after which the component installs and verifies, and the shipped driver works (Accessibility/Screen Recording granted, live capture verified). The ACL entry for a second local account is unaffected by the mode change.

   Not a duplicate of this issue: different platform, different error code, different packaging constraint.
3. syxscott commented on Nov 1, 2026

   

   syxscott

   on Nov 1, 2026

   Author

   More actions

   Adding the Windows-side evidence for this report, obtained by calling the product's own shipped modules instead of inferring from the code path. This is the technique that pins the failure mode on Windows.

   Reproduction with the shipped library on this Windows host

   I extracted the shipped @mavis/computer-use modules from app.asar (dist/component.js, dist/packaged-component.js, dist/desktop-lock.js, dist/contracts.js) and called them directly, exactly as the utility does:

   // dataDir = C:\Users\Administrator\.minimax   (the profile root in use here)
   prepareInstalledPackagedComponent({
     dataDir, packagedRoot: '<app>\resources\resources\computer-use',
     releaseToken: '<build-injected token>', platform: 'win32', arch: 'x64',
   })

   Input	Result
   dataDir: 'C:\Users\Administrator\.minimax'	OK — release token verified, manifest digest matched, all 10 component files re-hashed and matched, component copied into …\computer-use\components\0.34.1\win32-x64\42dd5ca4… and re-verified after install
   dataDir: ''	THREW computer_component_invalid: Component and profile roots must be absolute host-owned paths.
   dataDir: '.minimax' (relative)	THREW the same computer_component_invalid
   privateDirectory(desktopLockRoot())	resolved — no throw

   Two things this settles:

   1. On Windows, an empty/non-absolute dataDir is the only preparation-time failure that remains. Every other candidate was executed successfully against the real files: the build-injected release token, the manifest digest, the per-file hashes, the tree verification, and the runtime-directory safety checks. verifyTreePermissions and assertSafeAncestors skip their uid/mode checks on win32 by design (process.platform !== 'win32' && …), so the macOS-style computer_runtime_directory_unsafe path does not apply here — privateDirectory() succeeds on this host.

   2. A ~/.minimax junction is not the cause. On this machine C:\Users\Administrator\.minimax is a junction to D:\AppData\.minimax; resolveProfileDataDir() resolves it via realpath and the preparation completes normally.

   So on Windows the failure requires dataDir to be empty or relative at the moment the helper starts — which is what dataDir: process.env.MINIMAX_DATA_DIR ?? '' yields when MINIMAX_DATA_DIR is unset in the main process at fork time (the variable is a transient override prepared for local-runtime forks and deleted again by restoreLocalRuntimeDataDirOverride(); utilityProcess.fork inherits process.env but does not inject the value explicitly).

   Cross-platform note on the shared UI defect

   The Windows and macOS reports (#572) have different underlying causes — macOS fails on computer_runtime_directory_unsafe (home directory 0777), Windows fails on computer_component_invalid (empty data dir) — but both render the identical dialog, because the utility's startup error is swallowed by .catch(() => process.exit(1)) and every probe failure collapses into blocked() → restricted → 「设备受限 (家长控制)」.

   That makes two of the suggested fixes platform-independent and worth doing for both platforms:

   • log the real errorCode before the utility exits (today only exitCode=1 is recorded — that missing code is the entire reason this took an exclusion analysis rather than a log read);
   • do not render the macOS TCC rows (Screen Recording / Accessibility) on Windows, and never label a generic probe failure as "parental controls".

   Verified locally with the shipped bundle: Desktop 3.1.4.127, Windows 10 x64 (build 26200), Node v24.22.1, profile root C:\Users\Administrator\.minimax.
4. hetaoBackend commented on Nov 1, 2026

   

   hetaoBackend

   on Nov 1, 2026

   Collaborator

   More actions

   Sorry this sat for five days without a reply from us. That's on us, not on you.

   Thank you @syxscott for the original report and for reproducing it against the shipped @mavis/computer-use modules. Pinning it to computer_component_invalid from an empty or non-absolute dataDir, rather than a permissions problem, is exactly what we needed. Thanks also to @wittkung for linking the macOS side in #572.

   I'm bringing this to the desktop team today, and we'll treat #548 and #572 as one failure family. We'll post the owner and the fix plan here. We'll also stop showing 「设备受限（家长控制）」 when the helper fails to start, since that message sends people the wrong way.
5. dyh-sjtu commented on Nov 1, 2026

   

   dyh-sjtu

   on Nov 1, 2026

   Collaborator

   More actions

   Thanks again @syxscott for the detailed evidence, and @wittkung for linking #572.

   Windows root cause: fixed in Desktop 3.1.8 and later. In 3.1.4 the profile root is checked by assertNoSymlink. Node reports an NTFS junction as a symbolic link, so a ~/.minimax junction (in your case C:\Users\Administrator\.minimax → D:\AppData\.minimax) is rejected with the same computer_component_invalid code as an empty dataDir. The message text tells the two apart: a junction gives "Symbolic links are not allowed in component/runtime paths.", while an empty or relative dataDir gives "Component and profile roots must be absolute host-owned paths."

   resolveProfileDataDir(), which realpaths the profile root before these checks, first shipped in 3.1.8. 3.1.4 does not have it, so a reproduction that calls it must have used modules from a later build. 3.1.8+ also writes the startup errorCode to the log before the helper exits, which was missing from the 3.1.4 logs.

   Misleading 「设备受限（家长控制）」 status: fix in review. A component failure will now show as "Unavailable" instead of "Restricted (parental controls)". The error code will be written to main-computer-use.log, and on Windows the dialog will no longer list the macOS Screen Recording and Accessibility rows. We'll update this issue once it ships.

   Could you update to 3.1.8 or later (3.1.10 is current) and try Computer Use again? If it still fails, please attach main-computer-use.log and the utility_exit line with its errorCode. That will show whether a second cause remains.