ACL hardening Error - QEMU ARM64 Windows VM

[michaelchan1992]

Client or integration

Other

Area

CLI

Summary

After version 2.10.2, i get hit by this error,

DeepSeek-V4-Flash-0731 answer:
Root cause found
Your machine is a QEMU ARM64 Windows VM (virt-7.2, ARM64 OS) and ocx runs on the bundled Bun v1.3.14 Windows-arm64 binary, which has bun:ffi compiled out ("TinyCC is disabled" — TinyCC doesn't support aarch64, a known open platform gap, oven-sh/bun#28055).

C:\Users\Administrator>ocx start
[opencodex] Config mutation coordination directory ACL hardening did not complete; continuing without it. ACL hardening failed (EACLIDENTITY) — the effective Windows account SID could not be resolved
570 | && String((error as NodeJS.ErrnoException).code) === "ETIMEDOUT";
571 | }
572 |
573 | /** Preserve only the bounded machine-readable cause on a sanitized public error. */
574 | function sanitizedAclError(diagnostics: string, cause: unknown): NodeJS.ErrnoException {
575 | const error = new Error(diagnostics) as NodeJS.ErrnoException;
^
error: ACL hardening failed (EACLIDENTITY) — the effective Windows account SID could not be resolved
code: "EACLIDENTITY"

  at sanitizedAclError (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\lib\windows-secret-acl.ts:575:21)
  at hardenEntry (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\lib\windows-secret-acl.ts:728:28)
  at harden (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\config.ts:222:39)
  at atomicWriteFile (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\config.ts:235:8)
  at persistConfigUnlocked (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\config.ts:2559:3)
  at <anonymous> (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\config.ts:2572:9)
  at withConfigMutationLockSync (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\config.ts:2426:19)
  at saveConfig (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\config.ts:2570:3)
  at reconcileOAuthProviders (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\oauth\index.ts:819:16)
  at startServer (C:\Users\Administrator\AppData\Roaming\npm\node_modules\@bitkyc08\opencodex\src\server\index.ts:469:3)

Bun v1.3.14 (Windows arm64)

Reproduction

ocx start

Version

2.12.0

Operating system

QEMU ARM64 Windows 11 VM

Provider and model

No response

Logs or error output

Screenshots and supporting files

No response

Redacted configuration

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

[Ingwannu]

Confirmed on current dev. This is a real Windows ARM64 compatibility bug in the ACL identity path.

The SID lookup itself is not failing because of the account. Before PowerShell can run, resolveTrustedWindowsPowerShellExe() resolves System32 through GetSystemDirectoryW using bun:ffi. Bun 1.3.14 for Windows ARM64 cannot provide that FFI call, so executable resolution throws; the ACL layer sanitizes that as EACLIDENTITY, and a later required config-file harden aborts startup.

I will keep the security boundary intact while fixing the ARM64 path:

• retain GetSystemDirectoryW as the primary resolver;
• add a Windows-ARM64-only fallback for the non-elevated ACL SID query, anchored to the fixed protected default OS path C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe;
• never use SystemRoot, WINDIR, PATH, USERNAME, or USERDOMAIN as trust input;
• do not reuse the fallback for Task Scheduler/UAC elevation;
• fail closed when the fixed executable is absent (for example, a non-default Windows installation), rather than selecting an environment-controlled binary;
• add focused tests for ARM64 selection, hostile environment isolation, x64/non-Windows refusal, and missing-file refusal, plus the existing ACL suites and typecheck/privacy checks.

I will link the dev-targeted draft PR and exact verification here after the patch is ready.

[Ingwannu]

Implemented the narrow Windows ARM64 compatibility fix in draft PR #1452: #1452

The patch keeps GetSystemDirectoryW as the primary trusted resolver. Only the non-elevated ACL SID lookup on Windows ARM64 may fall back to the fixed protected default path C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe, and only when that exact file exists. It does not trust SystemRoot, WINDIR, PATH, USERNAME, or USERDOMAIN; it does not broaden the UAC or Task Scheduler paths; and non-default Windows roots continue to fail closed.

Exact-head verification:

• ACL/elevation focused suite: 238 pass, 0 fail
• typecheck: passed
• privacy scan: passed
• diff check: passed

I am leaving the issue open until Windows CI and independent maintainer review complete and the PR is integrated into dev.

[lidge-jun]

Fixed on dev (fcb337a18 + 4368bb352, via #1452).

The bundled Bun Windows-arm64 binary ships without bun:ffi (TinyCC has no aarch64 support), so the FFI path used to resolve the system directory is unavailable and the effective SID cannot be found — which is the EACLIDENTITY you hit. There is now a fallback to the default System32 PowerShell for exactly that condition.

Deliberately narrow: the fallback fires only on a typed WindowsSystemDirectoryFfiUnavailableError, thrown only where the FFI function cannot be loaded. Every other resolution failure — API call failure, a non-default Windows root, containment and validation failures — still fails closed rather than silently switching to a hard-coded path, because that path feeds SID discovery for secret-file ACL hardening.

Verified: 27 pass / 0 fail across the principal and elevation suites, with four fail-closed regressions that go red if the gate is removed. Note that no real ARM64 Windows host was exercised — windows N/4 is dispatch-only (#1059) — so if you can retry on your VM after the next release, that report would be valuable.