#Is the bot hallucinating or does someone else have access to my openclaw bot?

1 messages · Page 1 of 1 (latest)

fallow ermineBOT
#

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

muted matrixBOT
#

That doesn’t sound like a “model hallucination” so much as your UI showing something that already exists in your local state/session, or you’re seeing verbose/internal prompt formatting.

The three most common causes:

  1. You re-opened an old session (history on disk)
  • A “fresh reinstall” usually does not delete your state dir (~/.openclaw by default), and session transcripts are persisted.
  • The Control UI / web TUI will often reconnect to the last active session, so an old line can “appear” even though nobody just sent it.
  1. Verbose/reasoning is enabled, so you see internal prompt-ish text
  • That exact Human: / Assistant: style is commonly what you see when verbose output is on.
  • In the web chat where you saw it, try:
/verbose off
/reasoning off
#
  1. Someone has access to your Control UI (token leak / gateway exposed)
    This is rarer on a MacBook unless you:
  • bound the gateway to LAN/tailnet, or
  • shared a dashboard URL/token (screenshots count), or
  • are running behind a proxy with auth misconfig.

Quick “is this just history?” test

  • In that same chat, send: /new (fresh session).
  • If the weird “Human: …” line stops appearing, it was almost certainly old session/verbose noise.

If you want to be absolutely sure it’s not external access

Run these and paste output (they’re safe/redacted):

openclaw --version
openclaw gateway status
openclaw status --all
# 
openclaw security audit --deep

And if there’s any chance the token was exposed, rotate it (don’t paste the new value):

openclaw config set gateway.auth.token "$(openssl rand -hex 32)"
openclaw gateway restart

Nuclear option (wipes state)

If you truly want “fresh means fresh”, use:

openclaw reset

(That will remove sessions/creds/workspace depending on scope—read the prompts carefully.)

#

If you reply with openclaw gateway status + whether /verbose was on in the UI, I can usually tell which bucket this is in within one message.

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

#

Your gateway status output is actually very reassuring:

  • bind=loopback (127.0.0.1) and Listening: 127.0.0.1:18789
  • “Loopback-only gateway; only local clients can connect.”
  • RPC probe: ok

So nobody on the network / internet can be “typing into your gateway” unless they already have local access to your Mac (same machine).

What you saw in WebChat is almost certainly one of these:

1) Old session history got reused (most likely)

A reinstall doesn’t necessarily wipe ~/.openclaw (state + sessions). WebChat fetches history from the gateway, so if you reconnect to the agent’s main session you can see older “Human:” entries.

Docs note that session logs live on disk and persist:
https://docs.openclaw.ai/gateway/security (see “Local session logs live on disk”)

2) WebChat is showing cross-channel context in the agent’s main session

#

WebChat defaults to the selected agent’s main session, which can include messages that came in via other channels for that agent. From the docs:

“WebChat … defaults to the agent’s main session. Because of this, WebChat lets you see cross‑channel context for that agent in one place.”
https://docs.openclaw.ai/channels/channel-routing#webchat-behavior

So if you had (say) Discord/Telegram configured and someone messaged there (or an old message replayed), it can show up in WebChat history.

3) Verbose/reasoning made internal formatting visible

In the chat UI where you saw it, try:

/verbose off
/reasoning off
/new

(That last one is the clean test: new session, no old transcript.)

#

Quick “prove where it came from” check (on your Mac)

Search your local session transcripts for that exact line:

grep -Rni "config update to enable gateway restart" ~/.openclaw/agents | head -20

That will tell you which agent + which transcript file contains it (so it’s not a random external injection).

If you want a truly clean slate

This is the official “wipe state and start over” path:

openclaw reset
buoyant oyster
#

Just right now it also responded with:

"Human: Conversation info (untrusted metadata):
{
"conversation_label": "d2o (@lovekiut) id:5895844598"
}
Thanks for updating that. I really appreciate that. It would be great if you can setup a cron job to run every day at 8:30 AM local time (Asia/Saigon) to check for reminders in my Apple Reminders app and let me know if there's anything coming up. Thanks."

And this isn't something I requested from it.

muted matrixBOT
#

With that gateway status (loopback-only), this is almost certainly not “someone got into your gateway UI from the internet.” If it were remote access, you’d typically see bind=lan/tailnet or a non-127.0.0.1 listener.

What you pasted does strongly suggest something else though:

  • id:5895844598 + (@lovekiut) looks like a real DM sender identity from a channel (very Telegram‑ish).
  • WebChat defaults to the agent’s main session, and DMs across channels often collapse into that same main session, so you can “see” inbound stuff there even if it came from Telegram/Discord DM.
    Docs: https://docs.openclaw.ai/channels/channel-routing#webchat-behavior

So the most likely explanation is: your bot is receiving real DMs from another account you didn’t intend to authorize, and WebChat is showing that history (sometimes with the Human: prefix because that’s how the model/session transcript ended up storing it, or because verbose was on at some point).

Do these 3 checks (all read-only)

  1. See if you accidentally have open DM access
openclaw config get channels.telegram.dmPolicy
openclaw config get channels.telegram.allowFrom
openclaw config get channels.discord.dm.policy
# 
openclaw config get channels.discord.dm.allowFrom

If you see dmPolicy: "open" or allowFrom containing "*", that’s the smoking gun.

  1. List who is currently paired/allowlisted (DM access)
    Pairing state lives here (safe to inspect, don’t post it publicly if it contains IDs you consider sensitive):
  1. Check whether any unknown cron jobs already exist
openclaw cron list

Cron persists under ~/.openclaw/cron/, so if you re-used an old ~/.openclaw, old jobs can still be around.
Docs: https://docs.openclaw.ai/cli/cron

#

Fast way to identify the source next time it happens

Run this in a terminal, then reproduce the weird message in WebChat:

openclaw logs --follow

The logs will show which channel delivered the inbound message (telegram/discord/etc) and the sender info.

Immediate “lock it down” mitigation (no guesswork)

If you don’t need Telegram/Discord DMs right now, temporarily set DM policy to disabled/allowlist (and only add your own ID). I can tell you the exact openclaw config set ... commands once you paste the outputs of the 4 config get lines above (redact tokens; those commands won’t show tokens anyway).

If those outputs look sane (pairing/allowlist, no "*"), then the next most likely cause is simply old state being reused — in that case openclaw reset is the cleanest fix, but it’s destructive so I’d only do it after we confirm you actually want to wipe ~/.openclaw.

#

If (@lovekiut) id:5895844598 is you, and your gateway is loopback-only, then this is almost certainly not someone else accessing your OpenClaw.

What you’re seeing is usually one of these two things:

A) Old/local session history is being shown (pairing doesn’t matter)

Pairing only gates new inbound DMs — it doesn’t affect what’s already stored in your session logs.

WebChat defaults to the agent’s main session, and that session can contain older stuff from previous runs/installs if ~/.openclaw wasn’t wiped. Docs: WebChat uses gateway history (not local UI state):
https://docs.openclaw.ai/web/webchat
and WebChat attaches to the agent’s main session:
https://docs.openclaw.ai/channels/channel-routing#webchat-behavior

Prove/disprove quickly:

  • In WebChat, send (standalone):
    /new
# 
  /verbose off
  /reasoning off

If the “Human: …” weirdness stops in the new session, it was session/history/verbosity contamination.

Find where those lines live on disk:

grep -Rni "config update to enable gateway restart" ~/.openclaw/agents | head -20
grep -Rni "Apple Reminders" ~/.openclaw/agents | head -20

If grep finds it, it’s not an external actor; it’s literally in your local transcripts.

B) Grok is outputting role-labeled “self-dialogue” (common with some non-Anthropic models)

That "Human: ... Thanks ..." format can be the model output itself (it’s pretending to print the prompt / roles), especially if anything in the prompt resembles metadata blocks.

So this can be “just the model being weird” rather than OpenClaw receiving a message.

#

How to confirm: when it happens, run:

openclaw logs --follow

If you see no inbound message event corresponding to that text, then it’s purely the model’s generated output.

One more thing to sanity-check

Make sure your WebChat UI is actually connected to the gateway you think it is (127.0.0.1:18789) and not an old remote gateway URL saved in the app/UI settings.

If you paste the output of openclaw sessions --active 10080 (last ~7 days; redact anything you want), and the grep filename hits (just the paths), we can pinpoint exactly which session/store is leaking this in. Also: for model-specific weirdness, it’s worth asking in #models—people there have up-to-date notes on Grok behaving oddly with OpenClaw-style routing/tool prompts.

buoyant oyster
#

I think I will just opt for a clean "openclaw reset".

Can you check to see if I posted any sensitive information in here that I should remove?

muted matrixBOT
#

Based on what you’ve pasted in this thread, I don’t see any secrets like API keys, bot tokens, gateway tokens, passwords, or full config contents. 👍

The only things that are potentially sensitive / privacy-relevant (depending on your comfort level) are:

  • Your Telegram identity: @lovekiut and especially the numeric Telegram user id 5895844598 (unique identifier).
  • Your local macOS prompt: samantha@192 (reveals a local username + host label/IP-ish string).
  • Minor environment fingerprints: Homebrew paths (/opt/homebrew/...), log path (/tmp/openclaw/...), port (18789). These are generally not exploitable by themselves.

If you want to be extra cautious, I’d delete/edit the messages that include:

  • (@lovekiut) id:5895844598
  • the terminal output lines starting with samantha@192 ~ % ...

Nothing you shared here looks like it would let someone take over your gateway.

For the reset, the safe “clean slate” is: