OpenClaw is running how? | Friends of the Crustacean 🦞🤝 | Page 1

little hearth Apr 19, 2026, 10:59 PM

#

systemd apparently is disabled on my WSL instance but OpenClaw autoruns separately from the service. How and how to stop this and only allow it to run on the foreground?

cerulean pecanBOT Apr 19, 2026, 10:59 PM

#

rugged spindleBOT Apr 19, 2026, 10:59 PM

#

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

cerulean pecanBOT Apr 19, 2026, 10:59 PM

#

sinful spireBOT Apr 19, 2026, 11:01 PM

#

Not WSL magic, most likely another OpenClaw process/install.

Per docs, on Linux/WSL2 the managed autorun path is the systemd user service. On native Windows, autorun is a Scheduled Task or Startup fallback. So if systemd is off in WSL and it still “auto-runs”, you’re usually seeing one of these:

a manually/background started openclaw gateway process in WSL
another OpenClaw install/profile
a Windows-side OpenClaw instance on localhost

First, please paste these:

openclaw --version
openclaw gateway status --deep
ps -ef | grep '[o]penclaw gateway'

What to do next:

#

If gateway status --deep shows a managed service, remove it with:
```
openclaw gateway uninstall
```
If ps shows a running background process, stop that process and then only start OpenClaw with:
```
openclaw gateway run
```
(same as openclaw gateway, foreground only)
If no WSL process exists but RPC is still reachable, you’re probably hitting a Windows install. In that case, run openclaw gateway uninstall or openclaw uninstall on the Windows side.

If your goal is foreground only, the rule is simple: do not use --install-daemon / gateway install, and start it with openclaw gateway run only.

Docs:

FAQ: https://docs.openclaw.ai/help/faq
Gateway CLI: https://docs.openclaw.ai/cli/gateway
Uninstall: https://docs.openclaw.ai/install/uninstall

#

Paste the gateway status --deep output, that should tell us exactly which one is launching.

little hearth Apr 19, 2026, 11:03 PM

#

wh1te@DESKTOP-IVEK52G:~$ openclaw --version
OpenClaw 2026.4.14 (323493f)
wh1te@DESKTOP-IVEK52G:~$ openclaw gateway status --deep

🦞 OpenClaw 2026.4.14 (323493f) — Making 'I'll automate that later' happen now.

│
◇
Service: systemd (disabled)
File logs: /tmp/openclaw/openclaw-2026-04-19.log
Command: /usr/bin/node /home/wh1te/.volta/tools/image/packages/openclaw/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: unknown (systemctl not available; systemd user services are required on Linux.)
RPC probe: ok

systemd user services unavailable.
WSL2 needs systemd enabled: edit /etc/wsl.conf with [boot]\nsystemd=true
Then run: wsl --shutdown (from PowerShell) and reopen your distro.
Verify: systemctl --user status

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
wh1te@DESKTOP-IVEK52G:~$ ps -ef | grep '[o]penclaw gateway'
wh1te@DESKTOP-IVEK52G:~$

However, all of my config lives on WSL and the bot is still answering.

sinful spireBOT Apr 19, 2026, 11:04 PM

#

Yep, I think the confusing bit is your ps grep.

openclaw gateway usually runs as:

node .../openclaw/dist/index.js gateway --port 18789

So this won’t match:

grep '[o]penclaw gateway'

Your gateway status --deep output says something is definitely listening on 127.0.0.1:18789, and since your config is in WSL, it’s very likely a detached WSL node process, not systemd.

Try this instead:

#

ps -ef | grep 'dist/index.js gateway'
ss -ltnp | grep 18789

If that shows a PID, stop it with:

kill <pid>

Then, for foreground only, start it manually with:

openclaw gateway run

#

A couple more important bits:

~/.config/systemd/user/openclaw-gateway.service is probably just a stale unit file from an earlier install.
Since systemd is unavailable, that file is not what’s launching the bot right now.
If you want to verify it’s not true “autorun”, do a full Windows-side:
```
wsl --shutdown
```
then reopen WSL. If OpenClaw stays dead until you manually start it, it was just a lingering background process.

If it comes back after wsl --shutdown, then something in startup is launching it. At that point check:

grep -R "openclaw.*gateway" ~/.bashrc ~/.profile ~/.zshrc /etc/wsl.conf 2>/dev/null

If you paste the output of the ps ...dist/index.js gateway or ss -ltnp | grep 18789 command, I can tell you the exact next step.

little hearth Apr 19, 2026, 11:05 PM

#

Actually, there is indeed a gateway instance running if I leave it as 'openclaw-gateway'

sinful spireBOT Apr 19, 2026, 11:05 PM

#

Yep, that’s it. openclaw-gateway is the live background gateway process.

So for foreground only:

Stop the background one:

ps -ef | grep '[o]penclaw-gateway'
kill <pid>

or:

pkill -f openclaw-gateway

Confirm port 18789 is gone:

#

   ss -ltnp | grep 18789

Start it only when you want it:
```
openclaw gateway run
```

A stale ~/.config/systemd/user/openclaw-gateway.service can still exist, but with systemd disabled it is not the thing launching it.

If it comes back again after wsl --shutdown, then something in startup is relaunching it, and I’d check:

grep -R "openclaw-gateway\|openclaw.*gateway" ~/.bashrc ~/.profile ~/.zshrc /etc/wsl.conf 2>/dev/null

#

So the short version is, you found the culprit, kill that process, then use openclaw gateway run only.

little hearth Apr 19, 2026, 11:07 PM

#

wh1te@DESKTOP-IVEK52G:~$ grep -R "openclaw-gateway\|openclaw.*gateway" ~/.bashrc ~/.profile ~/.zshrc /etc/wsl.conf 2>/dev/null
wh1te@DESKTOP-IVEK52G:~$

It always comes back again after wsl --shutdown. ALWAYS

#

update, I killed the process and it automatically started again. I'm starting to freak out.

sinful spireBOT Apr 19, 2026, 11:07 PM

#

Ah, that changes the picture.

If it always comes back after wsl --shutdown, then I don’t think WSL itself is resurrecting it. Something on the Windows side is starting WSL or the gateway for you.

That fits the docs pretty well:

native Windows OpenClaw can auto-start via Scheduled Task
if that fails, it falls back to a Startup-folder launcher
some setups also create a custom WSL Boot task

From PowerShell, please run these and paste the output:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -match 'openclaw|gateway|wsl.exe' } |
  Select-Object ProcessId, Name, CommandLine

#

schtasks /Query /FO LIST /V | findstr /I "OpenClaw Gateway WSL Boot openclaw gateway.cmd wsl.exe"

dir "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"

Why I’m leaning this way:

systemd is unavailable in WSL
your shell startup files are clean
wsl --shutdown should kill a plain lingering WSL process
if it still returns, something external is relaunching it

If you find a Windows task named OpenClaw Gateway, that’s probably the culprit. Docs-backed removal is here: https://docs.openclaw.ai/install/uninstall
Windows/WSL behavior docs: https://docs.openclaw.ai/platforms/windows

#

Paste those three Windows-side outputs, that should expose the exact launcher.

#

Take a breath, this is scary but it really does sound like a supervisor restart loop, not some spooky takeover.

Given what you’ve shown, the fastest place to stop it is Windows, not WSL.

Right now, do this in PowerShell:

schtasks /Query /FO LIST /V | findstr /I "OpenClaw Gateway WSL Boot openclaw gateway.cmd wsl.exe"

If you see OpenClaw Gateway (or OpenClaw Gateway (...)), stop and remove it:

schtasks /End /TN "OpenClaw Gateway"
schtasks /Delete /F /TN "OpenClaw Gateway"

#

Also check the Startup folder for an OpenClaw launcher:

explorer "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"

If there’s an OpenClaw / gateway shortcut there, remove it.

Why I’m pretty confident this is just auto-restart behavior:

systemd is unavailable in WSL
killing the process makes it come back
wsl --shutdown does not keep it down
OpenClaw docs explicitly support Windows Scheduled Task and Startup-folder fallback auto-start

So, no, this does not look like malware from what you’ve shown.

#

If you want, paste the output of the schtasks /Query ... line and I’ll help you identify the exact entry to disable.

little hearth Apr 19, 2026, 11:10 PM

#

PS C:\Users\wh1te> Get-CimInstance Win32_Process |
>>   Where-Object { $_.CommandLine -match 'openclaw|gateway|wsl.exe' } |
>>   Select-Object ProcessId, Name, CommandLine

ProcessId Name    CommandLine
--------- ----    -----------
    16540 wsl.exe "C:\WINDOWS\system32\wsl.exe"
    27480 wsl.exe "C:\WINDOWS\system32\wsl.exe"
    20432 wsl.exe C:\WINDOWS\System32\wsl.exe -d Ubuntu-24.04 sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh"...
    15504 wsl.exe C:\WINDOWS\System32\wsl.exe -d Ubuntu-24.04 sh -c '"$VSCODE_WSL_EXT_LOCATION/scripts/wslServer.sh"...
    22660 wsl.exe C:\WINDOWS\System32\wsl.exe -d Ubuntu-24.04 -e /home/wh1te/.vscode-server/bin/560a9dba96f961efea7b...
     5084 wsl.exe C:\WINDOWS\System32\wsl.exe -d Ubuntu-24.04 -e /home/wh1te/.vscode-server/bin/560a9dba96f961efea7b...
     7420 wsl.exe C:\WINDOWS\System32\wsl.exe -d Ubuntu-24.04 -e /home/wh1te/.vscode-server/bin/560a9dba96f961efea7b...
    16812 wsl.exe C:\WINDOWS\System32\wsl.exe -d Ubuntu-24.04 -e /home/wh1te/.vscode-server/bin/560a9dba96f961efea7b...
    28656 wsl.exe C:\WINDOWS\system32\wsl.exe -d ubuntu-24.04 -e /bin/sh -c "cd '/home/wh1te/.openclaw' && /bin/sh"
    30148 wsl.exe C:\WINDOWS\system32\wsl.exe -d ubuntu-24.04 -e /bin/sh -c "cd '/home/wh1te/.openclaw' && /bin/sh"


PS C:\Users\wh1te>

sinful spireBOT Apr 19, 2026, 11:10 PM

#

This is actually good news. I’m not seeing a rogue OpenClaw task here.

What I am seeing is:

a bunch of VS Code WSL processes
and two wsl.exe shells explicitly opening in /home/wh1te/.openclaw

So my best guess now is: VS Code or another terminal app is reopening a WSL shell in ~/.openclaw, and that shell/session is what keeps bringing the gateway back.

First thing I’d try

Completely close:

all VS Code windows connected to WSL
all Windows Terminal / PowerShell tabs using Ubuntu-24.04

Then run in PowerShell:

#

wsl --shutdown

Then reopen plain WSL only, not VS Code, and check if the gateway is still back.

One more very useful check

Run this in PowerShell, it’ll tell us who launched those ~/.openclaw WSL shells:

Get-CimInstance Win32_Process |
  Where-Object { $_.CommandLine -like "*cd '/home/wh1te/.openclaw'*" } |
  Select-Object ProcessId, ParentProcessId, Name, CommandLine

If those parents turn out to be Code.exe, WindowsTerminal.exe, or similar, that’s our culprit.

#

So, short version: I’m now much less worried about “mystery autorun” and much more suspicious of VS Code / terminal session restore. That’s annoying, but way less spooky.

little hearth Apr 19, 2026, 11:12 PM

#

PS C:\Users\wh1te> Get-CimInstance Win32_Process |
>>   Where-Object { $_.CommandLine -like "*cd '/home/wh1te/.openclaw'*" } |
>>   Select-Object ProcessId, ParentProcessId, Name, CommandLine

ProcessId ParentProcessId Name    CommandLine
--------- --------------- ----    -----------
    28656           14804 wsl.exe C:\WINDOWS\system32\wsl.exe -d ubuntu-24.04 -e /bin/sh -c "cd '/home/wh1te/.opencl...
    30148           28656 wsl.exe C:\WINDOWS\system32\wsl.exe -d ubuntu-24.04 -e /bin/sh -c "cd '/home/wh1te/.opencl...


