#gateway

1 messages · Page 1 of 1 (latest)

viscid flowerBOT
hasty shaleBOT
#

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

viscid flowerBOT
crude streamBOT
#

Let me check the local docs paths first so I don’t make up a fix.

#

The install itself worked, but the post-install gateway probe timed out.

Also, small but important: you pasted a tokenized dashboard URL publicly, so I’d treat that token as compromised and rotate it.

Can you paste these next?

openclaw --version
openclaw gateway status --deep
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

Most common causes for this exact symptom are:

  • the service started, then crashed
  • CLI config and service config drifted
  • port 18789 is already in use
#

Nice, version looks current enough, so this probably isn’t a stale-build issue.

Next two are the important ones:

openclaw gateway status --deep
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

If journalctl --user complains about the user bus, also try:

export XDG_RUNTIME_DIR=/run/user/$(id -u)
journalctl --user -u openclaw-gateway.service -n 200 --no-pager

And definitely rotate that gateway token since it was posted publicly.

#

Nice, that actually looks healthy now.

The key lines are:

  • Runtime: running
  • RPC probe: ok
  • Listening: 127.0.0.1:18789

So the earlier Health check failed: timeout was probably just the install-time probe racing the first startup.

One important detail though: your gateway is loopback-only. That means http://127.0.0.1:18789/ works only on that machine.

If this is a remote VPS/server, use an SSH tunnel from your laptop:

ssh -N -L 18789:127.0.0.1:18789 <user>@<host>
#

Then open locally:

http://127.0.0.1:18789/

Or set up a proper remote path like Tailscale Serve later.

Also, please rotate that gateway token since it was posted publicly.

Docs:

If it’s working now, glad we caught the false alarm 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

#

Let me pull the Telegram setup docs so I can give you the exact next step, not a guessed one.

#

Yep, that was just the gateway. Telegram is a separate step.

My recommendation, do DM-only first, then add groups after it replies once. It’s way less annoying.

1) Create the bot in BotFather

In Telegram, talk to @BotFather and run:

/newbot

Save the token.

2) Add a minimal Telegram config

{
# 
  channels: {
    telegram: {
      enabled: true,
      botToken: "123:abc",
      dmPolicy: "pairing"
    }
  }
}

You can also use TELEGRAM_BOT_TOKEN=... for the default account.

Important: Telegram does not use openclaw channels login telegram.

3) Restart the gateway

# 
openclaw gateway restart

4) DM your bot, then approve the pairing

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

After that, your bot should answer in DM.

If you want group support later

  • add the bot to the group
  • either disable privacy mode in BotFather with /setprivacy, or make the bot a group admin
  • then configure channels.telegram.groups
#

I’m going to verify where those onboarding “personality/name/emoji” settings actually live, because they’re easy to mix up with Telegram config.

#

Yep, and the nice part is: that stuff is not actually Telegram-specific. Telegram is just the transport.

The name / emoji / personality live in the agent workspace files:

  • IDENTITY.md → name, vibe, emoji
  • SOUL.md → personality, tone, boundaries
  • USER.md → how it should address you
  • BOOTSTRAP.md → one-time “who am I / who are you” setup, if it still exists

So you’ve got two good options:

Fastest

Re-run the guided flow:

openclaw setup --wizard
#

Manual

Edit the workspace files directly, usually in:

~/.openclaw/workspace

If some files are missing, plain:

openclaw setup

will recreate the default workspace files without overwriting existing ones.

So, short version: you did not miss your only chance. You can still set all of that now, then continue Telegram setup after.

#

I’m checking the wizard docs/code path for that exact “why do I sometimes get the hatch step and sometimes not?” behavior.

#

Yeah, that’s expected-ish.

You usually get the “How do you want to hatch your bot?” step only when a few things line up:

  • onboarding UI is actually running
  • the gateway is reachable at that moment
  • the workspace is still in a first-run / not-fully-bootstrapped state

You may not get it when:

  • the gateway health/probe timed out during onboarding
  • UI was skipped/headless flow changed
  • the workspace is no longer brand new, so BOOTSTRAP.md is already gone
  • setup was done in a path that skips bootstrap

The important bit is this:

#
  • BOOTSTRAP.md is one-time
  • once bootstrapping is completed and that file is removed, OpenClaw should not recreate it on later restarts

