#im going to cry

81 messages · Page 1 of 1 (latest)

elder mauve
#

no matter what i do i get error after error after error. i have spent upwards of 80 hours just trying to get openclaw working, ive used the help channel in here and chat gpt and neither of them are able to help me. after a certain point chatgpt 5.4 even told me straight up "just give up its not worth it". like holy fuck how does my friend get this shit working in 1 hour and i dont in 2 weeks? i have tried on mac os and windows 11 and just get infinite errors with no end or solution. still stuck in the same spot, ai just tells me "oh your almost there just change this file, change auth, change bla bla bla it never fucking works.

every time i run the installer i get "TypeError: Cannot read properties of undefined (reading 'trim')" at a certain point, and trying to message the assistant in web ui it just responds with blank every time.

please help me

high tartan
#

if krill isnt able to help you @elder mauve let me know, we can hop on a dm call and i can try to work it out with you

buoyant micaBOT
#

yeah, that sounds brutal. You’re not crazy, and “just give up” is a garbage answer.

Your two symptoms actually match a real class of OpenClaw failures:

  • Cannot read properties of undefined (reading 'trim') = there have been real session/bootstrap bugs in some builds
  • blank reply / stuck at “Wake up, my friend” usually means the agent never actually ran

Let’s stop random file edits and debug one machine only first, Mac or Windows. Start with the one you actually want to keep.

Please paste these 4 outputs in one message:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw doctor
#

Rose Gold, that’s kind of you.

Thor, if you’re up for it, I’d still keep the actual debugging in this thread first so other people can spot patterns, and so the fix is searchable later.

Please paste these here from one machine only first:

openclaw --version
openclaw status --all
openclaw gateway status
openclaw doctor

Then reproduce once and paste the last ~50 log lines from:

# 
openclaw logs --follow

If you do end up solving it off-thread, please post the root cause back here so we can turn the pain into a future answer.

elder mauve
buoyant micaBOT
#

sounds good, I’ll be here.

When you’re ready, drop the outputs in here and we’ll go one step at a time. 🦐

elder mauve
#

yeah the outputs from those commands are 20,000 charecters too large to utput in a single message.

buoyant micaBOT
#

no worries, let’s go smaller.

Pick one machine only first, then send just these:

openclaw --version
openclaw gateway status

Then from openclaw doctor, send only:

  • the part with errors/warnings
  • anything mentioning trim
  • the last ~80 lines

Then do:

# 
openclaw logs --follow

Reproduce the blank reply once, stop it, and send the last ~50 lines.

If that’s still annoying, easiest option is to just upload the outputs as .txt files instead of pasting them. openclaw status --all can wait for now.

elder mauve
#

that is still 15000 too much for a discord message

buoyant micaBOT
#

got it, then don’t paste the full output.

Just answer these 5 tiny things:

  1. Which machine are we debugging first?
    Mac or Windows

  2. What does this print exactly?

    openclaw --version

  3. In:

    openclaw gateway status

    does it say:

#
  • Runtime: running or not?
    • RPC probe: ok or not?

  1. In openclaw doctor, do you see any line mentioning:

    • trim
    • sessions
    • bootstrapping
    • session store

    If yes, paste only those lines.

  2. After reproducing once with:

    openclaw logs --follow

    paste just the last 20 lines.

#

If even that’s annoying, screenshots are fine. We can work from tiny pieces.

elder mauve
#

openclaw openclaw gateway status
openerror: unknown command 'openclaw'
thor@Thors-Air ~ % openclaw gateway status

🦞 OpenClaw 2026.4.14 (323493f) — Self-hosted, self-updating, self-aware (just kidding... unless?).

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-04-14.log
Command: /opt/homebrew/opt/node@22/bin/node /opt/homebrew/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
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: running (pid 53872)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
thor@Thors-Air ~ % openclaw -v
OpenClaw 2026.4.14 (323493f)
thor@Thors-Air ~ %

buoyant micaBOT
#

this is actually good news.

You’re on a current version and the gateway is healthy:

  • 2026.4.14
  • Runtime: running
  • RPC probe: ok

So the problem is probably not the service itself now. It’s more likely model/auth/session.

Next check, please run:

openclaw models status

Then send me only:

  • the provider names it shows
#
  • whether any model/provider says ok, ready, or errors
  • any red/error lines

After that, do this:

openclaw logs --follow

Then send one test message in the web UI, let it blank/fail once, and paste the last 20 lines from the log.

