#auth-issue
Sorted by views, then solution_desc, solution, and root_cause length (desc).
2578 issues
On Windows, running OpenClaw onboarding in interactive mode crashes with: Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:' Environment: OS: Windows OpenClaw: 2026.4.5 (3e72c03) Node: v24.14.0 Install location: AppData/Roaming/npm/node_modules/openclaw Config path: [openclaw.json](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html) **What I already verified:** This is not fixed by changing normal Windows file paths inside [openclaw.json](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html) Non-interactive onboarding works on the same machine: openclaw onboard --non-interactive --accept-risk --mode local --flow quickstart --auth-choice skip --skip-channels --skip-skills --skip-search --skip-health --skip-ui So this appears specific to the interactive path (model/provider/plugin flow), not general config write/read Relevant logs: The same error is recorded in [openclaw-2026-04-06.log](vscode-file://vscode-app/c:/Program%20Files/Microsoft%20VS%20Code/e7fb5e96c0/resources/app/out/vs/code/electron-browser/workbench/workbench.html) Repeated entries show: Error [ERR_UNSUPPORTED_ESM_URL_SCHEME] ... Received protocol 'c:' Possible root cause: A dynamic import in the interactive onboarding/provider model flow appears to pass a raw Windows absolute path instead of converting to a file:// URL (for example via pathToFileURL). Impact: Windows users can be blocked from interactive onboarding and must use non-interactive workaround. [openclaw-2026-04-06.log](https://github.com/user-attachments/files/26505757/openclaw-2026-04-06.log) [openclaw-2026-04-04.log](https://github.com/user-attachments/files/26505769/openclaw-2026-04-04.log)
openclaw onboard --mode local --no-install-daemon fails before entering onboarding with loadFacadeModule(...).shouldNormalizeGoogleProviderConfig is not a function, while node dist/index.js onboard --mode local --no-install-daemon enters the wizard successfully under the same installation.
After a gateway restart following the 2026.4.1 update, the local node-host service requests a role-upgrade repair pairing (roleFrom=operator roleTo=node). This creates an unresolvable deadlock: openclaw devices list works (uses local fallback) openclaw devices approve <requestId> returns unknown requestId — no local fallback path openclaw doctor --fix does not detect or resolve the pending request The Control UI dashboard shows no pending pairing request to approve via UI All CLI commands requiring gateway auth fail with 1008: pairing required The result is a fully locked gateway that cannot be recovered through any supported CLI path.
After upgrading to OpenClaw 2026.4.1 (da64a97), the boot-md plugin injects the same workspace file (e.g. memory/YYYY-MM-DD.md mapped as DAILY.md) 3–5× per message instead of once. Each injection appears as a separate truncation warning in the session bootstrap output. Consuming ~2% extra context budget per occurrence
OpenClaw 2026.3.8 (3caab92) Setup Mac node host via SSH tunnel to local gateway Worker: 127.0.0.1:18791 → Gateway: 127.0.0.1:18789 Confirmed - tunnel works (nc -vz 127.0.0.1 18791 succeeds) - worker node service runs - worker has ~/.openclaw/identity/device.json - worker never creates ~/.openclaw/identity/device-auth.json Gateway behavior gateway logs show: device pairing auto-approved device=df72580fdf4e6ddf4a8635f50ecc2c23870a247ab1e0608feef328e4be1be34c role=node Node runtime state: Known: 1 · Paired: 0 · Connected: 1 Research Node ... unpaired · connected Device store: openclaw devices list --json { "pending": [], "paired": [ { "nodeId": "cb91b74b0afad0605fb8725ec991d86cccd24b3e059a73966a902778e19a8156" } ] } So the node reaches the runtime registry but never enters the persistent device pairing store and never writes device-auth.json. Question Why does WS node pairing auto-approve at runtime but never persist to devices pending/paired or create device-auth.json on the worker? 'Known: 1 · Paired: 0 · Connected: 1 Research Node ... unpaired · connected'
When configuring multiple Ollama providers (`ollama` on port 11434 and `ollama2` on port 11435), the Gateway routes ALL requests to the first provider (`ollama` on port 11434), completely ignoring the `baseUrl` configured for `ollama2`.
Starting a new Claude Code session in the Mac app with the **worktree** checkbox enabled fails with `Background full checkout failed: other`. The session aborts before the first turn. Unchecking the worktree box lets the session start normally. The failure is **100% reproducible** across many attempts in the same repo.