Update does not work | Friends of the Crustacean 🦞🤝 | Page 1

thick pecan Apr 16, 2026, 7:38 PM

#

I tried to update openclaw by issuing "openclaw update". This did not work. On the end of the console output was written "run openclaw doctor".

So I ran openclaw doctor with those results (i first ran only "openclaw doctor", afterwards I tried with "openclaw doctor --fix", both results are the same):

PS C:\Users\Assistent> openclaw doctor --fix

dark sparrowBOT Apr 16, 2026, 7:38 PM

#

polar schoonerBOT Apr 16, 2026, 7:38 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

dark sparrowBOT Apr 16, 2026, 7:38 PM

#

dull palmBOT Apr 16, 2026, 7:41 PM

#

This looks like 3 separate issues, and the actual update may already have succeeded.

openclaw update ends by running doctor
@discordjs/opus failed to install, that is an optional Discord voice runtime dep
the bigger blocker is your gateway service was not installed, and Windows denied the Scheduled Task creation (schtasks, “Zugriff verweigert”)

So I’d do this first on native Windows:

# PowerShell as Administrator
openclaw gateway install
openclaw gateway status --json

If you do not need auto-start yet, skip service install for now and just run:

#

openclaw gateway run

I would ignore @discordjs/opus for the moment unless you specifically need Discord voice. It is not the first thing I’d chase.

Also, Windows support exists, but WSL2 is still the recommended path:

If gateway install still fails, paste these next:

openclaw status --all
openclaw gateway install --json

#

and, if possible, the full earlier lines around the npm install failed part. That should make the remaining blocker pretty clear.

thick pecan Apr 16, 2026, 8:13 PM

#

I guess with "native windows" you mean a simple command line (cmd).
So I did it and the result looks familiar:

openclaw gateway install

🦞 OpenClaw 2026.4.14 (323493f) — I autocomplete your thoughts—just slower and with more API calls.

Gateway install failed: Error: schtasks create failed: FEHLER: Zugriff verweigert

dull palmBOT Apr 16, 2026, 8:14 PM

#

Yep, native Windows means “running directly in Windows”, not WSL2.

The important distinction here is not cmd vs PowerShell, it is normal shell vs Administrator shell.

schtasks create failed: Zugriff verweigert means Windows refused to create the Scheduled Task. So the next thing to try is:

open PowerShell as Administrator
run:

openclaw gateway install
openclaw gateway status --json

If you cannot run an elevated shell on that machine, then skip the service install for now and just start it manually:

#

openclaw gateway run

I’d still ignore the @discordjs/opus error for now. That is secondary.

If you already did run as Administrator and still get the same error, then I’m worried this is either:

a local Windows policy restriction, or
a native-Windows bug/regression

In that case, please paste:

openclaw gateway install --json
openclaw status --all

#

Docs here:

thick pecan Apr 16, 2026, 8:24 PM

#

I startet the PS in admin mode:

