SetInformationJobObject(JobObjectUILimitInformation) returns 0x80070057 on one Windows node — exec (system.run) cannot run; same-version laptop works

Summary

exec host=node against a paired Windows desktop node (OpenClaw desktop app, v2026.7.1, node-host / remote-pairing mode) fails every time with:

This blocks all system.run (exec) on this machine — no command can run remotely. Every other node channel works (screen.snapshot, device.status, system.notify, system.execApprovals.get/set).

Environment

• Desktop (affected): Windows 11 Pro (10.0.26100), OpenClaw desktop node v2026.7.1, clientMode: node, remote-paired to gateway v2026.8.1-beta.2 (100.69.89.74:18789).
• Launch method on desktop: started manually after login, as Administrator (right-click → Run as administrator). Not auto-start.
• Laptop (control): Windows node, same version v2026.7.1 — exec works normally (approval prompt shows, user clicks Allow, command runs).
• Gateway: 2026.8.1-beta.2.

Already ruled out (all tested, none fix it)

• ASUS ArmouryCrate + its kernel drivers (CTIAIO / IOMap / AsIO3) — stopped processes and drivers, no change.
• VBS / Core isolation (DeviceGuard all 0), Windows Defender real-time, third-party AV, SAC (Smart App Control = 0, disabled).
• Running node as Administrator, reinstalling node v2026.7.1.
• Desktop app "Allow Windows UI APIs" toggle (added by issue #1147, shipped in v2026.7.1): enabled + full app restart — no change (confirms a different mechanism than the Win32k-disable fix 0xc0000142).
• Plain PowerShell on the desktop can create a Job Object, set limits and run a child — exits 0, no error (OS-level job-object functionality is fine).

Key evidence

• The error string exists only on the Windows node side; it is absent from gateway/server dist. It is generated when the node sandbox applies JobObjectUILimitInformation to the exec child process.
• Same error whether approvals are "no prompt (ask=off)" or "prompt (ask=on)".
• Procmon capture found no blocking module (.sys) — consistent with 0x80070057 being a user-mode parameter-validation failure (fails before entering the kernel).

Questions for maintainers

1. Why would SetInformationJobObject(..., JobObjectUILimitInformation) return 0x80070057 (E_INVALIDARG) on one Windows machine but succeed on another machine with the identical node version? What prerequisite does this call require (desktop/session token, specific DLL state, Win32k desktop) that could differ per machine?
2. Is there an official/unpublished switch or env var to disable/bypass the job-object UILimit call for exec (e.g. something like disableJobObjectUILimit)? Note: this key is not present in the v2026.8.1 gateway schema, and I cannot confirm any Windows-node release newer than v2026.7.1 that carries it.
3. Windows CLI node-host (2026.8.1-beta.2) never creates exec-approvals.sock (Unix-socket semantics), so approval never surfaces and exec is always SYSTEM_RUN_DENIED — is this a known issue (references: #31175 / #20386)? Any Windows-native fix planned?

Start at the Windows node sandbox entry point that calls SetInformationJobObject with JobObjectUILimitInformation, and compare its behavior between the affected desktop node and the working laptop. Also inspect the CLI node-host path around exec-approvals.sock; done means identifying the machine-specific failure and restoring or clearly defining supported exec and approval behavior.