When using google-gemini-cli/xxx models, chat history does shows up in openclaw webui | Friends of the Crustacean 🦞🤝 | Page 1

next axle Apr 16, 2026, 12:40 AM

#

It also does not shows up in /home/node/.gemini/agents/main/session. I remember it works before but upgrading from v2026.4.6 to maybe around v2026.4.12 broke this. The thing is chat history did shows up in /home/node/.gemini/tmp/workspace/chats

#

My config literally did not change

clear palmBOT Apr 16, 2026, 12:43 AM

#

Let me check the docs and the current source, this smells like a regression rather than user error.

#

First, can you paste openclaw --version?

I think there are two different history stores getting mixed up here:

OpenClaw WebUI reads OpenClaw’s own transcripts from ~/.openclaw/agents/<agentId>/sessions/ plus sessions.json, not from .gemini/.... Docs: https://docs.openclaw.ai/help/faq
In current source, native CLI history import is implemented for Claude CLI, not Gemini CLI.
So if you see chats in /home/node/.gemini/tmp/workspace/chats but not in WebUI, that usually means OpenClaw is not persisting/parsing the Gemini run into its own session transcript.

There were also recent Gemini CLI fixes around:

JSON response parsing
backend arg construction

So an early 2026.4.x build could definitely break this.

Can you paste these 3 things next?

#

openclaw --version
openclaw status --all

And from:

~/.openclaw/agents/main/sessions/sessions.json

the entry for that thread/session, especially:

sessionFile
cliSessionIds
cliSessionBindings

If you paste that, I can tell pretty quickly whether this is expected current behavior, or a real regression.

#

Yeah, that actually makes me suspect a regression even more, not config drift. Let me check what changed between those releases.

#

Yeah, if the config did not change, I would treat this as a regression, not misconfig.

A couple useful findings from current source:

OpenClaw WebUI reads OpenClaw session transcripts from ~/.openclaw/agents/<agentId>/sessions/, not from .gemini/.... Docs: https://docs.openclaw.ai/help/faq
Native CLI history import is currently Claude CLI only, I do not see equivalent Gemini CLI import code.
So if Gemini is writing under /home/node/.gemini/tmp/workspace/chats but WebUI is blank, the likely failure is: OpenClaw stopped persisting the Gemini run into its own transcript store.

Also, there was a lot of session-history churn in that range, so your “same config, new version, broke” story is believable.

Two quick notes:

I do not see a v2026.4.6 tag upstream, so you were probably on v2026.4.5 or v2026.4.7
I would test on latest first before digging deeper

Can you paste:

#

openclaw --version
openclaw status --all

And if you want the fastest smoking gun, check whether this file is being updated at all:

~/.openclaw/agents/main/sessions/sessions.json

For the affected session/thread, I care about:

sessionFile
cliSessionIds
cliSessionBindings

If those look wrong or empty for google-gemini-cli, I’d call it a bug and send you to GitHub issues: https://github.com/openclaw/openclaw/issues

#

Oh, that status dump is the clue. Let me verify the state-dir behavior so I don’t guess.

#

Aha, that status blob is the real clue.

The important part is:

sessions.paths: ["/root/.openclaw/agents/main/sessions/sessions.json"]
sessions.count: 0

So right now the gateway is looking at /root/.openclaw, and it sees zero sessions.

That means this is probably not “Gemini stopped saving history”.
It looks more like OpenClaw is running with a different user/home/state dir now, so WebUI is reading a different session store than the one you expect.

That also matches your earlier path mismatch:

Gemini files you were checking: /home/node/.gemini/...
OpenClaw state it is actually using now: /root/.openclaw/...

#

So, same config can still break if the service user, HOME, OPENCLAW_STATE_DIR, or profile changed during upgrade.

Next read-only checks:

openclaw gateway status
openclaw doctor

From openclaw gateway status, I care about:

Config (cli)
Config (service)
Probe target

From openclaw doctor, I expect it may warn about:

multiple state directories
config/service mismatch

#

Docs:

state dir + sessions location: https://docs.openclaw.ai/help/faq
config/service mismatch troubleshooting: https://docs.openclaw.ai/gateway/troubleshooting

If you paste openclaw gateway status, I can tell you pretty quickly whether this is a /root vs /home/node service mismatch.

#

This actually makes the picture clearer. I’m checking whether the container/runtime user changed, because your status output now looks like a different, mostly-empty instance.

#

This looks much more like a container/user/state-volume issue than a Gemini-specific config problem.

Why I say that:

runtimeVersion: 2026.4.14, so you are already on latest stable
gateway.reachable: false, so openclaw status is not talking to a live gateway
gatewayService.installed: false, so there is no managed service to inspect
sessions.count: 0
active session path is under /root/.openclaw

Put together, that usually means:

the current runtime is looking at the wrong state dir, or
the container lost / changed its persisted state mount, or
the app is now running as a different user, so ~/.openclaw moved from /home/node to /root

And that would absolutely make WebUI history look empty.

#

For Docker/container installs, the docs expect state under /home/node/.openclaw, not /root/.openclaw: https://docs.openclaw.ai/install/docker

So I would check these next, inside the running container:

echo "$HOME"
echo "$OPENCLAW_STATE_DIR"
ls -la /home/node/.openclaw
ls -la /root/.openclaw

And if you can, also check whether your volume/bind mount still points to the same place it did before the upgrade.

At this point I’d frame it as:

probably not “Gemini stopped writing history”
probably the upgraded runtime is reading a different state directory / home directory

#

If you paste those 4 command outputs, plus how you launch it, I can narrow it down fast.

#

Yep, this is the smoking gun.

Your running instance is using:

workspaceDir: /root/.openclaw/workspace
sessionsPath: /root/.openclaw/agents/main/sessions/sessions.json
sessionsCount: 0

So the gateway/WebUI is reading /root/.openclaw, not /home/node/....

That means the most likely root cause is:

after the upgrade, your runtime/user/state-dir changed, so OpenClaw is now looking at a fresh empty state store.

That would explain all of this:

WebUI shows no history

#

sessionsCount=0
Gemini still writes its own temp/chat files elsewhere
config “did not change”, but runtime behavior did

Best fixes, in order

Recommended: make the running gateway use the old state dir explicitly
Set OPENCLAW_STATE_DIR=/home/node/.openclaw in whatever launches your app/container.
Also good: switch the container/runtime back to the expected Docker layout
Official Docker docs assume /home/node/.openclaw is the persisted state path:
https://docs.openclaw.ai/install/docker
Last resort: copy/migrate the old state into /root/.openclaw
I would avoid this unless you really want the new runtime to live under /root.

My recommendation

#

If your old working data lives under /home/node/.openclaw, do not chase .gemini/tmp/workspace/chats.
Just point OpenClaw back at the same persisted state dir it used before.

Docs:

state dir/session storage: https://docs.openclaw.ai/help/faq
Docker paths: https://docs.openclaw.ai/install/docker

If you want, paste how you launch the container/app, and I can tell you the exact env/volume change to make.

#

Thanks, that lines up with the same diagnosis.

At this point I’m pretty confident the issue is:

OpenClaw is using /root/.openclaw as its state dir now, and that store is empty.

So the missing WebUI history is coming from empty OpenClaw session state, not from Gemini refusing to save chats.

What matters now

OpenClaw WebUI history comes from:

$OPENCLAW_STATE_DIR/agents/main/sessions/