PS C:\Windows\system32> openclaw gateway install
openclaw : Die Benennung "openclaw" wurde nicht als Name eines Cmdlet, einer
Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt.
Überprüfen Sie die Schreibweise des Namens, oder ob der Pfad korrekt ist
(sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1

openclaw gateway install

  + CategoryInfo          : ObjectNotFound: (openclaw:String) [], CommandN
 otFoundException
  + FullyQualifiedErrorId : CommandNotFoundException

dull palmBOT Apr 16, 2026, 8:24 PM

#

Ah, that’s actually useful. We’re past the schtasks part for a moment, this one is just a PATH issue in the elevated shell.

Your normal shell can find openclaw, but the Administrator shell cannot.

Fastest fix:

In your normal PowerShell, run:

where.exe openclaw

It should print the full path to openclaw.cmd or openclaw.exe
Then in the Administrator PowerShell, run that full path explicitly, for example:

#

& "C:\Users\Assistent\.local\bin\openclaw.cmd" gateway install

That C:\Users\Assistent\.local\bin\openclaw.cmd path is a common one for the git installer, but use whatever where.exe openclaw actually prints.

If where.exe openclaw prints nothing, try this in the normal shell:

npm prefix -g

On Windows, that prefix usually needs to be on PATH:
https://docs.openclaw.ai/install/node#troubleshooting

Also relevant:
https://docs.openclaw.ai/install/installer

#

If you want, paste the output of where.exe openclaw, and I’ll tell you the exact command to run in the admin shell.

thick pecan Apr 16, 2026, 8:33 PM

#

where.exe reports that no file named openclaw (or openclaw.cmd) could be found. Maybe it got lost during the broken installation?

#

No

dull palmBOT Apr 16, 2026, 8:33 PM

#

That does not necessarily mean it was deleted.

where.exe only checks PATH. PowerShell can still run something via an alias, function, or script shim that where.exe will not show.

So the better check is this, in the shell where openclaw still works:

Get-Command openclaw | Format-List Name,CommandType,Source,Definition,Path

What I’d do next:

if Path is shown, copy that exact path and run it in the Administrator PowerShell
if it comes back as an alias/function, or points to some weird temp location, I’d repair the install

For a repair reinstall on Windows, I’d use:

#

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -NoOnboard

Then check:

openclaw --version
openclaw gateway install

Docs:

If you paste the output of Get-Command openclaw | Format-List ..., I can tell you whether to use the existing path or go straight to reinstall.

#

Got it. Then I’d stop digging and just repair the CLI install.

In a normal PowerShell, run:

& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1))) -NoOnboard

Then:

close all PowerShell windows
open a fresh normal PowerShell and check:

openclaw --version

#

open PowerShell as Administrator and run:

openclaw gateway install

then run:

openclaw doctor

Important: PATH changes usually only show up in newly opened shells, so don’t reuse the old admin window.

Docs:

#

If openclaw is still not found after reinstall in a fresh shell, paste the installer output. At that point I’d suspect a real Windows PATH/install bug.

thick pecan Apr 16, 2026, 8:37 PM

#

I used where in the normal powershell to find the path.

Then i called it in the admin console:

PS> C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd gateway install

🦞 OpenClaw 2026.4.14 (323493f) — I can run local, remote, or purely on vibes—results may vary with DNS.

Gateway install failed: Error: schtasks create failed: FEHLER: Zugriff verweigert

dull palmBOT Apr 16, 2026, 8:37 PM

#

Okay, that narrows it down a lot.

Since it still fails with the full path from an elevated PowerShell, this is not a PATH problem anymore.

At this point, I’d treat it as one of these:

a Windows policy/permission restriction on this machine
or a native Windows bug/regression in the gateway install flow

Also, current docs say native Windows should fall back to a Startup-folder login item if Scheduled Task creation is denied, so the fact it still hard-fails is a bit suspicious:
https://docs.openclaw.ai/platforms/windows

Best short-term unblock

If you just want OpenClaw running now, skip service install and do:

#

openclaw gateway run

That avoids schtasks completely.

Best long-term path

If you want a reliable always-on setup on Windows, I’d honestly use WSL2:
https://docs.openclaw.ai/platforms/windows

I do think this is worth reporting

Please file a GitHub issue here:
https://github.com/openclaw/openclaw/issues

Include:

#

openclaw --version
openclaw gateway install --json
openclaw status --all

and mention:

native Windows
elevated PowerShell
full path C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd
still gets schtasks create failed: Zugriff verweigert

I’d still ignore the @discordjs/opus bit for now, that is secondary.

If openclaw gateway run works, glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.

#

This helps Answer Overflow index the solution for future users.

thick pecan Apr 16, 2026, 8:41 PM

#

I think I made an error before. So I closed all consoles, opened a new Admin PS and tried again.

This time this was the result

C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd gateway install

🦞 OpenClaw 2026.4.14 (323493f) — Your task has been queued; your dignity has been deprecated.

No gateway token found. Auto-generated one and saving to config.

Installed Scheduled Task: OpenClaw Gateway
Task script: C:\Users\conta.openclaw\gateway.cmd

dull palmBOT Apr 16, 2026, 8:42 PM

#

Nice, that’s real progress 🎉

The Scheduled Task installed, so the permission/path mess is basically resolved.

Two quick checks now:

C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd gateway status --json
C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd status --all

If those look healthy, then run:

C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd doctor

#

One thing I do want to flag though:

earlier your config path was C:\Users\Assistent\.openclaw\openclaw.json
but the install output says task script: C:\Users\conta\.openclaw\gateway.cmd

If conta and Assistent are different Windows users, that could cause weird config/state mismatches later. So please tell me if that path difference is expected.

Also, if the only remaining doctor warning is @discordjs/opus, I’d ignore that unless you specifically need Discord voice.

thick pecan Apr 16, 2026, 8:44 PM

#

This conta user is the admin user. I guess the script dumped the gateway.cmd into the wrong user folder. Also I wonder if user "Assistent" could execute that command, as it was created with elevated rights by the admin.

dull palmBOT Apr 16, 2026, 8:45 PM

#

Yes, I think you found the real issue.

The service got installed from the admin profile, so it wrote gateway.cmd into:

C:\Users\conta\.openclaw\gateway.cmd

but your actual OpenClaw config/state appears to live under:

C:\Users\Assistent\.openclaw

I would not leave it like that.

I’d fix it like this

In Administrator PowerShell:

#

schtasks /Delete /F /TN "OpenClaw Gateway"

if (Test-Path "C:\Users\conta\.openclaw\gateway.cmd") {
  Remove-Item -Force "C:\Users\conta\.openclaw\gateway.cmd"
}

$env:OPENCLAW_CONFIG_PATH = "C:\Users\Assistent\.openclaw\openclaw.json"
$env:OPENCLAW_STATE_DIR   = "C:\Users\Assistent\.openclaw"

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway install
& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway status --json

That should force the installed task to use the Assistent user’s config/state, even though you are creating it from the admin shell.

Then, back in the normal Assistent shell, check:

#

openclaw status --all
openclaw doctor

Relevant docs:

If you want, paste the output of gateway status --json after reinstalling the task, and I’ll sanity-check it.

thick pecan Apr 16, 2026, 8:48 PM

#

{
"logFile": "C:\Users\conta\AppData\Local\Temp\openclaw\openclaw-2026-04-16.log",
"service": {
"label": "Scheduled Task",
"loaded": true,
"loadedText": "registered",
"notLoadedText": "missing",
"command": {
"programArguments": [
"C:\Program Files\nodejs\node.exe",
"C:\Users\Assistent\AppData\Roaming\npm\node_modules\openclaw\dist\index.js",
"gateway",
"--port",
"18789"
],
"environment": {
"OPENCLAW_STATE_DIR": "C:\Users\Assistent\.openclaw",
"OPENCLAW_CONFIG_PATH": "C:\Users\Assistent\.openclaw\openclaw.json",
"OPENCLAW_GATEWAY_PORT": "18789"
},
"sourcePath": "C:\Users\Assistent\.openclaw\gateway.cmd"
},
"runtime": {
"status": "unknown",
"state": "Bereit",
"detail": "Task status is locale-dependent and no numeric Last Run Result was available."
},
"configAudit": {
"ok": true,
"issues": []
}
},
"config": {
"cli": {
"path": "C:\Users\Assistent\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": true
}
},
"daemon": {
"path": "C:\Users\Assistent\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": true
}
}
},
"gateway": {
"bindMode": "loopback",
"bindHost": "127.0.0.1",
"port": 18789,
"portSource": "service args",
"probeUrl": "ws://127.0.0.1:18789",
"probeNote": "Loopback-only gateway; only local clients can connect."
},
"port": {
"port": 18789,
"status": "free",
"listeners": [],
"hints": []
},
"rpc": {
"ok": false,
"error": "gateway closed (1006): ",
"url": "ws://127.0.0.1:18789"
},
"health": {
"healthy": false,
"staleGatewayPids": []
},
"extraServices": []
}

dull palmBOT Apr 16, 2026, 8:49 PM

#

Nice, this is much cleaner now.

The important part is fixed:

OPENCLAW_STATE_DIR → C:\Users\Assistent\.openclaw
OPENCLAW_CONFIG_PATH → C:\Users\Assistent\.openclaw\openclaw.json
sourcePath → C:\Users\Assistent\.openclaw\gateway.cmd

So the wrong-user-path problem is gone. ✅

What’s left is simpler: the task is only registered / ready (Bereit), but the gateway is not actually running yet:

port 18789 is still free
rpc.ok is false

Next step

#

In the same Admin PowerShell, run:

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway start
& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway status --json

If it still does not come up, immediately run:

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" logs --follow

At this point I’d expect one of two outcomes:

it starts, and port.status changes from free to listening
it starts and then crashes, in which case the log will tell us why

#

If you paste the result of gateway start plus the next gateway status --json, we should be very close now.

thick pecan Apr 16, 2026, 8:55 PM

#

Inside admin console I ran a doctor first.

{
"logFile": "C:\Users\conta\AppData\Local\Temp\openclaw\openclaw-2026-04-16.log",
"service": {
"label": "Scheduled Task",
"loaded": true,
"loadedText": "registered",
"notLoadedText": "missing",
"command": {
"programArguments": [
"C:\Program Files\nodejs\node.exe",
"C:\Users\Assistent\AppData\Roaming\npm\node_modules\openclaw\dist\index.js",
"gateway",
"--port",
"18789"
],
"environment": {
"OPENCLAW_STATE_DIR": "C:\Users\Assistent\.openclaw",
"OPENCLAW_CONFIG_PATH": "C:\Users\Assistent\.openclaw\openclaw.json",
"OPENCLAW_GATEWAY_PORT": "18789"
},
"sourcePath": "C:\Users\Assistent\.openclaw\gateway.cmd"
},
"runtime": {
"status": "unknown",
"state": "Bereit",
"detail": "Task status is locale-dependent and no numeric Last Run Result was available."
},
"configAudit": {
"ok": true,
"issues": []
}
},
"config": {
"cli": {
"path": "C:\Users\Assistent\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": true
}
},
"daemon": {
"path": "C:\Users\Assistent\.openclaw\openclaw.json",
"exists": true,
"valid": true,
"controlUi": {
"allowInsecureAuth": true
}
}
},
"gateway": {
"bindMode": "loopback",
"bindHost": "127.0.0.1",
"port": 18789,
"portSource": "service args",
"probeUrl": "ws://127.0.0.1:18789",
"probeNote": "Loopback-only gateway; only local clients can connect."
},
"port": {
"port": 18789,
"status": "free",
"listeners": [],
"hints": []
},
"rpc": {
"ok": false,
"error": "gateway closed (1006): ",
"url": "ws://127.0.0.1:18789"
},
"health": {
"healthy": false,
"staleGatewayPids": []
},
"extraServices": []
}

dull palmBOT Apr 16, 2026, 8:55 PM

#

Yep, that doctor output is basically saying:

the task is installed correctly now
but the gateway is still not started

So the next step is not doctor, it is:

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway start
& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway status --json

doctor checks/repairs things, it does not mean the Scheduled Task is actively running.

If gateway start still doesn’t bring it up, run:

#

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" logs --follow

and paste the first error lines after trying gateway start.

You’re actually pretty close now, the service registration looks sane.

thick pecan Apr 16, 2026, 8:56 PM

#

I did that.

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway start

🦞 OpenClaw 2026.4.14 (323493f) — Somewhere between 'hello world' and 'oh god what have I built.'

Restarted Scheduled Task: OpenClaw Gateway
PS C:\Windows\system32> & "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway status --json

the json from before<

dull palmBOT Apr 16, 2026, 8:57 PM

#

Got it. That means the task is being triggered, but the gateway is not staying up.

So now we need the actual crash output.

Best next step

In one console, run:

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" logs --follow

Then in another console, run:

& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway start

#

and paste the first error lines that appear in the log.

If the log stays empty

Run the generated task script directly once, so the error prints in the terminal:

& "C:\Users\Assistent\.openclaw\gateway.cmd"

At this point we’re past install/setup. The remaining problem is almost certainly “starts, then crashes immediately”, and the log or direct script output will tell us why.

thick pecan Apr 16, 2026, 9:07 PM

#

attaching to the logs did not work without a running gateway.
starting the gateway via ...\Roaming\npn\openclaw.cmd from a normal/non admin PS did not work. See this:
& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway start

🦞 OpenClaw 2026.4.14 (323493f) — I'm basically a Swiss Army knife, but with more opinions and fewer sharp edges.

Gateway start failed: Error: schtasks run failed: FEHLER: Zugriff verweigert
Tip: openclaw gateway install
Tip: openclaw gateway
Tip: schtasks /Run /TN "OpenClaw Gateway"
PS C:\Users\Assistent>

Calling the .openclaw\gateway.cmd did work. It started up an was running.

dull palmBOT Apr 16, 2026, 9:08 PM

#

That’s actually a really useful result.

If C:\Users\Assistent\.openclaw\gateway.cmd starts and runs, then OpenClaw itself is fine.
The remaining problem is specifically Windows Scheduled Task permissions / ownership.

What’s happening now is probably:

the task was created from the admin account
so the normal Assistent user cannot schtasks /Run it
but the generated gateway script itself is valid and works

Practical conclusion

For right now, I would stop fighting Task Scheduler and use:

#

& "C:\Users\Assistent\.openclaw\gateway.cmd"

That is the cleanest workaround, and it proves your config/state are okay.

What this means

So the problem is no longer “update is broken” or “gateway is broken”.

It’s more like:

native Windows Scheduled Task management is broken on this setup, but the gateway script runs fine

I’d recommend 2 next actions

Use gateway.cmd for now

#

Open a GitHub issue with exactly this finding:
- installing/running the Scheduled Task needs admin
- normal user gets schtasks ... Zugriff verweigert
- C:\Users\Assistent\.openclaw\gateway.cmd works fine

Issue link:
https://github.com/openclaw/openclaw/issues

And yes, I’d still ignore the @discordjs/opus warning unless you specifically need Discord voice.

If this workaround is good enough for now, glad we finally cornered it 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

thick pecan Apr 16, 2026, 9:11 PM

#

Could you generate a promt for chatGPT so I can ask him to continue with the scheduler? I hope it is possible to rectify this. Please add as much openclaw know how into the prompt, as that model has not so much insight like you into openclaw.

dull palmBOT Apr 16, 2026, 9:12 PM

#

Yep, here’s a copy-paste prompt for ChatGPT.

You are helping me troubleshoot a native Windows OpenClaw scheduler problem.

Please focus specifically on the Windows Scheduled Task / scheduler side. Do not get distracted by secondary OpenClaw warnings unless they directly affect the scheduler.

Context and known facts:

- Product: OpenClaw
- Version: 2026.4.14 (323493f)
- OS: native Windows, not WSL2
- CLI path:
  C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd
- Main OpenClaw config:
  C:\Users\Assistent\.openclaw\openclaw.json

#

- Main OpenClaw state dir:
  C:\Users\Assistent\.openclaw
- Normal user account:
  Assistent
- Admin account:
  conta

Important OpenClaw know-how:
- On native Windows, OpenClaw uses a Scheduled Task named "OpenClaw Gateway" for managed startup.
- The generated task script lives in the OpenClaw state dir as:
  C:\Users\<user>\.openclaw\gateway.cmd
- The gateway can also be run directly via that generated script, without Task Scheduler.
- In my case, running the generated gateway.cmd directly works, so OpenClaw itself seems fine.
- This strongly suggests the remaining problem is Task Scheduler ownership / permissions / principal / run rights, not the OpenClaw runtime itself.
- There was also a warning about missing bundled plugin runtime dep @discordjs/opus during `openclaw doctor --fix`, but that is secondary and probably unrelated unless Discord voice matters. Please ignore it unless it directly explains the scheduler issue.

#


What happened:
1. `openclaw update` ended by telling me to run `openclaw doctor`
2. `openclaw doctor --fix` originally showed:
   - gateway not running
   - gateway service not installed
   - gateway install failed with:
     `schtasks create failed: FEHLER: Zugriff verweigert`
3. Running OpenClaw commands from elevated/admin PowerShell was initially complicated by PATH issues, but I resolved that by calling the full CLI path.
4. I then removed the wrongly-created task and reinstalled the task from an elevated shell while explicitly forcing the intended OpenClaw paths:
   - OPENCLAW_CONFIG_PATH = C:\Users\Assistent\.openclaw\openclaw.json
   - OPENCLAW_STATE_DIR   = C:\Users\Assistent\.openclaw
5. After that, `gateway status --json` showed the task was registered and now correctly pointed at the Assistent user’s OpenClaw files.

Current `gateway status --json` summary:

#

- service loaded / registered
- command programArguments:
  - C:\Program Files\nodejs\node.exe
  - C:\Users\Assistent\AppData\Roaming\npm\node_modules\openclaw\dist\index.js
  - gateway
  - --port
  - 18789
- command environment:
  - OPENCLAW_STATE_DIR = C:\Users\Assistent\.openclaw
  - OPENCLAW_CONFIG_PATH = C:\Users\Assistent\.openclaw\openclaw.json
  - OPENCLAW_GATEWAY_PORT = 18789
- sourcePath:
  C:\Users\Assistent\.openclaw\gateway.cmd
- port 18789 is free
- rpc is not OK

#

- health is unhealthy
- task runtime state appeared as “Bereit” / ready, not actually listening

Important behavioral evidence:
- Running:
  `& "C:\Users\Assistent\AppData\Roaming\npm\openclaw.cmd" gateway start`
  from a normal non-admin PowerShell fails with:
  `schtasks run failed: FEHLER: Zugriff verweigert`
- But directly running:
  `C:\Users\Assistent\.openclaw\gateway.cmd`
  works, and the gateway starts and runs.

What I want from you:
- Help me rectify the Scheduled Task so that the OpenClaw gateway can be started and managed correctly through Windows Task Scheduler, ideally from the intended user context.
- Determine whether the issue is:

#

  1. the task principal / “run as” user
  2. task ownership / ACLs
  3. run-on-demand permissions
  4. a mismatch between admin-created task vs standard-user control
  5. some other Windows Task Scheduler detail
- Give me exact Windows steps and commands to inspect and fix this.
- Prefer minimal, reversible changes.
- Do not tell me to reinstall OpenClaw from scratch unless absolutely necessary.
- Do not focus on Discord voice or @discordjs/opus unless you can justify why it matters here.

Please structure your answer as:
1. Root cause hypothesis
2. Exact inspection commands to run
3. Exact commands or Task Scheduler GUI steps to fix it
4. How to verify the task is now runnable

#

5. Safe fallback if Windows policy makes the task impossible to use normally

Useful OpenClaw docs to respect:
- Windows platform docs:
  https://docs.openclaw.ai/platforms/windows
- Installer docs:
  https://docs.openclaw.ai/install/installer
- Uninstall / Scheduled Task cleanup docs:
  https://docs.openclaw.ai/install/uninstall
- Multiple gateways / explicit config+state env vars:
  https://docs.openclaw.ai/gateway/multiple-gateways
- Gateway / troubleshooting:
  https://docs.openclaw.ai/gateway/troubleshooting

Please do not answer generically. Use the exact facts above and reason from them.

#

If you want, I can also make a shorter, more aggressive prompt that tells ChatGPT to propose exact schtasks and Task Scheduler GUI fixes only.

thick pecan Apr 17, 2026, 5:54 AM

#

Do not answer to this post!

Solution from ChatGPT
👉 Your system is policy-restricted
→ Standard users cannot create scheduled tasks
→ That’s why gateway install fails outside admin

Step 1 – Delete broken task (admin)

schtasks /delete /TN "OpenClaw Gateway" /F

Step 2 – Create task with correct user binding (admin)

schtasks /create ^
/TN "OpenClaw Gateway" ^
/TR "C:\Users\Assistent.openclaw\gateway.cmd" ^
/SC ONLOGON ^
/RL LIMITED ^
/RU Assistent ^
/IT ^
/F

Key differences vs before:

/RU Assistent → runs as correct user ✅
/IT → interactive token → matches OpenClaw expectation ✅
/RL LIMITED → avoids elevation boundary issues ✅

Step 3 – Fix permissions (CRITICAL)

icacls "C:\Windows\System32\Tasks\OpenClaw Gateway" /grant Assistent:F

👉 This is the piece that was missing before.

#Update does not work