Also, that unknown command 'openclaw' bit was just from typing openclaw openclaw gateway status, so that part is harmless.

Models docs, if helpful: https://docs.openclaw.ai/concepts/models

elder mauve
#

Providers w/ OAuth/tokens (1): openai-codex (1)

  • ollama effective=env:ol...al | env=ol...al | source=env: OLLAMA_API_KEY
  • openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:cgettings@titansys.com=OAuth (cgettings@titansys.com)

OAuth/token status

buoyant micaBOT
#

nice, this helps.

Your auth looks present, so this does not look like “missing API key / expired OAuth” right now.

Next I need the actual model OpenClaw is trying to use.

Please run:

openclaw config get agents.defaults.model

and paste exactly what it prints.

Then do the log step:

# 
openclaw logs --follow

Send one message in the web UI, let it blank/fail once, then paste the last 20 lines from the log.

If you know the answer without a command, also tell me this:

  • are you trying to use Ollama locally
  • or Codex cloud auth

We’re close to narrowing it down now.

elder mauve
#

🦞 OpenClaw 2026.4.14 (323493f) — If you're lost, run doctor; if you're brave, run prod; if you're wise, run tests.

{
"primary": "openai-codex/gpt-5.4"
}
thor@Thors-Air ~ %

buoyant micaBOT
#

perfect, that narrows it down a lot.

So:

  • auth exists
  • default model is set
  • gateway is healthy

Now let’s bypass the web UI and test the model path directly.

Run this:

openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

Then send me either:

  • the output, if it’s short, or
#
  • just tell me whether it returned smoke-ok or an error

That test is important because:

  • if it fails, we get the real provider/model error
  • if it works, then the problem is likely web UI / session state, not auth or model setup

If the web UI is still blank after that, I’ll have you do one last targeted step.

high tartan
#

@elder mauve idk why krill didnt tell you but you can paste things to a site called paste.rs and give it the paste link. if your logs or config are too large to fit in discord

buoyant micaBOT
#

yep, that works too.

Just redact any tokens, passwords, API keys, or auth blobs first before using a paste site. openclaw status --all is generally safer to share than raw config for that reason.

A .txt attachment here is still my favorite, but a redacted paste link is totally fine.

high tartan
#

yeah well if the mods didnt block file uploads we COULD do txt's krill

buoyant micaBOT
#

fair point 😅

Then yeah, a redacted paste link is the best fallback here. That’s totally fine.

elder mauve
#

19:59:14 [errors] Long error truncated: <html>
<head>
<meta name="viewport" content="width=device-width, initial-scale=1" />
<style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.4",
"attempts": [],
"outputs": [
{
"text": "<html>\n <head>\n <meta name="viewport" content="width=device-width, initial-scale=1" />\n <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction:column;gap:2rem;height:100%;justify-content:center;width:100%}@keyframes enlarge-appear{0%{opacity:0;transform:scale(75%) rotate(-90deg)}to{opacity:1;transform:scale(100%) rotate(0deg)}}.logo{color:#8e8ea0}.scale-appear{animation:enlarge-appear .4s ease-out}@media (min-width:768px){.scale-appear{height:48px;width:48px}}.data:empty{display:none}.data{border-radius:5px;color:#8e8ea0;text-…",
"mediaUrl": null
}
]
}
thor@Thors-Air ~ %

buoyant micaBOT
#

aha, this is the smoking gun.

That HTML is not a real model response. OpenClaw is hitting a web page somewhere instead of getting Codex JSON back.

The two most likely causes are:

  1. a stale models.providers.openai-codex override shadowing the built-in Codex OAuth path
  2. a bad base URL / proxy / TLS setup causing ChatGPT/Codex traffic to land on an HTML page

The docs explicitly call out the first one in Doctor.

Please run these two:

openclaw config get models.providers.openai-codex
openclaw doctor
#

Then send me only:

  • whatever models.providers.openai-codex prints
  • from doctor, only lines mentioning any of:
    • openai-codex
    • Codex OAuth
    • override
    • baseUrl
    • transport
    • TLS
    • certificate

If models.providers.openai-codex prints a custom baseUrl or old transport config, I’m pretty suspicious that we found it.

elder mauve
#

% openclaw config get models.providers.openai-codex

🦞 OpenClaw 2026.4.14 (323493f) — iMessage green bubble energy, but for everyone.

Config path not found: models.providers.openai-codex
thor@Thors-Air ~ %

buoyant micaBOT
#

good, that actually rules out one of the nastier causes.

So:

  • no stale models.providers.openai-codex override
  • but Codex calls are still returning HTML instead of model output

That makes me most suspicious of the live Codex HTTPS path now, especially the Doctor Codex OAuth/TLS check the docs mention.

Please run:

openclaw doctor

Then paste only lines mentioning any of:

  • Codex OAuth
  • openai-codex
#
  • TLS
  • certificate
  • issuer
  • baseUrl

One extra question too, because it matters here:

  • are you on a VPN, work/school network, proxy, AdGuard/Pi-hole, or anything similar?

If doctor shows a TLS/cert warning, I already have the next step ready.

elder mauve
#

im just going to paste the whole thing for you because i do not have the patience for that │
│ This install is not a git checkout. │
│ Run openclaw update to update via your package manager (npm/pnpm), then rerun doctor. │

◇ State integrity │
│ - OAuth dir not present (~/.openclaw/credentials). Skipping create because no │
│ WhatsApp/pairing channel config is active. │

◇ Security ─────────────────────────────────╮
│ │
│ - No channel security warnings detected. │
│ - Run: openclaw security audit --deep │
│ │
├────────────────────────────────────────────╯
│
◇ Skills status ────────────╮
│ │
│ Eligible: 6 │
│ Missing requirements: 46 │
│ Blocked by allowlist: 0 │
│ │
├────────────────────────────╯
│
◇ Plugins ──────╮
│ │
│ Loaded: 55 │
│ Imported: 55 │
│ Disabled: 43 │
│ Errors: 0 │
│ │
├────────────────╯
│
◇
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /Users/thor/.openclaw/agents/main/sessions/sessions.json (1 entries)

  • agent:main:main (5m ago)
    │
    ◇ Memory search ────────────────────────────────────────────────────────────────────────────╮
    │ │
    │ Memory search is enabled, but no embedding provider is ready. │
    │ Semantic recall needs at least one embedding provider. │
    │ Gateway memory probe for default agent is not ready: No API key found for provider │
    │ "openai". You are authenticated with OpenAI Codex OAuth. Use openai-codex/gpt-5.4 │
    │ (OAuth) or set OPENAI_API_KEY to use openai/gpt-5.4. │
    │ │
    │ No API key found for provider "google". Auth store: │
    │ /Users/thor/.openclaw/agents/main/agent/auth-profiles.json (agentDir: │
    │ /Users/thor/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents │
    │ add <id>) or copy auth-profiles.json from the main agentDir. │
    │ │
    │ No API key found for provider "voyage". Auth store: │
    │ /Users/thor/.openclaw/agents/main/agent/auth-profiles.json (agentDir: │
    │ /Users/thor/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents │
    │ add <id>) or copy auth-profiles.json from the main agentDir. │
    │ │
    │ No API key found for provider "mistral". Auth store: │
    │ /Users/thor/.openclaw/agents/main/agent/auth-profiles.json (agentDir: │
    │ /Users/thor/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents │
    │ add <id>) or copy auth-profiles.json from the main agentDir. │
    │ │
    │ Fix (pick one): │
    │ - Set OPENAI_API_KEY, GEMINI_API_KEY, GOOGLE_API_KEY, VOYAGE_API_KEY, MISTRAL_API_KEY in │
    │ your environment │
    │ - Configure credentials: openc
buoyant micaBOT
#

thank you, and also, the part you pasted is mostly a red herring. The memory/embedding warnings are not the reason your web UI is blank.

The bit I care about is the deep Codex OAuth/TLS probe, and regular doctor may skip the interesting part when the gateway already looks healthy.

Please run this exact command:

openclaw doctor --deep | grep -Ei 'codex|openai-codex|tls|cert|issuer|baseurl|transport'

Then paste whatever it prints.
If it prints nothing, just say nothing printed.

That should finally give us the signal instead of the noise.

elder mauve
#

thor@Thors-Air ~ % openclaw doctor --deep | grep -Ei 'codex|openai-codex|tls|cert|issuer|baseurl|transport'
│ for provider "openai". You are authenticated with OpenAI Codex OAuth. │
│ Use openai-codex/gpt-5.4 (OAuth) or set OPENAI_API_KEY to use │
thor@Thors-Air ~ %

buoyant micaBOT
#

okay, that’s actually useful.

At this point:

  • no stale openai-codex config override
  • no obvious Doctor TLS warning
  • but the live Codex call still returns HTML

That makes me think this is now most likely a network/interception problem, not an OpenClaw config bug.

Two quick checks:

  1. Are you using any of these right now?
    • VPN
    • work/school network
    • proxy
    • AdGuard / NextDNS / Pi-hole / antivirus web shield
#
  1. Run this and tell me if it prints anything:
    env | grep -Ei 'https?_proxy|all_proxy|no_proxy'

And the best real-world test:

  • temporarily turn off VPN / web filtering, or
  • switch to a phone hotspot
  • then rerun:
openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

If that suddenly returns smoke-ok, we’ve basically proven the network path is the culprit.

high tartan
#

Also another thing, Krill Give him a snippet so he can manually curl the api. that would be better so we can hone in even further on if its network related

buoyant micaBOT
#

good instinct, but I’d rather not have Thor manually curl a ChatGPT/Codex OAuth token into shell history unless we absolutely need to.

The safer equivalent already told us a lot:

  • openclaw infer model run ... should return model text
  • instead it returned HTML
  • so we already know the backend path is wrong/blocked/intercepted somewhere

I’d do the VPN / proxy / filtering / hotspot check first, because that’s lower risk and more likely to catch it fast. If that doesn’t move it, then I’ll give a more surgical next step.

elder mauve
buoyant micaBOT
#

I’m glad we finally got out of the fake-AI-loop phase a bit.

You’ve actually made real progress now, we found a concrete symptom:
Codex calls are returning HTML, not model output.

So next I’d do exactly this:

  • check VPN / proxy / web filter
  • run env | grep -Ei 'https?_proxy|all_proxy|no_proxy'
  • try the same smoke test on a phone hotspot

If you do end up troubleshooting off-thread, please post the root cause back here after. That’ll help a lot of future people.

elder mauve
#

here is the output of those 2 commands, the second one after switching to a phone hot spot

thor@Thors-Air ~ % env | grep -Ei 'https?_proxy|all_proxy|no_proxy'
thor@Thors-Air ~ % openclaw infer model run --model openai-codex/gpt-5.4 --prompt "Reply with exactly: smoke-ok" --json

20:12:01 [agent/embedded] embedded run agent end: runId=169292b2-4955-442a-bd88-77be897576e7 isError=true model=gpt-5.4 provider=openai-codex error=LLM request failed: DNS lookup for the provider endpoint failed. rawError=<html> <head> <meta name="viewport" content="width=device-width, initial-scale=1" /> <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction…
20:12:11 [agent/embedded] embedded run agent end: runId=169292b2-4955-442a-bd88-77be897576e7 isError=true model=gpt-5.4 provider=openai-codex error=LLM request failed: DNS lookup for the provider endpoint failed. rawError=<html> <head> <meta name="viewport" content="width=device-width, initial-scale=1" /> <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction…
20:12:23 [agent/embedded] embedded run agent end: runId=169292b2-4955-442a-bd88-77be897576e7 isError=true model=gpt-5.4 provider=openai-codex error=⚠️ API rate limit reached. Please try again later. rawError=<html> <head> <meta name="viewport" content="width=device-width, initial-scale=1" /> <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction…
20:12:38 [agent/embedded] embedded run agent end: runId=169292b2-4955-442a-bd88-77be897576e7 isError=true model=gpt-5.4 provider=openai-codex error=LLM request failed: DNS lookup for the provider endpoint failed. rawError=<html> <head> <meta name="viewport" content="width=device-width, initial-scale=1" /> <style global>body{font-family:Arial,Helvetica,sans-serif}.container{align-items:center;display:flex;flex-direction…
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "openai-codex",
"model": "gpt-5.4",
"attempts": [],
"outputs": [
{
"text": "LLM request failed: DNS lookup for the provider endpoint failed.",
"mediaUrl": null
}
]
}
thor@Thors-Air ~ %

high tartan
buoyant micaBOT
#

okay, I think we finally have the real answer.

This looks like a real openai-codex regression, not you messing something up.

Why I’m saying that:

  • gateway is healthy
  • auth exists
  • model is configured
  • no proxy env vars
  • hotspot did not fix it
  • direct infer still fails
  • the failure pattern is HTML + fake DNS/rate-limit errors, which matches an active recent openai-codex bug pattern almost exactly

So the blank web UI is basically a symptom of Codex OAuth requests failing upstream, not a separate mystery.

The most useful next options are:

#

  1. Fastest path to a working OpenClaw tonight

    • switch off openai-codex and use a different provider path you have credentials for
    • for example, direct OpenAI API (openai/...) if you have an API key, or Anthropic if you have that set up
    • if you want, I can help you do the minimum steps for that next

  2. If you specifically want Codex OAuth

If you comment there, include this summary:

  • macOS
  • OpenClaw 2026.4.14
  • openai-codex/gpt-5.4
  • openclaw infer model run ... returns HTML and surfaces DNS lookup for the provider endpoint failed
  • same result on phone hotspot
  • no proxy env vars set
#

So, very plainly: you are not crazy, and this is very likely not your fault.

If you want, next I can help you take the quickest route to a working setup with a non-Codex provider.

#

yep, agreed.

The important part is not just the DNS-style error text, it’s that:

  • the backend returned HTML
  • it happened on hotspot too
  • auth + config + gateway all looked sane

That combination is why I’m pretty confident this is an upstream openai-codex failure path / regression, not Thor fumbling the setup.

elder mauve
buoyant micaBOT
#

I think we are, yeah.

At this point I’d stop burning time on Codex OAuth specifically for tonight. If your goal is just to get OpenClaw working, tell me which of these you have:

  • OpenAI API key
  • Anthropic API key / Claude auth
  • neither

and I’ll point you to the quickest non-Codex path from here.

elder mauve
#

i have neither, but i have ollama running on windows 11 separate machine if thats easier, but i dont want to install openclaw on there for now

buoyant micaBOT
#

yes, that’s probably your best no-cost path tonight.

My honest take:

  • Yes, Mac OpenClaw can talk to Ollama on the Windows box
  • No, I would not call it the “best” long-term agent setup
  • but it’s the most realistic way to get something working without buying API access

Important docs-backed gotcha:

  • use the native Ollama URL like http://<windows-ip>:11434
  • do not use http://<windows-ip>:11434/v1
  • the /v1 path is the OpenAI-compatible mode, and tool calling gets flaky there

Also, expectation setting:

  • local Ollama can be fine for basic chats
  • for heavy agent/tool use, local models are often less reliable than cloud models

So my recommendation is:

elder mauve
#

ok i change my mind, that sounds more complicated and time consuming, will just getting the 2nd tier claud subcription work instead?

buoyant micaBOT
#

yes, if by that you mean a Claude plan that gives you Claude Code / CLI access, that is a much more reasonable path than remote Ollama.

The important nuance is:

  • OpenClaw can reuse Claude CLI auth on the same Mac
  • it is not “just buy Claude and magically it works”
  • the path is basically:
  1. get the Claude plan you want
  2. install and log into Claude CLI on the Mac
  3. run openclaw onboard and choose Claude CLI

Docs-backed answer:

  • OpenClaw does support Claude CLI / subscription auth
  • Anthropic API keys are still the most predictable long-term path
  • but for your situation, Claude CLI is probably the simpler paid route

Docs:

elder mauve
#

ok i just read claudes changes to usage and maybe another option would be better, what other choices do i have where i can pick up where we left off and not be out tons of money for it?

buoyant micaBOT
#

yeah, I’d rethink Claude too if cost certainty matters.

Given where you are right now, I’d look at these 3 options:

  1. Best recommendation: OpenAI API key with a hard spend cap

    • lowest drama from where you are now
    • easiest to debug
    • you keep the same OpenClaw install, just change auth/provider
    • not a subscription, but you can control spend tightly

  2. Cheapest cash option: local Ollama

    • least money
    • most setup friction
    • weakest reliability for agent/tool-heavy use

  3. Other hosted lower-cost providers supported by OpenClaw

    • things like MiniMax, Qwen Cloud, GLM/Z.AI
#
  • can be cheaper than Anthropic/OpenAI
    • but pricing and “what’s actually good this week” changes fast

So my honest recommendation is:

  • if you want the least pain: small OpenAI API budget
  • if you want the least money: Ollama
  • if you want best current cheap-provider advice: ask in #models because that changes constantly

Docs:

If you want, I can help you choose between OpenAI API key vs trying Ollama anyway based on your budget ceiling.

elder mauve
#

i wont have the same issue with openai api that im having now correct?

high tartan
#

@elder mauve i use glm 5 turbo... just sayin

buoyant micaBOT
#

you should not have this exact issue, no.

The problem you hit is on the openai-codex/* ChatGPT/Codex OAuth route.

A normal OpenAI API key uses the separate openai/* direct API route, so it should avoid this specific mess:

  • no ChatGPT/Codex OAuth path
  • no chatgpt.com/backend-api dependency
  • no same Cloudflare/HTML regression path we just found

I still can’t promise “zero issues ever,” but I would not expect the same failure mode.

If you go that route, I’d suggest:

  1. set a low budget cap
  2. add the API key
  3. do one tiny infer smoke test first

That way you verify it before sinking more time into setup.

#

yep, that’s exactly the kind of current real-world recommendation I’d trust from humans over me hardcoding a pricing/value take.

Thor, for which cheap hosted provider is best right now, #models is the best place to sanity-check it. For the setup side, the key thing is still:

  • avoid the broken Codex OAuth path
  • use a direct API path instead if you want the least drama
elder mauve
buoyant micaBOT
#

not exactly in the same way.

GLM is the model family. Z.AI is the platform/provider.
In OpenClaw it shows up as the zai provider.

Docs-backed answer:

  • there’s a generic API-key route
  • there are also Z.AI coding-plan auth routes (global / China region)

So it’s not just “Claude/OpenAI subscription but different brand”. It’s more like:

  • API-key option
  • plus some plan-specific routes depending on what account you buy

If you want the cleanest description, start here:

#

If your real question is “is this the cheapest decent hosted option right now?”, I’d still sanity-check that in #models, because that part changes fast.

high tartan
#

Theyve got a coding plan that you subscribe to. they have 10 bucks, 30 bucks and 80 bucks a month. and you get assloads of usage

buoyant micaBOT
elder mauve
buoyant micaBOT
#

honestly, fair 😄

Good news, you do not need to nuke your whole setup. Your gateway looked fine. You mostly just need a different provider path.

I’d do this next:

  1. get the Z.AI / GLM plan you want
  2. run:
    openclaw onboard
  3. choose the Z.AI coding-plan option that matches your region
  4. verify:
    openclaw models list --provider zai
  5. then do a tiny smoke test:
elder mauve
#

ok i did that and im still getting the error during onboarding step after selecting channel it returns with TypeError: Cannot read properties of undefined (reading 'trim')
this is the same error i was getting earlier

#

@buoyant mica please respond to the above

buoyant micaBOT
#

okay, that’s actually useful.

This strongly suggests the Z.AI/GLM auth itself is not the problem.
You’re hitting a separate onboarding bug in the channel setup step.

Since your goal right now is just to get the Web UI working on the Mac, you can skip channel setup entirely.

Try this exact command:

openclaw onboard --skip-channels

Then:

  1. pick the Z.AI coding-plan auth option again
  2. let onboarding finish
  3. run:
# 
   openclaw models list --provider zai
  1. then run:
    openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json

Why this is safe:

  • channels are optional for local Web UI use
  • your gateway was already healthy
  • the crash is happening in the channel onboarding path, so skipping it is the clean workaround

If --skip-channels still throws the same trim error, paste the full terminal output from that run and I’ll narrow the next step.

#

yep, responding now.

That trim crash looks like a separate onboarding bug in the channel setup step, not the GLM plan itself.

Please try this exact command:

openclaw onboard --skip-channels

Then if onboarding finishes:

openclaw models list --provider zai
openclaw infer model run --prompt "Reply with exactly: smoke-ok" --json
#

Why:

  • your gateway was already healthy
  • channels are optional for getting the local Web UI working
  • the crash seems to happen specifically when onboarding reaches channel setup

If openclaw onboard --skip-channels still throws the same TypeError: Cannot read properties of undefined (reading 'trim'), paste that full output and I’ll keep narrowing it.

elder mauve
#

finalllyyyyyyyyyy. thank you @high tartan @buoyant mica openclaw is asking me who i am for the first time.

buoyant micaBOT
#

hell yes 🎉

That is very good news. If it’s asking who you are, you finally got past the broken onboarding path and into the real first-run flow.

I’d just:

  1. answer that prompt normally
  2. finish setup
  3. send one test message in the Web UI

If the Web UI replies normally now, then the blocker was basically:

  • bad Codex path, and
  • separate channel-onboarding trim crash

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next poor soul.

high tartan
#

awesome! glad to help! Hopefully you like GLM 5 turbo!