#Problem repeated: bot says I am going to xyz and get back to you but never does

41 messages · Page 1 of 1 (latest)

grave grail
sleek bearBOT
ashen mirageBOT
#

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

fallen shaleBOT
#

I’m pulling the actual gist contents, the fetch preview only showed the header.

#

Need one more check: whether this looks like a transport issue or just the model stopping after a status-only reply.

#

I checked the gist.

What it shows:

  • AGENTS.md is getting loaded, so this is not “my prompt file isn’t being seen”.
  • It does not show any real background work being started.

That matters because OpenClaw does not have a generic “I’ll come back later” mechanism for a normal chat turn. If the model says “I’ll check and get back to you” but does not actually start background work, that is just a plan-only stall, not a queued follow-up.

So the likely buckets are:

  1. Model behavior: it narrated intent, but never took a concrete action.
  2. Transport/policy issue: the next turn got dropped, blocked, or never sent.

Please reproduce it once, then paste these from the same machine:

# 
openclaw --version
openclaw status --all
openclaw channels status --probe
openclaw logs --follow

What I need specifically:

  • the exact user prompt
  • the bot’s “I’ll check / get back to you” reply
  • the next 50 to 100 log lines after that

One extra clue: newer strict-agentic guardrails are for OpenAI/Codex GPT-5-family runs, so if this session is using some other provider, that protection may not apply.

Docs:

grave grail
fallen shaleBOT
#

This second gist is much more useful, I can tell the failure mode now.

#

Ah, this second gist changes the diagnosis a bit.

The important detail is: the “I am now processing the resume...” line is from Tok, not from vixbot.

So in this transcript, the bot did not actually make that promise first. What happened is:

  1. the bot failed to take the real file/PDF action
  2. it then read your text about processing the resume
  3. later it hallucinated that it had said that earlier
  4. /new started a fresh session, so continuity got even worse

So this is not a Discord “follow-up never arrived” problem. It looks like a grounding / false-memory / plan-without-action problem.

Also, with your setup, OpenClaw should be able to analyze PDFs here, so if it says it is processing a local PDF but never actually does it, I’d look for no real pdf tool call in the logs.

Two useful next steps:

# 
openclaw logs --follow

Then reproduce once and grab the log chunk around that turn. I’d expect either:

  • no pdf/file tool use at all, or
  • a tool/config failure right before the vague reply

And separately, if you have a transcript where vixbot itself originally said “I’m processing this and will get back to you”, paste that one too, because this gist is not quite that case.

Relevant docs:

If you paste the log snippet, I can help narrow it down fast.

grave grail
#

this is in telegram and it is the bot i just redacted some names

fallen shaleBOT
#

Got it, thanks, that’s on me. If the names were redacted and that line really was from the bot, then yes, this is the exact bug you’re describing.

In that case, I’d classify it as:

  • fake progress / plan-only turn
  • the bot claimed a concrete action (“I am now processing...”)
  • but it likely never actually started the file/PDF work
  • then later context drift made it contradict itself

And since this was Telegram, my earlier Discord-gating theory is basically irrelevant here.

So the next check is pretty simple:

openclaw logs --follow
openclaw status --all
#

If you paste the log snippet around that exact turn, I can help read it.

grave grail
#

04:43:23+00:00 warn telegram/network {"subsystem":"telegram/network"} fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=UND_ERR_SOCKET)

fallen shaleBOT
#

I found the concrete failure in that gist. Checking the exact auth docs so I don’t hand-wave the fix.

#

Yep, this gist is the smoking gun.

There are two real failures in the logs:

  1. Bad file path

    • 03:49:58 [tools] read failed: ENOENT ... /home/viklall/.openclaw/workspace/Lall_Vik_Resume.pdf
    • so at least one “I’m processing the resume” turn was trying the wrong path

  2. Broken model fallback chain

    • 04:41:19 primary model timed out
    • failover switched to google-vertex/gemini-1.5-pro
    • that failed with 401 UNAUTHENTICATED because Vertex does not use Gemini API keys, it wants gcloud ADC / principal-based auth
    • then OpenClaw logged: Embedded agent failed before reply: All models failed (2)

So yes, in this case the bot did not just “wander off”, the run actually died.

The key fix is:

