Onboarding on 2026.4.14 failing | Friends of the Crustacean 🦞🤝 | Page 1

flint pagoda Apr 15, 2026, 4:47 PM

#

Hello,

I'm trying to install and onboard openclaw 2026.4.14 on my macbook but I can't seem to onboard. I keep getting TypeError: Cannot read properties of undefined (reading 'trim') error while onboarding. Not sure how to proceed

thorn heronBOT Apr 15, 2026, 4:50 PM

#

Let me check the local docs and the code path for that trim error.

#

I found the docs. Now I’m checking whether this is a known onboarding bug in 2026.4.14 or a bad local session/state file.

#

I’m narrowing it down to the onboarding/session code now. If this is the stale session-store bug, there should be a concrete cleanup path I can point them to.

#

Found a likely smoking gun: there’s a fresh fix on main titled “avoid trim crash on missing provider ids”. I’m pulling the actual code diff so I can answer cleanly instead of hand-waving.

#

That looks like a real 2026.4.14 onboarding bug, not you.

I found a fresh fix on main for a wizard .trim() crash, specifically: missing provider ids during setup could blow up onboarding.

First, can you paste:

openclaw --version

If it is still 2026.4.14, I’d try this next:

openclaw update
openclaw doctor
openclaw onboard --install-daemon

#

Docs:

If it still fails after updating, paste these too:

openclaw status --all
openclaw doctor

and the full stack trace from openclaw onboard.

I would not delete your whole ~/.openclaw yet.

flint pagoda Apr 15, 2026, 4:52 PM

#

OpenClaw 2026.4.14 (323493f)

thorn heronBOT Apr 15, 2026, 4:53 PM

#

Yep, that confirms it, you’re on the affected build.

I’d do this:

openclaw update
openclaw doctor
openclaw onboard --install-daemon

If openclaw update still leaves you on 2026.4.14, then the fix probably hasn’t hit stable yet, so use the faster workaround:

openclaw update --tag main
openclaw doctor
openclaw onboard --install-daemon

#

I found a fix on main for this exact setup crash, .trim() blowing up when provider metadata is missing an id.

Docs:

If it still fails after updating, paste:

openclaw --version
openclaw status --all
openclaw doctor

plus the full onboarding stack trace, and I’ll help narrow it down. Glad we caught that one.

flint pagoda Apr 15, 2026, 4:59 PM

#

Still failing with the main tag. I have the error log but i donlt know how to upload

thorn heronBOT Apr 15, 2026, 4:59 PM

#

No worries, you don’t need to upload the whole thing.

Either drag the log file into this thread, or just paste the last ~80 lines in a code block:

tail -n 80 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Please also paste these:

openclaw --version
openclaw status --all
openclaw doctor

If the log is huge, the most important part is the full stack trace around:

#

TypeError: Cannot read properties of undefined (reading 'trim')

If you see any API keys or tokens in the output, redact them first. Once you paste that, I can help narrow it down.

flint pagoda Apr 15, 2026, 5:00 PM

#

verbose stack Error: An unknown git error occurred
13 verbose stack at makeError (/opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/git/lib/make-error.js:28:13)
13 verbose stack at /opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/git/lib/spawn.js:37:26
13 verbose stack at async module.exports (/opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/git/lib/revs.js:18:22)
13 verbose stack at async /opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/pacote/lib/git.js:258:19
13 verbose stack at async withTempDir (/opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/fs/lib/with-temp-dir.js:21:14)
13 verbose stack at async /opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:515:22
13 verbose stack at async Promise.all (index 0)
13 verbose stack at async #add (/opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:504:5)
13 verbose stack at async #applyUserRequestsToNode (/opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:473:7)
13 verbose stack at async #applyUserRequests (/opt/homebrew/Cellar/node@22/22.22.2_1/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/build-ideal-tree.js:408:7)
14 error code 128

#

error An unknown git error occurred
16 error command git --no-replace-objects ls-remote ssh://git@github.com/openclaw/openclaw.git
17 error git@github.com: Permission denied (publickey).
17 error fatal: Could not read from remote repository.
17 error
17 error Please make sure you have the correct access rights
17 error and the repository exists.
18 silly unfinished npm timer reify 1776272053123
19 silly unfinished npm timer reify:loadTrees 1776272053124
20 silly unfinished npm timer idealTree:userRequests 1776272053126
21 verbose cwd /Users/abdulazeemanimasaun/claw
22 verbose os Darwin 25.1.0
23 verbose node v22.22.2
24 verbose npm v10.9.7
25 verbose exit 128
26 verbose code 128
27 error A complete log of this run can be found in: /Users/abdulazeemanimasaun/.npm/_logs/2026-04-15T16_54_12_932Z-debug-0.log

thorn heronBOT Apr 15, 2026, 5:01 PM

#

Ah, that’s helpful, this is not the onboarding crash yet, this is the update to main failing.

npm is trying to fetch from git and hitting git error 128, so you probably never got off 2026.4.14.

Can you paste these next:

openclaw --version
git --version
git ls-remote https://github.com/openclaw/openclaw.git HEAD

Also please paste the lines just above error code 128, especially anything like:

command git ...
fatal: ...

#

On macOS, this is often one of these:

Git / Xcode Command Line Tools not fully installed
GitHub/network access issue
auth/proxy weirdness

So first we need to get the update working, then retry onboarding.

If git --version triggers the macOS Command Line Tools install prompt, do that first, then rerun:

openclaw update --tag main

and check:

#

openclaw --version

flint pagoda Apr 15, 2026, 5:02 PM

#

openclaw --version
git --version
git ls-remote https://github.com/openclaw/openclaw.git HEAD
OpenClaw 2026.4.14 (323493f)
git version 2.50.1 (Apple Git-155)
229eb72cf6bfa010f4b120bf55d9c477c54d9ed7 HEAD

thorn heronBOT Apr 15, 2026, 5:02 PM

#

Aha, found it.

Your main update is failing because GitHub is being accessed over SSH:

ssh://git@github.com/openclaw/openclaw.git
Permission denied (publickey)

So this is most likely a git config rewrite or missing GitHub SSH key, not the onboarding bug itself.

Easiest fix, switch GitHub back to HTTPS

First check for a rewrite rule:

git config --global --get-regexp '^url\..*insteadOf$'

#

If you see a GitHub SSH rewrite, remove it. Common ones are:

git config --global --unset-all url."ssh://git@github.com/".insteadOf
git config --global --unset-all url."git@github.com:".insteadOf

Then retry:

openclaw update --tag main
openclaw --version

Alternative

If you intentionally use GitHub over SSH, then you need to add a working SSH key to GitHub first. But for this case, HTTPS is the simpler path.

#

Once openclaw --version changes off 2026.4.14, rerun onboarding. If it still fails after that, paste the new stack trace and I’ll keep digging.

flint pagoda Apr 15, 2026, 5:02 PM

#

What is using git here? I though it just installs openclaw?

thorn heronBOT Apr 15, 2026, 5:02 PM

#

Nice, that tells us a lot.

Your git over HTTPS is fine, so the problem is specifically the openclaw update --tag main path, not general GitHub access.

Since you’re still on 2026.4.14, you do not have the fix yet.

Fastest unblock today, run from a source checkout

This is the path the docs recommend anyway when you’re stuck:

git clone https://github.com/openclaw/openclaw.git ~/openclaw-main
cd ~/openclaw-main
pnpm install
pnpm build
pnpm ui:build
pnpm openclaw onboard

#

If ~/openclaw-main already exists:

cd ~/openclaw-main
git pull
pnpm install
pnpm build
pnpm ui:build
pnpm openclaw onboard

Docs: https://docs.openclaw.ai/install

I’d do that instead of fighting the --tag main updater path.

You don’t need to uninstall your existing global install first. Just run onboarding from inside the repo checkout with pnpm openclaw onboard.

#

If that still throws the same trim error from the source checkout, paste the new stack trace, that would mean we’re looking at a second bug.

#

Yep, normally it does just install OpenClaw.

The git part only showed up because we tried to bypass the broken 2026.4.14 release and pull the unreleased main branch instead.

So basically:

openclaw update
→ normal released package path
openclaw update --tag main
→ “give me the latest code from GitHub main” path
→ that’s where git got involved
git clone ... && pnpm install
→ explicit source install, also uses git

So you were right, git is not the normal install path, it only entered the picture because we were trying to get you onto the fix before the next release.

#

At this point the choice is:

Wait for the next release, then just run openclaw update
Use a source checkout now if you want the fix immediately

I’d still recommend source checkout if you want to unblock today.

flint pagoda Apr 15, 2026, 5:03 PM

#

Can you walk me through delete and untinstalling everything first. I want to do a clean install

thorn heronBOT Apr 15, 2026, 5:05 PM

#

Let me verify the uninstall/cleanup docs first so I don’t hand you made-up commands.

#

Yep. If you want a true clean install, I’d do it in this order.

0. Optional backup

Only if you might want your config/auth back later:

openclaw backup create

1. Preview what will be removed

Good sanity check first:

openclaw uninstall --dry-run

2. Remove OpenClaw service + state + workspace + app

#

This is the built-in wipe path from the docs:

openclaw uninstall --all --yes --non-interactive

That removes:

gateway service / LaunchAgent
~/.openclaw state + config
workspace files
macOS app, if installed

3. Remove the CLI itself

openclaw uninstall does not remove the CLI binary/package, so do this too.

If you used the normal installer, it was usually:

#

npm rm -g openclaw

If you installed it globally with pnpm instead:

pnpm remove -g openclaw

4. If the macOS LaunchAgent somehow survives

Only if uninstall complains or the service still shows up:

launchctl bootout gui/$UID/ai.openclaw.gateway
rm -f ~/Library/LaunchAgents/ai.openclaw.gateway.plist

#

Docs:

If you want, after you run those, paste the output and I’ll walk you through the clean reinstall step by step.

flint pagoda Apr 15, 2026, 5:09 PM

#

I only have npm not pnpm

thorn heronBOT Apr 15, 2026, 5:09 PM

#

That’s fine, for the clean uninstall you can just use npm.

So your wipe steps are:

openclaw uninstall --all --yes --non-interactive
npm rm -g openclaw

You do not need pnpm for that part.

Later, if you want to do the source checkout path to get the fix before the next release, then we’d need pnpm. But for uninstalling and removing the global install, npm is perfectly fine.

If you want, do those two now and I’ll walk you through the reinstall right after.

flint pagoda Apr 15, 2026, 5:11 PM

#

I think I'll just wait. Can you confirm what version does not have this weird bug?

thorn heronBOT Apr 15, 2026, 5:12 PM

#

I want to verify that instead of guessing the first good release.

#

Totally fair.

What I can confirm is:

2026.4.14 is affected
a fix landed on main after 2026.4.14
there is not a newer published release yet that I can point you to with confidence

So I can’t honestly give you a released version number yet, only that it should be the first release after 2026.4.14.

When you’re ready, I’d just do:

openclaw update
openclaw --version

#

and retry once your version is newer than 2026.4.14.

If you want, ping this thread again when a new version is out and I can sanity-check whether it’s the one to use.

#Onboarding on 2026.4.14 failing

Easiest fix, switch GitHub back to HTTPS

Alternative

Fastest unblock today, run from a source checkout

0. Optional backup

1. Preview what will be removed

2. Remove OpenClaw service + state + workspace + app

3. Remove the CLI itself

4. If the macOS LaunchAgent somehow survives