#CLI hangs

41 messages · Page 1 of 1 (latest)

iron juniper
#

Same problem — openclaw gateway status hangs too. It's not just cron add, the entire openclaw CLI appears to be blocking on your system.

That's likely the root cause of a lot of the issues. If the OpenClaw CLI itself is hanging, that would explain:

• Cron jobs not adding (CLI hangs)
• Gateway status not showing (CLI hangs)
• Possibly the gateway not responding properly to things

This is probably a Windows-specific issue — either the OpenClaw process is getting stuck, or something in the gateway daemon is blocking new CLI connections.

Does openclaw help work at all, or does that hang too? And what about openclaw doctor --non-interactive — does that complete?

obsidian ospreyBOT
#

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

shadow carbonBOT
turbid thicketBOT
#

First, can you paste:

openclaw --version

That’s the first thing I want to rule out.

Also, these 4 checks will tell us where it’s hanging:

openclaw --help
openclaw gateway status --no-probe --json
openclaw gateway status --json
openclaw doctor --non-interactive
#

What each means:

  • openclaw --help hangs → not a cron issue, not even a gateway probe issue, the CLI itself is wedged
  • gateway status --no-probe works, but plain gateway status hangs → the RPC probe is the stuck part
  • both gateway status variants hang → likely Windows service / Scheduled Task inspection is stuck
  • doctor --non-interactive hangs too → confirms it’s broader than cron

If you’re on native Windows, docs still recommend WSL2 as the more stable path: https://docs.openclaw.ai/platforms/windows

Relevant docs:

Paste the outputs, even partial ones, and I’ll narrow it down.

iron juniper
#

Installed openclaw on Linux and during onboard , I get the error TypeError: Cannot read properties of undefined (reading 'trim')

turbid thicketBOT
#

That one looks like a known onboarding bug.

I found this in the changelog for 2026.4.15-beta.1:

Setup/providers: guard preferred-provider lookup during setup so malformed plugin metadata with a missing provider id no longer crashes the wizard with Cannot read properties of undefined (reading 'trim').

So first, please paste:

openclaw --version

If you’re on 2026.4.14 or older, I’d update first, because this may already be fixed.

If you’re already on a newer build and it still happens, please paste:

iron juniper
#

Fresh install 2026.4.14

turbid thicketBOT
#

Yep, that lines up exactly with the known bug.

2026.4.14 is the version right before this fix landed:

Setup/providers: guard preferred-provider lookup during setup so malformed plugin metadata with a missing provider id no longer crashes the wizard with Cannot read properties of undefined (reading 'trim')

So I would update first, not keep digging on 2026.4.14.

Try:

openclaw update --channel beta
openclaw doctor
openclaw onboard

Docs:

#

If you want, paste the output after the update. If it works, glad we caught it quickly 🦐

And if this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

iron juniper
#

The openclaw command doesn't work in terminal, do I need to be in a specific directory

turbid thicketBOT
#

Nope, openclaw should work from any directory.

If it does not, this is usually a PATH / install issue, not a cwd issue.

On Linux, please check:

which openclaw
npm prefix -g
echo "$PATH"

You want $(npm prefix -g)/bin to be on your PATH.

If it is missing, add it to your shell startup file:

#
export PATH="$(npm prefix -g)/bin:$PATH"

Then put that in ~/.bashrc (or ~/.zshrc), open a new terminal, and run:

hash -r
openclaw --version

If you installed from a source checkout instead of globally, use:

pnpm openclaw --version
iron juniper
#

I ran the update beta command and it's still on 2026.4.14 (323493f)

turbid thicketBOT
#

Ah, that’s helpful.

Two likely possibilities:

  1. --channel beta did not actually move you to the raw beta build
  2. you have multiple openclaw binaries on your PATH and are still hitting the old one

Please run these and paste the output:

type -a openclaw
openclaw update status
openclaw update --tag beta
openclaw --version

Why:

iron juniper
#

No it's not working , just installing the same version every time

turbid thicketBOT
#

Yep, you’re not doing anything wrong.

I checked the npm registry, and both dist-tags currently point to the same build:

  • beta2026.4.14
  • latest2026.4.14

So openclaw update --channel beta is just reinstalling the same version. The fix exists in git, but it hasn’t been published to npm yet.

So your real options are:

  1. Wait for the next npm publish (simplest)
  2. Switch to a source/dev install if you want the fix right now

Docs:

#

If you want, I can give you the exact Linux source/dev install steps next.