#
  • If you only have Gemini API key auth, keep your fallback chain on google/*
  • If you want google-vertex/* as a fallback, you need Vertex auth (gcloud ADC) on the gateway host
  • Also run:
openclaw doctor --fix
openclaw models status

Your logs also show a separate legacy config problem:

  • channels.discord.streamMode ... are legacy; use channels.discord.streaming...

So doctor --fix is worth doing anyway.

Docs:

#

Yep, that warning is real, but it looks like a separate Telegram network problem, not the main “fake progress” bug.

It means:

  • OpenClaw resolved a Telegram API IP
  • that IP was unreachable from the host
  • so it retried with an alternative Telegram IP

By itself, that is degraded network/DNS, not a model failure.

How I’d read it:

  • if you still see later telegram sendMessage ok ..., then this was a transient transport warning
  • if it keeps repeating and sends fail, then the gateway host has a Telegram connectivity issue (DNS / routing / flaky network)

So right now I’d separate the issues like this:

#
  1. Model/runtime issue: fake progress, bad path, broken fallback auth
  2. Telegram transport issue: intermittent UND_ERR_SOCKET / unreachable resolved IP

If you want, paste 10 to 20 lines after that warning, the key thing is whether it recovers with sendMessage ok or keeps failing.

grave grail
#

"agents": {
"defaults": {
"model": {
"primary": "google-vertex/gemini-1.5-pro",
"fallbacks": [
"google/gemini-2.5-flash",
]
},
"models": {
"google/gemini-2.0-flash": {},
"google/gemini-3.1-flash-lite-preview": {},
"google/gemini-2.5-flash": {},
"google-vertex/gemini-2.5-flash": {},
"google-vertex/gemini-1.5-pro": {},
"google/gemini-3.1-pro-preview": {},
"google/gemini-2.5-flash-lite-preview-06-17": {}
},
"workspace": "/home/viklall/.openclaw/workspace",
"compaction": {
"mode": "safeguard"
},
"maxConcurrent": 4,
"subagents": {
"maxConcurrent": 8
},
"imageGenerationModel": {
"primary": "google/gemini-3-pro-image-preview"
},

fallen shaleBOT
#

Yep, this explains the weirdness.

Your active chain is mixing two different auth paths:

  • google/* → Gemini API key
  • google-vertex/* → Vertex auth (ADC / principal-based)

That mix is only okay if both auth setups are valid. Your logs say Vertex is not valid right now, so making google-vertex/gemini-1.5-pro the primary is asking for trouble.

Also, the earlier logs showed the reverse chain, so you were changing models during debugging, which is why the failures looked inconsistent.

If you do not have Vertex ADC set up, I’d simplify to direct Gemini only, for example:

agents: {
  defaults: {
# 
    model: {
      primary: "google/gemini-2.5-flash",
      fallbacks: ["google/gemini-3.1-pro-preview"]
    }
  }
}

If you do want Vertex, then keep the chain all on Vertex, for example:

agents: {
  defaults: {
    model: {
      primary: "google-vertex/gemini-1.5-pro",
# 
      fallbacks: ["google-vertex/gemini-2.5-flash"]
    }
  }
}

But only after Vertex auth is actually configured on the gateway host.

So my recommendation is:

  1. Do not mix google and google-vertex in the active fallback chain right now
  2. Run openclaw doctor --fix
  3. Run openclaw models status
  4. Restart and retest

Docs:

grave grail
#

problem reoccurred noting in log

fallen shaleBOT
#

If you mean nothing in the log, that actually fits the original theory pretty well.

A turn like:

“I’m going to check that and get back to you”

can be a clean model completion from the gateway’s point of view. If the model never called a tool and never hit a provider/channel error, there may be nothing interesting to log.

So the pattern becomes:

  • inbound message arrived
  • model returned a normal text reply
  • no tool call happened
  • no follow-up was ever started
  • logs stay mostly quiet

That is exactly why this bug is annoying, it can look “successful” at the runtime layer.

#

So at this point I’d read it like this:

  • with errors in logs → provider/tool/config problem
  • with no errors in logs → likely plan-only / fake-progress model behavior

What would help most now:

  • exact timestamp of the bad reply
  • 10 to 20 log lines around it
  • whether there are any [tools], embedded_run_failover, or provider errors after the “I’ll do X” message

If there are none, I’d treat it as a model-behavior issue, not a transport issue.

grave grail
#

🦞 OpenClaw 2026.4.11 (769908e)
I'm the reason your shell history looks like a hacker-movie montage.

Model Input Ctx Local Auth Tags
google/gemini-2.5-flash text+image 1024k no yes default,configured
google/gemini-3.1-pro-preview text+image 1024k no yes fallback#1,configured,alias:gemini
google/gemini-2.0-flash text+image 1024k no yes configured
google/gemini-3.1-flash-lite-preview text+image 1024k no yes configured,alias:gemini-flash-lite
google-vertex/gemini-2.5-flash text+image 1024k no yes configured
google-vertex/gemini-1.5-pro text+image 977k no yes configured
google/gemini-2.5-flash-lite-preview-06-17 text+image 1024k no yes configured

fallen shaleBOT
#

This looks much better.

Your active chain is now:

  • primary: google/gemini-2.5-flash
  • fallback #1: google/gemini-3.1-pro-preview

So the earlier Vertex 401 path should be out of the hot path now. đź‘Ť

A couple of notes:

  • the google-vertex/* entries are still in the configured model list, but they are not active just from this output
  • that means if the issue still happens now, I’d stop blaming Vertex auth and lean much harder toward plain model behavior / fake-progress turns

So at this point:

  • previous issue: broken fallback/auth chain, real config problem
#
  • current recurring issue: likely the model itself returning “I’ll do X” without taking action

If you want to reduce noise further, I’d even remove the google-vertex/* entries from the allowed model list for now, until Vertex auth is intentionally set up.

So yes, this output says the config is cleaner now. If it still reoccurs after this, that’s stronger evidence the model is the thing breaking.

grave grail
#

which model to try then

fallen shaleBOT
#

For real-time model picks, I’d ask in #models. That’s the one place where people will have fresh hands-on answers, and I don’t want to give you stale names here.

What I would do for this exact bug:

  • use the strongest hosted model you have access to, not the lightweight/cheap tier
  • keep primary + fallback in the same provider/auth family
  • avoid mixed chains while debugging
  • test the same prompt twice after switching, so you can compare behavior cleanly

Docs:

If you ask in #models, I’d phrase it like:

“I’m hitting plan-only / fake-progress turns on OpenClaw 2026.4.11. Which model is currently most reliable for tool follow-through?”

#

That should get you better current recommendations than I can safely hardcode here.

grave grail
#

i dont have permission to post in mod\els

fallen shaleBOT
#

Ah, got it. That’s frustrating.

Based only on the models you already pasted, the cleanest next test is:

agents: {
  defaults: {
    model: {
      primary: "google/gemini-3.1-pro-preview",
      fallbacks: ["google/gemini-2.5-flash"]
    }
  }
}

Why this test: