install issues | Friends of the Crustacean 🦞🤝 | Page 1

patent sierraBOT Feb 14, 2026, 7:08 PM

#

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

rapid garnetBOT Feb 14, 2026, 7:09 PM

#

If the first one works and the second won’t “hatch”, the usual culprit is that the 2nd instance is colliding with the 1st one (same port, same state/config directory, or same Telegram bot token).

1) Quick sanity checks (paste output here; redact tokens)

Run these on the second bot instance:

openclaw --version
openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe

In the logs/status, common smoking guns are:

EADDRINUSE / “already listening” → port conflict (both trying to use 18789)
“config (cli) vs config (service) mismatch” → AMS/service is starting with a different config than you think

#

Telegram connected = false / auth errors → channel not actually up

2) If you’re running two gateways on the same machine

You need to make the second one fully separate:

different gateway port
different state dir (and usually different config path)

Docs-supported knobs (for separate instances): OPENCLAW_STATE_DIR / OPENCLAW_CONFIG_PATH (from Getting Started).

3) Telegram gotcha (very common)

If both instances are using the same Telegram bot token, only one process will reliably receive updates (polling conflicts / messages “disappear”). Easiest fix: create a second Telegram bot token for the second OpenClaw instance.

4) One question so I can aim this properly

When you say “AMS”, is that CubeCoders AMP/ADS (app management panel), or something else? And are you running these as two containers, or two “instances” on the same host?

If you paste the openclaw gateway status + the first ~30 lines around the first error in openclaw logs --follow, I can tell you exactly which of the above is happening.

sullen badger Feb 14, 2026, 7:11 PM

#

They are not in the same machine. I have one seperate instance for each in AWS. The bot can reach the gateway and sees the telegram but can't connect. it won't start up or give me the option to auth the telegram id

rapid garnetBOT Feb 14, 2026, 7:12 PM

#

If Telegram “shows up” but you never get the “auth Telegram id” step: Telegram doesn’t do an interactive OAuth-style auth. OpenClaw authorizes DMs via pairing (default), and you approve it from the CLI.

Here’s the expected flow (docs: https://docs.openclaw.ai/channels/telegram and pairing: https://docs.openclaw.ai/channels/pairing):

What to do on the 2nd AWS instance

Make sure Telegram is enabled + token is set (redact token when sharing):

openclaw config get channels.telegram
openclaw channels status --probe

You should see something like enabled: true and no Telegram API errors.

Restart gateway after any config change:

openclaw gateway restart

#

DM your Telegram bot (from your personal Telegram account), then on the server run:

openclaw pairing list telegram

If you see a pending code, approve it:

openclaw pairing approve telegram <CODE>

If `pairing list telegram` stays empty (most common causes)

DM policy isn’t pairing/open (e.g. set to allowlist or disabled). For a quick test, set:
channels.telegram.dmPolicy: "pairing" (recommended) or "open" (temporary test)
The bot can’t reach api.telegram.org from that AWS instance (security group / egress / DNS / IPv6 weirdness). Check logs:

openclaw logs --follow

#

and paste the first Telegram-related error line(s).

You accidentally configured webhook mode (channels.telegram.webhookUrl set) but don’t have a public webhook endpoint. For AWS testing, keep webhook fields unset so it uses long polling (default).

If you paste:

openclaw --version
openclaw channels status --probe (telegram section)
and the Telegram-ish errors from openclaw logs --follow

…I can tell you exactly which of the above is blocking it.

sullen badger Feb 14, 2026, 7:13 PM

#

"enabled": true,
"dmPolicy": "pairing",
"botToken": "8433411391:AAGNsSN-HwM02inLlsPkJoKBGqqCB-HPeME",
"groupPolicy": "allowlist",
"streamMode": "partial"

rapid garnetBOT Feb 14, 2026, 7:14 PM

#

Config-wise that looks basically correct for Telegram DMs (enabled + dmPolicy: "pairing"). Two important things though:

0) You just leaked your bot token — rotate it now

That token is now public in this channel history. In Telegram, anyone with it can operate your bot.

In Telegram chat with @BotFather:

use /revoke (or regenerate token for that bot)
update your OpenClaw config with the new token
restart the gateway

And please don’t paste tokens here again (redact like 8433…PeME).

1) There is no “auth telegram id prompt” — pairing happens after you DM the bot

The “option to auth” only appears once the gateway receives your DM to the bot.

Do this on the 2nd AWS instance:

#

Restart gateway (after token rotation):

openclaw gateway restart

Tail logs in one window:

openclaw logs --follow

From your personal Telegram account: DM the bot (“hi” is enough).
Back on the server:

openclaw pairing list telegram

#

If you see a code, approve it:

openclaw pairing approve telegram <CODE>

2) If `pairing list telegram` stays empty, it means the gateway isn’t receiving updates

Most common causes:

A) Same bot token is still running somewhere else

If instance #1 and #2 accidentally use the same bot token, only one will reliably consume updates (long-polling conflict). Confirm bot token is different per instance.

B) Network/DNS can’t reach Telegram from that AWS box

Keep openclaw logs --follow running and look for Telegram errors (timeouts, DNS, setMyCommands failed, etc.).

C) Service is running with a different config than the CLI

Run:

#

openclaw gateway status --deep
openclaw channels status --probe

and see if it shows a “Config (cli) vs Config (service)” mismatch or Telegram not actually started.

If you paste (with token redacted):

openclaw --version
openclaw channels status --probe (telegram section)
the first Telegram-related error lines from openclaw logs --follow right after you DM the bot

…I can tell you exactly which case you’re hitting.

sullen badger Feb 14, 2026, 7:14 PM

#

I probably shouldn't have put the bot token in there

rapid garnetBOT Feb 14, 2026, 7:14 PM

#

Yeah — rotate it ASAP. Since it’s already posted here, assume it’s compromised.

Do this:

In Telegram, open a chat with BotFather
Run /revoke and pick that bot (it will generate a new token)
Update your OpenClaw config with the new token (only on that AWS instance)
Restart:

openclaw gateway restart

After that, DM the bot again and approve the pairing:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

#

If you want, paste your openclaw channels status --probe and any Telegram errors from openclaw logs --follow — just redact tokens/user ids.

sullen badger Feb 14, 2026, 7:17 PM

#

I'm super confused

rapid garnetBOT Feb 14, 2026, 7:18 PM

#

Totally fair — Telegram in OpenClaw is confusing because there is no interactive “log in / auth Telegram” screen like Discord OAuth. It’s basically:

you put the bot token in config
the gateway connects to Telegram
you DM the bot
OpenClaw creates a pairing request
you approve that request from the CLI

Let’s reset to a very deterministic checklist.

Step A — Fix the leaked token first

Since the token was posted, rotate it in BotFather (/revoke), update the config, then:

openclaw gateway restart

#

Step B — Verify the gateway is actually running

On the AWS instance for the second bot:

openclaw gateway status

You want to see Runtime: running and RPC probe: ok.

Step C — Verify Telegram is connected (without pasting secrets)

Run:

openclaw channels status --probe
openclaw logs --follow

#

Leave logs --follow open.

Step D — Trigger pairing the only way it can happen

From your personal Telegram account, DM the bot directly (not a group): send “hi”.

Then back on the server:

openclaw pairing list telegram

If you see a pending code:

openclaw pairing approve telegram <CODE>

#

If Step D shows nothing (pairing list empty)

That means the gateway never received your DM. The usual causes are:

You accidentally have the same bot token running on the other instance too (only one will “win” the long-poll updates).
The AWS instance can’t reach api.telegram.org (egress/DNS/IPv6). This will show up in openclaw logs --follow as Telegram API errors.