iron juniper
#

So you've released a version of software that's impossible to install , that's amazing , well done

turbid thicketBOT
#

Yeah, that’s a fair criticism. I’d be annoyed too.

For your case, the normal install path is effectively busted right now:

  • published latest = 2026.4.14
  • published beta = 2026.4.14
  • the fix for the onboarding crash is in git, but not published to npm yet

So this is not you doing something wrong.

Real options right now:

  1. Wait for the next publish
  2. Use the source/dev install path to get the fix immediately

If you want, I can give you the shortest Linux source install steps in one message, no extra fluff.

iron juniper
#

Ok

turbid thicketBOT
#

Cool. Shortest Linux path to bypass the broken npm publish:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git --no-onboard
openclaw --version
openclaw onboard --install-daemon

Why this path:

  • it installs from a git checkout, not the stuck npm 2026.4.14 dist-tag
  • so you should get code newer than the broken onboard build

If openclaw --version still shows 2026.4.14 (323493f) after that, paste the output, because then you’re almost certainly still hitting an old binary on PATH.

Docs:

#

If this fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

iron juniper
#

Ok now when I run openclaw commands it says no such file or directory

turbid thicketBOT
#

Ugh, okay. That usually means the openclaw launcher exists, but it points at something that no longer exists, often a bad symlink or broken Node path.

Please paste the exact error, and run these:

command -v openclaw
ls -l "$(command -v openclaw)"
head -1 "$(command -v openclaw)"
node --version
npm prefix -g
echo "$PATH"

If command -v openclaw prints nothing, run this instead too:

#
type -a openclaw

Don’t reinstall again just yet. The exact path output will tell us whether this is:

  • a broken symlink
  • a stale shebang to a missing Node binary
  • or just PATH pointing at the wrong install

Paste that and I’ll narrow it down.

iron juniper
#

It says bash: /home/mothership/.npm-global/bin/openclaw: no such file or directory

turbid thicketBOT
#

That’s actually a useful clue.

Bash is trying to run an old deleted path:

/home/mothership/.npm-global/bin/openclaw

First do this:

hash -r
command -v openclaw
type -a openclaw
npm prefix -g

What I suspect happened:

#
  • your old openclaw lived in ~/.npm-global/bin
  • that binary got removed during reinstall/update
  • bash is still caching the dead path

If hash -r works, great.

If it still fails, paste the output of those 4 commands and we’ll fix the PATH/install location cleanly.

iron juniper
#

The third command said openclaw not found , the 4th says /home/mothership/.npm-global

turbid thicketBOT
#

Perfect, that means:

  • your PATH is fine
  • the openclaw binary is just missing from ~/.npm-global/bin

So let’s just restore the CLI cleanly with the official installer:

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --install-method git --no-onboard
hash -r
openclaw --version

If that still leaves openclaw missing, paste the full output from the installer command, because then the installer itself is failing before it creates the binary.

Once openclaw --version works again, run:

#
openclaw onboard --install-daemon
iron juniper
#

I've already ran that command to install the beta

turbid thicketBOT
#

Yep, then the installer itself is failing before it recreates the CLI.

Let’s stop guessing and get the debug trace. Please run this exact command and paste the last 50 to 100 lines:

curl -fsSL --proto '=https' --tlsv1.2 https://openclaw.ai/install.sh | bash -s -- --install-method git --no-onboard --verbose

--verbose turns on the installer debug output, which should show exactly where it dies.

You do not need to run onboard again yet. We just need the installer trace first.

iron juniper
#

The CLI auth seems out of sync after the Windows → Linux migration. The gateway has a token, the device has its own token, and they're not talking to each other properly.

turbid thicketBOT
#

Yep, that sounds like token drift after migration.

There are two different auth layers here:

  • the gateway shared token (gateway.auth.token)
  • the per-device token for the paired client/device

After a Windows → Linux move, they can get out of sync, especially if you moved only part of the state.

I’d check/fix it in this order:

openclaw doctor
openclaw gateway restart
openclaw config get gateway.auth.token
openclaw devices list
#

Then rotate the affected device token:

openclaw devices rotate --device <deviceId> --role operator

If that still does not fix it, remove the stale pairing and approve it again:

openclaw devices remove <deviceId>
openclaw devices list
openclaw devices approve <requestId>

Also important: if you migrated only openclaw.json, that is not enough. You want the whole ~/.openclaw/ state dir, and the same profile/state-dir on Linux.

Docs: