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

[gaojian125]

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 fix(mxc): PowerShell fails in the Windows node sandbox #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?

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 21, 2026, 3:07 AM ET / 07:07 UTC.

Summary
Keep open. Current main still treats a launcher-level MXC failure as a sandbox command failure rather than the documented unavailable-backend path, so this credible all-commands failure needs a narrowly security-reviewed classification.

Reproducibility: no. live affected host was available. Source tracing and the existing fake-executor tests provide a high-confidence focused regression shape: a matching launcher result currently cannot enter the unavailable-backend fallback path.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Should the exact SetInformationJobObject(JobObjectUILimitInformation) initialization failure be classified as MXC unavailable so the existing approved host-fallback policy can apply?	Recognize the exact launcher failure: Translate only the verified job-object initialization signature into the existing unavailable-backend path, preserving strict-mode denial.

Why: The desired repair changes whether an approved command remains contained on a host where the MXC launcher cannot initialize, so maintainers must confirm the narrowly recognized error boundary.

Next step
A maintainer must first approve the exact security-boundary classification before a repair can permit host fallback.

Security
Needs attention: The reported failure is security-sensitive because a repair may alter whether approved commands execute inside MXC containment or through host fallback.

Review details

Best possible solution:

Classify the verified job-object initialization signature as MXC-backend unavailable, then use the existing compatibility fallback or strict-denial policy with focused regression coverage and real gateway-to-node proof.

Do we have a high-confidence way to reproduce the issue?

No live affected host was available. Source tracing and the existing fake-executor tests provide a high-confidence focused regression shape: a matching launcher result currently cannot enter the unavailable-backend fallback path.

Is this the best way to solve the issue?

Unclear until the security boundary is confirmed. The Windows UI toggle is correctly separate from job-object setup; the narrowest repair is exact error recognition under the existing fallback policy, not a broad bypass for sandbox failures.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Treating arbitrary nonzero MXC results as unavailable could silently move approved commands from AppContainer containment to host execution; any fallback must recognize only a verified backend-initialization signature and preserve strict no-fallback denial.

Codex review notes: model internal, reasoning high; reviewed against d3ed6c78bf14.

Label changes

Label changes:

• add P1: All remotely approved system.run commands are blocked on the affected Windows node, disrupting a core agent-to-node workflow.
• add impact:other: The report concerns Windows-node command execution failure, which is meaningful operational impact outside the more specific owned impact classes.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-security-review: Current issue advisory state selects this label.

Label justifications:

• P1: All remotely approved system.run commands are blocked on the affected Windows node, disrupting a core agent-to-node workflow.
• impact:other: The report concerns Windows-node command execution failure, which is meaningful operational impact outside the more specific owned impact classes.

Evidence reviewed

Security concerns:

• [medium] Preserve the containment boundary — src/OpenClaw.Shared/Mxc/MxcCommandRunner.cs:178
  A repair must not map broad launcher or command failures to host fallback. It needs an exact, tested backend-initialization signature and must retain strict fallback blocking.
  Confidence: 0.94

What I checked:

• Launcher failures are returned as ordinary command results: The direct executor converts every normal wxc-exec.exe exit, including nonzero exits with stderr, into a result instead of a sandbox-unavailable exception. (src/OpenClaw.Shared/Mxc/MxcExecutor.cs:224, d3ed6c78bf14)
• Current runner preserves the failure: The runner returns that sandbox result directly; only SandboxUnavailableException reaches the compatibility fallback branch. (src/OpenClaw.Shared/Mxc/MxcCommandRunner.cs:163, d3ed6c78bf14)
• Existing test makes the gap explicit: The current regression test requires no host fallback for a generic nonzero sandbox result, so a recognized launcher-initialization signature needs a deliberately narrower path than arbitrary command failure. (tests/OpenClaw.Shared.Tests/Mxc/MxcCommandRunnerTests.cs:419, d3ed6c78bf14)
• Documented fallback contract: The FAQ says the default compatibility fallback applies when MXC is unavailable and strict mode instead denies execution, which supplies the intended safety boundary for a known backend setup failure. (docs/OPENCLAW_GATEWAY_NODE_EXEC_FAQ.md:646, d3ed6c78bf14)
• MXC dependency boundary: The tray build packages wxc-exec.exe from the pinned @microsoft/mxc-sdk 0.7.0 dependency, establishing that the reported job-object call is in the invoked MXC launcher boundary rather than gateway policy. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:112, d3ed6c78bf14)
• Feature provenance and release check: Blame attributes the current fallback behavior to the MXC UI compatibility change, and commit 4206611 is included in v2026.7.1. The current branch has no release tag containing d3ed6c7. (src/OpenClaw.Shared/Mxc/MxcCommandRunner.cs:178, 4206611f2b2e)

Likely related people:

• shanselman: The related merged MXC UI compatibility PR and blame for the central runner path both point to this contributor. (role: introduced the current MXC compatibility and fallback behavior; confidence: high; commits: 4206611f2b2e, 369287826f39; files: src/OpenClaw.Shared/Mxc/MxcCommandRunner.cs, src/OpenClaw.Shared/Mxc/MxcExecutor.cs, docs/OPENCLAW_GATEWAY_NODE_EXEC_FAQ.md)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[MilkyWay008]

The 0x80070057 on SetInformationJobObject is the MXC launcher, not the gateway or your box's policy, since the same build execs fine on your laptop. wxc-exec.exe is treating the failed job-object init as an ordinary command result, so the host-fallback (SandboxUnavailableException) path never engages and exec just dies. There's no user-facing switch to skip the UILimit call yet, so the real fix is the backend-classification patch that recognizes this exact signature. Oh, btw, in case it might help that, I built a portable Hermes OTG repo, check it, imo it may be able to help you diagnose and figure out the fix in no time. https://github.com/MilkyWay008/Hermes-OTG