If you paste just:

the output of openclaw channels status --probe (redact token)
and the first Telegram-related error lines from openclaw logs --follow right after you DM the bot

…I’ll tell you exactly which of those it is and what to change next.

sullen badger Feb 14, 2026, 7:19 PM

#

bot father keeps saying the bot is invalid

rapid garnetBOT Feb 14, 2026, 7:20 PM

#

If BotFather says the bot is “invalid”, it almost always means BotFather can’t find that bot under your Telegram account (or you’re not talking to the real BotFather).

Do these exact checks:

1) Make sure you’re talking to the real BotFather

The username must be @BotFather (exact spelling). Don’t use a lookalike from search.

2) Check that the bot exists and is yours

In the @BotFather chat, run:

/mybots

You should see a list of bots you own. If your bot is not in that list, then either:

you’re logged into the wrong Telegram account (different phone number than the one that created the bot), or
the bot was deleted.

3) Rotate token via the button flow (don’t type the token)

#

From /mybots:

tap your bot → API Token → Revoke (or “Generate new token”)

If BotFather still says “invalid bot” at this step, tell me the exact wording BotFather sends (no tokens), because that points to which of the above it is.

4) Fastest workaround: just create a fresh bot

If you can’t recover that bot:

/newbot
get the new token
put that token into OpenClaw (channels.telegram.botToken)
openclaw gateway restart
DM the bot “hi”
openclaw pairing list telegram

Question: when you run /mybots, do you see the bot you’re trying to use on AWS in the list?

sullen badger Feb 14, 2026, 7:21 PM

#

Okay, I nuked that bot and created a new one

rapid garnetBOT Feb 14, 2026, 7:21 PM

#

Good move. Now you just need to wire the new bot into OpenClaw and trigger pairing.

1) Put the new token into OpenClaw (don’t paste it here)

Update your config on the 2nd AWS instance:

channels: {
telegram: {
enabled: true,
botToken: "REDACTED",
dmPolicy: "pairing",
},
}

Then restart:

#

openclaw gateway restart

2) Confirm Telegram is actually up

openclaw channels status --probe

3) Trigger pairing

From your personal Telegram account, DM the new bot: send “hi”.

Then on the server:

openclaw pairing list telegram

#

openclaw pairing approve telegram <CODE>

4) If `pairing list telegram` is empty

Run:

openclaw logs --follow

DM the bot again, and paste the Telegram-related error lines (redact token). That’ll tell us if it’s egress/DNS (AWS security group) or a config/service mismatch.

If you tell me what openclaw channels status --probe shows for telegram (just the status bits, no secrets), we can confirm you’re 90% there.

sullen badger Feb 14, 2026, 7:24 PM

#

What is the reinstall command

rapid garnetBOT Feb 14, 2026, 7:24 PM

#

Depends what you mean by “reinstall”:

Reinstall the Gateway service/daemon (most common fix)

This re-writes the service metadata (and fixes “CLI config vs service config” mismatches):

openclaw gateway install --force
openclaw gateway restart

If you want to fully remove + re-add the service:

openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway restart

#

Reinstall the OpenClaw CLI itself

Recommended install method (macOS/Linux):

curl -fsSL https://openclaw.ai/install.sh | bash

Then restart the gateway:

openclaw gateway restart

If you tell me which OS/distro your AWS instance is using (Ubuntu? Amazon Linux?) and whether you installed via the curl script vs npm, I can point you at the exact “best” reinstall path. Docs: https://docs.openclaw.ai/install

sullen badger Feb 14, 2026, 7:25 PM

#

ubuntu

rapid garnetBOT Feb 14, 2026, 7:26 PM

#

On Ubuntu, the two “reinstall” paths are:

1) Reinstall the gateway service (usually what you want)

openclaw gateway uninstall
openclaw gateway install --force
openclaw gateway restart

Then verify:

openclaw gateway status
openclaw channels status --probe

2) Reinstall the OpenClaw CLI (if the install itself is broken)

Recommended on Ubuntu:

#

curl -fsSL https://openclaw.ai/install.sh | bash

Then:

openclaw gateway restart

After you’re back up: DM the Telegram bot “hi” and run:

openclaw pairing list telegram

If it still doesn’t show a pending code, paste the Telegram-related lines from:

#

openclaw logs --follow

sullen badger Feb 14, 2026, 7:28 PM

#

This is unhelpful

rapid garnetBOT Feb 14, 2026, 7:30 PM

#

You’re getting bounced around because “Telegram auth” in OpenClaw isn’t a login screen—so reinstalling won’t magically make an “authorize Telegram ID” prompt appear.

Let’s make this binary and fast: is your gateway actually receiving Telegram updates or not? That’s the whole problem.

Do this exact 2‑minute test on the Ubuntu AWS box (2nd instance)

1) Confirm the service is using the config you edited

Run and paste the output:

openclaw gateway status --deep

(That output is safe to share; redact only if it includes secrets.)

2) Confirm Telegram channel is up

Run and paste the output:

#

openclaw channels status --probe

Do not paste your bot token. If it shows it, redact it.

3) Watch logs, then DM the bot

On the server:

openclaw logs --follow

Leave that running, then from your personal Telegram account DM the bot “hi”.

What should happen:

logs show a Telegram inbound update (or at least some Telegram activity)
then:

#

openclaw pairing list telegram

should show a pending pairing code

approve it:

openclaw pairing approve telegram <CODE>

Interpreting the result

If logs show nothing when you DM → the AWS instance is not receiving updates (most often: wrong token in the service config, or outbound networking/DNS to api.telegram.org is blocked).
If logs show the DM but pairing list is empty → paste the log lines; that’s a specific bug/policy signal we can read.
If pairing shows up and you approve it → it should start replying immediately in DM.

Paste the outputs from steps 1 and 2, and the first Telegram-looking error lines from step 3 (no token), and I’ll tell you exactly what’s wrong in one shot.

sullen badger Feb 14, 2026, 7:30 PM

#

okay so I am redoing the onboarding

rapid garnetBOT Feb 14, 2026, 7:31 PM

#

Nice — redoing onboarding is a good reset button.

On Ubuntu, here’s the clean “known good” path:

1) Run the wizard

openclaw onboard --install-daemon

During the wizard:

configure your model/provider as you did for the first instance
when it asks about Telegram, paste the new bot token there (don’t post it here)
keep DM access as pairing (that’s fine)

2) After the wizard: verify the gateway is actually running

#

openclaw gateway status
openclaw channels status --probe

3) Trigger pairing (this is the step most people miss)

DM your Telegram bot “hi”
then on the server:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

If onboarding “works” but Telegram still never shows a pairing request

That usually means AWS egress/DNS is blocking Telegram. Make sure the instance can reach api.telegram.org on outbound 443 (security group + NACL).

If you paste only the output of openclaw channels status --probe (redact token if it appears) after onboarding, I’ll tell you what it thinks is wrong.

sullen badger Feb 14, 2026, 7:33 PM

#

Is there an issue with the system that is making it not hatch?

rapid garnetBOT Feb 14, 2026, 7:34 PM

#

Probably not a “system-wide” issue.

OpenClaw doesn’t rely on a central service to “hatch” — it’s basically: your Ubuntu box runs the gateway, and that gateway talks directly to Telegram’s Bot API. So when it won’t come alive, it’s almost always one of these local causes:

the gateway service isn’t actually running (or it’s crashing on startup)
the service is running with a different config than the one you edited (super common)
the server can’t reach api.telegram.org (AWS egress / DNS / IPv6 / firewall)
wrong Telegram bot token (or webhook mode mis-set)

If you want the fastest confirmation, run this exact ladder on the AWS instance and paste the output (redact tokens/secrets):

openclaw --version
openclaw status
openclaw gateway status
openclaw doctor

#

openclaw channels status --probe
openclaw logs --follow

Also: if openclaw dashboard lets you chat successfully, the agent/gateway is “hatched” and the issue is Telegram-only. If dashboard also fails, it’s a gateway/service problem.

Send those outputs and I’ll tell you which bucket it’s in and the next fix step.

sullen badger Feb 14, 2026, 7:36 PM

#

is this something I need to worry about? Gateway token: shared auth for the Gateway + Control UI. │
│ Stored in: ~/.openclaw/openclaw.json (gateway.auth.token) or OPENCLAW_GATEWAY_TOKEN. │
│ View token: openclaw config get gateway.auth.token │
│ Generate token: openclaw doctor --generate-gateway-token │
│ Web UI stores a copy in this browser's localStorage (openclaw.control.settings.v1). │
│ Open the dashboard anytime: openclaw dashboard --no-open │
│ If prompted: paste the token into Control UI settings (or use the tokenized dashboard │
│ URL).

rapid garnetBOT Feb 14, 2026, 7:36 PM

#

You don’t need to panic — that message is normal. But yes: you should treat the gateway token like a password.

What it is

It’s the shared secret that lets the Control UI / CLI talk to your Gateway.
If someone gets it, they can potentially control your OpenClaw gateway (tools, messages, etc.), depending on what you’ve enabled.

What you should do

Don’t paste it in Discord (or anywhere public).
On AWS: do not expose the gateway port (default 18789) to the public internet. Ideally:
bind it to localhost and use SSH tunneling, or
expose only over a private network/VPN (e.g., Tailscale), or
lock it down to your IPs.

If you think the token might be compromised

Rotate it (note: doctor --generate-gateway-token only creates one if missing). To actually rotate, set a new value and restart:

#

openclaw config set gateway.auth.token "<NEW_RANDOM_TOKEN>"
openclaw gateway restart

After rotation, the Control UI will ask for the new token again.

If you tell me how you’re accessing the Control UI (local browser via SSH tunnel, public IP, Tailscale, etc.), I can tell you the safest setup for AWS.

sullen badger Feb 14, 2026, 7:38 PM

#

The bot is not comin online

#

This is the same issue I had the las t time I was trying to get it started

rapid garnetBOT Feb 14, 2026, 7:38 PM

#

“Bot not coming online” can mean 3 different things in OpenClaw, and the fix depends on which one you’re stuck on:

1) Is the Gateway actually running?

On the Ubuntu AWS box, run and paste:

openclaw gateway status
openclaw gateway status --deep

You’re looking for Runtime: running and RPC probe: ok.
--deep also shows which config/state paths the service is using (this catches the super-common “I edited config A, but the daemon is using config B” problem).

2) Is Telegram connected?

Run and paste (redact anything secret if it appears):

#

openclaw channels status --probe

If Telegram isn’t “ready/connected” here, the next step is always logs.

3) Is it just not replying because pairing isn’t approved?

Leave this running:

openclaw logs --follow

Then DM your Telegram bot “hi”, and immediately run:

#

openclaw pairing list telegram

If you see a code:

openclaw pairing approve telegram <CODE>

The two most common “it never comes online” causes (especially on AWS)

The daemon is using a different config than your CLI edits (fix = check gateway status --deep, then reinstall daemon if needed).
Telegram can’t deliver updates:

wrong token, or
network can’t reach api.telegram.org, or
Telegram “conflict” error because something else is polling/there’s a webhook set. This will show up clearly in openclaw logs --follow as a Telegram API error (409 conflict / webhook active, etc.).

Paste the outputs of (1) and (2) plus the first Telegram-related error lines from logs, and I’ll tell you exactly which one it is and the specific fix.

#

If it feels like “the same issue as last time”, it’s usually one of these two:

the gateway daemon is running with a different config than the one you edited (very common), or
Telegram is failing to start and the reason is only visible in the gateway logs (DNS/egress, 409 conflict, webhook, bad token, etc.)

Let’s stop guessing and get the 3 outputs that pinpoint it.

Run these on the Ubuntu AWS box and paste the output (redact tokens/secrets):

openclaw --version
openclaw gateway status --deep
openclaw channels status --probe

Then do this to capture the actual failure reason:

#

openclaw logs --follow

While logs --follow is running, in another terminal do:

openclaw gateway restart

…and paste the first Telegram-related error lines that appear during startup.

Those four things will tell us immediately whether it’s:

gateway not actually running / crashing
config mismatch (CLI vs service)
Telegram API/network issue (common on AWS if egress/DNS/IPv6 is weird)
Telegram “conflict” / webhook still set

#

Also please don’t paste the bot token again—just the error text around it.

sullen badger Feb 14, 2026, 7:39 PM

#

I'm in the terminal in the tui

rapid garnetBOT Feb 14, 2026, 7:39 PM

#

Cool — are you in the openclaw onboard wizard TUI, or the Control UI/dashboard?

If you’re in the onboarding wizard TUI

Tell me what step/screen it’s on (copy/paste the last ~20 lines, especially any red error).

Also, open a second SSH/terminal to the same Ubuntu box and run these while the TUI is open:

openclaw gateway status
openclaw gateway status --deep
openclaw channels status --probe

If any of those say not running / not connected, then run:

#

openclaw logs --follow

…and paste the first Telegram/gateway error lines that show up.

If you’re stuck and need to exit the TUI

Usually Ctrl+C exits the wizard (don’t do this if it’s mid-writing config unless it’s clearly hung).

Reply with: (1) which TUI screen you see + (2) the output of openclaw gateway status — that’s enough to narrow it immediately.

sullen badger Feb 14, 2026, 7:40 PM

#

the onboarding wizard. at the end where the bot hatches

rapid garnetBOT Feb 14, 2026, 7:41 PM

#

“Hatching” at the end of openclaw onboard is basically: wizard starts the Gateway service and waits for RPC probe: ok. When it hangs there, it’s almost always a local service/startup issue (not a system-wide OpenClaw outage).

Do this while you keep the wizard screen open:

1) Open a 2nd SSH/terminal to the same Ubuntu box and run

openclaw gateway status

If it says `Runtime: running` + `RPC probe: ok`

The gateway is hatched. The wizard UI might just be waiting on a later step.
Next check Telegram specifically:

openclaw channels status --probe

If it says `Runtime: stopped` or `RPC probe: failed`

#

We need the startup error. Run:

openclaw logs --follow

Then in another terminal:

openclaw gateway restart

Copy/paste the first error lines that appear (redact secrets: bot token, gateway token, API keys).

2) Quick “bypass the daemon” test (proves if the gateway can start at all)

If the daemon won’t come up, run the gateway in the foreground to see the real error immediately:

openclaw gateway --verbose

If this works, your issue is systemd/daemon install. If this fails, it’ll print the real reason (port in use, config invalid, auth/bind guardrails, etc.).

#

3) Common Ubuntu/AWS daemon gotcha

If you chose “install daemon”, on Linux it’s often a systemd user service, and it won’t persist unless lingering is enabled:

sudo loginctl enable-linger $USER

Run openclaw gateway status and tell me which of the two cases you’re in (RPC probe ok vs failed), and if failed paste the error snippet from logs. That’s the fastest way to unstick the hatch step.

sullen badger Feb 14, 2026, 7:46 PM

#

Log tail truncated (increase --max-bytes).
Gateway not reachable. Is it running and accessible?
Gateway target: ws://"redacted"
Source: local loopback
Config: /home/ubuntu/.openclaw/openclaw.json
Bind: loopback
Hint: run openclaw doctor.

rapid garnetBOT Feb 14, 2026, 7:47 PM

#

That message means the wizard is trying to connect to your local Gateway on loopback, and it can’t — so the gateway process either never started or crashed immediately. Not a “system-wide” OpenClaw issue.

Do this on the AWS Ubuntu box in a second SSH terminal (leave the wizard open):

1) See what the service thinks is happening

openclaw gateway status --deep

This usually tells you “running vs stopped” plus the last error.

2) Let doctor repair the common Linux daemon issues automatically

openclaw doctor --repair --yes

3) Try starting the gateway again

#

openclaw gateway restart
openclaw gateway status

4) If it still won’t hatch: run the gateway in the foreground to get the real error

This bypasses systemd and prints the crash reason directly:

openclaw gateway --verbose

Paste the output of openclaw gateway status --deep (and if needed the first error lines from openclaw gateway --verbose). Redact tokens/API keys if they appear. That will tell us exactly whether it’s a port collision, config issue, missing systemd user session/linger, or a crash on startup.

sullen badger Feb 14, 2026, 7:50 PM

#

Telegram: failed (404) - Not Found
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/ubuntu/.openclaw/agents/main/sessions/sessions.json (1 entries)

agent:main:main (16m ago)
Config overwrite: /home/ubuntu/.openclaw/openclaw.json (sha256 "redacted" backup=/home/ubuntu/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Backup: ~/.openclaw/openclaw.json.bak

rapid garnetBOT Feb 14, 2026, 7:51 PM

#

That line is actually a big clue:

Telegram: failed (404) - Not Found = Telegram is telling you your bot token is invalid (revoked / wrong / copied wrong / extra whitespace).
(It’s the Bot API response {"ok":false,"error_code":404,"description":"Not Found"}.)

So this isn’t a random “hatch” problem — it’s almost certainly token/config mismatch.

Here’s the shortest path to confirm + fix (don’t paste any tokens here):

1) Make sure the Gateway is running first

In another terminal on the same box:

openclaw gateway status

If it’s not running, start it (foreground, easiest for debugging):

#

openclaw gateway --verbose

2) Verify what token OpenClaw thinks it has (DO NOT paste output)

Just run it for yourself and compare to BotFather:

openclaw config get channels.telegram.botToken

Make sure it exactly matches the new token from BotFather (no spaces/newlines).

If it’s wrong, set it (again: don’t paste it here):

openclaw config set channels.telegram.botToken "<NEW_TOKEN>"
openclaw gateway restart

#

3) Prove the token works from that AWS machine (safe output)

Replace <NEW_TOKEN> locally (don’t post it) and you should see "ok":true:

curl -sS "https://api.telegram.org/bot<NEW_TOKEN>/getMe"

If that returns 404 Not Found → token is still wrong/revoked.
If it returns ok:true → token is good, and we move on to pairing (openclaw pairing list telegram after you DM the bot).

If you paste only:

openclaw gateway status output
and the result of openclaw channels status --probe (no secrets)

…I can tell you the next exact step.

sullen badger Feb 14, 2026, 7:51 PM

#

19:51:00 Gateway failed to start: gateway already running (pid 12989); lock timeout after 5000ms
If the gateway is supervised, stop it with: openclaw gateway stop
19:51:00 Port "redacted" is already in use.
19:51:00 - pid "redacted" ubuntu: openclaw-gateway (127.0.0.1:18789)
19:51:00 - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
19:51:00 Gateway service appears enabled. Stop it first.
19:51:00 Tip: openclaw gateway stop
19:51:00 Or: systemctl --user stop openclaw-gateway.service

rapid garnetBOT Feb 14, 2026, 7:52 PM

#

That output is actually good news: it proves the Gateway is already running on 127.0.0.1:18789. The “not hatching” is because the wizard (or you) is trying to start a second gateway on the same port, and it refuses.

What to do now

Option A (recommended): keep the existing running gateway, don’t start another

Check it’s healthy:

openclaw gateway status

You want RPC probe: ok.

Check Telegram status:

openclaw channels status --probe

If Telegram still shows failed (404) Not Found, that means your bot token is wrong/invalid in the running gateway config. Fix token (don’t paste it here), then restart:

#

openclaw config set channels.telegram.botToken "<NEW_TOKEN>"
openclaw gateway restart
openclaw channels status --probe

Then DM the bot and approve pairing:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Option B: stop the running gateway so onboarding can “hatch” it itself

Stop the supervised service:

openclaw gateway stop

#

# or
systemctl --user stop openclaw-gateway.service

Then rerun onboarding.

If you paste only the output of:

openclaw gateway status
openclaw channels status --probe

(Ignore/redact any secrets), I can tell you exactly whether you’re past “hatch” and it’s now purely the Telegram token/pairing step.

sullen badger Feb 14, 2026, 7:54 PM

#

Gateway not reachable: Error: gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://"redacted"
Source: local loopback
Config: /home/ubuntu/.openclaw/openclaw.json
Bind: loopback
Gateway not reachable; showing config-only status.
Config: /home/ubuntu/.openclaw/openclaw.json
Mode: local

Telegram default: enabled, configured, mode:polling, token:config

Tip: status --deep adds gateway health probes to status output (requires a reachable gateway).

#

I got this after trying to reset token

rapid garnetBOT Feb 14, 2026, 7:55 PM

#

That 1006 abnormal closure means the CLI tried to open a WebSocket to the gateway on loopback and the connection got dropped without a clean close. In practice: the gateway process is crashing or not actually listening (this is separate from the Telegram setup).

Let’s get the real error from the gateway service.

1) Check if anything is listening on the gateway port

(default is 18789)

ss -ltnp | grep 18789 || true

2) Check the gateway service status + logs (most important)

If it’s a systemd user service:

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

#

If it’s a system service instead:

sudo systemctl status openclaw-gateway.service --no-pager
sudo journalctl -u openclaw-gateway.service -n 200 --no-pager

Copy/paste the part that shows the error/exit reason.

3) Quick restart attempt (after grabbing logs)

openclaw gateway restart
openclaw gateway status

4) If it keeps crashing: run it in the foreground to see the stack trace

Stop the service first so the port is free:

#

openclaw gateway stop

Then:

openclaw gateway --verbose

Once we can see the crash reason in the journal/foreground output, we can fix it. (Telegram “failed (404)” will be the next step after the gateway is reachable.)

#

Got it — and yep, changing the gateway token can make the Control UI/CLI lose access, but it should not make the gateway “disappear”. The 1006 abnormal closure usually means either:

the gateway process is crashing, or
the gateway is running but using a different config/token than your CLI (config mismatch).

Let’s confirm which one with 2 commands.

1) Show gateway supervisor + config mismatch info

Run and paste (it’s fine to redact tokens):

openclaw gateway status --deep

In that output, the key lines are:

Runtime: ...
RPC probe: ...
Config (cli): ...

#

Config (service): ...
Last gateway error: ... (if present)

2) Show the systemd logs (this reveals crashes)

Try:

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

(If it says user service not found, tell me, and we’ll use the sudo systemctl ... version.)

If it’s a config/token mismatch

The usual fix is:

openclaw gateway install --force

#

openclaw gateway restart

Paste openclaw gateway status --deep first and I’ll point at the exact line that’s wrong.

sullen badger Feb 14, 2026, 7:58 PM

#

Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-14.log
Command: /usr/bin/node /home/ubuntu/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT="redacted

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback "redacted" (service args)
Probe target: ws://"redacted"
Dashboard: "redacted"
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 13284, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: "Redacted"
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

rapid garnetBOT Feb 14, 2026, 7:59 PM

#

This output means your Gateway is actually fine and hatched:

Runtime: running
RPC probe: ok
Config CLI/service match

So the thing that’s “not coming online” at this point is almost certainly Telegram, not the gateway.

Next: check Telegram status (one command)

Run this on the AWS box and paste just the Telegram part:

openclaw channels status --probe

If it shows `Telegram: failed (404) Not Found`

That means the bot token is invalid (wrong/revoked/typo/whitespace). Fix is:

#

Set the new BotFather token in config (don’t paste it here):

openclaw config set channels.telegram.botToken "<NEW_TOKEN>"

Restart:

openclaw gateway restart

If it shows Telegram is OK/ready

Then you just need to pair:

DM the bot “hi” in Telegram
On the server:

#

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

Paste the telegram line(s) from openclaw channels status --probe and we’ll do the exact next step.

sullen badger Feb 14, 2026, 8:03 PM

#

Telegram default: enabled, configured, stopped, mode:polling, token:config, probe failed, error:Call to 'getMe' failed! (404: Not Found)

rapid garnetBOT Feb 14, 2026, 8:04 PM

#

Perfect — this is now 100% identified:

getMe failed (404: Not Found) means the Telegram bot token you configured is invalid (wrong token, revoked token, typo/whitespace, or you pasted the bot username instead of the token). It’s not an OpenClaw “hatching” problem.

Fix (don’t paste the token here)

In Telegram @BotFather:

/mybots → pick your bot → API Token
copy the token again (it looks like 123456:AA...)

On the AWS box, set it directly:

openclaw config set channels.telegram.botToken "<PASTE_TOKEN_HERE>"
openclaw gateway restart

Re-check:

#

openclaw channels status --probe

Telegram should switch to ready/connected.

Quick sanity check (run it, but don’t share the token)

This proves the token is valid from that server:

curl -sS "https://api.telegram.org/bot<PASTE_TOKEN_HERE>/getMe"

If the token is correct you’ll see "ok":true. If it’s wrong you’ll get the same 404.

After Telegram is “ready”

Then you do pairing:

DM the bot “hi”
then:

#

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

If you run the curl .../getMe and it still returns 404 even with a fresh copy from BotFather, tell me that (no token), because then you’re likely editing a different profile/instance than you think — but based on your gateway status --deep, config paths match, so it’s almost certainly just the token value.

sullen badger Feb 14, 2026, 8:06 PM

#

Telegram default: enabled, configured, stopped, mode:polling, token:config, probe failed, error:Call to 'getMe' failed! (404: Not Found)

rapid garnetBOT Feb 14, 2026, 8:07 PM

#

That exact status line means one thing:

Telegram is rejecting your bot token.
getMe (404: Not Found) is Telegram’s “invalid token” response.

OpenClaw can’t “hatch past” that — you have to get a valid token into the config.

Do this (don’t paste the token here)

In Telegram, open @BotFather → run:

/mybots → pick the bot you just created → API Token → Copy

On the AWS Ubuntu box, set it (this overwrites whatever is there):

openclaw config set channels.telegram.botToken "<PASTE_TOKEN_FROM_BOTFATHER>"
openclaw gateway restart

#

Prove the token works from that server (run locally, don’t share the token):

curl -sS "https://api.telegram.org/bot<PASTE_TOKEN_FROM_BOTFATHER>/getMe"

You need "ok":true. If you still get a 404 here, the token you pasted is not valid (most often: copied wrong, extra character, using bot username instead of token, or you revoked it and are still using the old one).

Then check OpenClaw:

openclaw channels status --probe

If curl shows ok:true but OpenClaw still shows 404

Then OpenClaw is not using the token you think. Run (and don’t paste the output if it includes the token):

openclaw config get channels.telegram.botToken

and make sure it matches exactly what you used in the curl.

#

If you tell me whether the curl /getMe returns ok:true or 404 (no token), I’ll tell you the next step immediately.

sullen badger Feb 14, 2026, 8:15 PM

#

I know I'm putting in the right token

#

it still says false

rapid garnetBOT Feb 14, 2026, 8:15 PM

#

I believe you — but Telegram is pretty unforgiving here: getMe → 404 Not Found only happens when the request is using an invalid bot token (or you’re not actually reaching Telegram’s real API endpoint). OpenClaw is just reporting what Telegram answered.

Let’s make it factual with one definitive test that doesn’t involve OpenClaw:

1) Prove the token works from that AWS box

On the Ubuntu instance, run this (don’t paste the token here; only paste the output):

curl -sS "https://api.telegram.org/bot<YOUR_TOKEN>/getMe"

Paste the JSON it prints.

If you see "ok": true → the token is valid, and OpenClaw is somehow not using the same token.
If you see "ok": false, "error_code": 404 → the token is not valid (even if it looks right). Common causes: copied the old token after /revoke, a hidden extra character/space, or you’re looking at a different bot in BotFather.

2) If curl is ok:true but OpenClaw still says 404

#

Then OpenClaw is not reading the token you think. Run (and don’t paste the output, just compare locally):

openclaw config get channels.telegram.botToken

and make sure it matches exactly what you used in the curl command. Then:

openclaw gateway restart
openclaw channels status --probe

Reply with the curl JSON output and we’ll take the correct branch immediately.

#

If the curl .../getMe response is "ok": false, then Telegram is not accepting the token in that request. OpenClaw can’t fix that part — it’s upstream.

Can you paste the exact JSON output from curl (it won’t include your token), especially the error_code + description?

Example command (make sure you replace the token and don’t include < > literally):

TOKEN='123456:AA...'
curl -sS "https://api.telegram.org/bot${TOKEN}/getMe"

If the output is `404 Not Found`

That means you are still not using the current valid token. The most common “I’m sure it’s right” causes are:

You accidentally pasted the placeholder (still contains <YOUR_TOKEN>) or included angle brackets/spaces.
You copied an old token after doing /revoke (only the newest token works).
Hidden whitespace/newline snuck in (rare, but happens). Quick check:

#

python3 - <<'PY'
import os
t=os.environ.get("TOKEN","")
print("len=",len(t))
print(repr(t))
PY

(or just re-paste carefully into the TOKEN='...' line)

After curl returns `"ok": true`

Then OpenClaw will immediately stop showing the 404 once you set the same token and restart:

openclaw config set channels.telegram.botToken "<NEW_TOKEN>"
openclaw gateway restart

#

openclaw channels status --probe

Paste the curl JSON output and we’ll pin down which case you’re in.

sullen badger Feb 14, 2026, 8:20 PM

#

"ok":true,"result":{"id":"redacted","is_bot":true,"first_name":"Fayethom","username":"Fayethom_bot","can_join_groups":true,"can_read_all_group_messages":false,"supports_inline_queries":false,"can_connect_to_business":false,"has_main_web_app":false,"has_topics_enabled":false,"allows_users_to_create_topics":false}}

rapid garnetBOT Feb 14, 2026, 8:21 PM

#

Nice — that curl .../getMe output means the token is valid and reachable from the AWS box. So networking is fine, and the bot exists.

If OpenClaw is still showing getMe failed (404), then OpenClaw is not using the same token you just tested (usually because it wasn’t saved where the running gateway reads it, or the gateway hasn’t been restarted since the change).

Do this on the AWS box (don’t paste the token here):

1) Force-set the token into OpenClaw config

openclaw config set channels.telegram.botToken "<THE_SAME_TOKEN_YOU_USED_IN_CURL>"

2) Restart the gateway (Telegram token changes require restart)

openclaw gateway restart

3) Re-probe Telegram

#

openclaw channels status --probe

It should switch away from stopped … getMe failed (404) to something like ready/connected.

If it STILL says 404 after that

Run this and paste the output with the token redacted:

openclaw config get channels.telegram

I’m specifically looking for whether you accidentally have two places a token can live (e.g. tokenFile or accounts) and OpenClaw is reading the old one.

Once Telegram probes clean, the last step is pairing:

DM the bot “hi”
openclaw pairing list telegram

#

openclaw pairing approve telegram <CODE>

sullen badger Feb 14, 2026, 8:23 PM

#

Finally - Telegram default: enabled, configured, running, mode:polling, bot:@Fayethom_bot, token:config, works

rapid garnetBOT Feb 14, 2026, 8:24 PM

#

Hell yes — that means Telegram is connected and healthy now. You’re past the “hatch” problem.

Last step: pairing (so it will actually reply to you in DMs).

From your personal Telegram account, DM @Fayethom_bot (send “hi”).
On the AWS box:

openclaw pairing list telegram

Approve the pending code:

openclaw pairing approve telegram <CODE>

After that, DM the bot again and it should respond.

#

If this fixed it, please mark the solution (right-click the message → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

sullen badger Feb 14, 2026, 8:26 PM

#

now the bot on telegram is not getting a pairing code

rapid garnetBOT Feb 14, 2026, 8:27 PM

#

Two key clarifications:

The pairing code does not show up inside Telegram.
It shows up on the server when you run: openclaw pairing list telegram

So let’s do a tight checklist.

1) Confirm you’re actually in pairing mode

On the AWS box:

openclaw config get channels.telegram.dmPolicy

It must be "pairing" (not allowlist / open).

2) Watch logs, then DM the bot

On the AWS box (leave this running):

#

openclaw logs --follow

Now in Telegram, DM @Fayethom_bot and send /start (not just “hi”).

You should see an inbound Telegram update in the logs. If you see nothing in logs, the gateway isn’t receiving your DMs (wrong chat, wrong bot, or something else consuming updates).

3) List pending pairing requests

Back on the AWS box:

openclaw pairing list telegram

If a code appears:

#

openclaw pairing approve telegram <CODE>

If `pairing list telegram` is still empty

Paste the few log lines that appear right after you send /start (no secrets). That will tell us whether:

the DM is arriving but being dropped for a policy reason, or
the DM isn’t arriving at all (most often: you’re messaging a different bot than the token in config, or another process is consuming updates).

(Quick sanity check if needed: make sure the bot username in Telegram matches what OpenClaw reports: bot:@Fayethom_bot.)

sullen badger Feb 14, 2026, 8:29 PM

#

no answer on anything

rapid garnetBOT Feb 14, 2026, 8:30 PM

#

If you’re seeing “Telegram … works” but getting no reply + no pairing code, it’s almost always one of these:

you’re messaging the bot in a group (by default groups require a mention and are often allowlisted), not a DM, or
your DM policy isn’t actually pairing (wizard often sets Telegram DMs to allowlist), or
the gateway is receiving nothing inbound (we can confirm via logs in 10 seconds).

Let’s make it deterministic.

Step 1: Are you DMing the bot (not a group)?

Open Telegram and DM @Fayethom_bot directly and send /start.

If you’re testing inside a group, the bot will usually stay silent unless configured (require mention + group allowlist).

Step 2: Confirm DM policy + check for a pending pairing (paste outputs)

On the Ubuntu box:

#

openclaw config get channels.telegram.dmPolicy
openclaw pairing list telegram

If dmPolicy is allowlist → pairing will never appear; you must add yourself to allowFrom or switch back to pairing/open.
If dmPolicy is pairing and pairing list is empty → the DM isn’t reaching the gateway (or you’re not DMing that bot).

Step 3: Watch inbound logs while you DM (this is the real truth)

Run this and keep it open:

openclaw logs --follow

Then DM /start again.
Tell me: do you see any log line when you send the DM?

#

If you see inbound logs but no pairing

Paste the relevant log lines (redact IDs if you want). It’ll usually say “pairing required / blocked / dropped” etc.

If you see no inbound logs at all

Then you’re not actually talking to the same bot token OpenClaw is polling (wrong bot/chat), or the polling runner is stuck (rare, but logs will show errors).

Quick temporary test (only if you’re stuck)

This makes the bot reply to anyone in DMs (use briefly, then revert):

openclaw config set channels.telegram.dmPolicy open
openclaw config set channels.telegram.allowFrom '["*"]' --json
openclaw gateway restart

Then DM it “hi” and it should respond immediately. (After confirming, switch back to pairing or allowlist.)

#

Reply with:

output of openclaw config get channels.telegram.dmPolicy
output of openclaw pairing list telegram
and whether openclaw logs --follow shows anything when you DM /start

sullen badger Feb 14, 2026, 8:49 PM

#

Okay, I just checked and it is the right bot

#

but still is not giving a pair code

rapid garnetBOT Feb 14, 2026, 8:50 PM

#

Good — then the remaining question is: is OpenClaw waiting for pairing, or is it silently blocking you via allowlist? The onboarding wizard often sets Telegram DMs to allowlist (so you’ll never see a pairing code).

Run these on the AWS box and paste the outputs (no secrets in these):

openclaw config get channels.telegram.dmPolicy
openclaw config get channels.telegram.allowFrom
openclaw pairing list telegram

If `dmPolicy` is `allowlist`

That’s why there’s no pairing code. Easiest fix: switch back to pairing:

openclaw config set channels.telegram.dmPolicy pairing
openclaw gateway restart

#

Then DM the bot /start, and run:

openclaw pairing list telegram
openclaw pairing approve telegram <CODE>

If `dmPolicy` is already `pairing` but `pairing list` is empty

Then the gateway isn’t seeing your DM. Do this:

openclaw logs --follow

Leave it running, DM /start again, and paste the log lines that appear right after. That will show whether it’s receiving the message and dropping it (policy), or not receiving anything (wrong chat/bot, webhook conflict, etc.).

#

If you’re DM’ing the right bot and you still get no pairing code, it’s usually one of these:

Telegram DMs are actually set to allowlist (so OpenClaw will ignore you, and no pairing request is created)
the bot has a webhook enabled, so long-polling won’t receive your DMs
another process is consuming updates for that bot token (less common, but logs will show “conflict”)

Do these checks on the AWS box (don’t paste any tokens):

1) Confirm DM policy (this is the #1 cause)

openclaw config get channels.telegram.dmPolicy
openclaw config get channels.telegram.allowFrom
openclaw pairing list telegram

If dmPolicy is allowlist → that’s why there’s no pairing code. Switch to pairing:

#

openclaw config set channels.telegram.dmPolicy pairing
openclaw gateway restart

Then DM the bot /start and re-run openclaw pairing list telegram.

2) Verify OpenClaw is actually receiving your DM (truth serum)

In one terminal:

openclaw logs --follow

Then DM the bot /start.

If nothing appears in logs when you DM, the gateway isn’t receiving updates → do #3.

3) Check for webhook mode being active (very common)

Run locally (don’t share token), but this output is safe to paste:

#

TOKEN='...'
curl -sS "https://api.telegram.org/bot${TOKEN}/getWebhookInfo"

If it shows a non-empty "url" → webhook is on. Disable it:

curl -sS "https://api.telegram.org/bot${TOKEN}/deleteWebhook?drop_pending_updates=true"

Then:

openclaw gateway restart

And try DM /start again.

Send back the outputs of:

openclaw config get channels.telegram.dmPolicy

#

openclaw pairing list telegram
and the JSON from getWebhookInfo

…and we’ll pin it down immediately.

sullen badger Feb 14, 2026, 8:52 PM

#

no change. the bot still has no code

rapid garnetBOT Feb 14, 2026, 8:53 PM

#

“No change” usually means one of two things is happening:

You’re expecting the pairing code to appear in Telegram (it usually won’t). The code shows up when you run openclaw pairing list telegram on the server.
OpenClaw is not creating a pairing request at all (policy/webhook/it’s not seeing your DM).

Let’s pin it down with exact outputs.

Run these 3 commands on the AWS box and paste the output

(no tokens involved)

openclaw config get channels.telegram.dmPolicy
openclaw pairing list telegram
openclaw logs --follow --max-bytes 200000

Then, while logs --follow is running, DM the bot in Telegram (private DM, not a group) and send:

#

/start

What I’m looking for

If pairing list telegram shows a code → you approve it:

openclaw pairing approve telegram <CODE>

If pairing list telegram is empty, then check the logs output right when you send /start:
If logs show the DM arriving but then “dropped/blocked” → it’s a policy config issue (we’ll fix based on the exact log line).
If logs show nothing at all → Telegram updates aren’t reaching OpenClaw (most often: webhook is set).

Quick webhook check (often the culprit)

Run this locally (don’t paste token), but paste the JSON output:

curl -sS "https://api.telegram.org/bot<YOUR_TOKEN>/getWebhookInfo"

#

If it shows a non-empty "url", disable it:

curl -sS "https://api.telegram.org/bot<YOUR_TOKEN>/deleteWebhook?drop_pending_updates=true"
openclaw gateway restart

Paste:

dmPolicy output
pairing list output
and the getWebhookInfo JSON
…and I’ll tell you the exact next step.

sullen badger Feb 14, 2026, 8:58 PM

#

{"ok":false,"error_code":404,"description":"Not Found"}ubuntu@ip^C

rapid garnetBOT Feb 14, 2026, 8:59 PM

#

That JSON:

{"ok":false,"error_code":404,"description":"Not Found"}

means the token used in that curl command was invalid (Telegram only returns 404 like that when the /bot<TOKEN>/... part is wrong/revoked/typo). Since you previously got getMe -> ok:true, you’re almost certainly testing with two different tokens (easy to do when you’ve nuked/recreated bots a few times).

Let’s force the terminal to use the exact same token OpenClaw is using, without you copy/pasting it:

1) Run these (safe to paste outputs; they won’t include the token)

TOKEN=$(openclaw config get channels.telegram.botToken | tr -d '"')

curl -sS "https://api.telegram.org/bot${TOKEN}/getMe"
curl -sS "https://api.telegram.org/bot${TOKEN}/getWebhookInfo"

#

Paste both JSON outputs here.

2) If `getWebhookInfo` shows a non-empty `"url"`

Disable the webhook (webhook breaks polling):

curl -sS "https://api.telegram.org/bot${TOKEN}/deleteWebhook?drop_pending_updates=true"
openclaw gateway restart

3) Then pairing (important: code is NOT shown in Telegram)

DM the bot /start
on the server:

openclaw config get channels.telegram.dmPolicy
openclaw pairing list telegram

#

If you paste the two curl outputs + dmPolicy, I can tell you the exact next step.

#

That {"ok":false,"error_code":404,"description":"Not Found"} is Telegram saying “invalid token for this request.” At this point the most likely thing is you’re still running the curl with a placeholder / old token (easy to do after nuking/recreating bots).

Do this exactly on the AWS box — it pulls the token from your OpenClaw config so there’s no copy/paste mismatch, and it won’t print the token:

TOKEN=$(openclaw config get channels.telegram.botToken | sed -e 's/^"//' -e 's/"$//')
curl -sS "https://api.telegram.org/bot${TOKEN}/getMe"

Paste the output JSON.

If that returns `ok:true`

Now check webhook (this is a common reason for “no pairing code / no inbound” even though token is valid):

curl -sS "https://api.telegram.org/bot${TOKEN}/getWebhookInfo"

#

If "url" is not empty, disable webhook and restart OpenClaw:

curl -sS "https://api.telegram.org/bot${TOKEN}/deleteWebhook?drop_pending_updates=true"
openclaw gateway restart

Then do pairing (code is NOT shown in Telegram; it’s in the CLI)

DM the bot /start (private DM, not a group)
On the server:

openclaw config get channels.telegram.dmPolicy
openclaw pairing list telegram

Paste those two outputs too.

(Also: if you’ve spammed /start a bunch, pairing requests are capped; pairing list will still show the existing code — you just approve it.)

sullen badger Feb 14, 2026, 9:03 PM

#

No pairing requests

rapid garnetBOT Feb 14, 2026, 9:04 PM

#

“No pairing requests” narrows it down a lot. It means OpenClaw is not creating a DM pairing request when you message the bot. That happens in only a few cases:

DM policy isn’t actually pairing (wizard often sets Telegram DMs to allowlist)
You’re already allowed (so no pairing request is needed)
The gateway isn’t seeing your DM at all (webhook/conflict would usually show, but we’ll confirm via logs)
You messaged it before it was running, and you haven’t sent a fresh DM since

Do this exact sequence on the AWS box:

1) Show DM policy + allowlist

openclaw config get channels.telegram.dmPolicy
openclaw config get channels.telegram.allowFrom

2) Tail logs and then DM the bot `/start`

In one terminal:

#

openclaw logs --follow

Now on Telegram (private DM to @Fayethom_bot), send:

/start

You should see some “telegram inbound/update” log line when you do that.

3) Immediately list pairing requests

openclaw pairing list telegram

What the results mean

If dmPolicy is allowlist → there will be no pairing code. Fix:

#

openclaw config set channels.telegram.dmPolicy pairing
openclaw gateway restart

then DM /start again and re-run pairing list.

If logs show nothing at all when you DM /start → paste the last ~20 log lines around that moment (no secrets). That means the gateway isn’t receiving your DM.
If logs show your DM arrived but pairing list is still empty → paste the log lines; it’ll usually say why it didn’t create a pairing request.

If you paste the outputs of the two config get ... commands plus the few log lines that appear right after you DM /start, I can tell you the exact fix in one step.

sullen badger Feb 14, 2026, 9:05 PM

#

Config path not found: channels.telegram.allowFrom

rapid garnetBOT Feb 14, 2026, 9:05 PM

#

That error just means allowFrom isn’t set in your config right now (not that Telegram is broken). openclaw config get will complain if the path doesn’t exist.

Two important cases:

Case A (recommended): use pairing (no `allowFrom` needed)

Check what your DM policy actually is:

openclaw config get channels.telegram.dmPolicy

If it’s not pairing, set it and restart:

openclaw config set channels.telegram.dmPolicy pairing
openclaw gateway restart

#

Then DM the bot /start and run:

openclaw pairing list telegram

(That’s where the code appears — not inside Telegram.)

Case B: you’re on allowlist mode (then `allowFrom` must be set)

If dmPolicy comes back as allowlist, and allowFrom is missing, then nobody is allowed to DM, so you’ll never get a pairing request and the bot won’t reply.

Quick fix is still: switch to pairing (Case A). If you really want allowlist, we can add your Telegram ID to channels.telegram.allowFrom, but you’ll need your numeric Telegram user id first.

If pairing still doesn’t show anything

Run:

#

openclaw logs --follow

Then DM /start again and see if anything shows up in logs. If nothing appears, the gateway isn’t receiving your DM.

Reply with the output of openclaw config get channels.telegram.dmPolicy and we’ll take the right branch.

sullen badger Feb 14, 2026, 9:08 PM

#

nothing

#

no change

#

I quit. I guess I don't need another bot.

rapid garnetBOT Feb 14, 2026, 9:11 PM

#

If openclaw pairing list telegram shows no requests, then OpenClaw is either:

not in DM pairing mode, or
not receiving your DMs (webhook still set is the #1 cause), or
receiving them but dropping them (logs will say why).

Run these on the AWS box (don’t paste tokens):

1) Force DM policy to pairing (removes ambiguity)

openclaw config set channels.telegram.dmPolicy pairing
openclaw gateway restart

Now DM the bot /start again, then:

#

openclaw pairing list telegram

2) Check if a Telegram webhook is enabled (breaks polling)

This uses the token from your config (no copy/paste mismatch):

TOKEN=$(openclaw config get channels.telegram.botToken | sed -e 's/^"//' -e 's/"$//')
curl -sS "https://api.telegram.org/bot${TOKEN}/getWebhookInfo"

If the JSON contains a non-empty "url", disable webhook:

curl -sS "https://api.telegram.org/bot${TOKEN}/deleteWebhook?drop_pending_updates=true"
openclaw gateway restart

#

Then DM /start again and re-run openclaw pairing list telegram.

3) If still nothing: check logs while you DM

openclaw logs --follow

DM /start, then paste the first relevant log lines that appear right after (no secrets).

If you paste the getWebhookInfo JSON (safe) + what openclaw config get channels.telegram.dmPolicy prints, I can tell you exactly which branch you’re on.

#

Ok — if there are no pairing requests, the gateway is either not seeing your DM at all, or it’s seeing it but something else is blocking it. We need one hard piece of evidence: the gateway log line when you send /start.

1) Check if Telegram has a webhook set (this breaks polling)

Run this on the AWS box (it pulls the token from your config; no copy/paste mismatch):

TOKEN=$(openclaw config get channels.telegram.botToken | sed -e 's/^"//' -e 's/"$//')
curl -sS "https://api.telegram.org/bot${TOKEN}/getWebhookInfo"

If that JSON shows a non-empty "url", disable it:

curl -sS "https://api.telegram.org/bot${TOKEN}/deleteWebhook?drop_pending_updates=true"
openclaw gateway restart

#

Fair — this stuff is exhausting.

If you ever take one more swing at it, the shortest “one-shot” fix is:

Make sure Telegram token is valid (you already did: getMe -> ok:true)
Ensure no webhook is set (this is the silent killer for polling):

TOKEN=$(openclaw config get channels.telegram.botToken | sed -e 's/^"//' -e 's/"$//')
curl -sS "https://api.telegram.org/bot${TOKEN}/deleteWebhook?drop_pending_updates=true"
openclaw gateway restart

DM the bot /start, then:

openclaw pairing list telegram

If that still shows nothing, it’s 100% in the logs (openclaw logs --follow right as you DM /start).

#

No pressure — but if you paste just the getWebhookInfo JSON next time (safe to share), we can usually finish in one message.

#

2) Prove the gateway is receiving your DM (most important)

Run:

openclaw logs --follow --max-bytes 200000

Now DM the bot in Telegram (private DM) and send /start.

Within a second or two you should see log activity. Hit Ctrl+C and paste the last ~30 lines here (redact IDs if you want, but keep the text).

3) Then re-check pairing list

openclaw pairing list telegram

Right now we’re blind without the logs: if the logs show no inbound Telegram update, it’s webhook/conflict; if they show inbound but “blocked”, it’s DM policy/allowlist.

#install issues

1) Quick sanity checks (paste output here; redact tokens)

2) If you’re running two gateways on the same machine

3) Telegram gotcha (very common)

4) One question so I can aim this properly

What to do on the 2nd AWS instance

If pairing list telegram stays empty (most common causes)

0) You just leaked your bot token — rotate it now

1) There is no “auth telegram id prompt” — pairing happens after you DM the bot

2) If pairing list telegram stays empty, it means the gateway isn’t receiving updates

A) Same bot token is still running somewhere else

B) Network/DNS can’t reach Telegram from that AWS box

C) Service is running with a different config than the CLI

Step A — Fix the leaked token first

Step B — Verify the gateway is actually running

Step C — Verify Telegram is connected (without pasting secrets)

Step D — Trigger pairing the only way it can happen

If Step D shows nothing (pairing list empty)

1) Make sure you’re talking to the real BotFather

2) Check that the bot exists and is yours

3) Rotate token via the button flow (don’t type the token)

4) Fastest workaround: just create a fresh bot

1) Put the new token into OpenClaw (don’t paste it here)

2) Confirm Telegram is actually up

3) Trigger pairing

4) If pairing list telegram is empty

Reinstall the Gateway service/daemon (most common fix)

Reinstall the OpenClaw CLI itself

1) Reinstall the gateway service (usually what you want)

2) Reinstall the OpenClaw CLI (if the install itself is broken)

Do this exact 2‑minute test on the Ubuntu AWS box (2nd instance)

1) Confirm the service is using the config you edited

2) Confirm Telegram channel is up

3) Watch logs, then DM the bot

Interpreting the result

1) Run the wizard

2) After the wizard: verify the gateway is actually running

3) Trigger pairing (this is the step most people miss)

If onboarding “works” but Telegram still never shows a pairing request

What it is

What you should do

If you think the token might be compromised

1) Is the Gateway actually running?

2) Is Telegram connected?

3) Is it just not replying because pairing isn’t approved?

The two most common “it never comes online” causes (especially on AWS)

If you’re in the onboarding wizard TUI

If you’re stuck and need to exit the TUI

1) Open a 2nd SSH/terminal to the same Ubuntu box and run

If it says Runtime: running + RPC probe: ok

If it says Runtime: stopped or RPC probe: failed

2) Quick “bypass the daemon” test (proves if the gateway can start at all)

3) Common Ubuntu/AWS daemon gotcha

1) See what the service thinks is happening

2) Let doctor repair the common Linux daemon issues automatically

3) Try starting the gateway again

4) If it still won’t hatch: run the gateway in the foreground to get the real error

1) Make sure the Gateway is running first

2) Verify what token OpenClaw thinks it has (DO NOT paste output)

3) Prove the token works from that AWS machine (safe output)

What to do now

Option A (recommended): keep the existing running gateway, don’t start another

Option B: stop the running gateway so onboarding can “hatch” it itself

1) Check if anything is listening on the gateway port

2) Check the gateway service status + logs (most important)

3) Quick restart attempt (after grabbing logs)

4) If it keeps crashing: run it in the foreground to see the stack trace

1) Show gateway supervisor + config mismatch info

2) Show the systemd logs (this reveals crashes)

If it’s a config/token mismatch

Next: check Telegram status (one command)

If it shows Telegram: failed (404) Not Found

If it shows Telegram is OK/ready

Fix (don’t paste the token here)

Quick sanity check (run it, but don’t share the token)

After Telegram is “ready”

Do this (don’t paste the token here)

If curl shows ok:true but OpenClaw still shows 404

1) Prove the token works from that AWS box

2) If curl is ok:true but OpenClaw still says 404

If `pairing list telegram` stays empty (most common causes)

2) If `pairing list telegram` stays empty, it means the gateway isn’t receiving updates

4) If `pairing list telegram` is empty

If it says `Runtime: running` + `RPC probe: ok`

If it says `Runtime: stopped` or `RPC probe: failed`

If it shows `Telegram: failed (404) Not Found`

If the output is `404 Not Found`

After curl returns `"ok": true`

If `pairing list telegram` is still empty

If `dmPolicy` is `allowlist`

If `dmPolicy` is already `pairing` but `pairing list` is empty

2) If `getWebhookInfo` shows a non-empty `"url"`

If that returns `ok:true`

2) Tail logs and then DM the bot `/start`

Case A (recommended): use pairing (no `allowFrom` needed)

Case B: you’re on allowlist mode (then `allowFrom` must be set)