So if you want the guided experience again, the cleanest path is:

openclaw setup --wizard

If you just want to finish identity/personality manually, edit:

  • IDENTITY.md
  • SOUL.md
  • USER.md

Docs:

#

Yep, that’s the culprit.

When onboarding hits:

Health check failed: timeout

it usually skips the hatch step for that run, because the hatch UI is only offered once the gateway is reachable.

So the pattern is basically:

  • gateway starts a bit slowly
  • onboarding health check times out
  • no hatch flow appears
  • a moment later the gateway is actually fine
#

That matches what you pasted earlier, where openclaw gateway status --deep later showed:

  • Runtime: running
  • RPC probe: ok

So this is probably a startup timing/race issue, not “your bot can’t hatch”.

Easiest recovery

Once the gateway is up, run:

openclaw setup --wizard

That should let you go through the guided flow again.

Quick sanity check first

# 
openclaw gateway status

If that says RPC probe: ok, you’re clear to rerun the wizard.

And if the workspace is still fresh and BOOTSTRAP.md is still there, you’ll get the real first-run identity ritual too.

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

#

--wizard means: run the full interactive onboarding flow.

So:

openclaw setup

= just initialize config + workspace

while

openclaw setup --wizard

= launch the guided setup/onboarding screens again, including things like:

#
  • workspace/bootstrap setup
  • gateway mode/bind/auth
  • channels like Telegram/Discord
  • daemon install
  • health check
  • the hatch flow, when the gateway is reachable

So I’d think of it as:

  • setup = basic scaffolding
  • setup --wizard = “take me through the whole thing again”

Docs: https://docs.openclaw.ai/cli/setup

crude streamBOT
#

Let me verify the docs wording on multi-model/fallback before I answer, since model config details drift fast.

#

Yes, absolutely, and usually yes, it’s a good idea.

Best pattern is:

  • 1 strong primary model
  • 1 or 2 fallbacks
  • optionally a separate image/pdf model if you need that

I would not build a huge chain, though. That gets messy fast.

A good reason to use multiple models:

  • provider outages / rate limits
  • cheaper backup for low-stakes turns
  • different capabilities for text vs image/pdf

A bad reason:

  • hoping fallbacks will magically solve “hard tasks”
#

I’m checking the docs for the exact OpenAI subscription wording so I don’t steer you wrong.

#

You do not need Pro just to use OpenClaw, but there’s an important split:

  • ChatGPT/OpenAI subscription sign-in → goes through the openai-codex/* route
  • Direct OpenAI API usage → needs an API key for openai/*

So if you want to use your ChatGPT-style subscription, the supported path is Codex OAuth.

What I wouldn’t assume is that Plus and Pro behave identically, because the usable quota/entitlements for openai-codex/* are OpenAI-managed and plan-dependent.

Short version:

  • Can Plus work? Potentially, yes, via Codex OAuth
  • Do docs guarantee Plus specifically? No
  • Do you need Pro for OpenClaw itself? No
  • Most predictable option? OpenAI API key

Also important: ChatGPT subscription access does not automatically unlock the direct openai/* API route in OpenClaw.

crude streamBOT
#

I’m checking whether onboarding has an actual “back” mechanic or if the intended flow is rerunning the wizard.

#

There isn’t really a general “go back one step” button in CLI onboarding.

The normal way is:

openclaw setup --wizard

and go through it again.

Good news: re-running the wizard does not wipe anything unless you explicitly choose Reset.

If you only want to revisit one part, this is usually better:

openclaw configure
#

Or a specific section:

openclaw configure --section model
openclaw configure --section channels
openclaw configure --section gateway
openclaw configure --section daemon

So the practical rule is:

  • whole flow again → openclaw setup --wizard
  • just one area → openclaw configure --section ...

Docs:

#

Easiest path:

Option 1, rerun the guided flow

Once the gateway is healthy:

openclaw setup --wizard

That’s the closest thing to “please ask me the identity questions again”.

Option 2, do it manually now

Edit these files in your workspace, usually:

~/.openclaw/workspace
#
  • IDENTITY.md → bot name, vibe, emoji
  • USER.md → your name, how it should address you
  • SOUL.md → personality, tone, boundaries

If those files are missing, seed them with:

openclaw setup

That recreates missing defaults without wiping existing files.

If BOOTSTRAP.md exists

That means the workspace is still in first-run mode, so you can use that as the identity ritual starting point too.

Docs:

#

Oof, yeah, at that point I’d stop looping onboarding. That timeout is probably the wizard’s health probe racing startup, and it’s wasting your time.

Do this instead

First check whether the gateway is actually healthy after onboarding bails:

openclaw gateway status

If that shows:

RPC probe: ok

then the gateway is fine, and you can skip re-running onboarding.

#

Use these instead:

openclaw configure --section channels
openclaw configure --section model
openclaw configure --section gateway --section daemon

For identity/persona, use:

openclaw setup

and edit the workspace files in ~/.openclaw/workspace (IDENTITY.md, SOUL.md, USER.md).

If openclaw gateway status is NOT healthy

#

Then I want the real error, not the wizard summary. Paste:

openclaw status --all
openclaw logs --follow

So short version:

  • healthy after the timeout? ignore the wizard failure and configure things directly
  • not healthy? grab status/logs and debug the gateway itself

That’s the path I’d take here.

#

Easiest way, from the terminal:

cd ~/.openclaw/workspace
ls
nano IDENTITY.md

Other useful ones:

nano SOUL.md
nano USER.md

If you use nano:

#
  • save: Ctrl+O, then Enter
  • exit: Ctrl+X

If the files aren’t there yet, run:

openclaw setup

That should seed the workspace files.

If you want to open the whole folder in an editor and you have VS Code installed on that machine:

code ~/.openclaw/workspace
#

If you want, I can also show you a super simple starter IDENTITY.md you can paste in.

crude streamBOT
#

That sounds like it probably picked the wrong kind of reminder.

There are 2 different paths:

  1. Chat reminder / scheduled reminder → uses cron in the Gateway

  2. Device-native reminder → uses a linked device/node (reminders.add)

    • that needs a paired phone/mac device that supports reminders
    • on a plain Linux gateway, that usually is not available

So if it said something like “Gateway isn’t linked”, I suspect it tried device reminders instead of cron.

What to do

Ask it more explicitly in Telegram:

#

“Set a cron reminder for 01:00 and send it back to me here on Telegram.”

or

“Schedule a reminder for 01:00 using the gateway scheduler, not device reminders.”

Important

Cron reminders only fire if the Gateway is running continuously until 01:00.
Docs confirm cron runs inside the Gateway process: https://docs.openclaw.ai/help/faq#cron-or-reminders-do-not-fire-what-should-i-check

Quick checks

Run these on the machine:

openclaw --version
openclaw status --deep
# 
openclaw channels status
openclaw cron list

If Telegram is already replying to you live, then Telegram is probably fine, and this is more likely a tool-choice issue than a real Telegram link failure.

If you paste those 4 outputs, I can tell you exactly which one it is.

#

Yeah, that wording is probably misleading.

If OpenClaw is already replying to you on Telegram, then the Gateway is already linked enough for Telegram chat.

What it likely means is:

  • it tried to use device reminders (reminders.add)
  • but there is no linked reminders-capable device/node
  • so it said “gateway isn’t linked”

For a message me later on Telegram reminder, it should use cron, not device reminders.

Try phrasing it like this

“Schedule a cron reminder for <date/time> and send it back to me in this Telegram chat.”

If you actually want native phone/mac reminders

Then you need a linked device/node that supports reminders. A plain Linux gateway usually does not.

#

Nice, that approval actually went through.

The important part is this line:

Approved ... (20fc727e-d3c8-4683-a2ff-1d997d7e3287)

The earlier bit:

gateway connect failed: ... pairing required
Direct scope access failed; using local fallback.

just means the CLI tried the normal gateway RPC path first, hit a pairing requirement, then because you were on local loopback it used the local fallback and approved it anyway.

#

So, next step: try the reminder again on Telegram.

If it still fails

Run:

openclaw nodes status
openclaw channels status

What I’m looking for:

  • if there is no connected node with reminders capability, OpenClaw is still trying device-native reminders
  • if Telegram is healthy but reminders still fail, then it’s probably choosing the wrong tool and should be using cron instead

In that case, ask it explicitly: