#win
1 messages · Page 1 of 1 (latest)
Looks like that got sent mid-keystroke — what did you mean / what do you need?
Those npm warn deprecated … lines are annoying but usually not the reason the install fails — they’re just dependency warnings.
The real problem in your snippet is the Windows EPERM: operation not permitted, rmdir … during npm warn cleanup: on Windows that almost always means files are locked (running openclaw/node process, VS Code holding handles, antivirus, or permissions).
Things that typically fix it:
- Close anything that might be using it
- stop any running
openclawgateway / node processes - close VS Code/terminal tabs pointing at that folder
-
Re-run in an elevated shell (PowerShell “Run as Administrator”)
-
Delete the stuck folder manually, then retry the install
C:\Users\asus\AppData\Roaming\npm\node_modules\openclaw\...(the path shown in the error)
If you want the least-pain Windows experience long-term, the docs also recommend WSL2 over native Windows.
If you paste:
- the command you ran (
npm i -g openclaw? the installer?), - plus the final error lines after this warning block,
I can be more specific. Docs ref: https://docs.openclaw.ai/start/faq (Windows section).
[OK] Windows detected
[] Existing OpenClaw installation detected
[OK] Node.js v24.14.0 found
[] Installing OpenClaw (openclaw@latest)...
That output looks normal so far — the installer has gotten past the prereqs and is now doing essentially an npm install -g openclaw@latest (and it noticed an existing install).
If it hangs here or you see EPERM again, it’s almost always “Windows has the old global install folder locked”. Quick fix is:
- close anything that could be using OpenClaw/Node (including other terminals / VS Code)
- run PowerShell as Admin
- delete the existing global folder it complains about (often
%AppData%\\npm\\node_modules\\openclaw) - rerun the installer
If it’s just slow: give it a minute, then paste the next ~30 lines (or the final error).
If you need more installer detail on Windows, the FAQ suggests PowerShell tracing (since install.ps1 doesn’t have a nice verbose flag yet):
Set-PSDebug -Trace 1
& ([scriptblock]::Create((iwr -useb https://openclaw.ai/install.ps1)))
Set-PSDebug -Trace 0
node.exe : npm error code ETARGET
所在位置 行:1 字符: 1
- & "C:\Program Files\nodejs/node.exe" "C:\Program Files\nodejs/node_mo ...
-
+ CategoryInfo : NotSpecified: (npm error code ETARGET:String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError
npm error code ETARGET means npm couldn’t find a requested package version. The important part (usually a line like No matching version found for <package>@<version>) is above what you pasted — can you scroll up and paste the few lines right before npm error code ETARGET?
In the meantime, the most common cause on Windows is: you’re not hitting the real npm registry (or you’re using a mirror/private registry that doesn’t have the needed versions/dist-tags).
Quick checks in PowerShell:
npm -v
npm config get registry
npm view openclaw version
npm view openclaw dist-tags --json
If npm config get registry is not https://registry.npmjs.org/, switch it and retry:
npm config set registry https://registry.npmjs.org/
npm cache clean --force
Then rerun the installer / npm i -g openclaw@latest.
Paste the “No matching version found …” line and I’ll tell you exactly which dependency/version is missing.
"beta": "2026.3.8",
"latest": "2026.3.8"
}
调试: 50+ >>>> exit $LASTEXITCODE
Nice — that output shows the openclaw dist-tags resolve fine (latest exists and points to 2026.3.8). So your earlier ETARGET is almost certainly for a dependency, not openclaw itself.
Given your earlier path had node_modules\\@buape\\carbon\\..., a very common gotcha is a scoped registry override (e.g. @buape:registry=...) pointing at a registry that doesn’t have that package/version.
Can you run these and paste the outputs?
npm config get registry
npm config get @buape:registry
npm config get @openclaw:registry
npm config list -l | findstr registry
If @buape:registry (or any scope) is set to something other than https://registry.npmjs.org/, set it back (or delete it), then retry the install:
npm config delete @buape:registry
# (or: npm config set @buape:registry https://registry.npmjs.org/)
Also: if you can paste the full ETARGET text line (No matching version found for ...), I can tell you exactly which package/version is missing.
调试: 2+ >>>> npm -v
调试: 3+ >>>> Set-StrictMode -Version 'Latest'
调试: 5+ >>>> $NODE_EXE="$PSScriptRoot/node.exe"
调试: 6+ if ( >>>> -not (Test-Path $NODE_EXE)) {
调试: 9+ if ( >>>> -not (Test-Path $NODE_EXE)) {
调试: 13+ >>>> $NPM_PREFIX_JS="$PSScriptRoot/node_modules/npm/bin/npm-prefix.js"
调试: 14+ >>>> $NPM_CLI_JS="$PSScriptRoot/node_modules/npm/bin/npm-cli.js"
调试: 15+ >>>> $NPM_PREFIX=(& $NODE_EXE $NPM_PREFIX_JS)
调试: 17+ if ( >>>> $LASTEXITCODE -ne 0) {
调试: 22+ >>>> $NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
调试: 23+ if ( >>>> Test-Path $NPM_PREFIX_NPM_CLI_JS) {
调试: 23+ if ( >>>> Test-Path $NPM_PREFIX_NPM_CLI_JS) {
调试: 27+ if ( >>>> $MyInvocation.ExpectingInput) { # takes pipeline input
调试: 29+ } elseif ( >>>> -not $MyInvocation.Line) { # used "-File" argument
调试: 32+ if ( >>>> ($MyInvocation | Get-Member -Name 'Statement') -and $MyInvocation.Statement) {
调试: 35+ >>>> $NPM_ORIGINAL_COMMAND = (
调试: 40+ >>>> $NODE_EXE = $NODE_EXE.Replace("", "````") 调试: 41+ >>>> $NPM_CLI_JS = $NPM_CLI_JS.Replace("", "````")
调试: 43+ >>>> $NPM_COMMAND_ARRAY = [Management.Automation.Language.Parser]::ParseInput($NPM_ORIGINAL_COMMAND,
[ref] $null, [ref] $null).
调试: 45+ >>>> $NPM_ARGS = ($NPM_COMMAND_ARRAY | Select-Object -Skip 1) -join ' '
调试: 47+ >>>> Invoke-Expression "& "$NODE_EXE" "$NPM_CLI_JS" $NPM_ARGS"
调试: 1+ >>>> & "C:\Program Files\nodejs/node.exe" "C:\Program Files\nodejs/node_modules/npm/bin/npm-cli.js" -v
11.9.0
调试: 50+ >>>> exit $LASTEXITCODE
Yep — that paste is just PowerShell trace output showing npm 11.9.0. Helpful to confirm you’re on a modern npm, but it won’t show why ETARGET happened.
Two things next:
- Turn off the trace (so the output isn’t 200 lines of “调试…”):
Set-PSDebug -Trace 0
- Run these (they’re safe to paste; they shouldn’t include tokens):
npm config get registry
npm config get @buape:registry
npm config get @openclaw:registry
npm config list -l | findstr registry
Also, please paste the actual npm error line for ETARGET (it usually says No matching version found for ...). That one line tells us exactly which dependency/version can’t be found.
调试: 50+ >>>> exit $LASTEXITCODE
调试: 4+ >>>> npm config list -l | findstr registry
调试: 3+ >>>> Set-StrictMode -Version 'Latest'
调试: 5+ >>>> $NODE_EXE="$PSScriptRoot/node.exe"
调试: 6+ if ( >>>> -not (Test-Path $NODE_EXE)) {
调试: 9+ if ( >>>> -not (Test-Path $NODE_EXE)) {
调试: 13+ >>>> $NPM_PREFIX_JS="$PSScriptRoot/node_modules/npm/bin/npm-prefix.js"
调试: 14+ >>>> $NPM_CLI_JS="$PSScriptRoot/node_modules/npm/bin/npm-cli.js"
调试: 15+ >>>> $NPM_PREFIX=(& $NODE_EXE $NPM_PREFIX_JS)
调试: 17+ if ( >>>> $LASTEXITCODE -ne 0) {
调试: 22+ >>>> $NPM_PREFIX_NPM_CLI_JS="$NPM_PREFIX/node_modules/npm/bin/npm-cli.js"
调试: 23+ if ( >>>> Test-Path $NPM_PREFIX_NPM_CLI_JS) {
调试: 23+ if ( >>>> Test-Path $NPM_PREFIX_NPM_CLI_JS) {
调试: 27+ if ( >>>> $MyInvocation.ExpectingInput) { # takes pipeline input
调试: 29+ } elseif ( >>>> -not $MyInvocation.Line) { # used "-File" argument
调试: 32+ if ( >>>> ($MyInvocation | Get-Member -Name 'Statement') -and $MyInvocation.Statement) {
调试: 35+ >>>> $NPM_ORIGINAL_COMMAND = (
调试: 40+ >>>> $NODE_EXE = $NODE_EXE.Replace("", "````") 调试: 41+ >>>> $NPM_CLI_JS = $NPM_CLI_JS.Replace("", "````")
调试: 43+ >>>> $NPM_COMMAND_ARRAY = [Management.Automation.Language.Parser]::ParseInput($NPM_ORIGINAL_COMMAND,
[ref] $null, [ref] $null).
调试: 45+ >>>> $NPM_ARGS = ($NPM_COMMAND_ARRAY | Select-Object -Skip 1) -join ' '
调试: 47+ >>>> Invoke-Expression "& "$NODE_EXE" "$NPM_CLI_JS" $NPM_ARGS"
调试: 1+ >>>> & "C:\Program Files\nodejs/node.exe" "C:\Program Files\nodejs/node_modules/npm/bin/npm-cli.js" config
list -l
调试: 50+ >>>> exit $LASTEXITCODE
You’re still in PowerShell trace mode (all the 调试: lines). That’s why your paste isn’t showing the actual registry = ... output — it’s getting buried.
Do this first:
- Open a fresh new PowerShell window (simplest way to kill tracing), or run:
Set-PSDebug -Trace 0
- Then run these (no pipes, minimal output) and paste the results:
npm config get registry
npm config get @buape:registry
npm config get @openclaw:registry
If @buape:registry is set to anything other than https://registry.npmjs.org/, that would explain the ETARGET (OpenClaw pulls @buape/carbon).
After that, rerun the install and paste the single line that says No matching version found for ... (that’s the key ETARGET detail).
https://registry.npmjs.org/
; "builtin" config from C:\Program Files\nodejs\node_modules\npm\npmrc
prefix = "C:\Users\asus\AppData\Roaming\npm"
; "user" config from C:\Users\asus.npmrc
git = "C:\Program Files\Git\cmd\git.exe"
; node bin location = C:\Program Files\nodejs\node.exe
; node version = v24.14.0
; npm local prefix = C:\WINDOWS\system32
; npm version = 11.9.0
; cwd = C:\WINDOWS\system32
; HOME = C:\Users\asus
; Run npm config ls -l to show all defaults.
; "builtin" config from C:\Program Files\nodejs\node_modules\npm\npmrc
prefix = "C:\Users\asus\AppData\Roaming\npm"
; "user" config from C:\Users\asus.npmrc
git = "C:\Program Files\Git\cmd\git.exe"
; node bin location = C:\Program Files\nodejs\node.exe
; node version = v24.14.0
; npm local prefix = C:\WINDOWS\system32
; npm version = 11.9.0
; cwd = C:\WINDOWS\system32
; HOME = C:\Users\asus
; Run npm config ls -l to show all defaults.
Cool — your npm is definitely pointed at the real registry (https://registry.npmjs.org/), so the remaining question is: ETARGET for which package/version.
When npm throws ETARGET, it always has a line like:
No matching version found for <package>@<version>.
That line is sometimes easier to grab from the npm debug log. After the failed install, run this and paste the matching lines (please redact anything that looks like _authToken= if it appears):
$log = Get-ChildItem "$env:APPDATA\npm-cache\_logs" | Sort-Object LastWriteTime -Desc | Select-Object -First 1
$log.FullName
Select-String -Path $log.FullName -Pattern "ETARGET|No matching version|notarget" | Select-Object -First 20
Also (quick sanity check for the dependency we saw earlier in your cleanup path):
npm view @buape/carbon version
Once we see the exact No matching version found for ... target, we’ll know whether it’s a scoped package resolution issue or a transient publish/mirror/cache problem.
Get-ChildItem : 找不到路径“C:\Users\asus\AppData\Roaming\npm-cache_logs”,因为该路径不存在。
所在位置 行:1 字符: 8
- $log = Get-ChildItem "$env:APPDATA\npm-cache_logs" | Sort-Object Las ...
-
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~- CategoryInfo : ObjectNotFound: (C:\Users\asus\A...npm-cache_logs:String) [Get-ChildItem], ItemNotFound
Exception - FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetChildItemCommand
- CategoryInfo : ObjectNotFound: (C:\Users\asus\A...npm-cache_logs:String) [Get-ChildItem], ItemNotFound
Select-String : 无法将参数绑定到参数“Path”,因为该参数是空值。
所在位置 行:3 字符: 21
- Select-String -Path $log.FullName -Pattern "ETARGET|No matching versi ...
-
~~~~~~~~~~~~~- CategoryInfo : InvalidData: (:) [Select-String],ParameterBindingValidationException
- FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.SelectStrin
gCommand
Yep — my bad: on Windows the npm cache is usually under LocalAppData, not Roaming.
Let’s ask npm where its cache is, then read the _logs folder from there:
$cache = npm config get cache
$cache
Get-ChildItem "$cache\_logs" | Sort-Object LastWriteTime -Desc | Select-Object -First 1
Then grep the latest log for the ETARGET line:
$log = Get-ChildItem "$cache\_logs" | Sort-Object LastWriteTime -Desc | Select-Object -First 1
Select-String -Path $log.FullName -Pattern "ETARGET|No matching version|notarget" | Select-Object -First 30
(If you see anything like _authToken=..., redact it before pasting.)
Also run this quick check and paste the output:
npm view @buape/carbon version
Once we see the exact “No matching version found for …” target, we can fix it fast.
PS C:\WINDOWS\system32> npm view @buape/carbon version
0.14.0
PS C:\WINDOWS\system32> $cache = npm config get cache
$cache
Get-ChildItem "$cache_logs" | Sort-Object LastWriteTime -Desc | Select-Object -First 1
C:\Users\asus\AppData\Local\npm-cache
目录: C:\Users\asus\AppData\Local\npm-cache\_logs
Mode LastWriteTime Length Name
-a---- 2026/3/11 9:23 894 2026-03-11T01_23_24_700Z-debug-0.log
PS C:\WINDOWS\system32> $log = Get-ChildItem "$cache_logs" | Sort-Object LastWriteTime -Desc | Select-Object -First 1
Select-String -Path $log.FullName -Pattern "ETARGET|No matching version|notarget" | Select-Object -First 30
PS C:\WINDOWS\system32> npm view @buape/carbon version
0.14.0
PS C:\WINDOWS\system32>
Great: @buape/carbon resolves fine (0.14.0), so ETARGET isn’t coming from that package.
The reason your log grep returned nothing is: the newest log you grabbed (01:23) is almost certainly from the npm view … commands you just ran — not from the earlier failed install.
Two options to get the right evidence:
Option A (quick): rerun the install, then grab the newest log
Run:
cd $HOME
npm i -g openclaw@2026.3.8
If it fails, immediately run:
$cache = npm config get cache
$log = Get-ChildItem "$cache\_logs" | Sort-Object LastWriteTime -Desc | Select-Object -First 1
Get-Content $log.FullName
…and paste the content (it’s usually safe; just redact any _authToken if it shows up).
Option B: search across existing logs for the ETARGET line
$cache = npm config get cache
Select-String -Path "$cache\_logs\*-debug-0.log" -Pattern "ETARGET|notarget|No matching version|openclaw" | Select-Object -First 50
Either way, we need the exact No matching version found for ... line to know what npm is actually complaining about.
carbon@0.0.0-beta-20260216184201 OK for: openclaw@2026.3.8 want: 0.0.0-beta-20260216184201
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:276:275 silly placeDep node_modules/openclaw @clack/
prompts@1.1.0 OK for: openclaw@2026.3.8 want: ^1.1.0
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:277:276 silly placeDep node_modules/openclaw @discor
djs/voice@0.19.1 OK for: openclaw@2026.3.8 want: ^0.19.0
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:278:277 silly placeDep node_modules/openclaw @grammy
js/runner@2.0.3 OK for: openclaw@2026.3.8 want: ^2.0.3
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:279:278 silly placeDep node_modules/openclaw grammy@
1.41.1 OK for: @grammyjs/runner@2.0.3 want: ^1.13.1
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:280:279 silly placeDep node_modules/openclaw @grammy
js/transformer-throttler@1.2.1 OK for: openclaw@2026.3.8 want: ^1.2.1
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:281:280 silly placeDep node_modules/openclaw @homebr
idge/ciao@1.3.5 OK for: openclaw@2026.3.8 want: ^1.3.5
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:282:281 silly placeDep node_modules/openclaw @larksu
iteoapi/node-sdk@1.59.0 OK for: openclaw@2026.3.8 want: ^1.59.0
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:283:282 silly placeDep node_modules/openclaw @line/b
ot-sdk@10.6.0 OK for: openclaw@2026.3.8 want: ^10.6.0
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:284:283 silly placeDep node_modules/openclaw @lydell
/node-pty@1.2.0-beta.3 OK for: openclaw@2026.3.8 want: 1.2.0-beta.3
AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log:285:284 silly placeDep node_modules/openclaw @marioz
echner/pi-agent-core@0.57.1 OK for: openclaw@2026.3.8 want: 0.57.1
AppData\Loc
Nice — you found the right log (…01_25_04_762Z-debug-0.log). The chunk you pasted is still the “dependency placement” section; the actual failure will be near the bottom where npm prints ERR!.
Can you run these two commands and paste the output?
$log = "C:\Users\asus\AppData\Local\npm-cache\_logs\2026-03-11T01_25_04_762Z-debug-0.log"
Select-String -Path $log -Pattern "ERR!|ETARGET|notarget|No matching version" -Context 0,5
and:
Get-Content $log -Tail 80
(If anything with _authToken shows up, redact it — but usually npm debug logs don’t include it.)
Once we see the No matching version found for <pkg>@<ver> line, we’ll know exactly what to change/work around.
Files\nodejs\node_modules\npm\node_modules@npmcli\run-script\lib\run-script-pkg.js:79:13)
4536 verbose stack at runScript (C:\Program Files\nodejs\node_modules\npm\node_modules@npmcli\run-script\lib\run-script.js:9:12)
4536 verbose stack at C:\Program Files\nodejs\node_modules\npm\node_modules@npmcli\arborist\lib\arborist\rebuild.js:327:17
4536 verbose stack at run (C:\Program Files\nodejs\node_modules\npm\node_modules\promise-call-limit\dist\commonjs\index.js:67:22)
4536 verbose stack at C:\Program Files\nodejs\node_modules\npm\node_modules\promise-call-limit\dist\commonjs\index.js:84:9
4536 verbose stack at new Promise (<anonymous>)
4536 verbose stack at callLimit (C:\Program Files\nodejs\node_modules\npm\node_modules\promise-call-limit\dist\commonjs\index.js:35:69)
4537 verbose pkgid node-llama-cpp@3.16.2
4538 error code 3221225477
4539 error path C:\Users\asus\AppData\Roaming\npm\node_modules\openclaw\node_modules\node-llama-cpp
4540 error command failed
4541 error command C:\WINDOWS\system32\cmd.exe /d /s /c node ./dist/cli/cli.js postinstall
4542 error [node-llama-cpp] The prebuilt binary for platform "win" "x64" with Vulkan support is not compatible with the current system, falling back to using no GPU
4543 silly unfinished npm timer reify 1773192305213
4544 silly unfinished npm timer reify:build 1773192426329
4545 silly unfinished npm timer build 1773192426330
4546 silly unfinished npm timer build:deps 1773192426330
4547 silly unfinished npm timer build:run:postinstall 1773192427392
4548 silly unfinished npm timer build:run:postinstall:node_modules/openclaw/node_modules/node-llama-cpp 1773192427392
4549 verbose cwd C:\Users\asus
4550 verbose os Windows_NT 10.0.26200
4551 verbose node v24.14.0
4552 verbose npm v11.9.0
4553 verbose exit -1073741819
4554 verbose code -1073741819
4555 error A complete log of this run can be found in: C:\Users\asus\AppData\Local\npm-cache_logs\2026-03-11T01_25_04_762Z-debug-0.log
Found it — this isn’t ETARGET at all. The install is crashing in node-llama-cpp@3.16.2 postinstall with Windows exit code 3221225477 (-1073741819, access violation):
npm error path ...\openclaw\node_modules\node-llama-cpp
npm error command node ./dist/cli/cli.js postinstall
[node-llama-cpp] ... Vulkan ... falling back to using no GPU
Key detail: in openclaw@2026.3.8, node-llama-cpp is a peerDependency, and npm auto-installs peer deps by default — that’s why it’s getting pulled in and killing the install.
Workaround (recommended): install OpenClaw without auto-installing peer deps
From a normal shell (not C:\Windows\system32), run:
cd $HOME
npm uninstall -g openclaw
npm i -g openclaw@latest --legacy-peer-deps
That should skip installing node-llama-cpp automatically, so OpenClaw can install and run (you just won’t have local llama.cpp support on Windows until that upstream crash is fixed).
If you do need local models: the “smooth path” is WSL2 (docs recommend it for Windows generally). There’s also an OpenClaw issue tracking this exact Windows crash: https://github.com/openclaw/openclaw/issues/35181
npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead
npm warn deprecated glob@10.5.0: Old versions of glob are not supported, and contain widely publicized security vulnerabilities, which have been fixed in the current version. Please update. Support for old versions may be purchased (at exorbitant rates) by contacting i@izs.me
added 533 packages in 1m
95 packages are looking for funding
run npm fund for details
Perfect — that means the install succeeded. Those two “deprecated …” warnings are harmless.
Next checks:
- Confirm the CLI is on PATH + see version:
openclaw --version
- Then run onboarding:
openclaw onboard
If openclaw is “not recognized”, add your npm global bin (C:\Users\asus\AppData\Roaming\npm) to PATH and reopen PowerShell (that path matches your prefix).
Note: because you used --legacy-peer-deps, local llama.cpp support (node-llama-cpp) won’t be installed — everything else should work fine. If this fixed it, please mark the solution so Answer Overflow can index it.
WhatsApp Web connection ended before fully opening. status=408 Request Time-out QR refs attempts ended
WhatsApp login failed: Error: status=408 Request Time-out QR refs attempts ended
|
o WhatsApp help -----------------------------------------------+
| |
| Docs: whatsapp |
| |
+---------------------------------------------------------------+
|
o WhatsApp DM access ------------------------------------------------------+
| |
| WhatsApp direct chats are gated by channels.whatsapp.dmPolicy + |
| channels.whatsapp.allowFrom. |
| - pairing (default): unknown senders get a pairing code; owner approves |
| - allowlist: unknown senders are blocked |
| - open: public inbound DMs (requires allowFrom to include "*") |
| - disabled: ignore WhatsApp DMs |
| |
| Current: dmPolicy=pairing, allowFrom=unset |
| Docs: whatsapp |
| |
+---------------------------------------------------------------------------+
|
- WhatsApp phone setup
| > This is my personal phone number
| Separate phone just for OpenClaw
That WhatsApp error is the linking step timing out (status=408 … QR refs attempts ended). Usually it’s one of:
- WhatsApp Web can’t be reached from your network/region (so it never gets stable QR refs), or
- you got a QR but it wasn’t scanned in time / connection dropped mid-link.
What I’d do:
- Sanity check: can you open https://web.whatsapp.com in a normal browser on that machine/network?
- If it doesn’t load, this is a network block issue → try a different network (hotspot) or run the Gateway on a VPS where WhatsApp works.
- Retry linking from the CLI:
openclaw channels login --channel whatsapp
openclaw channels status
Scan the QR from WhatsApp mobile → Linked devices → Link a device.
On the wizard question (“personal number” vs “separate phone”): personal is fine for testing; separate number is cleaner/safer long-term.
o Selected channels ---------------------------------------------------------------+
| |
| WhatsApp — works with your own number; recommend a separate phone + eSIM. Docs: |
| whatsapp |
| |
+-----------------------------------------------------------------------------------+
Updated ~.openclaw\openclaw.json
Workspace OK: ~.openclaw\workspace
Sessions OK: ~.openclaw\agents\main\sessions
|
o Web search ----------------------------------------+
| |
| Web search lets your agent look things up online. |
| Choose a provider and paste your API key. |
| Docs: https://docs.openclaw.ai/tools/web |
| |
+-----------------------------------------------------+
|
o Search provider
| Gemini (Google Search)
|
- Gemini (Google Search) API key
| AIza...
—
Don’t paste API keys into Discord (even partial ones) — assume that AIza… key is now compromised.
What to do now:
-
Revoke/rotate that key immediately in Google AI Studio: https://aistudio.google.com/apikey
(Delete the old key, create a new one. Ideally restrict it to the Gemini API / add usage limits.) -
In the onboarding wizard, paste the new key directly into your terminal prompt (not here). OpenClaw will store it in your local config (or you can use env var).
If you’d rather skip web search for now, you can finish onboarding and configure later via:
openclaw configure --section web
Docs: https://docs.openclaw.ai/tools/web
Also consider deleting/editing the Discord message that contained the key, but rotating it is the important part.
|
o WhatsApp personal phone -----------------------+
| |
| Personal phone mode enabled. |
| - dmPolicy set to allowlist (pairing skipped) |
| - allowFrom includes +15187419795 |
| |
+-------------------------------------------------+
|
o Selected channels ---------------------------------------------------------------+
| |
| WhatsApp — works with your own number; recommend a separate phone + eSIM. Docs: |
| whatsapp |
| |
+-----------------------------------------------------------------------------------+
Updated ~.openclaw\openclaw.json
Workspace OK: ~.openclaw\workspace
Sessions OK: ~.openclaw\agents\main\sessions
|
o Web search ----------------------------------------+
| |
| Web search lets your agent look things up online. |
| Choose a provider and paste your API key. |
| Docs: https://docs.openclaw.ai/tools/web |
| |
+-----------------------------------------------------+
|
o Search provider
| Gemini (Google Search)
|
- Gemini (Google Search) API key
| AIza...
—
Please don’t paste onboarding screens that contain your phone number / API keys into Discord. Delete/edit that message if you can, and assume any AIza… key you typed here needs rotation.
For the wizard step you’re on right now:
- It’s asking for the Gemini API key in your terminal. Paste the key there and press Enter (nothing needs to be posted here).
If you don’t want to set up web search right now, you can skip it and configure later:
- abort and rerun onboarding with:
openclaw onboard --skip-search
- or finish onboarding and later run:
openclaw configure --section web
Docs: https://docs.openclaw.ai/tools/web and wizard reference: https://docs.openclaw.ai/reference/wizard
WhatsApp Web connection ended before fully opening. status=428 Precondition Required Connection Terminated
WhatsApp login failed: Error: status=428 Precondition Required Connection Terminated
status=428 Precondition Required (Connection Terminated) is coming from the WhatsApp Web/Baileys side — usually it means the session is in a bad state (or WhatsApp is refusing the connection) and the fastest fix is a clean relink.
Try this clean reset:
- On your phone: WhatsApp → Linked devices → log out of all linked devices (or at least anything that looks stale).
- On the machine running OpenClaw:
openclaw channels logout --channel whatsapp
openclaw channels login --channel whatsapp
…then scan the new QR.
Also make sure:
- your WhatsApp app is up to date
- you don’t have another Baileys/OpenClaw instance trying to link the same number
- your network can reach
web.whatsapp.comreliably (some networks/regions block it → try a different network/hotspot/VPS)
If it still 428s, paste the last ~50 lines of:
openclaw logs --follow
right after you attempt channels login.
o Configure skills now? (recommended)
| Yes
|
- Install missing skill dependencies
| [ ] Skip for now
| [ ] 🔐 1password
| [ ] 📰 blogwatcher
| [ ] 🫐 blucli
| [ ] 📸 camsnap
| [ ] 🧩 clawhub
| [ ] 🎛️ eightctl
| [ ] ♊️ gemini
| [ ] 🧲 gifgrep
| [ ] 🐙 github
| [ ] 🎮 gog
| [ ] 📍 goplaces
| [ ] 📧 himalaya
| [ ] 📦 mcporter
| [ ] 🍌 nano-banana-pro
| [ ] 📄 nano-pdf
| [ ] 💎 obsidian
| [ ] 🎙️ openai-whisper
| [ ] 💡 openhue
| [ ] 🧿 oracle
| [ ] 🛵 ordercli
| [ ] 🗣️ sag
| [ ] 🌊 songsee
| [•] 🔊 sonoscli (Control Sonos speakers (discover/status/play/volume/group). — Install sonoscli (go))
| [ ] 🧾 summarize
| [ ] 🎞️ video-frames
| [ ] 📱 wacli
| [ ] 𝕏 xurl
—
On that “Install missing skill dependencies” screen: if you’re not 100% sure you need a specific skill right now, pick “Skip for now”.
Reason: a bunch of those skills pull in extra CLIs that are macOS/Linux-centric and can be flaky on native Windows. Skipping won’t break the core setup — you can always install skill deps later once the Gateway is up and you know what you actually want to use.
After you finish the wizard, I’d focus on:
openclaw gateway
openclaw channels login --channel whatsapp
(And if WhatsApp is still throwing 428, do the logout → relink flow we talked about.)
11:05:20 [gateway] agent model: openai-codex/gpt-5.4
11:05:20 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 9684)
11:05:20 [gateway] log file: C:\Users\asus\AppData\Local\Temp\openclaw\openclaw-2026-03-11.log
11:05:20 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
11:05:20 [gateway] device pairing auto-approved device=fb3583e6a356e3f42adbe5b3ad0e379a8fd4909387e5e02a369e4edff04c700e role=operator
11:05:22 [bonjour] gateway name conflict resolved; newName="DESKTOP-VPQ5HHJ (OpenClaw) (2)"
11:05:22 [bonjour] gateway hostname conflict resolved; newHostname="openclaw-(2)"
11:06:19 [gateway] security audit: device access upgrade requested reason=scope-upgrade device=fb3583e6a356e3f42adbe5b3ad0e379a8fd4909387e5e02a369e4edff04c700e ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin client=gateway-client conn=79c2b975-6180-4e33-85bb-2864e1b3ecd2
11:06:19 [gateway] device pairing auto-approved device=fb3583e6a356e3f42adbe5b3ad0e379a8fd4909387e5e02a369e4edff04c700e role=operator
11:06:20 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, image). These entries won't match any tool unless the plugin is enabled.
11:06:34 [agent/embedded] embedded run agent end: runId=de3fb23d-0558-42e5-9c73-8dc3d0fa3ae6 isError=true error={"detail":"The 'gpt-5.4' model is not supported when using Codex with a ChatGPT account."}
11:06:34 [agent/embedded] unsupported thinking level for openai-codex/gpt-5.4; retrying with off
11:06:34 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch, image). These entries won't match any tool unless the plugin is enabled.
11:06:43 [agent/embedded] embedded run agent end: runId=de3fb23d-0558-42e5-9c73-8dc3d0fa3ae6 isError=true error={"detail":"The 'gpt-5.4' model is not supported when using Codex with a ChatGPT account."}
Your Gateway is running fine — the thing that’s breaking replies is the default model:
error: The 'gpt-5.4' model is not supported when using Codex with a ChatGPT account.
Fix = switch the default model to one your auth actually supports.
Do this:
- Inspect what OpenClaw thinks is configured/available:
openclaw models status
openclaw models list
- Set a different default model (pick one from the list that matches your auth):
openclaw models set <model-or-alias>
- Restart the gateway:
openclaw gateway restart
If you paste the output of openclaw models status (redact any secrets), I can tell you exactly what to change.
run error: {"detail":"The 'gpt-5.4' model is not supported when using Codex with a ChatGPT account."}
connected | error
agent main | session main (openclaw-tui) | openai-codex/gpt-5.4 | think low | tokens ?/272k
Yep — that TUI line confirms you’re stuck because the default model is set to openai-codex/gpt-5.4, and your Codex (ChatGPT OAuth) account doesn’t have access to it.
Fix is simply: switch the default model.
From a terminal on the same machine:
openclaw models list
openclaw models set <pick-a-supported-model-from-the-list>
openclaw gateway restart
If you only see openai-codex/gpt-5.4 (nothing else you can use), then you’ll need to switch auth method instead (e.g. configure an OpenAI API key provider) — but first run openclaw models list and paste the relevant section and I’ll tell you what to set.
127.0.0.1 拒绝了我们的连接请求。
“127.0.0.1 refused the connection” just means nothing is listening on that localhost port (the Gateway isn’t running, crashed, or you’re hitting the wrong port).
On Windows (native), the Gateway usually only stays up while the terminal window is open. Check this:
openclaw gateway status
openclaw status
If it’s not running, start it (and keep that terminal open):
openclaw gateway
Then open the dashboard at:
http://127.0.0.1:18789/(default)
If gateway status shows a different port, use that one. Paste the output of openclaw gateway status if you want me to pinpoint what’s off.
🦞 OpenClaw 2026.3.8 (3caab92) — I'm the middleware between your ambition and your attention span.
12:03:02 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\asus.openclaw\canvas)
12:03:02 [heartbeat] started
12:03:02 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
12:03:02 [gateway] agent model: moonshot/kimi-k2.5
12:03:02 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 21076)
12:03:02 [gateway] log file: C:\Users\asus\AppData\Local\Temp\openclaw\openclaw-2026-03-11.log
12:03:02 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
12:03:03 [hooks:loader] Registered hook: boot-md -> gateway:startup
12:03:03 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
12:03:03 [hooks:loader] Registered hook: command-logger -> command
12:03:03 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
12:03:03 [hooks] loaded 4 internal hook handlers
12:03:05 [bonjour] gateway name conflict resolved; newName="DESKTOP-VPQ5HHJ (OpenClaw) (2)"
12:03:05 [bonjour] gateway hostname conflict resolved; newHostname="openclaw-(2)"
That log looks healthy now:
- Gateway is listening on 127.0.0.1:18789
- Canvas + heartbeat started
- Your default model is now moonshot/kimi-k2.5 (so you’re no longer stuck on the Codex
gpt-5.4error)
Next step: open the Control UI:
openclaw dashboard
(or manually go to http://127.0.0.1:18789/).
If the UI asks for auth, get the token locally with:
openclaw config get gateway.auth.token
(and paste it into the Control UI auth field — don’t paste tokens into Discord).
HTTP 401: Invalid Authentication
HTTP 401: Invalid Authentication can mean one of two things in OpenClaw:
A) Dashboard/Gateway auth token is wrong (most common)
If you’re seeing this in the browser / Control UI, make sure you’re using the Gateway token (not a model key):
openclaw config get gateway.auth.token
Then in the Control UI: Control → Overview → Gateway Access and paste it into the Gateway Token field (there’s also a Password field next to it—easy to mix up).
Also double-check you’re opening the right URL: http://127.0.0.1:18789/ (not the browser-control port 18791).
B) Your model API key is invalid
If this happened when the agent tried to reply, it’s your model provider auth (Moonshot/Kimi/etc). In that case, paste the few log lines around the error from:
openclaw logs --follow
Tell me where you saw the 401 (browser vs TUI vs CLI) and what URL/command triggered it, and I’ll point you to the exact fix.
04:09:01 info WhatsApp: not linked
04:09:01 info Agents: main (default)
04:09:01 info Heartbeat interval: 30m (main)
04:09:01 info Session store (main): C:\Users\asus.openclaw\agents\main\sessions\sessions.json (1 entries)
04:09:01 info - agent:main:main (54m ago)
04:09:31 info gateway {"subsystem":"gateway"} device pairing auto-approved device=e3e3f5745e08d1d3a0aed26398067f07fe024320f3bce888f6aa1e10c0f5ac0e role=operator
04:09:31 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=cb5ef53e-e49b-477f-ba9b-1a20aae50e1d remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.8
04:10:11 warn tools {"subsystem":"tools"} tools.profile (coding) allowlist contains unknown entries (apply_patch). These entries won't match any tool unless the plugin is enabled.
04:10:13 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=533b249f-dfd5-4745-8efd-0522a417e940 isError=true error=HTTP 401: Invalid Authentication
04:10:33 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ config.schema 1451ms conn=cb5ef53e…0e1d id=f24d47ac…d4d7
04:10:33 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ config.get 208ms conn=cb5ef53e…0e1d id=a29dd27a…7b90
04:10:33 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ channels.status 1691ms conn=cb5ef53e…0e1d id=fcf5c1f1…9b67
04:18:02 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} [whatsapp:default] health-monitor: restarting (reason: stopped)
04:25:01 warn tools {"subsystem":"tools"} tools.profile (coding) allowlist contains unknown entries (apply_patch). These entries won't match any tool unless the plugin is enabled.
04:25:07 warn agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=c0b48cd8-2218-4005-9b57-8808b1dfd98e isError=true error=HTTP 401: Invalid Authentication
04:28:02 info gateway/health-monitor {"subsystem":"gateway/health-monitor"} [whatsapp:default] health-monitor: restarting (reason: stopped)
The 401 is coming from the model provider, not the dashboard.
Your gateway log says your agent model is:
moonshot/kimi-k2.5
That model requires a Moonshot API key (MOONSHOT_API_KEY). If you accidentally set a Kimi Coding key (KIMI_API_KEY) or a different provider key, you’ll get exactly this HTTP 401: Invalid Authentication.
Fix checklist:
- Verify model/auth state:
openclaw models status
# optional (does real requests): openclaw models status --probe --probe-provider moonshot
- Make sure you have the right key for the right endpoint:
- International:
MOONSHOT_API_KEY+https://api.moonshot.ai/v1 - China: you must use the
.cnendpoint (https://api.moonshot.cn/v1) and the matching key
Fastest way to reconfigure (no copying keys into Discord): rerun onboarding just to update auth:
openclaw onboard --auth-choice moonshot-api-key
# (or moonshot-api-key-cn if you’re using the .cn endpoint)
Then:
openclaw gateway restart
Docs: https://docs.openclaw.ai/providers/moonshot
If you paste openclaw models status (redact secrets), I can tell you which key/endpoint mismatch you’ve got.
127.0.0.1 拒绝了我们的连接请求。
Same diagnosis as before: “127.0.0.1 refused the connection” = the Gateway isn’t listening right now (stopped/crashed, or you closed the terminal that was running it).
Please run:
openclaw gateway status
- If it’s not running → start it and keep that terminal open:
openclaw gateway
- Then open
http://127.0.0.1:18789/(or just runopenclaw dashboard).
If you paste the openclaw gateway status output, I can tell you exactly why it’s not staying up.
Service: Scheduled Task (registered)
File logs: ~\AppData\Local\Temp\openclaw\openclaw-2026-03-11.log
Command: C:\Program Files\nodejs\node.exe C:\Users\asus\AppData\Roaming\npm\node_modules\openclaw\dist\index.js gateway --port 18789
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
RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: C:\Users\asus.openclaw\openclaw.json
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
Thanks — that openclaw gateway status output explains the “127.0.0.1 refused” symptom: your Gateway service is installed (Scheduled Task) but it’s not actually staying up, so the WS probe fails.
Next step is to look at the Gateway log right after it tries to start.
Run:
openclaw gateway restart
openclaw logs --follow
If logs --follow doesn’t show anything useful, tail the file log it printed (and paste the last ~100 lines; redact any secrets):
Get-ChildItem "$env:LOCALAPPDATA\Temp\openclaw\openclaw-*.log" |
Sort-Object LastWriteTime -Desc | Select-Object -First 1 |
ForEach-Object { Get-Content $_.FullName -Tail 120 }
Once we see the startup error (config parse issue, missing env var, crash stack, etc.), we can fix the service so the dashboard stays reachable.
12:52:23 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
12:52:23 [gateway] agent model: moonshot/kimi-k2.5
12:52:23 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 7308)
12:52:23 [gateway] log file: C:\Users\asus\AppData\Local\Temp\openclaw\openclaw-2026-03-11.log
12:52:24 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
12:52:25 [hooks:loader] Registered hook: boot-md -> gateway:startup
12:52:25 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
12:52:25 [hooks:loader] Registered hook: command-logger -> command
12:52:25 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
12:52:25 [hooks] loaded 4 internal hook handlers
12:52:27 [ws] webchat connected conn=c5879bea-6437-4e82-ab6e-96c8f3e3a2c0 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.8
12:54:13 [tools] tools.profile (coding) allowlist contains unknown entries (apply_patch). These entries won't match any tool unless the plugin is enabled.
12:54:15 [agent/embedded] embedded run agent end: runId=e695502b-1436-4c39-b90e-a15537fbf7ac isError=true error=HTTP 401: Invalid Authentication
12:55:27 [gateway] parse/handle error: Error: EPERM: operation not permitted, rename 'C:\Users\asus.openclaw\devices\paired.json.7031d830-5352-4872-8d0d-1d05f84eb66b.tmp' -> 'C:\Users\asus.openclaw\devices\paired.json'
12:55:27 [ws] ✗ parse-error error=Error: EPERM: operation not permitted, rename 'C:\Users\asus.openclaw\devices\paired.json.7031d830-5352-4872-8d0d-1d05f84eb66b.tmp' -> 'C:\Users\asus.openclaw\devices\paired.json': code=EPERM conn=07ec671b…416a
12:55:27 [ws] closed before connect conn=07ec671b-46f3-4b62-9e0f-0dba5970416a remote=127.0.0.1 fwd=n/a origin=n/a host=127.0.0.1:18789 ua=n/a code=1000 reason=n/a
12:57:23 [health-monitor] [whatsapp:default] health-monitor: restarting (reason: stopped)
This log shows two separate problems:
1) Model auth is still failing
embedded run agent ... error=HTTP 401: Invalid Authentication
Since your default model is moonshot/kimi-k2.5, that points to a bad/missing MOONSHOT_API_KEY (or wrong endpoint). Fix that first (as in the Moonshot doc): https://docs.openclaw.ai/providers/moonshot
2) Your Control UI/device pairing state can’t be written on Windows
This is the bigger “why the UI sometimes won’t connect” issue:
EPERM: operation not permitted, rename ...\devices\paired.json.<tmp> -> ...\devices\paired.json
That usually happens on Windows when something has paired.json locked (common culprits: antivirus/Defender scanning, OneDrive/backup sync, or two OpenClaw instances touching the same state).
What to try:
- Make sure only one Gateway is running (either the Scheduled Task or a foreground
openclaw gateway, not both), then restart:
openclaw gateway stop
openclaw gateway start
-
If you have OneDrive “protect/sync” or aggressive AV, add an exclusion for:
C:\Users\asus\.openclaw\ -
Sanity-check the file isn’t read-only:
attrib "$env:USERPROFILE\.openclaw\devices\paired.json"
If it still reproduces after that, it’s likely a Windows atomic-write edge case and I’d file a GitHub issue with that EPERM snippet + your version (2026.3.8): https://github.com/openclaw/openclaw/issues
127.0.0.1 拒绝了我们的连接请求。
“127.0.0.1 refused” still means the same thing: the Gateway isn’t listening at that moment (service stopped/crashed).
Given you’re also hitting that paired.json EPERM, I’d debug by running the Gateway in the foreground (so we can see if it dies on connect):
openclaw gateway stop
openclaw gateway
Keep that terminal open, then open http://127.0.0.1:18789/.
If it immediately exits or drops the listener, paste the last ~30 lines from the terminal/log — that will tell us whether the Scheduled Task is crashing, or if something is killing the process.
13:12:48 [canvas] host mounted at http://127.0.0.1:18789/__openclaw__/canvas/ (root C:\Users\asus.openclaw\canvas)
13:12:48 [heartbeat] started
13:12:48 [health-monitor] started (interval: 300s, startup-grace: 60s, channel-connect-grace: 120s)
13:12:48 [gateway] agent model: moonshot/kimi-k2.5
13:12:48 [gateway] listening on ws://127.0.0.1:18789, ws://[::1]:18789 (PID 22932)
13:12:48 [gateway] log file: C:\Users\asus\AppData\Local\Temp\openclaw\openclaw-2026-03-11.log
13:12:48 [browser/server] Browser control listening on http://127.0.0.1:18791/ (auth=token)
13:12:49 [hooks:loader] Registered hook: boot-md -> gateway:startup
13:12:49 [hooks:loader] Registered hook: bootstrap-extra-files -> agent:bootstrap
13:12:49 [hooks:loader] Registered hook: command-logger -> command
13:12:49 [hooks:loader] Registered hook: session-memory -> command:new, command:reset
13:12:49 [hooks] loaded 4 internal hook handlers
13:13:01 [ws] webchat connected conn=12a0348c-3ad8-4085-95f4-a22630c70821 remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.8
Nice — that’s the healthy baseline:
- Gateway is listening on
127.0.0.1:18789 - Control UI connected (
webchat connected … client=openclaw-control-ui)
Now keep that terminal running and open the dashboard at:
http://127.0.0.1:18789/(or runopenclaw dashboardin another shell)
Next two things to get you to “it can actually reply”:
- Fix the model auth (your model is
moonshot/kimi-k2.5, so you need a valid MOONSHOT_API_KEY / correct endpoint). Easiest:
openclaw onboard --auth-choice moonshot-api-key
# (use moonshot-api-key-cn if you’re on the .cn endpoint)
Then restart the gateway.
- Leave the Scheduled Task gateway stopped for now (you’re already running one foreground instance; two instances can cause weird state/lock issues on Windows).
If you try a chat in the dashboard and still see the 401, paste the openclaw models status output (redact secrets) and we’ll pinpoint exactly what key/endpoint is mismatched.
HTTP 401: Invalid Authentication
That 401 is still your model provider auth failing. Since your default is moonshot/kimi-k2.5, it means OpenClaw is calling Moonshot with a missing/wrong key or wrong endpoint.
First, run this and paste the output (it should not print raw secrets — it uses markers):
openclaw models status --plain
Then fix based on what key you actually have:
- If you have a Moonshot key → run:
openclaw onboard --auth-choice moonshot-api-key
(use moonshot-api-key-cn if your key/region is for api.moonshot.cn)
- If you only have a Kimi Coding key (
KIMI_API_KEY) → you need to switch the default model to thekimi-coding/...provider instead ofmoonshot/...(Moonshot and Kimi Coding keys are not interchangeable; docs: https://docs.openclaw.ai/providers/moonshot).
After changing auth/model, restart the gateway:
openclaw gateway restart
Don’t paste any sk-... / AIza... values into Discord.
How do you want to hatch your bot?
| > Hatch in TUI (recommended)
| Open the Web UI
| Do this later
—
Given you’re still getting HTTP 401: Invalid Authentication on the model, I’d pick “Do this later” for the hatch step.
Then fix the model/auth first:
openclaw models status --plain
Set the right provider key (Moonshot vs Kimi Coding), restart the gateway, and then hatch via TUI/Web UI once the agent can actually reply.
|
| Open the dashboard anytime: openclaw dashboard --no-open |
| If prompted: paste the token into Control UI settings (or use the tokenized dashboard |
| URL). |
| |
+--------------------------------------------------------------------------------------------+
|
o How do you want to hatch your bot?
| Do this later
|
o Later -------------------------------------------+
| |
| When you're ready: openclaw dashboard --no-open |
| |
+---------------------------------------------------+
|
o Workspace backup ----------------------------------------+
| |
| Back up your agent workspace. |
| Docs: https://docs.openclaw.ai/concepts/agent-workspace |
| |
+-----------------------------------------------------------+
|
o Security ------------------------------------------------------+
| |
| Running agents on your computer is risky — harden your setup: |
| https://docs.openclaw.ai/security |
| |
+-----------------------------------------------------------------+
|
o Web search --------------------------------------------------+
| |
| Provider Brave Search is selected but no API key was found. |
| web_search will not work until a key is added.
Cool — onboarding finished cleanly, and you chose “Do this later” (good call while auth is still flaky).
Two follow-ups from that screen:
1) Your agent replies are still blocked until you fix the model auth
Run (safe to paste here; it masks secrets):
openclaw models status --plain
Then either:
- configure Moonshot properly:
openclaw onboard --auth-choice moonshot-api-key
(paste the key in your terminal, not Discord)
- or switch to a provider you do have a valid key for and
openclaw models set ….
After changing anything:
openclaw gateway restart
2) Web search is currently disabled (missing Brave key)
Not required for basic use. When you care, configure it later:
openclaw configure --section web
Once models status looks good and a quick chat works in the dashboard, you can hatch via TUI/Web UI.
HTTP 401: Invalid Authentication