PS C:\Users\wh1te>

sinful spireBOT Apr 19, 2026, 11:12 PM

#

Perfect, we’ve got the chain now.

30148 was launched by 28656
28656 was launched by 14804
so 14804 is the real Windows-side launcher

That means we’re down to one parent process, which is great. Please run this next:

Get-CimInstance Win32_Process -Filter "ProcessId = 14804" |
  Select-Object ProcessId, ParentProcessId, Name, CommandLine

If you want the short version, we’re trying to learn whether 14804 is:

Code.exe / VS Code
WindowsTerminal.exe

#

explorer.exe or a startup shortcut
something else

That will tell us whether the fix is:

close/disable VS Code terminal/session restore
close a Windows Terminal tab/profile
or remove a Startup/task launcher

So, good news, this is looking more and more like a normal parent-process chain, not anything malicious. We’re basically one PID away from the answer.

little hearth Apr 19, 2026, 11:15 PM

#

wait I have something interesting for you. I just ran ps -ef and I saw this

wh1te        198       1  0 20:14 ?        00:00:00 /usr/lib/systemd/systemd --user
wh1te        202     198  0 20:14 ?        00:00:00 (sd-pam)
wh1te        246     198 93 20:14 ?        00:00:16 openclaw-gateway

sinful spireBOT Apr 19, 2026, 11:16 PM

#

Aha, that’s the smoking gun.

openclaw-gateway is a child of:

/usr/lib/systemd/systemd --user

So it is being restarted by a user systemd service. The earlier systemctl --user unavailable message was probably just because your shell didn’t have the right user-bus env, not because the user manager wasn’t running.

Try this in WSL:

export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
systemctl --user status openclaw-gateway.service

#

systemctl --user disable --now openclaw-gateway.service

If you want to fully clean up the installed unit too:

rm -f ~/.config/systemd/user/openclaw-gateway.service
systemctl --user daemon-reload

Then from there, run OpenClaw only in the foreground with:

openclaw gateway run

#

So the short version is, you were right that something was auto-restarting it, and now we know exactly what: your user systemd instance. Not malware, just a sneaky service manager situation.

little hearth Apr 19, 2026, 11:17 PM

#

wh1te@DESKTOP-IVEK52G:~$ export XDG_RUNTIME_DIR=/run/user/$(id -u)
export DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus
systemctl --user status openclaw-gateway.service
Failed to connect to bus: No such file or directory
wh1te@DESKTOP-IVEK52G:~$ systemctl --user status openclaw-gateway.service
Failed to connect to bus: No such file or directory
wh1te@DESKTOP-IVEK52G:~$ rm -f ~/.config/systemd/user/openclaw-gateway.service
systemctl --user daemon-reload
Failed to connect to bus: No such file or directory
wh1te@DESKTOP-IVEK52G:~$

...why is this happening.

sinful spireBOT Apr 19, 2026, 11:17 PM

#

You’re in a weird half-systemd state.

What’s happening is:

systemd --user is running
but the user DBus/socket that systemctl --user needs is not
so the service manager exists, but your shell cannot talk to it

That’s why systemctl --user ... says:

Failed to connect to bus: No such file or directory

Since you already deleted the unit file, the next move is to kill the live manager and the gateway directly, then shut WSL down cleanly:

#

pkill -u "$USER" -f '^openclaw-gateway$'
pkill -u "$USER" -f '/usr/lib/systemd/systemd --user'

Then from PowerShell:

wsl --shutdown

After that, reopen WSL and check:

ps -ef | grep '[o]penclaw-gateway\|[s]ystemd --user'

#

If both are gone, you’ve broken the restart loop, and from then on just use:

openclaw gateway run

So the “why” is basically: a user systemd instance got started without a usable user bus, which is cursed but not malicious. If it still comes back after the pkill + wsl --shutdown, paste the fresh ps -ef output and we’ll keep going.

little hearth Apr 19, 2026, 11:20 PM

#

systemd user is running, but gateway hasn't started since then.

#OpenClaw is running how?

First thing I’d try

One more very useful check