and your status shows that currently as:

#

/root/.openclaw/agents/main/sessions/

with sessionsCount: 0.

So the fix is to correct the runtime state path

If your old working setup used /home/node/.openclaw, then make the upgraded runtime use that again.

Best fix:

set OPENCLAW_STATE_DIR=/home/node/.openclaw
make sure that path is the one backed by your persistent volume/bind mount

Important side note

.gemini/... is Gemini CLI’s own storage.

#

OpenClaw WebUI does not use that as its primary session history source.

So I’d stop chasing:

/home/node/.gemini/tmp/workspace/chats

and focus on:

/root/.openclaw
vs
/home/node/.openclaw

Next useful thing from you

#

Instead of more truncated status output, the most helpful next paste is just:

how you launch the app/container
what env vars you set
what host path is mounted to the state dir

If you paste that, I can tell you the exact one-line change to make.

next axle Apr 16, 2026, 12:55 AM

#

Oh I did with wrong user. Here the actual non-root user since openclaw run as non-root anyway:

clear palmBOT Apr 16, 2026, 12:56 AM

#

Ah, okay, that explains the /root weirdness 😅

Yeah, that previous dump is probably a red herring then.

Please paste these from the actual user that runs OpenClaw:

openclaw --version
openclaw status --all
openclaw gateway status
echo "$HOME"
echo "$OPENCLAW_STATE_DIR"

The bits I care about most are:

sessions.paths

#

sessions.count
agents[].workspaceDir
whether the gateway is reachable
the actual HOME / OPENCLAW_STATE_DIR

Once we have the non-root output, we can tell if this is really:

a state-dir mismatch, or
a Gemini/session-history regression.

#

Nice, glad we caught that.

This rules out the state-dir mismatch.

Your real OpenClaw instance is using:

/home/node/.openclaw/agents/main/sessions/sessions.json
sessions.count: 19

So OpenClaw is seeing normal session state.

That means we’re back to one of these two:

session routing bug for this Discord thread, or
Gemini transcript write/read bug for that session

The fastest next check is:

#

find the sessions.json entry for this thread
get its sessionFile
inspect whether that transcript file actually contains the missing turns

If the transcript file has the turns, then it’s a WebUI/session-history loading bug.
If the transcript file does not have the turns, then it’s a session write/routing bug.

Can you paste the relevant entry from:

/home/node/.openclaw/agents/main/sessions/sessions.json

I care about these fields:

sessionId
sessionFile

#

lastThreadId
channel
subject
model / modelProvider

If you already know the sessionFile, paste the first few lines of that transcript too. That’ll tell us which side is broken.

#

That confirms Gemini sessions exist, but it still isn’t the key bit we need yet.

We need the actual sessions.json entry for this Discord thread.

This read-only Python snippet should pull it cleanly:

python - <<'PY'
import json
p = "/home/node/.openclaw/agents/main/sessions/sessions.json"
with open(p) as f:
    data = json.load(f)

target = "1494135269748772864"
found = False

#

for key, value in data.items():
    if str(value.get("lastThreadId", "")) == target:
        found = True
        print("KEY:", key)
        for field in [
            "sessionId",
            "sessionFile",
            "lastThreadId",
            "channel",
            "subject",
            "model",
            "modelProvider",
            "updatedAt",
        ]:
            print(f"{field}: {value.get(field)}")

#

        print()

if not found:
    print("NO_MATCH")
PY

If that prints:

NO_MATCH → this is probably a thread routing/session binding bug
a real sessionFile path → then paste the first ~20 lines of that transcript file, and we can tell whether it’s a write bug or a WebUI read bug

So we’re very close now, we just need that one exact entry.

#

That’s still the big status --all blob, not the sessions.json lookup output 🙂

Please run the exact Python snippet from my last message. The output should be tiny, either:

NO_MATCH

or something like:

KEY: ...
sessionId: ...
sessionFile: ...
lastThreadId: ...
channel: ...

#

subject: ...
model: ...
modelProvider: ...

That one result tells us:

NO_MATCH → routing bug
matching entry + sessionFile → inspect transcript file next

We’re stuck until we get that exact sessions.json lookup, because the truncated status --all output does not include the fields we need.

#

You’re still pasting the status --all JSON, not the lookup output.

Please do not run openclaw status --all again for this step.

Run only this:

python - <<'PY'
import json
p = "/home/node/.openclaw/agents/main/sessions/sessions.json"
with open(p) as f:
    data = json.load(f)

target = "1494135269748772864"
for key, value in data.items():
    if str(value.get("lastThreadId", "")) == target:

#

        print("KEY:", key)
        print("sessionId:", value.get("sessionId"))
        print("sessionFile:", value.get("sessionFile"))
        print("lastThreadId:", value.get("lastThreadId"))
        print("channel:", value.get("channel"))
        print("subject:", value.get("subject"))
        print("model:", value.get("model"))
        print("modelProvider:", value.get("modelProvider"))
        raise SystemExit

print("NO_MATCH")
PY

Then paste only the result of that command.

#

Valid outputs are just:

NO_MATCH
or the small KEY / sessionId / sessionFile / ... block

That’s the one thing we need now.

next axle Apr 16, 2026, 12:59 AM

#

$ python3 - <<'PY'
import json
p = "/home/node/.openclaw/agents/main/sessions/sessions.json"
with open(p) as f:
    data = json.load(f)
target = "1494135269748772864"
for key, value in data.items():
    if str(value.get("lastThreadId", "")) == target:
        print("KEY:", key)
        print("sessionId:", value.get("sessionId"))
        print("sessionFile:", value.get("sessionFile"))
        print("lastThreadId:", value.get("lastThreadId"))
        print("channel:", value.get("channel"))
        print("subject:", value.get("subject"))
        print("model:", value.get("model"))
        print("modelProvider:", value.get("modelProvider"))
        raise SystemExit
print("NO_MATCH")
PY
NO_MATCH

clear palmBOT Apr 16, 2026, 12:59 AM

#

I think I may have enough of a clue now. I’m checking how Discord thread/forum sessions are keyed, because that agent:main:discord:channel:... entry may be the actual bug.

#

I think we’ve got the likely bug now.

From what you pasted, I can see a Discord session like:

agent:main:discord:channel:1488779068425109574

But the current thread we’re talking in is:

1494135269748772864

Since Discord thread/forum messages are arriving here with the thread’s channel id, I would expect a session keyed to this id, not some other channel id.

So my current read is:

#

this is not primarily a Gemini local-history problem
it looks like a Discord thread/forum session routing bug
Gemini may still be answering fine, but OpenClaw is not binding/persisting this thread to the expected session key, so WebUI history for this thread goes missing

At this point I’d file it as a bug with:

version: 2026.4.14
current thread id: 1494135269748772864
observed stored Discord session key using a different channel id
note that Gemini chat data appears under /home/node/.gemini/tmp/workspace/chats, but OpenClaw WebUI thread history is missing

GitHub issues: https://github.com/openclaw/openclaw/issues

If you want, I can help you write a tight bug report message for the issue so it’s easy to file.

#

At this point I’d stop digging in Discord and file it as a bug.

Here’s a tight issue draft you can paste into GitHub:

Title
google-gemini-cli sessions not showing thread history in Control UI / Discord thread routing regression

Body

### Version
OpenClaw 2026.4.14

### Summary
When using `google-gemini-cli/*` models in a Discord help/forum thread, chat history does not show up correctly in the OpenClaw WebUI / Control UI for that thread.

### What I see

#

- Gemini chat data does appear under:
  - `/home/node/.gemini/tmp/workspace/chats`
- But the expected history does **not** show up in the OpenClaw WebUI thread view
- I also do not see the expected Gemini session history under:
  - `/home/node/.gemini/agents/main/session`

### Environment
- Non-root runtime user
- OpenClaw state dir is under:
  - `/home/node/.openclaw`
- `openclaw status --all` shows normal session state, not an empty store

### Expected
Discord thread/forum messages should bind to the correct OpenClaw session key and their history should be visible in the WebUI.

#

### Actual
The thread history appears missing/misrouted in WebUI, even though Gemini is clearly producing chat data.

### Notes
This seemed to work on an older 2026.4.x version and regressed somewhere around upgrading from ~2026.4.5/2026.4.7 to later 2026.4.x builds.

Current Discord thread id:
- `1494135269748772864`

Issue link: https://github.com/openclaw/openclaw/issues

If you want, I can also help tighten the title/body after you paste the exact version history or any extra logs.

#

I think Discord is just chewing up the JSON now, we’re not getting the exact fields cleanly.

You’ve already got enough for a bug report, so I would stop pasting more status --all here and use the GitHub issue draft above.

If you want to keep debugging locally, the fastest path is honestly a local agent on the box so it can inspect sessions.json directly without Discord mangling the output:
https://docs.openclaw.ai/help/faq#i-am-stuck-fastest-way-to-get-unstuck

But from this thread, my recommendation is:

file the GitHub issue
include version 2026.4.14
mention Discord thread id 1494135269748772864
mention Gemini data appears under /home/node/.gemini/tmp/workspace/chats but WebUI thread history is missing

That’s enough for maintainers to reproduce/start triage.

#

Perfect, that answers it.

NO_MATCH means OpenClaw never created or updated a session entry with:

lastThreadId = 1494135269748772864

So this is not just “Gemini history stored in the wrong place”.

It’s much more specifically a:

Discord thread/forum session routing or binding bug

That also explains why the WebUI has nothing to show for this thread. There is no matching thread-bound session metadata for it.

I’d file the bug with this exact evidence:

#

OpenClaw 2026.4.14
Discord thread id: 1494135269748772864
sessions.json lookup for lastThreadId == 1494135269748772864 returns NO_MATCH
Gemini output exists under /home/node/.gemini/tmp/workspace/chats
WebUI thread history is missing

GitHub issues: https://github.com/openclaw/openclaw/issues

Suggested title:

Discord thread/forum session not bound for google-gemini-cli runs, sessions.json has NO_MATCH for lastThreadId

Glad we got to a real signal there. If this fixed the diagnosis, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

next axle Apr 16, 2026, 1:01 AM

#

So what's the dirty fix for this? Since I'm trying to chat within openclaw ui itself for gemini-cli backend but messages does not shows up. It only shows up for other non-gemini-cli backend

clear palmBOT Apr 16, 2026, 1:02 AM

#

Let me check the official Google provider docs so I can give you the least-bad workaround, not a made-up one.

#

Dirty fix, use direct Gemini API instead of the CLI backend in the UI.

Recommended workaround

Switch from:

google-gemini-cli/gemini-3.1-pro-preview

to:

google/gemini-3.1-pro-preview

and authenticate with GEMINI_API_KEY or GOOGLE_API_KEY.

#

Config:

{
  agents: {
    defaults: {
      model: {
        primary: "google/gemini-3.1-pro-preview",
      },
    },
  },
}

Docs:

Google provider: https://docs.openclaw.ai/providers/google
Models: https://docs.openclaw.ai/concepts/models

#

Why

google-gemini-cli is the unofficial CLI/OAuth path, and that looks like the broken path here.
The direct google/* provider is the least-bad workaround if you want Gemini in OpenClaw UI with normal history.

If you cannot use an API key

Your realistic dirty options are:

Use a non-CLI backend in the UI for now, recommended
Downgrade to the last version that worked for your google-gemini-cli setup
Keep using google-gemini-cli, but accept that UI history may be busted until the bug is fixed

So my honest recommendation is: do not use google-gemini-cli in the WebUI right now, use google/* instead.

next axle Apr 16, 2026, 1:02 AM

#

Can you help me the regression that directly affect this?

clear palmBOT Apr 16, 2026, 1:03 AM

#

I’m checking the actual Gemini CLI codepath now, because the Discord thread routing thing may be separate from your real WebUI symptom.

#

Yeah, I think the thing that directly affects your actual WebUI + google-gemini-cli symptom is the Gemini CLI parser/backend path, not the Discord thread NO_MATCH thing. That part was a separate clue from this support thread.

The most relevant code/commits I found are:

c75f82448f
fix(google-cli): parse gemini json response and stats (#60801)
This touches src/agents/cli-output.ts and is the code that decides whether Gemini CLI output becomes visible assistant text and usage inside OpenClaw.

Why it matters:
- it added support for Gemini JSON response
- it added stats fallback when usage is empty
- if this parser misses your CLI’s output shape, the UI history can look blank
d56831f81b
fix: align gemini cli live backend runs
This touches:
- extensions/google/cli-backend.ts

#

src/agents/cli-runner/helpers.ts

Why it matters:
- it changed Gemini CLI args to use the prompt placeholder correctly
- bad arg ordering here can break how the CLI run is interpreted or resumed

My honest read

If you want the most direct codepath to inspect/fix, start here:

src/agents/cli-output.ts
extensions/google/cli-backend.ts
src/agents/cli-runner/helpers.ts
src/agents/cli-runner.ts

Important nuance

I do not see a clean later 2026.4.7+ Gemini-specific commit that obviously explains “history missing in WebUI” by itself.

#

So the likely possibilities are:

Gemini CLI output shape drifted again, and OpenClaw’s parser is still incomplete
the CLI backend run succeeds, but OpenClaw ends up with empty payloads, so the transcript/UI stays blank
there is a generic UI/session history issue that only shows up on the CLI provider path

If you want, I can help you turn that into a more precise code-level bug report with the exact files/commit hashes called out.

next axle Apr 16, 2026, 1:05 AM

#

yeah I already suspect it's not related to discord at all since discord still works by using non-gemini-cli models

clear palmBOT Apr 16, 2026, 1:05 AM

#

Yep, I agree. That makes the Discord angle basically a red herring for the real bug.

If non-gemini-cli models show history fine, then I’d narrow it to:

google-gemini-cli output parsing
CLI backend session/result handling
UI transcript rendering only as a downstream effect

So the most likely direct fault line is still:

src/agents/cli-output.ts
extensions/google/cli-backend.ts
src/agents/cli-runner.ts

If you want one fast way to confirm the parser mismatch, capture a raw Gemini CLI JSON response and compare its fields to what OpenClaw expects:

visible text from response

#

usage from usage
fallback usage from stats

If your current gemini output shape differs, that’s probably the exact break.

So yes, I’d describe it as:

“google-gemini-cli backend regression in OpenClaw UI/session history path, not a Discord routing problem.”

If you want, I can help you write a super precise “suspected root cause” section for the GitHub issue with those files called out.

next axle Apr 16, 2026, 1:06 AM

#

Hm how do I do this then?

If you want one fast way to confirm the parser mismatch, capture a raw Gemini CLI JSON response and compare its fields to what OpenClaw expects:

clear palmBOT Apr 16, 2026, 1:07 AM

#

Yep, easiest way is to run the Gemini CLI directly, with the same JSON mode OpenClaw uses, and inspect the raw output.

Try this:

gemini --model gemini-3.1-pro-preview --output-format json --prompt "Reply with only OK" | tee /tmp/gemini-raw.json

Then inspect what came back:

cat /tmp/gemini-raw.json

And to make it easier to spot the fields:

#

python3 - <<'PY'
import json
p = "/tmp/gemini-raw.json"
with open(p) as f:
    data = json.load(f)

print("TYPE:", type(data).__name__)
if isinstance(data, dict):
    print("TOP_LEVEL_KEYS:", sorted(data.keys()))
    for key in ["response", "result", "text", "content", "usage", "stats", "session_id", "sessionId"]:
        if key in data:
            print(f"{key}:", data[key])
PY

What you want to see

#

OpenClaw’s Gemini CLI path is basically expecting:

visible reply text in response
usage in usage
or fallback usage in stats
session id in session_id or sessionId

What would confirm the mismatch

If your current Gemini CLI returns something like:

no response
no usage / stats
or the text is under some other field

then that’s the likely parser break.

If you paste the TOP_LEVEL_KEYS and the values for response / usage / stats, I can tell you pretty quickly whether OpenClaw is parsing the wrong shape.

next axle Apr 16, 2026, 1:12 AM

#

node@37c021880d4f:/app$ gemini --model gemini-3.1-pro-preview --output-format json --prompt "Reply with only OK" | tee /tmp/gemini-raw.json
{
  "session_id": "xxx",
  "response": "OK",
  "stats": {
    "models": {
      "gemini-3.1-pro-preview": {
        "api": {
          "totalRequests": 1,
          "totalErrors": 0,
          "totalLatencyMs": 3798
        },
        "tokens": {
          "input": 1261,
          "prompt": 7460,
          "candidates": 1,
          "total": 7603,
          "cached": 6199,
          "thoughts": 142,
          "tool": 0
        },
        "roles": {
          "main": {
            "totalRequests": 1,
            "totalErrors": 0,
            "totalLatencyMs": 3798,
            "tokens": {
              "input": 1261,
              "prompt": 7460,
              "candidates": 1,
              "total": 7603,
              "cached": 6199,
              "thoughts": 142,
              "tool": 0
            }
          }
        }
      }
    },
    "tools": {
      "totalCalls": 0,
      "totalSuccess": 0,
      "totalFail": 0,
      "totalDurationMs": 0,
      "totalDecisions": {
        "accept": 0,
        "reject": 0,
        "modify": 0,
        "auto_accept": 0
      },
      "byName": {}
    },
    "files": {
      "totalLinesAdded": 0,
      "totalLinesRemoved": 0
    }
  }
}

clear palmBOT Apr 16, 2026, 1:13 AM

#

Nice, this is actually super useful. The raw Gemini JSON looks compatible on the top-level fields, so the break is probably one step later. I’m checking the transcript/write path now.

#

Perfect, this tells us a lot.

What this proves

The top-level Gemini CLI output is fine for OpenClaw’s parser:

session_id ✅
response ✅
stats ✅

So the visible reply text should be parseable.

Small nuance

Your stats shape is nested under:

stats.models["gemini-3.1-pro-preview"].tokens

#

while OpenClaw’s usage fallback expects flatter keys like stats.input, stats.cached, etc.

So usage/token accounting is probably still wrong, but that alone should not make messages disappear from the UI.

So the likely regression moved one step later

The problem is probably now in:

transcript persistence
session write/mirroring
or Control UI history loading for CLI-backed runs

Next exact check

Since your recent session list showed agent:main:main with session id:

5d43d1f2-a1f0-4ac2-b18f-040dd1b564d1

#

check the actual transcript file for that session:

ls -1 /home/node/.openclaw/agents/main/sessions | grep 5d43d1f2

Then open it:

sed -n '1,80p' /home/node/.openclaw/agents/main/sessions/<that-file>

What the result means

If the transcript file contains the Gemini replies, then this is a Control UI history rendering/loading bug
If the transcript file does not contain the Gemini replies, then this is a session/transcript write bug on the google-gemini-cli path

So, good news, we can now stop blaming the raw Gemini JSON parser for the missing messages.

next axle Apr 16, 2026, 1:14 AM

#

output is too large for the sed command. Maybe grep?

clear palmBOT Apr 16, 2026, 1:15 AM

#

Yep, grep or tail with truncation is better.

Try this:

FILE=/home/node/.openclaw/agents/main/sessions/<that-file>
tail -n 12 "$FILE" | cut -c1-400

If you want just assistant/user turns:

grep -n '"role":"assistant"\|"type":"assistant"' "$FILE" | tail -n 5 | cut -c1-400
grep -n '"role":"user"\|"type":"user"' "$FILE" | tail -n 5 | cut -c1-400

What I’m looking for:

#

assistant lines exist for the Gemini session → transcript write is fine, UI read/render is broken
only user lines / no assistant lines → the google-gemini-cli path is failing before transcript persistence

If you paste the last few truncated assistant/user lines, that should be enough.

#

That transcript is really helpful, and it actually points to something else. Let me verify the exact provider/api tags OpenClaw writes for Gemini CLI transcripts so I can give you the right grep.

#

Yep, that’s the wrong transcript for this bug.

That file is showing:

provider:"openrouter"
provider:"openai-codex"

So it’s not your google-gemini-cli run.

Try this instead, across the whole sessions dir:

rg -n '"provider":"google-gemini-cli"|"api":"google-gemini-cli"' /home/node/.openclaw/agents/main/sessions

What that tells us

No matches at all → google-gemini-cli assistant messages are probably never being persisted to transcript

#

Matches exist → then the data is on disk, and the bug is more likely Control UI history loading/rendering

If you get matches, paste just 2-3 lines around one of them.
If you get no matches, that’s actually very strong evidence for the bug report.

next axle Apr 16, 2026, 1:19 AM

#

There's match but unfortunately none shows the latest recent message. The last message is like 5 days old

clear palmBOT Apr 16, 2026, 1:20 AM

#

That’s the smoking gun. Nice catch.

So the picture is now:

old google-gemini-cli transcript entries exist
new google-gemini-cli messages are not being written
raw Gemini CLI output still contains response + session_id

That means the regression is most likely:

recent google-gemini-cli replies stop getting persisted into OpenClaw session transcripts

So this is probably not:

a Discord problem
a Control UI-only render bug
or a total Gemini CLI parse failure

#

It looks like a regression in the current transcript/session write path for google-gemini-cli runs.

Best bug-report wording

You can now say:

Historical google-gemini-cli transcript entries exist on disk, but recent google-gemini-cli replies stop appearing in ~/.openclaw/agents/main/sessions/* even though raw gemini --output-format json still returns valid session_id and response. Other non-CLI backends still persist normally.

That is much tighter than where we started.

Practical takeaway

Workaround: use google/* instead of google-gemini-cli/* in the UI
Bug: recent google-gemini-cli runs are not being persisted to transcript history

If you want, I can write the final GitHub issue body now with all the evidence cleaned up into one paste.

next axle Apr 16, 2026, 1:20 AM

#

Continue then

clear palmBOT Apr 16, 2026, 1:21 AM

#

Yep, here’s a cleaned-up issue you can paste:

Title

google-gemini-cli replies stop being persisted to OpenClaw session transcripts / WebUI history

Body

### Version
OpenClaw 2026.4.14

### Summary
When using `google-gemini-cli/*` models in the OpenClaw UI, new assistant messages stop appearing in OpenClaw session history / WebUI history.

This does **not** affect other non-`google-gemini-cli` backends.

#


### Repro
1. Configure OpenClaw to use a `google-gemini-cli/*` model
2. Chat in the OpenClaw UI
3. Observe that new messages do not show up properly in UI history / transcript history
4. Switch to a non-`google-gemini-cli` backend
5. History works normally again

### What I checked

#### 1) Raw Gemini CLI output still looks valid
Running Gemini directly:

```bash
gemini --model gemini-3.1-pro-preview --output-format json --prompt "Reply with only OK"

#


returns valid JSON with:

- `session_id`
- `response`
- `stats`

Example:

```json
{
  "session_id": "...",
  "response": "OK",
  "stats": {
    "models": {
      "gemini-3.1-pro-preview": {

#

"tokens": {
"input": 1261,
"prompt": 7460,
"candidates": 1,
"total": 7603,
"cached": 6199,
"thoughts": 142,
"tool": 0
}
}
}
}
}


So the CLI itself is still returning a usable response payload.

#


#### 2) Historical `google-gemini-cli` transcript entries exist
Searching under:

```bash
/home/node/.openclaw/agents/main/sessions

does find older transcript entries with provider:"google-gemini-cli" / api:"google-gemini-cli".

3) But recent `google-gemini-cli` messages are no longer being persisted

The matching transcript entries are old (around ~5 days old), and newer google-gemini-cli UI messages are missing from transcript history.

So this looks like a regression where:

#

- older `google-gemini-cli` runs were persisted correctly
- newer `google-gemini-cli` runs are no longer being written into OpenClaw session transcripts

### Expected
New `google-gemini-cli` replies should be persisted into OpenClaw session transcripts and appear in WebUI history like other backends.

### Actual
Recent `google-gemini-cli` replies do not appear in transcript history / WebUI history, even though raw Gemini CLI output still includes a valid `response`.

### Notes
This appears to be specific to the `google-gemini-cli` backend path, not a general Discord/UI issue, since non-CLI backends still persist and render normally.

Possible area to inspect:
- `src/agents/cli-output.ts`
- `extensions/google/cli-backend.ts`

#

- `src/agents/cli-runner.ts`
- transcript/session persistence after CLI runs

Issue link: https://github.com/openclaw/openclaw/issues

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

next axle Apr 16, 2026, 1:22 AM

#

Hm next task we probably to bisect to actual offending commit

clear palmBOT Apr 16, 2026, 1:22 AM

#

Yep, I think that’s the right next step.

A good bisect plan would be:

1) Pick the range

There is no v2026.4.6 tag upstream, so use:

good: v2026.4.5 or v2026.4.7 (whichever you confirm worked)
bad: v2026.4.14 or v2026.4.12

Example:

git bisect start
git bisect bad v2026.4.14
git bisect good v2026.4.5

#

2) Use a very small test

At each bisect step:

build/run OpenClaw
send one trivial prompt through the OpenClaw UI using google-gemini-cli/gemini-3.1-pro-preview
check whether a new google-gemini-cli transcript entry is written

3) Use transcript persistence as the pass/fail signal

Instead of judging by UI manually, use the transcript signal:

rg -n '"provider":"google-gemini-cli"|"api":"google-gemini-cli"' /home/node/.openclaw/agents/main/sessions

If a fresh entry appears for the run, mark it good.
If the UI talks to Gemini but no fresh transcript entry appears, mark it bad.

#

Then:

git bisect good
# or
git bisect bad

4) Most suspicious areas

If you want to narrow your attention while bisecting, I’d watch commits touching:

src/agents/cli-output.ts
src/agents/cli-runner.ts
extensions/google/cli-backend.ts
src/auto-reply/reply/agent-runner.ts
src/config/sessions/transcript.ts

#

My guess

Since raw Gemini JSON still looks fine, I’d bet the offending commit is in the post-CLI transcript/session persistence path, not the raw CLI parser itself.

If you want, I can also help you write a tiny bisect checklist so each step is fast and consistent.

next axle Apr 16, 2026, 1:33 AM

#

Hmm can we list all relevant commit that touch suspected files assuming I already git clone entire repo?

clear palmBOT Apr 16, 2026, 1:34 AM

#

Yep. Assuming you already cloned the repo, these are the commands I’d use.

1) Main suspect list, compact

Use the likely regression window first. Since there is no v2026.4.6 tag, start with v2026.4.5 or v2026.4.7.

git log --oneline --decorate --reverse v2026.4.5..v2026.4.14 -- \
  src/agents/cli-output.ts \
  src/agents/cli-runner.ts \
  src/agents/cli-runner/helpers.ts \
  extensions/google/cli-backend.ts \
  src/auto-reply/reply/agent-runner.ts \
  src/config/sessions/transcript.ts

If you know v2026.4.7 was still good, narrow it:

#

git log --oneline --decorate --reverse v2026.4.7..v2026.4.14 -- \
  src/agents/cli-output.ts \
  src/agents/cli-runner.ts \
  src/agents/cli-runner/helpers.ts \
  extensions/google/cli-backend.ts \
  src/auto-reply/reply/agent-runner.ts \
  src/config/sessions/transcript.ts

2) Broader session/history path

If the first list is too narrow:

git log --oneline --decorate --reverse v2026.4.5..v2026.4.14 -- \
  src/agents \

#

  src/auto-reply/reply \
  src/config/sessions

3) Filter for likely keywords

This is handy after the raw file-touch list:

git log --oneline --decorate v2026.4.5..v2026.4.14 -- \
  src/agents src/auto-reply/reply src/config/sessions extensions/google \
| rg 'gemini|google-cli|google-gemini-cli|cli|transcript|session|history'

4) Show one commit in detail

When a commit looks suspicious:

#

git show --stat <commit>
git show <commit> -- \
  src/agents/cli-output.ts \
  src/agents/cli-runner.ts \
  src/agents/cli-runner/helpers.ts \
  extensions/google/cli-backend.ts \
  src/auto-reply/reply/agent-runner.ts \
  src/config/sessions/transcript.ts

5) The two Gemini-specific commits I’d definitely inspect first

git show c75f82448f
git show d56831f81b

#

Those are:

c75f82448f fix(google-cli): parse gemini json response and stats
d56831f81b fix: align gemini cli live backend runs

If you want, paste the output of command 1 and I can help rank which commits are most suspicious before you bisect.

next axle Apr 16, 2026, 1:37 AM

#

b04dd6d05c refactor: consolidate session history sanitization
c39f061003 Revert "refactor(cli): remove bundled cli text providers"
ef923805f5 Revert "refactor(cli): remove custom cli backends"
0f224724dc Agents: slim cli-runner test seams
a4253deb67 refactor: dedupe agent error formatting
3d23103081 refactor: dedupe hook gateway error formatting
d0562a873f perf(agents): extract cli runner image and approval seams
b514d61000 refactor: dedupe reply execution readers
d56831f81b fix: align gemini cli live backend runs
c2f9de3935 feat: unify live cli backend probes
1fdb013599 refactor: dedupe routing lowercase helpers
c541a9c110 Tests: fix flaky shard expectations
8e4eaec394 refactor: dedupe agent lowercase helpers
9e61209780 refactor: dedupe agent lowercase helpers
d56fe040b4 refactor: dedupe agent lowercase helpers
4d3c72a521 fix: surface Claude CLI API errors
b77db8c0b6 Reply: surface OAuth reauth failures (#63217)
2d0e25c23a fix: pass system prompt to codex cli
fa8723c7e4 test: keep cli reliability and fallback coverage off plugin scans
aad9ecd9cc test: move runReplyAgent reset state coverage to helper
2645ed154b fix: provider-qualified session context limits (#62493) (thanks @neeravmakwana)
b83726d13e Feat: Add Active Memory recall plugin (#63286)
89d7a24a35 fix(cli-runner): wire OpenClaw skills into Claude CLI
fe0f686c92 Gate Matrix profile updates for non-owner message tool runs (#62662)
733137615f test: trim agents shard waits
202f80792e feat: add plugin text transforms
74e7b8d47b fix(cycles): bulk extract leaf type surfaces
bb0bfabec8 perf: trim agent test runtime imports
c37e49f275 Add /trace toggle and fix Active Memory diagnostics
7c09ba70ef fix(trace command): Improve trace raw diagnostics and trace command UX (#66089)
9a2675e9fd perf(agents): lazy-load cli runner seams

clear palmBOT Apr 16, 2026, 1:37 AM

#

Nice, that list is way more manageable.

If I had to rank the suspicious ones, I’d do it like this:

Highest suspicion

d56831f81b fix: align gemini cli live backend runs
Directly Gemini CLI specific. First one I’d inspect.
0f224724dc Agents: slim cli-runner test seams
Touches CLI runner internals, easy place to accidentally break payload/result propagation.
d0562a873f perf(agents): extract cli runner image and approval seams
Another CLI-runner refactor, likely in the path between CLI result and transcript persistence.
b514d61000 refactor: dedupe reply execution readers
Could affect how reply payloads/results are read after the runner returns.

#

Medium suspicion

c39f061003 Revert "refactor(cli): remove bundled cli text providers"
ef923805f5 Revert "refactor(cli): remove custom cli backends"
These smell important because they touch the whole CLI backend/provider registration layer.
b04dd6d05c refactor: consolidate session history sanitization
Less likely for “not persisted at all”, but still worth a look if the write happened and UI dropped it.

Lower suspicion

202f80792e feat: add plugin text transforms
Could theoretically affect CLI text rewriting, but not my first guess.
2645ed154b fix: provider-qualified session context limits
Probably not the main culprit for missing transcript writes.

Probably ignore for now

These look unlikely for your bug:

#

4d3c72a521 Claude CLI error surfacing
2d0e25c23a Codex system prompt
b77db8c0b6 OAuth reauth failures
fe0f686c92 Matrix profile updates
tests / trace / Active Memory / perf-only commits

If I were doing manual inspection before bisect

I’d run:

git show d56831f81b
git show 0f224724dc
git show d0562a873f
git show b514d61000
git show c39f061003
git show ef923805f5

#

git show b04dd6d05c

So yeah, d56831f81b + the CLI-runner refactors are my strongest suspects from that list.

If you want, paste git show --stat for those top 4 to 6 commits and I can help narrow it even further.

next axle Apr 16, 2026, 1:39 AM

#

Git show dump for d56831f81b: https://pastebin.com/raw/S4GwBe2C

#

?

#

You still there?

clear palmBOT Apr 16, 2026, 1:44 AM

#

I looked through that diff, and honestly, d56831f81b does not look like the direct cause of your missing OpenClaw history.

What it actually changes

Mostly three things:

Gemini CLI arg order

from:
```
--prompt --output-format json
```

to:

--output-format json --prompt "{prompt}"

buildCliArgs() placeholder replacement
- adds support for replacing "{prompt}" inside the configured arg list

#

live-test / docker auth metadata
- adds Gemini live smoke metadata
- includes .gemini auth dir in test/docker auth helpers

Why I don’t think it’s the smoking gun

It does not touch the parts I’d expect for your actual symptom:

transcript writing
session persistence
UI history loading
assistant payload sanitization/storage

It looks much more like:

“make Gemini CLI runs invoke correctly”
“make live tests work”
“make prompt placeholder handling consistent”

#

My read

If anything, d56831f81b looks like a CLI invocation fix, not a history persistence regression.

So after seeing this diff, I’d move suspicion more toward:

b514d61000 refactor: dedupe reply execution readers
b04dd6d05c refactor: consolidate session history sanitization
0f224724dc Agents: slim cli-runner test seams
d0562a873f perf(agents): extract cli runner image and approval seams

One caveat

There is a tiny chance the {prompt} placeholder change affected resumed Gemini runs in some weird way, but from this diff alone, I would not call it the likely culprit.

So yeah, I’d deprioritize d56831f81b unless bisect conclusively lands on it.

If you want, send the next diff for b514d61000 or b04dd6d05c. Those feel more promising now.

#

Short version: d56831f81b is probably not the culprit.

It mostly changes Gemini CLI invocation, not history persistence.

Next commit to inspect

I’d do this one next:

git --no-pager show b514d61000

If that looks boring, then:

git --no-pager show b04dd6d05c

#

Those two are more likely to affect:

reply result reading
transcript/history sanitization
what actually gets written into session history

If you paste either diff, I’ll rank it fast.

#

Yep, still here 🦐

I think d56831f81b is probably not it.
Next best diff to inspect is:

git --no-pager show b514d61000

That one is more likely to affect how reply results get read before transcript persistence.

If you paste it, I’ll keep narrowing this down with you.

next axle Apr 16, 2026, 1:45 AM

#

https://pastebin.com/raw/msteYJgC

clear palmBOT Apr 16, 2026, 1:46 AM

#

Got it, I’m checking that diff now.

#

Thanks, this is useful.

My read on these two

`b514d61000` `refactor: dedupe reply execution readers`

This one still does not look like the smoking gun.

What it changes:

swaps .trim() checks to normalizeOptionalString(...)
normalizes:
- result.payloads?.[0]?.text
- runResult.meta?.agentMeta?.sessionId
- some group/session metadata fields

Why I’m not sold:

it does not change transcript write logic itself
it does not change Gemini parsing

#

it does not change payload assembly shape
if anything, it should make empty-string detection safer, not make good Gemini replies vanish

So I’d mark this low-to-medium suspicion, not top suspect.

`b04dd6d05c` `refactor: consolidate session history sanitization`

From the visible diff, this looks even less relevant.

What I can see is mostly:

Anthropic/tool-call history sanitization
test changes around toolUse / toolCall / toolResult
empty aborted tool-only assistant turn handling

That smells like:

history cleanup for tool-call transcripts

#

not Gemini CLI text reply persistence

Unless the hidden non-test part of the diff does something broader, I would not put this near the top either.

So where does that leave us?

After seeing these, my suspicion shifts more toward:

0f224724dc Agents: slim cli-runner test seams
d0562a873f perf(agents): extract cli runner image and approval seams
c39f061003 / ef923805f5
the CLI backend revert pair

Those still feel more likely to affect:

how CLI results are produced
what gets handed back to reply execution

#

whether the final assistant payload is in the shape transcript persistence expects

Next one I’d inspect

git --no-pager show 0f224724dc

If you paste that, I think we’ll either find the real suspect or at least narrow it hard.

next axle Apr 16, 2026, 1:47 AM

#

https://pastebin.com/raw/bepuL6Km

clear palmBOT Apr 16, 2026, 1:47 AM

#

Checking 0f224724dc now.

#

This one looks like a dud for your bug.

`0f224724dc` looks unlikely

What it actually changes in production code:

src/agents/cli-output.ts
- replaces an imported isClaudeCliProvider(...) with a tiny local helper
src/agents/cli-runner/helpers.ts
- same thing, local Claude helper
src/agents/cli-runner/prepare.ts
- moves MCP loopback runtime imports to a split file
src/gateway/mcp-http.loopback-runtime.ts
- new extracted MCP loopback runtime module

That is basically:

test seam cleanup

#

Claude helper dedupe
MCP runtime extraction

Why I don’t think it’s your culprit

It does not touch:

Gemini payload parsing logic
transcript persistence
session history writing
final assistant payload assembly

Unless your broken Gemini runs depend on some weird MCP/tooling side effect, this looks very low probability.

So far

From the commits we inspected:

d56831f81b → probably not it

#

b514d61000 → probably not it
b04dd6d05c → probably not it
0f224724dc → probably not it

Next best move

I’d inspect:

git --no-pager show d0562a873f

If that also looks clean, I think we should broaden the search, because the real regression may be outside the initial suspected file list.

For example, next search range:

#

git log --oneline v2026.4.5..v2026.4.14 -- \
  src/auto-reply/reply \
  src/config/sessions \
  src/agents/pi-embedded-runner \
  src/agents

and filter for:

rg 'transcript|history|payload|assistantTexts|finalAssistantVisibleText|sessionId|cliSessionBinding'

If you want, send d0562a873f next, and if that’s also boring I’ll help you widen the net.

next axle Apr 16, 2026, 1:49 AM

#

https://pastebin.com/raw/pYBd8z5B

clear palmBOT Apr 16, 2026, 1:49 AM

#

Checking d0562a873f now.

#

Yep, d0562a873f also looks basically unrelated.

From the visible diff it’s mostly:

exec approval tests
image helper seams
test plumbing
no obvious Gemini transcript/session persistence change

So I’d stop burning time on these initial “CLI runner refactor” commits. They’re looking like noise.

New plan: search by behavior, not just file list

I’d broaden and search for commits that touch the actual failure shape:

final assistant payload creation
transcript persistence
CLI session binding/sessionId propagation

#

server-chat event emission

Good next commands

git log --oneline --reverse v2026.4.5..v2026.4.14 -- \
  src/auto-reply/reply/agent-runner-execution.ts \
  src/auto-reply/reply/agent-runner.ts \
  src/config/sessions \
  src/gateway/cli-session-history.ts \
  src/agents/pi-embedded-runner

And even better, search by code patterns:

git log -p v2026.4.5..v2026.4.14 -G 'payloads|cliSessionBinding|sessionId|finalAssistantVisibleText|emitAgentEvent|transcript|assistantTexts' -- \

#

  src/auto-reply/reply/agent-runner-execution.ts \
  src/auto-reply/reply/agent-runner.ts \
  src/config/sessions \
  src/agents/pi-embedded-runner \
  src/gateway/cli-session-history.ts

What I think now

The offending commit is probably outside the Gemini-specific diffs we already checked.

It smells more like a generic regression in:

how CLI results become final assistant payloads
or how those payloads get persisted into session history

If you paste the next narrowed commit list from that broader search, I think we’ll get much closer.

next axle Apr 16, 2026, 1:54 AM

#

pastebin does not accept huge dump so I switched to my own solution: https://app.trung0246.com/file/_view/iir8uh7qaw4y/error.txt

clear palmBOT Apr 16, 2026, 1:54 AM

#

Got it, I’ll read that dump and pull out the actually interesting commits instead of making you paste giant logs.

#

Oh, this one is actually interesting.

Why `fecd4fcc` is different

Unlike the earlier diffs, this changes real runtime behavior in:

src/agents/pi-embedded-runner/run/attempt.ts
src/agents/pi-embedded-runner/run/attempt.context-engine-helpers.ts

And it changes when new messages are considered “post-prompt”, plus how the context engine:

afterTurn(...)
ingestBatch(...)
assemble(...)

runs across iterations.

Why that matters

#

Your symptom is basically:

Gemini CLI still runs
raw output exists
old history exists
new turns stop showing up properly

This commit introduces fencepost-ish logic around:

prePromptMessageCount
“new messages since last iteration”
returning an assembled view instead of source messages

That is the first diff I’ve seen that could plausibly cause:

recent turns to get skipped
or the runner/UI to keep exposing an older assembled view

#

especially on resumed / multi-turn flows

Is it a perfect match?

Not quite.

It still smells more like context/compaction behavior than direct JSONL transcript append logic.

But compared to the other commits, this is the first one I would not dismiss.

My take

I’d mark this:

much more suspicious than the previous commits
especially because it’s recent and touches message lifecycle logic directly

Best next move

If you’re bisecting, I’d absolutely test this commit boundary.

#

If you want one more targeted check, look for whether your broken google-gemini-cli session is going through a context-engine-owned compaction path. If yes, this commit jumps way up the suspect list.

So yeah, finally, this one smells real.

next axle Apr 16, 2026, 2:00 AM

#

Hmm I think there's more commit in the dump. Can you check further to see if https://github.com/openclaw/openclaw/commit/fecd4fcc is actualyl the cause?

clear palmBOT Apr 16, 2026, 2:01 AM

#

Yeah, let me read further down the dump before we blame fecd4fcc. I don’t want to call the wrong commit.

#

I checked further.

What I found

The next visible commit after fecd4fcc is:

14779eaeb0 fix: recover reasoning-only OpenAI turns (#66167)

That one is OpenAI-specific and doesn’t look relevant to your google-gemini-cli history issue.

So is `fecd4fcc` the cause?

Maybe, but not proven.
From the dump so far, it is still the strongest candidate I’ve seen.

Why:

it changes real runtime message lifecycle logic
it affects per-iteration afterTurn / ingest / assemble

#

it can change whether the runner exposes raw source messages vs an assembled/cached view
that is much closer to your “new turns stop showing up” symptom than the other commits

Important caveat

If you already know the bug was present on a build before Apr 14, then fecd4fcc cannot be the first bad commit.

That’s the main thing stopping me from calling it definitively.

Best way to confirm fast

Test the exact boundary:

git checkout fecd4fcc^
# test gemini-cli history

git checkout fecd4fcc

#

# test again

If parent is good and fecd4fcc is bad, then yep, that’s your culprit.

My current verdict

Most suspicious commit so far: fecd4fcc
Not enough evidence yet to say 100%
If v2026.4.12 was already bad, then keep looking earlier

If you want, I can help turn this into a very tight 2-commit confirmation test so you can verify it quickly.

next axle Apr 16, 2026, 2:02 AM

#

Are those 2 only?

clear palmBOT Apr 16, 2026, 2:02 AM

#

No, probably not, those are just the ones I could see before the fetch got truncated.

So:

not only 2 commits in the dump
just 2 visible in the chunk I could read clearly
the remote fetch cut off the rest

Fast way to list all commits from your dump locally

If your dump is in a file:

grep '^commit ' error.txt

Or with line numbers:

#

grep -n '^commit ' error.txt

That’ll show every commit block in the dump.

If you want the commits after `fecd4fcc`

Use the line number from the second command, then print a slice after it:

sed -n 'START,ENDp' error.txt

For example:

#

grep -n '^commit ' error.txt
sed -n '200,420p' error.txt

If you paste just the commit headers after fecd4fcc, I can tell you which ones are worth opening and which are junk.

next axle Apr 16, 2026, 2:03 AM

#

I think you can fetch then write to temp text file or something then read it chunk by chunk

clear palmBOT Apr 16, 2026, 2:04 AM

#

Yep, good call. I’m pulling it locally so I can read it in chunks instead of guessing from the truncated fetch.

#

I’ve got the whole dump locally now. Let me pull the commit messages so we can stop flying blind.

#

I fetched it and indexed the commit headers locally. Let me pull the ones that actually smell relevant to your symptom.

#

Yep, I did that. There are 54 commits in the dump, so definitely not just those first two.

From the full header list, I’d now rank the most relevant suspects like this:

Strongest suspects

594ea6e1b9
fix(agents): backfill missing sessionKey in embedded PI runner — prevents undefined key in model selection and live-switch (#60555)

This one jumps out hard because your bug smells session/history-related, and missing sessionKey can absolutely cascade into weird transcript/history behavior.
fecd4fcc55
fix(agents) context-engine: per-iteration ingest and assemble for compaction (#63555)

Still very suspicious. It changes message lifecycle/assembly directly.
c15b295a85
Run context-engine turn maintenance as idle-aware background work (#65233)

#

Also context-engine related, which might pair badly with the symptom “old history exists, new turns don’t show up”.

9eed092baa
fix: suppress commentary fallback payloads

If Gemini CLI falls into some fallback path, suppressing payloads could absolutely make messages disappear from what gets surfaced/persisted.

Medium suspects

f1c4e2f11d
fix(agents): split queued embedded compaction wrapper
b04dd6d05c
refactor: consolidate session history sanitization

Lower priority / probably noise

OpenAI reasoning / replay / tool-result overflow commits
trace / test / perf-only changes

#

clearly provider-specific OpenAI stuff

My updated take

After seeing the full list, I would not say fecd4fcc is the only plausible cause anymore.

If I were narrowing this fast, I’d inspect in this order:

git --no-pager show 594ea6e1b9
git --no-pager show fecd4fcc55
git --no-pager show c15b295a85
git --no-pager show 9eed092baa

So yeah, 594ea6e1b9 is now the one I’m most curious about.

If you paste that diff next, I think we might finally hit something real.

next axle Apr 16, 2026, 2:08 AM

#

https://pastebin.com/raw/2AwHAEuU 594ea6e1b9

clear palmBOT Apr 16, 2026, 2:09 AM

#

Nice, checking 594ea6e1b9 now.

#

I read 594ea6e1b9, and I don’t think this is the regression.

Why

This commit is basically a defensive fix:

backfill sessionKey from sessionId if caller omitted it
trim whitespace-only keys to undefined
pass the resolved sessionKey consistently into:
- hooks
- runEmbeddedAttempt(...)
- model fallback / live-switch logic

That is much more:

“prevent undefined session key weirdness”
not “drop Gemini replies from transcript history”

#

Could it still matter?

A little, yes. It proves sessionKey propagation is important.

But the direction of this change is:

more correct
more stable
less likely to lose history

So unless this introduced some wrong-key resolution edge case with stale session stores, I would not call it the bad commit.

My updated ranking

After reading this diff:

594ea6e1b9 → probably not the culprit
fecd4fcc55 → still suspicious
c15b295a85 → still suspicious
9eed092baa → now more interesting again

#

Next diff I’d inspect

git --no-pager show 9eed092baa

Reason: if your recent google-gemini-cli runs are producing something that only survives via a fallback payload path, “suppress commentary fallback payloads” could absolutely make those turns disappear from what gets surfaced/persisted.

So yeah, 594ea6e1b9 looks more like a fix in the right direction, not the regression.

next axle Apr 16, 2026, 2:10 AM

#

https://pastebin.com/raw/7YbkRrAY

clear palmBOT Apr 16, 2026, 2:11 AM

#

Checking that one now.

#

Oh, this one is very promising.

Why `9eed092baa` matches your bug much better

This commit changes fallback payload generation from:

extractAssistantText(...)
to
extractAssistantVisibleText(...)

in:

src/agents/pi-embedded-runner/run/payloads.ts

Why that matters

Before this commit, if streamed/final text was missing, OpenClaw could still fall back to any assistant text.

After this commit, it only falls back to visible/final-answer text.

#

So if your google-gemini-cli path is producing assistant text that is:

commentary-only
missing final_answer tagging
or otherwise not considered “visible text”

then payloads become:

[]

And that would line up really well with what you’re seeing:

Gemini CLI still runs
raw output still exists
but assistant payloads disappear

#

so history/transcript/UI entries stop showing up

Why I like this candidate

Date is Apr 12, which matches your suspected regression window much better
It directly touches payload creation
Empty payloads would explain “history stopped appearing” better than most of the other commits

My current ranking

This is now probably my top suspect.

Best confirmation test

Test the boundary:

git checkout 9eed092baa^
# test gemini-cli history

#When using google-gemini-cli/xxx models, chat history does shows up in openclaw webui

Best fixes, in order

My recommendation

What matters now

So the fix is to correct the runtime state path

Important side note

Next useful thing from you

Recommended workaround

Why

If you cannot use an API key

My honest read

Important nuance

What you want to see

What would confirm the mismatch

What this proves

Small nuance

So the likely regression moved one step later

Next exact check

What the result means

What that tells us

Best bug-report wording

Practical takeaway

3) But recent google-gemini-cli messages are no longer being persisted

1) Pick the range

2) Use a very small test

3) Use transcript persistence as the pass/fail signal

4) Most suspicious areas

My guess

1) Main suspect list, compact

2) Broader session/history path

3) Filter for likely keywords

4) Show one commit in detail

5) The two Gemini-specific commits I’d definitely inspect first

Highest suspicion

Medium suspicion

Lower suspicion

Probably ignore for now

If I were doing manual inspection before bisect

What it actually changes

Why I don’t think it’s the smoking gun

My read

One caveat

Next commit to inspect

My read on these two

b514d61000 refactor: dedupe reply execution readers

b04dd6d05c refactor: consolidate session history sanitization

So where does that leave us?

Next one I’d inspect

0f224724dc looks unlikely

Why I don’t think it’s your culprit

So far

Next best move

New plan: search by behavior, not just file list

Good next commands

What I think now

Why fecd4fcc is different

Why that matters

Is it a perfect match?

My take

Best next move

What I found

So is fecd4fcc the cause?

Important caveat

Best way to confirm fast

My current verdict

Fast way to list all commits from your dump locally

If you want the commits after fecd4fcc

Strongest suspects

Medium suspects

Lower priority / probably noise

My updated take

Why

Could it still matter?

My updated ranking

Next diff I’d inspect

Why 9eed092baa matches your bug much better

Why that matters

Why I like this candidate

My current ranking

Best confirmation test

3) But recent `google-gemini-cli` messages are no longer being persisted

`b514d61000` `refactor: dedupe reply execution readers`

`b04dd6d05c` `refactor: consolidate session history sanitization`

`0f224724dc` looks unlikely

Why `fecd4fcc` is different

So is `fecd4fcc` the cause?

If you want the commits after `fecd4fcc`

Why `9eed092baa` matches your bug much better