#simple telegram bot token rotation --> Telegram 401 and no success fixing

1 messages · Page 1 of 1 (latest)

strong path
#

After rotating my Telegram bot token, I updated ~/.openclaw/.env with the new token. Gateway restarts are not picking it up — still getting 401 Unauthorized on deleteWebhook every retry cycle.

What I've tried:

Updated TELEGRAM_BOT_TOKEN in ~/.openclaw/.env
openclaw secrets reload → says reloaded, no unresolved refs
openclaw gateway restart → Telegram still 401s on next attempt
Status output shows:

Copy
│ Telegram │ ON │ WARN │ token env (8612…jnww · len 46)
Token length 46, correct <id>:<hash> format, colon present, numeric ID.

Log error (repeating, auto-restart loop):

Copy
telegram deleteWebhook failed: Call to 'deleteWebhook' failed! (401: Unauthorized)
[default] channel exited: Call to 'deleteWebhook' failed! (401: Unauthorized)
[default] auto-restart attempt N/10 in Xs
My openclaw.json telegram section has NO token field — token comes entirely from .env. No hardcoded values.

Questions:

Does secrets reload actually hot-swap the Telegram token, or does it require a full gateway restart?
Is there a way to force the channel to re-read the token without a full restart?
Could the old token still be cached somewhere other than .env or openclaw.json?
OpenClaw version: (run openclaw --version and add it)
Node: 24.14.1 / macOS Darwin 25.4.0 arm64

magic kilnBOT
broken gladeBOT
#

Let me verify this against the actual docs and code path for Telegram config loading.

#

I found the important bit: runtime secrets reload swaps the active snapshot, but the .env loader is additive only. I’m checking whether macOS service installs can also keep an older token in the service environment, which would explain why even a restart still shows the old one.

#

Short answer, yes, this smells like stale process/service env, not Telegram-specific caching.

  1. openclaw secrets reload

    • It re-resolves the active runtime snapshot.
    • It does not hot-swap a changed ~/.openclaw/.env value if TELEGRAM_BOT_TOKEN is already present in the running process env.
    • In current code, .env loading is additive, it fills missing vars, it does not overwrite existing ones.

  2. Force re-read without full restart

    • For a plain .env token change, not really.
    • If you run the gateway as a managed macOS service, the old token can still live in the launchd service environment.
    • Best fix is:
openclaw --version
openclaw gateway status --deep
openclaw gateway install --force
# 
openclaw gateway restart
  1. Could the old token be cached elsewhere?
    Yes:
    • the running gateway process env
    • the macOS LaunchAgent/service env
    • a profile/state-dir mismatch where CLI and service use different ~/.openclaw roots
    • also, TELEGRAM_BOT_TOKEN env fallback is for the default Telegram account only

A couple of important notes:

  • 401 Unauthorized on deleteWebhook means Telegram is rejecting the token actually being sent.
  • So if restart alone did not help, the most likely cause is that the service is still launching with the old env, or the rotated token itself is not the one for that bot.

Docs:

strong path
#

finally found a fix: sharing in case it helps someone else. also some suggestion for openclaw.

What Happened
Root cause: The LaunchAgent plist (~/Library/LaunchAgents/ai.openclaw.gateway.plist) bakes all env vars in at install time. The gateway reads from the plist, not .env directly. When you rotated the Telegram token in .env, the plist still had the old token — so every gateway restart kept using the stale one. secrets reload and openclaw gateway restart both do NOT regenerate the plist.

Why it was hard to find: openclaw status showed the token was coming from env (token env (*********), which looked correct. Nothing in the logs pointed to "plist has old value."

Prevention: Two Options
Option A — Update rotate-keys.sh yourself (recommended)
Add plist sync to the script. Run this to see what's in it first:

Copy
cat ~/.openclaw/scripts/rotate-keys.sh
Then add this block before the gateway restart step:

Copy

Sync .env values into LaunchAgent plist

PLIST=~/Library/LaunchAgents/ai.openclaw.gateway.plist
while IFS='=' read -r key value; do
[[ "$key" =~ ^# ]] && continue
[[ -z "$key" ]] && continue
/usr/libexec/PlistBuddy -c "Set :EnvironmentVariables:$key $value" "$PLIST" 2>/dev/null
done < ~/.openclaw/.env
Option B — One-liner alias to always fix it manually
Add to ~/.zshrc:

Copy
alias ocrotate-full='~/.openclaw/scripts/rotate-keys.sh && NEW_TOKEN=$(grep "^TELEGRAM_BOT_TOKEN=" ~/.openclaw/.env | cut -d= -f2) && /usr/libexec/PlistBuddy -c "Set :EnvironmentVariables:TELEGRAM_BOT_TOKEN $NEW_TOKEN" ~/Library/LaunchAgents/ai.openclaw.gateway.plist && launchctl unload ~/Library/LaunchAgents/ai.openclaw.gateway.plist && launchctl load ~/Library/LaunchAgents/ai.openclaw.gateway.plist'
Also worth reporting to OpenClaw
This is a bug in openclaw gateway restart — it should regenerate/sync the plist from .env before reloading. Worth filing at https://github.com/openclaw/openclaw or posting in Discord so they fix it in a future release.

broken gladeBOT
#

Nice catch, yep, that’s the failure mode.

For future readers, I’d avoid editing the plist directly. The supported fix is:

openclaw gateway install --force
openclaw gateway restart

That rewrites the managed service metadata from the current ~/.openclaw/.env, then restarts it.

So the behavior is basically:

  • openclaw secrets reload = refreshes runtime secrets snapshot, does not rebuild service env
  • openclaw gateway restart = restarts the service, using whatever env the service already has
  • openclaw gateway install --force + restart = refreshes the LaunchAgent/service env
#

This also lines up with the FAQ note that daemons read env from ~/.openclaw/.env or the service environment, and with the config mismatch fix path.

Docs:

I do agree the logging/status could make this a lot clearer. If you want maintainer eyes on it, please file a GitHub issue here:
https://github.com/openclaw/openclaw/issues

Suggested issue title:
gateway restart does not refresh LaunchAgent env from ~/.openclaw/.env

Glad you found it, that’s a sneaky one. 🦐

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index it for the next person.

strong path
#

thank you

broken gladeBOT
#

Anytime, glad you tracked it down 🙂