Windows companion 2026.7.1-4: dashboard-triggered PowerShell/where fail with 0xc0000142; manual PowerShell succeeds

[PollyBot13]

Reported on behalf of another user from a supplied public-support-thread summary dated 2026-09-16. This is not a local reproduction by the filing account. Root cause and fix remain unverified.

Summary

A user can run PowerShell successfully in their Windows terminal, but requesting shell execution through the OpenClaw dashboard leads to application-startup failures. Screenshots were identified during support as showing powershell.exe and where.exe application errors with code 0xc0000142 (DLL initialization failure).

The agent's repeated claim that an empty executable allowlist caused the failure is not established by the collected evidence. Gateway effective policy and the node's saved defaults/main-agent policy were all security=full, ask=off. The node does not expose a complete resolved host policy, so those saved settings do not establish every runtime restriction.

Environment

• Gateway/CLI: OpenClaw 2026.9.3, commit 1391f7c.
• Windows node reports version 2026.7.1-4.
• Companion state directory: %APPDATA%\OpenClawTray.
• Windows version reported earlier in the thread: 10.0.26200.9445.
• Earlier MCP crash output reported Node.js v26.8.1; the interpreter used by each current component has not been independently established.
• CLI launcher found at %APPDATA%\npm\openclaw.cmd.
• Agent model referenced in the conversation: minimax-portal/MiniMax-M3.
• Two paired node records with the same display name; one connected, one disconnected. Diagnostics targeted the connected node by ID.
• This is not a confirmed clean-install reproduction: troubleshooting included attempted configuration rewrites before the evidence below was collected.

The Gateway/node version difference is a diagnostic lead, not proof of incompatibility or causation.

Reported reproduction sequence

These steps describe the affected installation, not a maintainer-verified minimal reproduction.

1. Connect the Windows companion node to the Gateway and open the dashboard chat.
2. Ask the agent to execute:

   powershell.exe -NoProfile -Command Get-Date
   

3. Observe the Windows application-startup error during dashboard-triggered execution.
4. Run the same command manually in the user's existing PowerShell terminal.
5. Observe successful date output.

A subsequent dashboard-related screenshot was identified as a where.exe application error with the same code. Its complete command line and invocation context have not been captured.

Expected behavior

An authorized command should start successfully, or return an actionable error identifying the actual launch/policy failure. The same simple PowerShell command should not fail only through the companion without sufficient diagnostics to explain the difference.

Actual behavior and evidence

Manual PowerShell succeeds — direct user terminal output

PS C:\WINDOWS\system32> powershell.exe -NoProfile -Command Get-Date

Wednesday, September 16, 2026 4:16:08 PM

Dashboard execution fails — screenshots and agent summaries

The support conversation recorded screenshots of application-error dialogs for:

• powershell.exe: 0xc0000142.
• where.exe: 0xc0000142.

Original screenshot message links are below. The filing agent could not access the source Discord messages in this session; screenshots are not attached or independently inspected here.

The user's agent separately reported this output:

Warning: tools.exec.pathPrepend is ignored for host=node.
Access is denied.
(Command exited with code 1)

It also reported a different test ending with -1073741502, which corresponds to 0xC0000142, not 0xC000013A.

Evidence boundary: these textual tool results were copied from the agent's prose, not obtained as a complete raw tool invocation/result. The exit-1 report and the application-error reports should not be assumed to be the same attempt. Exact argv, working directory, environment, launch identity, and timestamps remain missing.

Gateway approvals — direct CLI output

Command used:

openclaw.cmd approvals get --gateway

Reported:

Defaults: security=full, ask=off, askFallback=full, autoAllowSkills=on
Agents: 0
Allowlist: 0
Effective tools.exec: security=full, ask=off

openclaw.cmd approvals pending reported no pending approvals at the time checked. This is not proof that no approval was ever requested.

Node approvals — direct CLI output and selected local file contents

The connected node's approvals report showed:

Path: %APPDATA%\OpenClawTray\exec-approvals.json
Defaults: security=full, ask=off, askFallback=deny, autoAllowSkills=off
Agents: 1
Allowlist: 0

Effective Policy
This node does not expose a complete resolved host policy, so Effective Policy is unavailable.

Reading only the file's agents field returned:

{
  "main": {
    "security": "full",
    "ask": "off",
    "askFallback": "deny"
  }
}

Node capabilities — direct CLI output

Selected fields from openclaw.cmd nodes describe --node <connected-node-id> --json:

{
  "platform": "windows",
  "version": "2026.7.1-4",
  "clientId": "node-host",
  "clientMode": "node",
  "deviceFamily": "Windows",
  "sessionHost": false,
  "approvalState": "approved",
  "paired": true,
  "connected": true
}

The returned command list includes system.run, system.run.prepare, system.which, and system.execApprovals.get/set. A missing advertised shell-execution capability is therefore not supported by this output. Pairing approval alone does not authorize every shell command.

Diagnostics already attempted

• Confirmed openclaw.cmd works. Bare openclaw previously produced unexpected launcher behavior; the Windows launcher association/resolution issue was not fully diagnosed.
• Confirmed manual PowerShell launch succeeds.
• Checked Gateway policy, connected-node saved policy, and main-agent saved policy.
• Checked node connection/capabilities.
• Queried the Windows Application event log for messages containing powershell.exe in the prior 30 minutes; no output. The query used -ErrorAction SilentlyContinue, so this does not establish that no relevant event or query error existed.
• Recursively listed %APPDATA%\OpenClawTray\Logs, including hidden files. Only September 9 setup logs were found, not current execution logs.
• Located a Diagnostics item in the tray menu, but no resulting diagnostic report has yet been collected.
• No verified fix, clean reinstall reproduction, or successful companion execution retest has been obtained.

Configuration history / confounders

The user's agent suggested unsupported nested configuration paths involving agents.entries.main.models.…agentRuntime.tools.exec and whole-file PowerShell rewrites. A direct terminal capture shows a property-not-found error. A later save line could still have rewritten configuration after that error.

The agent also claimed backups/restoration and additional script changes; these claims have not all been independently verified. Do not treat the current state as pristine or the claimed backup as verified.

An earlier, separate MCP subprocess-cleanup crash reported:

Error: stdio process cleanup cannot confirm descendant extinction

That earlier crash should be triaged separately unless evidence links it to this launch failure.

Requested engineering investigation

1. Capture a complete failing exec invocation and node-side process-launch diagnostics: executable path, argv, cwd, sanitized environment differences, process/user/session identity, launch flags, and native error/exit status.
2. Identify the supported way to obtain current runtime logs from this companion build; the discovered directory only contained setup logs.
3. Reproduce on the reported Gateway/companion version pair and compare with a supported matched/current pair in a controlled test.
4. Compare terminal and companion launch contexts for both PowerShell and where.exe; do not assume permissions, PATH, a specific DLL, security software, or the version mismatch is the cause without evidence.
5. Preserve existing configuration and approval policy while collecting evidence. No further blanket permission widening is justified by these findings.

Source references

• Public support thread: https://discord.com/channels/1456350064065904867/1546779292078313543
• Manual PowerShell success: https://discord.com/channels/1456350064065904867/1546779292078313543/1549740683559174215
• PowerShell screenshot message: https://discord.com/channels/1456350064065904867/1546779292078313543/1549740882218061864
• where.exe screenshot message: https://discord.com/channels/1456350064065904867/1546779292078313543/1549743949110054996
• Node capability output: https://discord.com/channels/1456350064065904867/1546779292078313543/1549742567950917713
• Node main-agent policy: https://discord.com/channels/1456350064065904867/1546779292078313543/1549740596917313537
• Tagged CLI documentation: https://github.com/openclaw/openclaw/blob/v2026.9.3/docs/cli/nodes.md
• Tagged approval documentation: https://github.com/openclaw/openclaw/blob/v2026.9.3/docs/cli/approvals.md

Discord references may require server access. Sanitized original screenshots and complete raw invocation/results remain evidence gaps.

Related reports and diagnostic leads

• [Bug]: Windows Companion node sandbox hardcodes ui.disable=true (Win32k syscall disable), killing every user32-linked child program (whoami, where, tasklist, powershell, pwsh) with 0xc0000142 / empty stdout #1143 (closed) reports the same error family for PowerShell and other User32-linked programs under MXC UI-deny on an older companion. This could be the same policy behavior, but this installation’s active sandbox mode and Windows UI API setting were not captured; recurrence/regression is not established.
• SetInformationJobObject(JobObjectUILimitInformation) returns 0x80070057 on one Windows node — exec (system.run) cannot run; same-version laptop works #1189 (open) concerns SetInformationJobObject(JobObjectUILimitInformation) / 0x80070057. That signature is not present in this supplied evidence, so it should not be assumed to be the same defect.
• Windows node: allow unsandboxed exec mode for trusted nodes openclaw#149401 discusses local sandbox controls and the companion ownership boundary; this report requests diagnosis and actionable launch errors, not an unsandboxed-execution feature or broader approval policy.
• The current companion README documents %LOCALAPPDATA%\OpenClawTray\openclaw-tray.log, whereas support inspected %APPDATA%\OpenClawTray\Logs. The former has not yet been collected from the affected host. Current README also documents openclaw://logs and redacted support-context diagnostics; availability in this exact installed build has not been verified.

Please first determine whether this is expected UI-deny behavior needing clearer diagnostics, recurrence of #1143, or a separate launch-context failure. Preserve the user’s current configuration and sandbox settings while collecting that evidence. Model troubleshooting errors and the earlier MCP cleanup crash are outside this issue’s scope.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 16, 2026, 8:05 AM ET / 12:05 UTC.

Summary
Keep open: the reported launch failure remains unverified, and current main does not establish its resolution. The earlier PowerShell fix already exists in the reported release, so it cannot alone justify closing this report.

Reproducibility: no. The report provides a useful affected-host sequence, but no complete raw failing invocation or current-release reproduction establishes the active execution route; no runtime tests were executed during this read-only review.

Ways to help us reproduce this

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

Next step
A safe repair boundary is not established: collect a redacted raw invocation/result and existing Diagnostics output with sandbox settings, then compare on the supported release while preserving configuration.

Review details

Best possible solution:

Use the existing Diagnostics surface to explain the actual launch failure and offer policy-preserving recovery guidance, without automatically relaxing containment or approvals.

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

No. The report provides a useful affected-host sequence, but no complete raw failing invocation or current-release reproduction establishes the active execution route; no runtime tests were executed during this read-only review.

Is this the best way to solve the issue?

Yes, diagnosis before changing policy is the appropriate approach. Existing UI compatibility controls and diagnostics should be checked before adding another execution path or attributing the failure to approvals.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The active sandbox mode, Windows UI API setting, and complete failing invocation are unknown, so policy denial and another launch-context failure cannot yet be distinguished.
• Current main additionally restricts sandbox admission to safe BaseContainer support; a changed execution route on upgrade would not by itself demonstrate that the original failure was repaired.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Label changes

Label changes:

• add P2: This is a concrete, installation-specific Windows command-execution failure whose current cause and scope remain unverified.
• add impact:other: The affected product capability is remote Windows process execution, outside the more specific impact categories established by this evidence.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.

Label justifications:

• P2: This is a concrete, installation-specific Windows command-execution failure whose current cause and scope remain unverified.
• impact:other: The affected product capability is remote Windows process execution, outside the more specific impact categories established by this evidence.

Evidence reviewed

What I checked:

• Reported evidence boundary: The supplied issue body distinguishes successful manual PowerShell output from secondhand dashboard results. Exact failing argv, active sandbox settings, launch context, original screenshots, and a successful current-version retest are missing; the exit-1 and DLL-initialization reports may be separate attempts.
• Existing fix predates the affected release: GitHub verifies fix(mxc): PowerShell fails in the Windows node sandbox #1147 (fix(mxc): PowerShell fails in the Windows node sandbox) merged on August 11, 2026. It added a default-off Windows UI API setting and actionable denial for direct PowerShell requests, and closed the older hardcoded-policy report. (4206611f2b2e)
• Release containment check: Both the reported v2026.7.1-4 tag and latest v2026.9.4 contain the earlier UI-policy fix. Its existence therefore does not prove this affected installation is fixed. (4206611f2b2e)
• Current policy and error boundary: The configuration builder rejects recognized PowerShell-family launches when Windows UI access is denied; the command runner returns actionable guidance for that exception. Ordinary nonzero process results remain command failures rather than automatically becoming host fallback. (src/OpenClaw.Shared/Mxc/MxcCommandRunner.cs:213, 3c43751b2bac)
• Documented alternative failure mechanism: The execution FAQ describes host-specific child-process failures with 0xC0000142 or Access is denied, independent of approval allowlists, and separately documents Win32k denial. Similar error codes alone cannot establish which mechanism affected this installation. (docs/OPENCLAW_GATEWAY_NODE_EXEC_FAQ.md:620, 3c43751b2bac)
• Available diagnostic surface: README documents openclaw://logs, openclaw://support-context, and %LOCALAPPDATA%\OpenClawTray\openclaw-tray.log. The current runner records sandbox settings, executor, shell mode, policy, exit code, and containment without logging raw command content by default. (README.md:148, 3c43751b2bac)

Likely related people:

• shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Barbara Kudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.