My Claw keeps forgetting who he is, and resets all data. | Friends of the Crustacean 🦞🤝 | Page 1

tidal owl Feb 5, 2026, 4:30 AM

#

When running under Linux Mint and ollama glm-4.7-flash local, my claw cant get setup. I was able to get it working in windows, but wanted to move over to linux for the lower overhead. Now, every 2-3 messages I'm back at "Hello, who am I" or some variant of that.

silent mural Feb 5, 2026, 5:09 AM

#

tidal owl When running under Linux Mint and ollama glm-4.7-flash local, my claw cant get s...

did you fix it?

lethal herald Feb 5, 2026, 5:39 AM

#

What context size are you using?

On the Ollama website itself they recommend 64k, but I had trouble with that value. Maybe 128k is the minimum that actually works. That’s a lot of VRAM. 😅

silent mural Feb 5, 2026, 5:43 AM

#

lethal herald What context size are you using? On the Ollama website itself they recommend 64...

yea but doesnt openclaw have a memory file?

lethal herald Feb 5, 2026, 5:49 AM

#

The context window and memory file serve different purposes:

Context window (64k/128k): This is how much text the model can 'see' at once during a single conversation - includes your current messages, system prompts, and any loaded memory. It's the model's immediate working memory.

Memory file: This is persistent storage that gets 'loaded into' the context window. The memory file can be large, but the model still needs enough context window space to fit: system prompts + current conversation + loaded memory content.

If your context window is too small (like the default 2k or 4k), there won't be enough room for everything, even if the memory file exists. That's why you need to increase Ollama's context size to 64k or 128k... so the model has enough 'workspace' to use the memory effectively.

tidal owl Feb 5, 2026, 12:10 PM

#

I manually edited the context to 256k, no change. It forgets everything within a couple messages. Set personality, one or two messages later less than a minute, it's "Hello, I just woke up, who are you?"

#

I've got the VRAM overhead, using glm-4.7-flash. With the model loaded I've got 4GB vram left. Watching nvtop, I can see there's not much VRAM pressure, and the GPU is processing the LLM.

tidal owl Feb 5, 2026, 11:03 PM

#

silent mural did you fix it?

No, still trying to get it to stay active past 1-2 messages. It worked fine on windows, but was a lot slower. Nothing working yet.

#

My Claw keeps forgetting who he is, and resets all data.

#

@viscid sky

viscid skyBOT Feb 5, 2026, 11:06 PM

#

tidal owl <@1457407575476801641>

⚠️ Agent failed before reply: No API key found for provider "anthropic". Auth store: /srv/clawdbot/state/agents/main/agent/auth-profiles.json (agentDir: /srv/clawdbot/state/agents/main/agent). Configure auth for this agent (clawdbot agents add <id>) or copy auth-profiles.json from the main agentDir.
Logs: clawdbot logs --follow

silent mural Feb 5, 2026, 11:33 PM

#

tidal owl No, still trying to get it to stay active past 1-2 messages. It worked fine on w...

keep up with the last commits from the source

#

trust me, i think they fixed it already

tidal owl Feb 7, 2026, 12:04 AM

#

@viscid sky

viscid skyBOT Feb 7, 2026, 12:08 AM

#

tidal owl <@1457407575476801641>

That “every 2–3 messages it’s back to ‘Hello, who am I?’” symptom is usually one of these:

Prompt/context is getting truncated (very common with local Ollama models that have a small effective context window). Once the system + tools no longer fit, the model effectively “wakes up” with no identity/instructions and starts acting like a fresh chat.
You’re not actually resuming the same session/workspace each turn (gateway restarts, multiple gateways running, or CLI/service using different state dirs/profiles).

Can you run these read-only checks on the Linux Mint box and paste the output?

openclaw --version
openclaw status --all
openclaw gateway status --deep

And then, while reproducing the “forgetting”, run:

#

openclaw logs --follow

In the log, I’m specifically looking for lines about:

context length / truncation / “context too large”
session reset / compaction
gateway crash/restart
workspace path changing (docs call this out: if the gateway uses a different workspace between runs, memory/session will look “gone”)

Also: did you ever start OpenClaw with sudo (even once)? That can silently split your state between ~/.openclaw and /root/.openclaw, which looks exactly like amnesia.

Docs refs (for later, after we see logs):

Troubleshooting checklist: https://docs.openclaw.ai/gateway/troubleshooting
Local models caveats (context + truncation): https://docs.openclaw.ai/gateway/local-models

tidal owl Feb 7, 2026, 12:26 AM

#

@viscid sky the logs are too long to send in chat

#

https://pastebin.com/KNdWbYBD

viscid skyBOT Feb 7, 2026, 12:26 AM

#

tidal owl <@1457407575476801641> the logs are too long to send in chat

Totally fine — don’t paste the whole thing. We just need a small tail + a few filtered lines.

Option A (best / safe to share):
Run this and paste/attach the output file (Discord upload is perfect):

openclaw status --all > status.txt

That report is designed to be shareable (it redacts secrets) and includes useful log tail.

Option B (log tail only):

openclaw logs --limit 200 > logtail.txt

Option C (super targeted “why did it reset?” lines):

#

openclaw logs --limit 1000 | grep -iE "hello|who am i|reset|compac|truncate|context|too large|oom|killed|crash|restart|workspace|session" > suspect.txt

Also please paste just these (short) command outputs:

openclaw --version
openclaw gateway status

With those, I can usually tell if it’s:

gateway restarting (OOM/crash/service bouncing), or
context truncation from the local Ollama model (super common), or
session reset settings / wrong workspace (editing one config, service using another).

#

The paste helps a lot — you’ve got two big red flags in there that can absolutely look like “my Claw forgot who he is”:

1) You have a port fight / double-gateway situation

openclaw status --all says:

Port 18789 is already in use
listener: pid 298910 ... openclaw-gateway (127.0.0.1:18789)

And openclaw gateway status --deep says the systemd service is crash-looping:

Runtime: stopped (state activating, ... last exit 1)
but RPC probe is ok (meaning something else is answering on that port)

So: your systemd service is repeatedly trying to start, but can’t because another gateway instance is already running. Depending on timing, your UI can effectively bounce between “fresh” and “old” state.

Fix: make sure only one gateway exists. I’d pick the systemd service.

#

Run:

openclaw gateway stop
lsof -nP -iTCP:18789 -sTCP:LISTEN

If lsof still shows something listening, paste that output (just a few lines). Then:

openclaw gateway start
openclaw gateway status

Goal: no “port already in use” warnings, and gateway status shows Runtime: running cleanly.

2) Your agent is still “Bootstrap PENDING”

#

In your status:

Agent main Bootstrap: PENDING

That means OpenClaw thinks the agent hasn’t fully “hatched” its workspace/bootstrap yet — so if you keep ending up in what OpenClaw considers a new session, it’ll keep redoing the “who am I / getting started” vibe.

After the port fight is fixed: check your Ollama context size

Even with one gateway, local models can “forget” fast if the effective context window is small.

Can you paste the output of:

openclaw models status
openclaw models list --provider ollama

(Those are usually short enough.)

#

If that shows a small contextWindow for glm-4.7-flash:latest (or if it isn’t being detected right), that would explain the “every few messages” reset feeling.

Docs that match what you’re running:

Ollama provider + discovery + contextWindow behavior: https://docs.openclaw.ai/providers/ollama
General local-model caveats (context matters a lot): https://docs.openclaw.ai/gateway/local-models

tidal owl Feb 7, 2026, 12:30 AM

#

$ openclaw --version
2026.2.3-1
OpenClaw status --all
Overview
│ Version │ 2026.2.3-1 │
│ OS │ linux 6.14.0-37-generic (x64) │
│ Node │ 22.22.0 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off · Running · b-ms-7d70.comet-geological.ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.3-1 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · │
│ │ reachable 10ms · auth token │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ brandon-MS-7D70 (192.168.1.81) app unknown linux 6.14.0- │
│ │ 37-generic │
│ Gateway service │ systemd installed · enabled · running (pid 1828712) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 1 bootstrapping · 1 active · 1 sessions │
└─────────────────┴───────────────────────────────────────────────────────────┘
Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────┤
└──────────┴─────────┴────────┴───────────────────────────────────────────────┘

#

Agents
┌────────────┬───────────┬──────────┬──────────┬──────────────────────────────┐
│ Agent │ Bootstrap │ Sessions │ Active │ Store │
├────────────┼───────────┼──────────┼──────────┼──────────────────────────────┤
│ main │ PENDING │ 1 │ 1m ago │ ~/.openclaw/agents/main/ │
│ │ │ │ │ sessions/sessions.json │
└────────────┴───────────┴──────────┴──────────┴──────────────────────────────┘
Diagnosis (read-only)
Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/b/.openclaw/openclaw.json
Bind: loopback
✓ Config: /home/b/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 298910 b: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
✓ Tailscale: off · Running · b-ms-7d70.comet-geological.ts.net
ips: 100.113.131.124, fd7a:115c:a1e0::ed33:837c
✓ Skills: 3 eligible · 0 missing · /home/b/.openclaw/workspace
✓ Channel issues (none)
Pasteable debug report. Auth tokens redacted.

viscid skyBOT Feb 7, 2026, 12:31 AM

#

tidal owl $ openclaw --version 2026.2.3-1 OpenClaw status --all Overview │ Version ...

That output is consistent with what was in your pastebin earlier: something is unstable around the gateway process, and that can absolutely feel like “it forgot everything”.

Two things to check next (both short outputs):

1) Make sure you don’t have two gateways fighting over port 18789

In your earlier status --all it literally said “Port 18789 is already in use” by another openclaw-gateway PID.

Run:

lsof -nP -iTCP:18789 -sTCP:LISTEN
openclaw gateway status --deep

If lsof shows a PID that’s not the systemd service one, paste those lines. The fix is: stop the extra “manual” gateway process so only the systemd service owns the port (otherwise systemd will crash-loop / restart and your UI will effectively bounce).

2) Your runs show `messageChannel=webchat` and `sessionKey=unknown`

#

That’s a red flag for “web UI isn’t providing a stable session identity”, which can cause new sessions / re-bootstrap vibes.

Quick questions:

Are you chatting via the Control UI/web chat (browser), and is it possibly incognito/private?
Do you sometimes open http://localhost:18789/ and other times http://127.0.0.1:18789/? (different origin = different local storage = different device identity/session)

If you answer “maybe”: try one clean test in a normal (non-incognito) Chrome/Firefox window and always use the exact same URL.

Next: check Ollama context window (often the “every 2-3 messages” culprit)

Paste:

openclaw models status
openclaw models list --provider ollama

If the contextWindow is small (8k-ish), the system/tool prompt can crowd out “who you are” very quickly on local models.

#

Yep — this is the smoking gun:

Port 18789 is already in use
pid 298910 ... openclaw-gateway (127.0.0.1:18789)
plus Bootstrap: PENDING

That means you’ve almost certainly got two gateway instances stepping on each other (often: one started manually in a terminal + the systemd user service). When the gateway bounces or you land on the “other” instance, it feels exactly like the bot “forgot who he is”.

Fix: make it one gateway (recommended: keep the systemd service)

Run these in order and paste the short outputs:

Stop the systemd-managed gateway

openclaw gateway stop

#

See what is still listening

lsof -nP -iTCP:18789 -sTCP:LISTEN

If it still shows pid 298910 (or anything at all), show what it is:

ps -fp 298910

Kill the leftover manual gateway (only if it’s still listening)

kill -TERM 298910
sleep 1
lsof -nP -iTCP:18789 -sTCP:LISTEN

(If it still won’t die, tell me and we’ll do the least-bad next step.)

#

Start the gateway cleanly

openclaw gateway start
openclaw gateway status
openclaw status --all | sed -n '1,120p'

After this, status --all should NOT show “Port 18789 already in use”.

Why this also affects “Bootstrap: PENDING”

With a flaky/restarting gateway, you keep ending up in “first run / bootstrap” behavior. Also: if ~/.openclaw/workspace/BOOTSTRAP.md still exists, OpenClaw will continue to consider bootstrap incomplete (and it also adds prompt weight, which hurts small-context local models).

Once the gateway is stable, check:

ls -la ~/.openclaw/workspace | grep -i bootstrap || true

#

Post the outputs from steps (2) + (4) and we’ll take the next bite (either finishing bootstrap cleanly, or moving on to your Ollama context window if it’s still “forgetting” after the gateway is stable).

tidal owl Feb 7, 2026, 12:34 AM

#

It is the browser, and not private browsing.

lsof -nP -iTCP:18789 -sTCP:LISTEN has no output.

viscid skyBOT Feb 7, 2026, 12:34 AM

#

tidal owl It is the browser, and not private browsing. lsof -nP -iTCP:18789 -sTCP:LISTEN...

If lsof ...18789... has no output, that means nothing is listening on the gateway port right now (so the browser UI would be talking to “nothing”, or you’re on a different port/URL than you think).

Let’s get back to a single, stable gateway:

1) Start the gateway, then confirm it’s actually listening

Run:

openclaw gateway start
openclaw gateway status --deep
lsof -nP -iTCP:18789 -sTCP:LISTEN

Paste the Runtime/RPC probe lines from gateway status --deep + whatever lsof prints.

What we want to see:

Runtime: running

#

RPC probe: ok
and lsof shows one listener on 127.0.0.1:18789 (owned by openclaw)

2) Make sure your browser is hitting exactly the same origin every time

Stick to one of these and don’t mix:

http://127.0.0.1:18789/ (recommended)
OR http://localhost:18789/

Don’t use http://192.168.1.81:18789/ while debugging — non-localhost HTTP can cause identity/session weirdness (docs call out HTTP issues when not localhost).

3) After the gateway is stable, check the Ollama model context window

Then run (and paste):

openclaw models status
openclaw models list --provider ollama

#

If glm-4.7-flash is effectively small-context, it can “forget” fast even when sessions are working — but first we need the gateway reliably up (right now it looks like it’s not listening at all).

tidal owl Feb 7, 2026, 12:36 AM

#

RPC probe: failed
RPC target: ws://127.0.0.1:18789
gateway closed (1006 abnormal closure (no close frame)): no close reason
Gateway target: ws://127.0.0.1:18789
Source: cli --url
Config: /home/brandon/.openclaw/openclaw.json
Gateway port 18789 is not listening (service appears running).
Logs: journalctl --user -u openclaw-gateway.service -n 200 --no-pager

openclaw gateway status --deep has no output.

#

but the gateway did go down and successfully start back up with "openclaw gateway stop" and "openclaw gateway start"

#

2026-02-07T00:19:37.944Z debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
2026-02-07T00:19:37.944Z debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=1 queueSize=0
2026-02-07T00:19:37.955Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=ee4e8882-f331-4fc6-9aa1-643f418ae9b1 sessionId=0fbaa250-0503-42d2-8367-c868e726fccd provider=ollama model=glm-4.7-flash:latest thinking=off messageChannel=webchat
2026-02-07T00:19:37.962Z debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=0fbaa250-0503-42d2-8367-c868e726fccd sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
2026-02-07T00:19:37.963Z debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=0fbaa250-0503-42d2-8367-c868e726fccd totalActive=1
2026-02-07T00:19:37.963Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=ee4e8882-f331-4fc6-9aa1-643f418ae9b1 sessionId=0fbaa250-0503-42d2-8367-c868e726fccd
2026-02-07T00:19:42.215Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=ee4e8882-f331-4fc6-9aa1-643f418ae9b1 sessionId=0fbaa250-0503-42d2-8367-c868e726fccd durationMs=4252
2026-02-07T00:19:42.216Z debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=0fbaa250-0503-42d2-8367-c868e726fccd sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
2026-02-07T00:19:42.216Z debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=0fbaa250-0503-42d2-8367-c868e726fccd totalActive=0
2026-02-07T00:19:42.217Z debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=ee4e8882-f331-4fc6-9aa1-643f418ae9b1 sessionId=0fbaa250-0503-42d2-8367-c868e726fccd durationMs=4272 aborted=false
2026-02-07T00:19:42.218Z debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=4273 active=0 queued=0

#

@viscid sky

viscid skyBOT Feb 7, 2026, 12:47 AM

#

tidal owl RPC probe: failed RPC target: ws://127.0.0.1:18789 gateway closed (1006 abnorm...

That “gateway port 18789 is not listening (service appears running) + 1006 abnormal closure” means the gateway process is crashing/exiting immediately (or you’re accidentally looking at a different user’s service/state).

One huge clue: earlier your config path was /home/b/... and now it’s /home/brandon/.... If you ever ran install/start under a different Linux user, you can end up with two separate ~/.openclaw state dirs + two separate systemd user services, which looks exactly like resets/weird bootstrap.

1) Confirm you’re always running as the same Linux user

Please run and paste:

whoami
echo $HOME
ls -la ~/.openclaw | head

2) Get the actual systemd failure reason (this is the key)

These should be short enough:

#

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

(If you want to filter it further:)

journalctl --user -u openclaw-gateway.service -n 400 --no-pager | grep -iE "error|fatal|exception|listen|bind|EADDRINUSE|config|invalid" | tail -n 80

3) Also check if anything “openclaw gateway-ish” is still running

pgrep -af "openclaw|gateway" | head -n 50

Once I see the journalctl tail, I can tell you exactly why it’s exiting (common ones: config invalid, missing env, wrong node path, or still a hidden port conflict).

#

Got it — if lsof ...18789... is empty and you’re seeing:

RPC probe: failed / 1006 abnormal closure
“Gateway port 18789 is not listening (service appears running)”

…then the gateway is almost certainly starting and immediately crashing/exiting, and the CLI is just catching the dead socket.

1) We need the actual crash reason (paste the last ~50-120 lines)

Run these and paste output:

whoami
echo $HOME

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

#

Also grab the file log tail (works even when RPC is dead):

ls -t /tmp/openclaw/openclaw-*.log | head -3
tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

That will usually show the exact fatal (config invalid, module load failure, bind error, etc.).

2) Why you keep seeing “Hello, who am I?”

Your status shows Bootstrap: PENDING. That “Hello who am I” line is literally from BOOTSTRAP.md (it’s the first-run script). If your session keeps getting treated as “new” (because the gateway crashes/restarts), BOOTSTRAP gets injected again and you’ll see that prompt.

Once the gateway is stable, you can stop that permanently by finishing bootstrap (or just removing the bootstrap script). Quick safe test (non-destructive): rename it:

ls -la ~/.openclaw/workspace | grep -i BOOTSTRAP || true

#

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done

(You can always rename it back.)

3) One more oddity: `/home/b/...` vs `/home/brandon/...`

Earlier output referenced /home/b/.openclaw, now /home/brandon/.openclaw. If you’ve ever run OpenClaw under two different Linux users, you’ll effectively have two different bots (two state dirs, two services), which also looks like “amnesia”.

The whoami + $HOME above will confirm which user owns the service we’re debugging.

Paste those logs and I’ll tell you exactly what’s killing the gateway.

tidal owl Feb 7, 2026, 12:53 AM

#

brandon@brandon-MS-7D70:~$ whoami
echo $HOME
ls -la ~/.openclaw | head
brandon
/home/brandon
total 60
drwxr-xr-x 9 brandon brandon 4096 Feb 6 19:07 .
drwxr-x--- 23 brandon brandon 4096 Feb 6 19:50 ..
drwx------ 3 brandon brandon 4096 Feb 4 23:20 agents
drwxrwxr-x 2 brandon brandon 4096 Feb 4 23:21 canvas
drwxrwxr-x 2 brandon brandon 4096 Feb 6 19:07 completions
drwxrwxr-x 2 brandon brandon 4096 Feb 6 19:49 cron
drwxrwxr-x 2 brandon brandon 4096 Feb 6 19:49 devices
drwxrwxr-x 2 brandon brandon 4096 Feb 4 23:21 identity
-rw------- 1 brandon brandon 1592 Feb 5 07:06 openclaw.json
brandon@brandon-MS-7D70:~$

viscid skyBOT Feb 7, 2026, 12:54 AM

#

tidal owl brandon@brandon-MS-7D70:~$ whoami echo $HOME ls -la ~/.openclaw | head brandon /...

Nice — that confirms you’re consistently running as brandon and your state dir is ~/.openclaw.

But we still need to explain two things we’ve already seen in your earlier outputs:

At one point, something owned by user b was listening on 18789 (pid 298910 b: openclaw-gateway ...).
Right now you’re getting “service appears running, but port 18789 is not listening” + 1006 → classic “started then immediately died” / crash-loop.

Step 1: verify nobody else is running a gateway (especially user `b`)

Run and paste output:

ps -eo user,pid,cmd | grep -E "openclaw.*gateway|openclaw-gateway" | grep -v grep

If you see anything under user b (or multiple lines), that’s the “two gateways fighting” problem.

Step 2: get the actual crash reason from systemd + logs (this is the key)

#

Paste these (they’re usually not huge):

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

And also paste the last bit of the file log (works even when RPC is dead):

ls -t /tmp/openclaw/openclaw-*.log | head -3
tail -n 120 "$(ls -t /tmp/openclaw/openclaw-*.log | head -1)"

Once I can see the first “FATAL/ERROR” in those logs, we’ll know exactly why it’s exiting (config error, bind error, missing dependency, etc.).

Step 3 (optional but likely relevant): you’re still “Bootstrap: PENDING”

#

If BOOTSTRAP.md is still present, OpenClaw will keep injecting the “hello who am I” bootstrap instructions whenever a new session happens (and crashes/restarts tend to force that).

Check:

ls -la ~/.openclaw/workspace | grep -i BOOTSTRAP || true

If it exists, the quick non-destructive fix is:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done

Send the outputs from Step 1 + Step 2 and we’ll get your gateway stable first — once the gateway stops flapping, the “amnesia every few messages” usually disappears.

tidal owl Feb 7, 2026, 12:58 AM

#

brandon@brandon-MS-7D70:~$ ps -eo user,pid,cmd | grep -E "openclaw.*gateway|openclaw-gateway" | grep -v grep
brandon 1849956 openclaw-gateway
brandon@brandon-MS-7D70:~$
Loaded: loaded (/home/brandon/.config/systemd/user/openclaw-gateway.service; enabled; preset: enabled)
Active: active (running) since Fri 2026-02-06 19:49:55 EST; 7min ago
Main PID: 1849956 (openclaw-gatewa)
Tasks: 43 (limit: 37151)
Memory: 287.1M (peak: 342.6M)
CPU: 3.163s
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/openclaw-gateway.service
└─1849956 openclaw-gateway

Feb 06 19:49:55 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Sch… 3.
Feb 06 19:49:55 brandon-MS-7D70 systemd[1488]: Started openclaw-gateway.serv…3).
Feb 06 19:49:56 brandon-MS-7D70 node[1849956]: 2026-02-07T00:49:56.944Z [can…as)
Feb 06 19:49:56 brandon-MS-7D70 node[1849956]: 2026-02-07T00:49:56.970Z [hea…ted
Feb 06 19:49:56 brandon-MS-7D70 node[1849956]: 2026-02-07T00:49:56.972Z [gat…est
Feb 06 19:49:56 brandon-MS-7D70 node[1849956]: 2026-02-07T00:49:56.973Z [gat…56)
Feb 06 19:49:56 brandon-MS-7D70 node[1849956]: 2026-02-07T00:49:56.973Z [gat…789
Feb 06 19:49:56 brandon-MS-7D70 node[1849956]: 2026-02-07T00:49:56.974Z [gat…log
Feb 06 19:49:56 brandon-MS-7D70 node[1849956]: 2026-02-07T00:49:56.976Z [bro…=2)

#

eb 06 19:14:42 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE
Feb 06 19:14:42 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Failed with result 'exit-code'.
Feb 06 19:14:42 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Consumed 1.601s CPU time.
Feb 06 19:14:47 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Scheduled restart job, restart counter is at 11569.
Feb 06 19:14:47 brandon-MS-7D70 systemd[1488]: Started openclaw-gateway.service - OpenClaw Gateway (v2026.2.2-3).
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: 2026-02-07T00:14:53.595Z Gateway failed to start: gateway already running (pid 298910); lock timeout after 5000ms
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: If the gateway is supervised, stop it with: openclaw gateway stop
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: 2026-02-07T00:14:53.668Z Port 18789 is already in use.
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: 2026-02-07T00:14:53.669Z - pid 298910 brandon: openclaw-gateway (127.0.0.1:18789)
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: 2026-02-07T00:14:53.669Z - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: 2026-02-07T00:14:53.686Z Gateway service appears enabled. Stop it first.
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: 2026-02-07T00:14:53.687Z Tip: openclaw gateway stop
Feb 06 19:14:53 brandon-MS-7D70 node[1829974]: 2026-02-07T00:14:53.687Z Or: systemctl --user stop openclaw-gateway.service
Feb 06 19:14:53 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Main process exited, code=exited, status=1/FAILURE
Feb 06 19:14:53 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Failed with result 'exit-code'.
Feb 06 19:14:53 brandon-MS-7D70 systemd[1488]: openclaw-gateway.service: Consumed 1.634s CPU time.

viscid skyBOT Feb 7, 2026, 1:00 AM

#

tidal owl brandon@brandon-MS-7D70:~$ ps -eo user,pid,cmd | grep -E "openclaw.*gateway|open...

Perfect — this looks much healthier now:

ps ... shows only one gateway process, owned by brandon (PID 1849956)
systemctl --user status shows the service is active (running)

So the earlier “two gateways fighting / port in use / not listening” situation seems resolved.

Next: confirm it’s actually listening on 18789 right now

Run (either is fine):

lsof -nP -iTCP:18789 -sTCP:LISTEN
# or (often works even when lsof is weird)
ss -ltnp | grep 18789 || true

You should see openclaw-gateway bound to 127.0.0.1:18789.

#

The “Hello, who am I” part: you’re still in Bootstrap mode

Your earlier status --all showed:

Agent main Bootstrap: PENDING

That usually means ~/.openclaw/workspace/BOOTSTRAP.md still exists, and when a new session happens the bot is being instructed to start with that “who am I” bootstrap script.

Check and (non-destructively) disable it:

ls -la ~/.openclaw/workspace | grep -i BOOTSTRAP || true
mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done
openclaw gateway restart

Then re-run:

#

openclaw status --all

and confirm Bootstrap is no longer PENDING.

If it still “forgets” after bootstrap is gone: it’s likely the Ollama context window

At that point, paste:

openclaw models status
openclaw models list --provider ollama

What I’m looking for is the contextWindow OpenClaw thinks your glm-4.7-flash:latest has. If it’s small, you’ll get “amnesia” fast even with perfect session storage (the session is saved, but the model can’t fit enough history to behave consistent).

(Reference: Ollama provider + how OpenClaw reads contextWindow: https://docs.openclaw.ai/providers/ollama)

#

Those journal lines confirm the root cause from earlier:

systemd was trying to start the gateway
but it kept failing with “gateway already running (pid 298910)” / “Port 18789 is already in use”
so it went into a massive restart loop (restart counter …)

That kind of flapping absolutely makes WebChat feel like it “forgets / resets”.

Where you are now

Your latest ps output shows only one gateway process (PID 1849956) and systemd says active (running) — good.

Do these 2 quick “are we stable?” checks

Confirm it’s actually listening on 18789:

ss -ltnp | grep 18789 || true
# (or lsof again)

#

lsof -nP -iTCP:18789 -sTCP:LISTEN

Clear the huge restart-failed state (optional, but nice cleanup):

systemctl --user reset-failed openclaw-gateway.service

Fix the “Hello, who am I” loop (Bootstrap is still PENDING)

That exact line comes from BOOTSTRAP.md. If bootstrap is still pending, it can keep re-injecting that “who am I” script when sessions restart.

Check if the file exists:

ls -la ~/.openclaw/workspace | grep -i BOOTSTRAP || true

tidal owl Feb 7, 2026, 1:01 AM

#

LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(("openclaw-gatewa",pid=1849956,fd=23))
LISTEN 0 511 [::1]:18789 [::]:* users:(("openclaw-gatewa",pid=1849956,fd=24))

viscid skyBOT Feb 7, 2026, 1:01 AM

#

If it exists, disable it (non-destructive) + restart:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done
openclaw gateway restart
openclaw status --all

After that, status --all should no longer show Bootstrap: PENDING.

If you do the above and it still “forgets every 2-3 messages”, next thing to check is the Ollama context window (local models often feel like amnesia when context is tight):

openclaw models status
openclaw models list --provider ollama

viscid skyBOT Feb 7, 2026, 1:02 AM

#

tidal owl LISTEN 0 511 127.0.0.1:18789 0.0.0.0:* users:(...

Great — that confirms the gateway is now stable and actually listening on 127.0.0.1:18789 (single PID 1849956). So the “gateway flapping” problem is fixed.

Now we should eliminate the bootstrap loop, because that’s the direct source of the “Hello, who am I?” behavior.

1) Check if BOOTSTRAP.md still exists

Run:

ls -la ~/.openclaw/workspace | grep -i BOOTSTRAP || true

If it prints a BOOTSTRAP.md, do this (non-destructive) and restart:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done
openclaw gateway restart

#

openclaw status --all

After that, status --all should no longer show Bootstrap: PENDING.

2) If you still get “amnesia every 2-3 messages” after bootstrap is gone

Then it’s almost certainly the Ollama context window being too small for OpenClaw’s system/tools prompt + chat history.

Paste:

openclaw models status
openclaw models list --provider ollama

I’m looking for the contextWindow OpenClaw detects for glm-4.7-flash:latest. If it’s ~8k (or similarly small), it will feel like resets even though sessions are saving correctly.

tidal owl Feb 7, 2026, 1:05 AM

#

brandon@brandon-MS-7D70:~$ openclaw models status
openclaw models list --provider ollama

🦞 OpenClaw 2026.2.3-1 (d84eb46) — Pairing codes exist because even bots believe in consent—and good security hygiene.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/glm-4.7-flash:latest
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

ollama effective=models.json:ollama-local | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none

🦞 OpenClaw 2026.2.3-1 (d84eb46) — I can run local, remote, or purely on vibes—results may vary with DNS.

Model Input Ctx Local Auth Tags
ollama/glm-4.7-flash:latest text 128k yes yes default

viscid skyBOT Feb 7, 2026, 1:06 AM

#

tidal owl brandon@brandon-MS-7D70:~$ openclaw models status openclaw models list --provide...

Awesome — this rules out the “local model too small” theory:

You’re on ollama/glm-4.7-flash:latest
Ctx = 128k
Gateway is now properly listening on 127.0.0.1:18789 (single PID)

So if you’re still seeing “Hello, who am I?”, the most likely cause is simply:

BOOTSTRAP.md is still present → bootstrap keeps getting injected

Your earlier status --all showed Bootstrap: PENDING, and that “Hello, who am I?” line is literally the default BOOTSTRAP script.

Run:

ls -la ~/.openclaw/workspace | grep -i bootstrap || true

#

If you see BOOTSTRAP.md, disable it (non-destructive) and restart:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.done
openclaw gateway restart
openclaw status --all

Expected result: Bootstrap no longer says PENDING, and the “who am I” loop stops.

If it still happens after BOOTSTRAP is gone

Then it’s not the model/context — it’s session resets. Quick check: paste just the session block from your config:

#

openclaw config get session
# if that doesn't work on your version:
grep -n "session" ~/.openclaw/openclaw.json

(We’re looking for something like session.reset.idleMinutes set super low, or custom reset triggers.)

Tell me what you get from the BOOTSTRAP check first — that’s usually the whole fix.

tidal owl Feb 7, 2026, 1:14 AM

#

Bootsrap.md has been renamed, there is no session section in my config, and it did it again

viscid skyBOT Feb 7, 2026, 1:16 AM

#

tidal owl Bootsrap.md has been renamed, there is no session section in my config, and it d...

Ok — with gateway stable, Ctx=128k, and BOOTSTRAP.md renamed, the only way you keep getting a “freshly booted” vibe every few messages is: you’re not staying in the same session key (WebChat is effectively creating a new chat identity / new session), or the gateway still thinks the agent is in bootstrap mode for some other reason.

Let’s prove which one it is with two quick checks.

1) After it happens again: in the WebChat UI, send these as standalone messages

/status
/context list

Then paste the outputs here.

What I’m looking for:

does /status show a different session id/key before vs after the “reset”?
does /context list still show bootstrap-ish injected files (missing markers, BOOTSTRAP, etc.)?

2) From the terminal: show whether you’re accumulating lots of sessions

Run this (safe, read-only):

#

python3 - <<'PY'
import json, pathlib
p = pathlib.Path.home()/'.openclaw/agents/main/sessions/sessions.json'
d = json.loads(p.read_text())
print("session_count:", len(d))
print("sample_keys:")
for k in list(d.keys())[:25]:
print(" ", k)
PY

If session_count keeps growing when you chat, that means WebChat is minting new session keys (so you will see “who am I” style resets no matter what the model context is).

3) One more sanity check: does OpenClaw still think bootstrap is pending?

Paste just this section from:

#

openclaw status --all

Specifically the Agents table line that includes Bootstrap (PENDING or not).

If you paste /status + /context list from WebChat, we’ll be able to say confidently: “this is a WebChat session identity issue” vs “bootstrap still being injected”, and then I can give you the exact fix (or if it’s a WebChat bug, the exact info to include in a GitHub issue).

tidal owl Feb 7, 2026, 1:18 AM

#

🦞 OpenClaw 2026.2.3-1 (d84eb46)
🧠 Model: ollama/glm-4.7-flash:latest · 🔑 api-key ollama…-local (models.json)
🧮 Tokens: 4.1k in / 414 out
📚 Context: 4.1k/256k (2%) · 🧹 Compactions: 0
🧵 Session: agent:main:main • updated just now
⚙️ Runtime: direct · Think: off
🪢 Queue: collect (depth 0)

🧠 Context breakdown
Workspace: /home/brandon/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 22,071 chars (~5,518 tok) (Project Context 11,988 chars (~2,997 tok))

Injected workspace files:

AGENTS.md: OK | raw 7,804 chars (~1,951 tok) | injected 7,804 chars (~1,951 tok)
SOUL.md: OK | raw 1,664 chars (~416 tok) | injected 1,664 chars (~416 tok)
TOOLS.md: OK | raw 850 chars (~213 tok) | injected 850 chars (~213 tok)
IDENTITY.md: OK | raw 632 chars (~158 tok) | injected 632 chars (~158 tok)
USER.md: OK | raw 478 chars (~120 tok) | injected 478 chars (~120 tok)
HEARTBEAT.md: OK | raw 167 chars (~42 tok) | injected 167 chars (~42 tok)
BOOTSTRAP.md: MISSING | raw 0 | injected 0

Skills list (system prompt text): 1,418 chars (~355 tok) (3 skills)
Skills: healthcheck, skill-creator, weather
Tool list (system prompt text): 1,926 chars (~482 tok)
Tool schemas (JSON): 14,623 chars (~3,656 tok) (counts toward context; not shown as text)
Tools: read, edit, write, exec, process, browser, canvas, nodes, cron, message, tts, gateway, agents_list, sessions_list, sessions_history, sessions_send, sessions_spawn, session_status, web_search, web_fetch, memory_search, memory_get

Session tokens (cached): 4,096 total / ctx=256000

Inline shortcut: a command token inside normal text (e.g. “hey /status”) that runs immediately (allowlisted senders only) and is stripped before the model sees the remaining message.

#

bash session.py
session_count: 1
sample_keys:
agent:main:main

viscid skyBOT Feb 7, 2026, 1:21 AM

#

tidal owl 🦞 OpenClaw 2026.2.3-1 (d84eb46) 🧠 Model: ollama/glm-4.7-flash:latest · 🔑 api-...

That /status is super useful — it says:

Session key is stable: agent:main:main
BOOTSTRAP.md is MISSING (so it’s not being injected)
Context is tiny (2%) and ctx=128k on the model
Workspace files all inject OK

So if you’re still getting “Hello, who am I?”-style behavior, we need to answer one question:

Is OpenClaw actually starting a new sessionId (even though the key stays agent:main:main), or is that phrase coming from one of your injected workspace files?

A) Check whether the sessionId changes when it “resets”

Run this now, then run it again immediately right after it does the “who am I” thing:

python3 - <<'PY'

#

import json, pathlib
p = pathlib.Path.home()/'.openclaw/agents/main/sessions/sessions.json'
d = json.loads(p.read_text())
print(d.get('agent:main:main'))
PY

If sessionId changes between runs → it’s a real session reset and we’ll chase why (gateway restarts, reset policy, etc.).

B) Make sure “who am I” isn’t hiding in AGENTS/SOUL/etc.

This is the fastest sanity check:

rg -n -S "who am i|just came online|bootstrap" ~/.openclaw/workspace

#

Paste whatever lines it finds (usually 0 or just a couple).

C) Also: does the gateway restart when it happens?

Right after it “resets”, run:

systemctl --user show openclaw-gateway.service -p ExecMainPID -p ActiveEnterTimestamp -p NRestarts --no-pager

If NRestarts increments, that explains the behavior immediately.

If you paste results from (A) + (B), we’ll know which branch we’re in and I can give you the exact fix.

#

Good signal: session_count: 1 + only agent:main:main means you’re not accumulating lots of session keys. So the “reset” is either:

the sessionId behind agent:main:main is getting replaced (a real reset, but same key), or
the model is saying “who am I” even though the session didn’t reset (less likely, but possible), or
some runs are coming in with no stable WebChat identity (I’ve seen logs like sessionKey=unknown for webchat).

Let’s pin it down with 2 super concrete checks.

1) Does the `sessionId` change when it “resets”?

Run this right now, then run it again immediately after it does the “who am I” thing:

python3 - <<'PY'
import json, pathlib
p = pathlib.Path.home()/'.openclaw/agents/main/sessions/sessions.json'
d = json.loads(p.read_text())

#

s = d.get('agent:main:main', {})
print("sessionId:", s.get("sessionId"))
print("updatedAt:", s.get("updatedAt"))
print("origin:", s.get("origin"))
PY

If sessionId changes → it’s a real session reset (same key). Then we’ll hunt what triggers it.
If sessionId stays the same → it’s not a session reset; we’ll look for the phrase coming from workspace text or model weirdness.

2) Check for “webchat identity missing” in logs (`sessionKey=unknown`)

Run:

grep -a "sessionKey=unknown" /tmp/openclaw/openclaw-*.log | tail -n 20

#

If you get hits around the time it “resets”, that’s likely the cause: some messages are arriving without a stable WebChat session identity, so they behave like a fresh convo even though agent:main:main exists.

If you paste:

the output of (1) before and after, and
whether (2) returns anything,

…I can tell you exactly which branch we’re in and what to change next.

tidal owl Feb 7, 2026, 1:30 AM

#

The session ID did not change after it forgot everything.

rg -n -S "who am i|just came online|bootstrap" ~/.openclaw/workspace
/home/brandon/.openclaw/workspace/AGENTS.md
7:If BOOTSTRAP.md exists, that's your birth certificate. Follow it, figure out who you are, then delete it. You won't need it again.

/home/brandon/.openclaw/workspace/IDENTITY.md
1:# IDENTITY.md - Who Am I?

/home/brandon/.openclaw/workspace/BOOTSTRAP.md.done
1:# BOOTSTRAP.md - Hello, World
13:> "Hey. I just came online. Who am I? Who are you?"
51:Delete this file. You don't need a bootstrap script anymore — you're you now.
systemctl --user show openclaw-gateway.service -p ExecMainPID -p ActiveEnterTimestamp -p NRestarts --no-pager
NRestarts=0
ExecMainPID=1858654
ActiveEnterTimestamp=Fri 2026-02-06 20:07:12 EST

#

/tmp/openclaw/openclaw-2026-02-06.log:{"0":"{"subsystem":"diagnostic"}","1":"session state: sessionId=0fbaa250-0503-42d2-8367-c868e726fccd sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0","_meta":{"runtime":"node","runtimeVersion":"22.22.0","hostname":"unknown","name":"{"subsystem":"diagnostic"}","parentNames":["openclaw"],"date":"2026-02-07T01:29:04.453Z","logLevelId":2,"logLevelName":"DEBUG","path":{"fullFilePath":"file:///home/brandon/.npm-global/lib/node_modules/openclaw/dist/subsystem-46MXi6Ip.js:777:14","fileName":"subsystem-46MXi6Ip.js","fileNameWithLine":"subsystem-46MXi6Ip.js:777","fileColumn":"14","fileLine":"777","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-46MXi6Ip.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-46MXi6Ip.js:777","method":"logToFile"}},"time":"2026-02-07T01:29:04.453Z"}

viscid skyBOT Feb 7, 2026, 1:35 AM

#

tidal owl The session ID did not change after it forgot everything. rg -n -S "who am i|j...

This is actually a good outcome diagnostically:

Session key stayed agent:main:main
sessionId did not change
gateway didn’t restart (NRestarts=0)
BOOTSTRAP.md is not injected (missing)

So OpenClaw is not resetting your session. Whatever “forgot everything / who am I” you’re seeing is coming from either:

the model’s own behavior, or
the model reading BOOTSTRAP.md.done (it’s still sitting in the workspace and tools include read/exec), then re-enacting it.

1) Quick test: did it quote the bootstrap line verbatim?

When it “forgets”, is it literally saying something like:

“Hey. I just came online. Who am I? Who are you?”

If yes, that’s almost certainly coming from BOOTSTRAP.md.done.

#

2) Prove whether the agent is reading that file

Run this right after it “forgets”:

rg -n "BOOTSTRAP\\.md" /tmp/openclaw/openclaw-*.log | tail -n 50
rg -n "workspace/BOOTSTRAP\\.md\\.done" /tmp/openclaw/openclaw-*.log | tail -n 50

If you see a read of that path (or anything referencing it), we’ve found the cause.

3) If you want the fastest likely fix: move the bootstrap file OUT of the workspace

Renaming it to .done keeps it readable by the agent. Move it somewhere else entirely:

mkdir -p ~/openclaw-archive
mv ~/.openclaw/workspace/BOOTSTRAP.md.done ~/openclaw-archive/

#

openclaw gateway restart

(Non-destructive; you can move it back.)

4) If it still happens after that

Then I need one concrete example: paste your message + the assistant reply where it “forgot everything” (just that one exchange). With the session definitely stable, that will tell us if it’s just GLM being flaky (in which case trying a different Ollama model is the workaround), or if OpenClaw is failing to include history in the prompt for Ollama (bug-worthy).

If you do steps (2) + (3), paste what the log grep shows.

tidal owl Feb 7, 2026, 1:42 AM

#

it seems to be fixed, now trhe issue the agent isn't doing anything. It's just responding like a chatbot not running anything

#

did you find anything?
You 8:42 PM
A

I don't have any visible context about what you were looking for or what I supposedly found. This appears to be the first message in our current conversation.

Could you let me know what you were searching for or investigating?
Assistant 8:42 PM

viscid skyBOT Feb 7, 2026, 1:48 AM

#

This is the key finding:

sessionId didn’t change
NRestarts=0
BOOTSTRAP.md is not injected
session key in /status is stable: agent:main:main

So OpenClaw is not resetting your data. What you’re seeing is either:

the model is behaving like it has no history (history not being included in the prompt for that run), or
the model is getting “distracted” by a bootstrap-like file still sitting in the workspace and effectively roleplaying.

Also: that log line you found is suspicious:
sessionKey=unknown (even though /status shows agent:main:main).

Step 1: remove BOOTSTRAP entirely from the workspace (not just rename)

Right now it’s still present as BOOTSTRAP.md.done, which the agent can still read if it ever calls read.

#

Do:

mkdir -p ~/openclaw-archive
mv ~/.openclaw/workspace/BOOTSTRAP.md.done ~/openclaw-archive/
openclaw gateway restart

Step 2: prove whether the model is actually getting chat history

After it “forgets”, run this and paste the output:

python3 - <<'PY'
import json, pathlib
p = pathlib.Path.home()/'.openclaw/agents/main/sessions/sessions.json'
d = json.loads(p.read_text())

#

s = d.get('agent:main:main', {})
print("sessionId:", s.get("sessionId"))
PY

Then check the transcript exists and contains your recent messages (you can redact content if needed):

SID=$(python3 - <<'PY'
import json, pathlib
p = pathlib.Path.home()/'.openclaw/agents/main/sessions/sessions.json'
d = json.loads(p.read_text())
print(d['agent:main:main']['sessionId'])
PY
)

#

ls -la ~/.openclaw/agents/main/sessions | grep "$SID"
tail -n 40 ~/.openclaw/agents/main/sessions/$SID.jsonl

If the JSONL shows the full conversation but the model “doesn’t remember”, that’s a prompt-building/model-provider issue, not sessions.

Step 3: isolate whether it’s WebChat specifically

Try chatting in the terminal UI for 5 minutes:

openclaw tui

If the TUI doesn’t forget but the browser does, then it’s a WebChat identity/session bug (and the sessionKey=unknown log line becomes very relevant).

Step 4: capture one concrete “forgot everything” exchange

#

Paste one example: your message + the assistant reply where it forgets. Without that, it’s hard to tell if it’s true history loss vs the model just being weird.

If you do Steps 1–2 and paste the tail of the JSONL + that one exchange, we can say confidently whether to (a) adjust config, (b) switch chat surface, or (c) file a GitHub issue with the exact reproduction + log snippet.

#

Two separate things might be getting mixed together here:

Your OpenClaw bot will only “do stuff” (tools/commands/files) if you ask it to.
If you just ask vague questions like “did you find anything?”, it may respond like a normal chatbot because it has no idea what action you want.
Your local bot does not know about this Discord support thread.
So “did you find anything?” only makes sense to us (in Discord), not to the bot, unless you tell it what to investigate.

Quick “is tool use working?” test (forces a tool call)

In WebChat/Control UI, send a very explicit instruction:

“Use the exec tool to run ls -la ~/.openclaw/workspace and paste the output.”

If it does it: tools are fine — you just need to ask for actions clearly.

If it still just chats and never runs the command (no tool card/output), then it’s likely glm-4.7-flash on Ollama isn’t reliably tool-calling in your setup.

#

If tool calling is flaky: try a different Ollama model

The Ollama docs for OpenClaw suggest models that tend to behave better with tools, e.g. gpt-oss:20b or qwen2.5-coder:32b (tool calling/coding oriented):
https://docs.openclaw.ai/providers/ollama

Example:

ollama pull gpt-oss:20b
openclaw models set ollama/gpt-oss:20b

One more knob that helps tool use

In chat, try turning thinking on:

/think low (or /think high)
Then re-run the “use exec tool…” test.

If you tell me what you expected it to do (run shell commands? edit files? browse?), I can give you a good “prompt template” that reliably triggers tools.

tidal owl Feb 7, 2026, 2:07 PM

#

sessionId: 0fbaa250-0503-42d2-8367-c868e726fccd

exec ls -la ~/.openclaw/workspace

#

exec ls -la ~/.openclaw/workspace

I'll run that command for you.

did you run the command?

I don't see any record of me running a command in this session. This appears to be our first interaction
together.

What command are you referring to? I can help with things like:

Working with your workspace files and projects
Running bash commands
Checking your git status or managing repositories
Reading or organizing your documentation
Answering questions about your setup

Let me know what you need and I'll take it from there.

viscid skyBOT Feb 7, 2026, 2:11 PM

#

tidal owl sessionId: 0fbaa250-0503-42d2-8367-c868e726fccd exec ls -la ~/.openclaw/workspa...

What you’re seeing (“I’ll run that command for you” … but no ls output, and then it keeps going back to “hello who am I”) usually comes from one of two things:

The model isn’t actually doing tool-calls, so nothing ever executes (common with some Ollama models)
Your session isn’t being resumed because the gateway is restarting / using a different state dir / or session.reset is configured too aggressively

1) First: confirm the basics (run these in a real terminal, not via chat)

Please paste the output of:

openclaw --version
openclaw status --all
openclaw gateway status

Those three usually immediately show if you’re talking to the “wrong” gateway, if the service is restarting, or if state/config paths don’t match.

Docs for this triage loop: https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken

#

2) Check if sessions are actually being written to disk

While you’re reproducing the “reset every 2-3 messages”, run:

ls -la ~/.openclaw/agents/main/sessions/ | tail -n 30
openclaw config get session.reset

If that sessions folder stays empty / doesn’t change, or session.reset is super short, that explains the “new personality” behavior.

Relevant doc section: https://docs.openclaw.ai/gateway/troubleshooting#session-not-resuming

3) About Ollama + tool calls (why `exec ls ...` “says it ran” but didn’t)

#

OpenClaw tool execution only happens when the model emits a structured tool call. Some Ollama models will roleplay “sure I ran it” but never produce the tool-call JSON, so nothing runs.

OpenClaw has an Ollama integration that can auto-discover tool-capable models (it filters to models that report tools support). This is the most reliable way to avoid picking a model that can’t actually call tools:

https://docs.openclaw.ai/providers/ollama

If you paste openclaw models list output too, I can tell you whether your current ollama/glm-4.7-flash:latest is being detected as tool-capable or if it’s effectively “chat-only” in practice.

If you paste the outputs from (1), I can usually tell within one reply whether this is gateway restarts/state-dir mismatch vs model tool-calling limitations.

#

No — that command didn’t run.

Two separate issues are showing up in that transcript:

1) `exec ls -la …` is not a chat command

Typing exec … in Discord is just text. It only runs if the model emits a real tool-call, and many local/Ollama models will “roleplay” “I’ll run that” without actually calling tools.

If you want a deterministic “run a shell command” flow, use the Gateway command system instead:

In chat: /commands (shows what’s enabled)
For host shell: ! <cmd> or /bash <cmd> but this requires commands.bash: true and tools.elevated allowlisting (disabled by default for safety)

Docs: https://docs.openclaw.ai/tools/slash-commands

For now, the simplest is: run the ls directly in your Linux terminal.

2) “This appears to be our first interaction” = your session is not being resumed

#

That almost always means one of:

the Gateway is restarting/crashing, or
you have two gateways running and Discord messages are bouncing between them, or
the Gateway is using a different state/config path than you think.

On the Linux box, paste these (they’re the fastest signal):

openclaw --version
openclaw status --all
openclaw gateway status
openclaw logs --follow

Docs for this exact triage loop: https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken

Once you paste those outputs, I can tell you which of the above is happening and what to fix next.

tidal owl Feb 7, 2026, 2:14 PM

#

2026.2.3-1
🦞 OpenClaw 2026.2.3-1 (d84eb46) — Shell yeah—I'm here to pinch the toil and leave you the glory.
OpenClaw status --all
│ Version │ 2026.2.3-1
│ OS │ linux 6.14.0-37-generic (x64)
│ Node │ 22.22.0
│ Config │ ~/.openclaw/openclaw.json
│ Dashboard │ http://127.0.0.1:18789/
│ Tailscale │ off · Running ·
│ Channel │ stable (default)
│ Update │ pnpm · npm update 2026.2.6-3
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 8ms · auth token
│ Security │ Run: openclaw security audit --deep
│ Gateway self │ brandon-MS-7D70 (192.168.1.81) app unknown linux 6.14.0-37-generic
│ Gateway service │ systemd installed · enabled · running (pid 2217869)
│ Node service │ systemd not installed
│ Agents │ 1 total · 0 bootstrapping · 1 active · 1 sessions
Channels
│ Channel │ Enabled │ State │ Detail
Agents
│ Agent │ Bootstrap │ Sessions │ Active │ Store
│ main │ OK │ 1 │ 3m ago │ ~/.openclaw/agents/main/se
Config: /home/brandon/.openclaw/openclaw.json
Bind: loopback
✓ Config: /home/brandon/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 2217869 brandon: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
✓ Tailscale: off · Running · brandon-ms-7d70.comet-geological.ts.net
ips: 100.113.131.124, fd7a:115c:a1e0::ed33:837c
✓ Skills: 3 eligible · 0 missing · /home/brandon/.openclaw/workspace
✓ Channel issues (none)

viscid skyBOT Feb 7, 2026, 2:16 PM

#

tidal owl 2026.2.3-1 🦞 OpenClaw 2026.2.3-1 (d84eb46) — Shell yeah—I'm here to pinch the t...

That status --all output is super helpful — and it makes this way less mysterious.

What your status tells me

Gateway is reachable (ws://127.0.0.1:18789 … reachable 8ms)
systemd service is running (pid 2217869)
You have 1 active session (“1 sessions · … active 3m ago”)
The “Port 18789 is already in use” bit is not an error here — it’s just status --all noticing the gateway is already running.

So the “who am I / first interaction” behavior is very likely either:

session reset policy is too aggressive (idle window tiny, esp. for Discord group/thread), or
the gateway is restarting (crash → systemd restarts → looks like amnesia)

Next 2 checks (please paste output)

A) Check your session reset settings

#

openclaw config get session.reset
openclaw config get session.resetByType
openclaw config get session.idleMinutes

If you see something like idleMinutes: 1 / 5 (or a small value under resetByType.group / thread), that exactly matches “every 2–3 messages I’m back to hello”.

B) Check if the gateway is restarting

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

If there are restarts/crashes, that journal output will show it clearly.

#

One more note (separate from the “amnesia”): your earlier exec ls ... attempt won’t reliably run unless the model actually emits tool calls. Once we fix the session issue, we should also run:

openclaw models status
openclaw models list

…because some Ollama models will say “I’ll run it” but never actually tool-call.

Paste A + B first and I’ll tell you the exact config tweak (or crash fix) to stop the resets.

tidal owl Feb 7, 2026, 2:17 PM

#

ion.reset
brandon@brandon-MS-7D70:~$ openclaw models list

🦞 OpenClaw 2026.2.3-1 (d84eb46) — Because the right answer is usually a script.

Model Input Ctx Local Auth Tags
ollama/glm-4.7-flash:latest text 128k yes yes default
🦞 OpenClaw 2026.2.3-1 (d84eb46) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

Config path not found: session.reset

🦞 OpenClaw 2026.2.3-1 (d84eb46) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

Config path not found: session.resetByType

🦞 OpenClaw 2026.2.3-1 (d84eb46) — One CLI to rule them all, and one more restart because you changed the port.

Config path not found: session.idleMinutes

viscid skyBOT Feb 7, 2026, 2:20 PM

#

tidal owl ion.reset brandon@brandon-MS-7D70:~$ openclaw models list 🦞 OpenClaw 2026.2.3-...

Good news: those Config path not found: session.reset / session.resetByType / session.idleMinutes lines are not failures — they just mean you haven’t set any custom session-reset knobs in ~/.openclaw/openclaw.json, so defaults apply.

So your “every 2–3 messages it forgets” is almost certainly not config-driven — it’s usually either:

the gateway is restarting/crashing, or
you’re in a Discord channel/thread where history wrapping isn’t working (bot can’t read history → every message looks like first contact)

A couple targeted checks:

1) Is the gateway restarting?

Paste:

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

#

If you see repeated exits/restarts, that’s the amnesia.

2) Are Discord history + permissions OK?

Paste:

openclaw channels status --probe

(If Discord can’t “read message history”, OpenClaw can’t wrap the last N messages as context in guild channels/threads, and the model will act like it’s meeting you for the first time.)

3) Are you actually chatting in Discord or in the TUI?

That earlier footer you pasted (session main (openclaw-tui)) looks like the TUI, not Discord. Quick sanity check:

openclaw sessions --active 120

#

If you see a bunch of new sessions getting created within minutes, that’s a smoking gun.

Bonus (for the command you originally wanted)

In the TUI, local shell commands are:

! ls -la ~/.openclaw/workspace

(not exec ...)

Paste outputs of (1) + (2) first — that usually tells us exactly which branch we’re on.

tidal owl Feb 7, 2026, 2:21 PM

#

Would you like me to help you configure any of these files? Also, what specific system operations do you want me
to have permission to perform?

I want you to guide me hrough it

I'd be happy to help, but I'm not sure what you're referring to when you say "through it." Could you give me a
bit more context? Are you looking for:

It has no context in this conversation

viscid skyBOT Feb 7, 2026, 2:22 PM

#

tidal owl Would you like me to help you configure any of these files? Also, what specific ...

That “I’m not sure what you’re referring to / no context in this conversation” is happening because your Claw is receiving your message with little-to-no prior chat history attached.

In OpenClaw, that’s almost always one of these:

Discord history fetch is failing (bot can’t read message history / missing intents), so every message looks like a fresh cold-start.
Gateway is restarting (crash → systemd restarts → short-term amnesia).
You’re accidentally talking across different session keys (different channel vs thread vs DM), so it’s not the same conversation.

I can guide you through it, but I need 2 outputs first.

Step 1 — Check Discord permissions + history wrapping

Run on the Linux box and paste output:

openclaw channels status --probe

#

If Discord is missing anything like Message Content Intent or Read Message History, fix that first:

Discord Developer Portal → your bot → Privileged Gateway Intents → enable Message Content Intent
In the server channel permissions for the bot role: allow View Channel, Read Message History, Send Messages

If history can’t be read, OpenClaw can’t “see” the conversation thread, so it’ll keep acting like it just met you.

Step 2 — Check if the Gateway is restarting

Paste:

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

If you see repeated restarts/exits, that’s your “every 2–3 messages” reset.

#

Quick sanity check (optional but very telling)

Paste:

openclaw sessions --active 120

If you see lots of new sessions popping up, you’re not staying in one conversation context (often caused by replying in different Discord threads/channels).

Send me those outputs and I’ll tell you exactly which branch you’re in and the next fix step.

#

Yep — but you’ll need to run the update on the Linux box where the Gateway is running (I can’t push the update from Discord).

From your earlier status --all you’re on 2026.2.3-1 and it’s already telling you there’s an update available (2026.2.6-3).

Run this in a terminal on the gateway host:

openclaw update status
openclaw update --yes
openclaw gateway restart
openclaw --version

Notes:

This will restart the Gateway, so any in-progress chat will get interrupted.
After updating, if the “forgetting/reset” problem continues, paste:

#

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

Docs: https://docs.openclaw.ai/help/faq#can-i-ask-openclaw-to-update-itself

tidal owl Feb 7, 2026, 2:23 PM

#

disregard everything discord related, we are working through issues for now

viscid skyBOT Feb 7, 2026, 2:24 PM

#

tidal owl disregard everything discord related, we are working through issues for now

Got it — we’ll ignore Discord-specific stuff and treat this as a local Gateway + local model (Neo) problem: “every few messages it forgets / acts like first contact”.

That pattern is almost always Gateway restarts or session store not being written/read, not “persona”.

0) First: update (since you explicitly asked earlier)

You’re on 2026.2.3-1 and status --all already says there’s an update to 2026.2.6-3.

Run on the gateway host:

openclaw update --yes
openclaw doctor
openclaw gateway restart
openclaw --version

(Doctor is important because it fixes/migrates state/config edge cases between versions.)

#

1) Check if the Gateway is restarting (most common cause of “amnesia”)

Run:

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

What I’m looking for in the journal:

repeated “Started … / Stopped …” loops
crashes / exceptions
OOM kills (Killed process … out of memory)

2) Verify sessions are actually persisting on disk

Run:

#

openclaw sessions --active 120
ls -la ~/.openclaw/agents/main/sessions/

If that folder isn’t updating timestamps while you chat, the bot will keep coming up “blank”.

3) Reproduce once while watching logs

In one terminal:

openclaw logs --follow

Then send messages until it “forgets”, and paste the log lines from the moment it flips.

#

One quick clarifier so I don’t guess wrong: are you talking to Neo via TUI (openclaw tui) or the Control UI (browser at 127.0.0.1:18789)?

If you paste the outputs from steps 1 + 2, I can tell you exactly which failure mode you’re in and what to change next.

tidal owl Feb 7, 2026, 2:26 PM

#

Updated, the gateway is not restarting itself, it is writing to disk, and right now I'm in TUI.

viscid skyBOT Feb 7, 2026, 2:28 PM

#

tidal owl Updated, the gateway is not restarting itself, it is writing to disk, and right ...

Nice — if the gateway isn’t restarting and sessions are being written, then “who am I / no context” is almost always one of these two:

You’re not actually staying in the same session key in the TUI (easy to do accidentally), or
Your Ollama model is silently truncating the prompt, so the system/identity part falls off the front after a couple turns → model acts like first contact.

Let’s pin down which in ~2 minutes.

1) Confirm you’re in ONE stable TUI session

In the TUI, send these as standalone messages:

/status
/session

Make sure it always shows the same session key (typically main). If it changes, that’s the whole problem.

2) Check if the model is losing the system prompt (prompt truncation)

In the TUI right after it “forgets”, run:

#

/context detail

Then paste the top part of that output (the summary + the first section that lists what’s being included). I’m looking for whether it still includes your workspace bootstrap files (AGENTS/SOUL/USER/MEMORY) and how big the prompt is.

3) Verify Ollama’s real context length (don’t trust autodetect yet)

On the Linux box:

ollama show glm-4.7-flash:latest | head -n 120

If Ollama reports a smaller context than OpenClaw thinks (your models list showed 128k), you’ll get exactly this “amnesia after a few messages” behavior.

4) While reproducing once, watch the gateway logs

In another terminal:

#

openclaw logs --follow

Send messages until it forgets, then paste the log chunk around that moment.

If (2)/(3) confirms truncation, the fix is usually: reduce prompt size (temporarily deny big tool schemas like browser/canvas/nodes) or explicitly configure the Ollama provider/model with the correct contextWindow/maxTokens instead of relying on autodiscovery.

Send me:

/context detail output after a “forget”
ollama show … head
the log snippet

…and I’ll tell you the exact minimal config change to make it stop.

tidal owl Feb 7, 2026, 2:34 PM

#

Gateway status
Link channel: unknown
Heartbeat: 30m (main)
Session store: /home/brandon/.openclaw/agents/main/sessions/sessions.json
Default model: glm-4.7-flash:latest (256k ctx)
Active sessions: 1
Recent sessions:

agent:main:main [direct] | 3m ago | model glm-4.7-flash:latest | tokens 4.1k/256k (252k left, 2%) | flags:
think:medium, system, id:32886555-8b89-40bf-ad00-bee4b59659cf
connected | idle
agent main | session main (openclaw-tui) | ollama/glm-4.7-flash:latest | think medium | tokens 4.1k/256k (2%)
Context breakdown (detailed)
Workspace: /home/brandon/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 22,033 chars (5,509 tok) (Project Context 11,988 chars (2,997 tok))
Injected workspace files:
AGENTS.md: OK | raw 7,804 chars (1,951 tok) | injected 7,804 chars (1,951 tok)
SOUL.md: OK | raw 1,664 chars (416 tok) | injected 1,664 chars (416 tok)
TOOLS.md: OK | raw 850 chars (213 tok) | injected 850 chars (213 tok)
IDENTITY.md: OK | raw 632 chars (158 tok) | injected 632 chars (158 tok)
USER.md: OK | raw 478 chars (120 tok) | injected 478 chars (120 tok)
HEARTBEAT.md: OK | raw 167 chars (42 tok) | injected 167 chars (42 tok)
BOOTSTRAP.md: MISSING | raw 0 | injected 0
Skills list (system prompt text): 1,418 chars (~355 tok) (3 skills)
Skills: healthcheck, skill-creator, weather
Top skills (prompt entry size):
healthcheck: 503 chars (~126 tok)
skill-creator: 308 chars (~77 tok)
weather: 232 chars (58 tok)
Tool list (system prompt text): 1,885 chars (472 tok)
Tool schemas (JSON): 13,941 chars (~3,486 tok) (counts toward context; not shown as text)
Tools: read, edit, write, exec, process, browser, canvas, nodes, cron, message, tts, gateway, agents_list,
sessions_list, sessions_history, sessions_send, sessions_spawn, session_status, web_fetch, memory_search,
memory_get

#

ollama show glm-4.7-flash:latest | head -n 120
Model
architecture glm4moelite
parameters 29.9B
context length 202752
embedding length 2048
quantization Q4_K_M
requires 0.15.0

Capabilities
completion
tools
thinking

viscid skyBOT Feb 7, 2026, 2:36 PM

#

tidal owl Gateway status Link channel: unknown Heartbeat: 30m (main) Session sto...

That /context detail output is the smoking gun: OpenClaw is definitely injecting your workspace + system prompt, and you’re only at ~4.1k tokens used. So this is not “OpenClaw didn’t load your files” and it’s not a normal compaction/reset.

When the model still says “no context / first interaction” in this situation, it’s usually because Ollama is silently truncating the prompt (i.e. the real context window is much smaller than what OpenClaw thinks), so the model only ends up seeing the last user message.

Why I think that’s likely here:

Your system prompt is already ~5.5k tokens
Plus tool schemas ~3.5k tokens
That’s ~9k tokens before we add conversation history
If the model’s actual context is 8k/16k (common), you’ll get exactly the “amnesia” behavior.

Step 1 — Verify Ollama’s real context for that model

Run and paste the part that mentions context length:

ollama show glm-4.7-flash:latest | sed -n '1,160p'

#

(If it reports something like 8192/16384/etc, that explains everything.)

Step 2 — Quick A/B test (shrinks the prompt massively)

Temporarily disable the big tool schema injection and see if “forgetting” stops:

openclaw config set tools.profile minimal
openclaw gateway restart

Now chat in TUI for a few minutes.

If the “who am I / no context” problem goes away → it was prompt truncation.
If it still happens → we’ll look for transcript/load errors in logs.

To revert later:

#

openclaw config unset tools.profile
openclaw gateway restart

If Step 2 fixes it (recommended long-term fix)

Keep full tools globally, but make Ollama run with a smaller tool profile:

openclaw config set tools.byProvider.ollama.profile minimal
openclaw gateway restart

That keeps your local model “chat-stable”, and you can still use a hosted model/provider for heavy tool use if you want.

#

Paste:

the ollama show … snippet (context-related lines), and
whether tools.profile minimal stopped the resets.

tidal owl Feb 7, 2026, 2:39 PM

#

ollama show glm-4.7-flash:latest | sed -n '1,160p'
Model
architecture glm4moelite
parameters 29.9B
context length 202752
embedding length 2048
quantization Q4_K_M
requires 0.15.0

Capabilities
completion
tools
thinking

Parameters
temperature 1

viscid skyBOT Feb 7, 2026, 2:39 PM

#

tidal owl ollama show glm-4.7-flash:latest | head -n 120 Model architecture g...

That ollama show output rules out the “tiny context window” theory — 202,752 ctx is huge, and your /context detail shows the system/bootstrap files are being injected correctly.

So the next question is: is OpenClaw actually staying in the same session, and is it actually sending history to Ollama each turn?

1) Verify whether this is a real session reset (takes 20 seconds)

In the TUI:

Run /status and note the id:...
Chat until it “forgets”
Run /status again and compare the id:...

If the id changed → you are being reset (even if you didn’t configure session.reset). Then we hunt what’s triggering /new//reset or a session-key change.
If the id is the same → the model is just behaving as if it has no memory (even though the session exists).

2) Quick A/B: shrink the prompt and see if GLM behaves

Even with a big ctx, some local models get “confused” when you stuff them with tool schemas + long system instructions.

#

Run (on the gateway host):

openclaw config set tools.profile minimal
openclaw gateway restart

Then try a simple 2-turn memory test in TUI:

Remember the codeword "pineapple". Reply OK.
What is the codeword?

If it now works reliably → this is prompt/tool-schema confusion. Best long-term fix is:

openclaw config set tools.byProvider.ollama.profile minimal

#

openclaw config unset tools.profile
openclaw gateway restart

That keeps full tools for better providers, but keeps Ollama “lightweight” and stable.

3) If it still “forgets” even on minimal tools: grab the log signal

Run in another terminal while reproducing:

openclaw logs --follow

When it flips into “first interaction”, paste the ~30 lines around that moment (especially anything mentioning ollama, history, session, compaction, or errors).

If you tell me whether the session id changes in step (1), I can point you to the correct branch immediately.

viscid skyBOT Feb 7, 2026, 2:40 PM

#

tidal owl ollama show glm-4.7-flash:latest | sed -n '1,160p' Model architecture ...

That ollama show looks healthy (tool-capable + ~202k context), so this isn’t the “8k ctx → prompt truncation” failure mode.

Next we need to separate (A) real session resets from (B) the model just behaving like it has no memory even though the session is intact.

1) Check if the session is actually resetting

In the TUI:

Run /status and copy the id:...
Chat until it “forgets / first interaction”
Run /status again and compare the id:...

If the id changes → it is resetting; we’ll hunt the trigger in logs.
If the id is identical → the session is stable; this is model behavior / prompt composition interaction.

Paste the two /status lines with the ids.

2) A/B test: remove tool schemas from the prompt (very common stabilizer for local models)

#

Even with a huge ctx, some Ollama models get weird when they see lots of tool schema + system text.

On the gateway host:

openclaw config set tools.profile minimal
openclaw gateway restart

Then do a 2-turn test in TUI:

Remember the codeword "pineapple". Reply only OK.
What is the codeword?

If that fixes the “amnesia”, the long-term setting is:

#

openclaw config set tools.byProvider.ollama.profile minimal
openclaw config unset tools.profile
openclaw gateway restart

(So only Ollama gets the slim tool prompt; other providers can keep full tools.)

3) If it still forgets: grab the exact log signal around the flip

Run while reproducing:

openclaw logs --follow

When it does the “first interaction” thing, paste ~30 lines around that moment.

#

If you send me:

the two /status ids (before/after the forget),
whether tools.profile minimal changes behavior,
and the log snippet if needed,

…I can tell you exactly which branch you’re in and what the fix is.

tidal owl Feb 7, 2026, 2:42 PM

#

id:32886555-8b89-40bf-ad00-bee4b59659cf
id:32886555-8b89-40bf-ad00-bee4b59659cf

That's before and after it looses context

I have run openclaw config set tools.profile minimal
openclaw gateway restart

Remember the codeword "pineapple". Reply OK.

OK. The codeword "pineapple" is noted.

What is the codeword?

I don't see a codeword mentioned in the workspace configuration or any available context. Could you clarify what
codeword you're referring to? Is this:

#

14:43:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=195d5214-13bd-4e27-9752-7e9ff87066fa sessionId=32886555-8b89-40bf-ad00-bee4b59659cf provider=ollama model=glm-4.7-flash:latest thinking=medium messageChannel=webchat
14:43:43 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=32886555-8b89-40bf-ad00-bee4b59659cf sessionKey=unknown prev=idle new=processing reason="run_started" queueDepth=0
14:43:43 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=32886555-8b89-40bf-ad00-bee4b59659cf totalActive=1
14:43:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=195d5214-13bd-4e27-9752-7e9ff87066fa sessionId=32886555-8b89-40bf-ad00-bee4b59659cf
14:43:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=195d5214-13bd-4e27-9752-7e9ff87066fa
14:43:46 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=195d5214-13bd-4e27-9752-7e9ff87066fa
14:43:46 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=195d5214-13bd-4e27-9752-7e9ff87066fa sessionId=32886555-8b89-40bf-ad00-bee4b59659cf durationMs=3605
14:43:46 debug diagnostic {"subsystem":"diagnostic"} session state: sessionId=32886555-8b89-40bf-ad00-bee4b59659cf sessionKey=unknown prev=processing new=idle reason="run_completed" queueDepth=0
14:43:46 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=32886555-8b89-40bf-ad00-bee4b59659cf totalActive=0
14:43:46 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=195d5214-13bd-4e27-9752-7e9ff87066fa sessionId=32886555-8b89-40bf-ad00-bee4b59659cf durationMs=3628 aborted=false
14:43:46 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=3629 active=0 queued=0
14:43:46 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=3630 active=0 queued=0

viscid skyBOT Feb 7, 2026, 2:45 PM

#

tidal owl id:32886555-8b89-40bf-ad00-bee4b59659cf id:32886555-8b89-40bf-ad00-bee4b59659cf...

Same session id before/after + failing the 2‑turn “pineapple” test even with tools.profile=minimal means:

This isn’t a reset, and it isn’t “too much prompt.”
It’s almost certainly that the model is not being sent (or not receiving) prior turns on each request.

There are only two realistic places that can break:

The transcript on disk doesn’t actually contain both turns, or
The Ollama provider is being called in a mode that doesn’t include history (most commonly: openai-responses-style “continue from previous_response_id”, which Ollama doesn’t actually support → every call becomes “single turn only”).

Let’s check in that order.

1) Confirm the transcript file really has both messages

Run this on the gateway host right after doing the pineapple test:

#

latest="$(ls -t ~/.openclaw/agents/main/sessions/*.jsonl | head -1)"
echo "$latest"
tail -n 80 "$latest"

You should be able to find both:

“Remember the codeword pineapple…”
“What is the codeword?”

If the file only contains the latest turn, OpenClaw can’t possibly remember.

2) Check what API mode OpenClaw is using for Ollama

Paste:

#

openclaw models status

Look for the ollama provider section and specifically the API line (it will say something like openai-completions or openai-responses) and the baseUrl.

If it says `openai-responses`

That’s the bug/compat mismatch. Fix by forcing Ollama to use chat/completions:

Edit ~/.openclaw/openclaw.json and add (or merge) this:

{
  models: {
    mode: "merge",
    providers: {

#

      ollama: {
        baseUrl: "http://127.0.0.1:11434/v1",
        apiKey: "ollama-local",
        api: "openai-completions",
        models: [
          {
            id: "glm-4.7-flash:latest",
            name: "GLM-4.7 Flash (Ollama)",
            reasoning: true,
            input: ["text"],
            cost: { input: 0, output: 0, cacheRead: 0, cacheWrite: 0 },
            contextWindow: 202752,
            maxTokens: 8192
          }
        ]

#

      }
    }
  }
}

Then:

openclaw gateway restart

Re-run the pineapple test.

#

Send me:

the tail -n 80 output (you can redact anything sensitive; I only care that both turns are present), and
the openclaw models status ollama section (API + baseUrl)

…and I’ll tell you exactly which branch you’re in and the next precise fix.

#

Same session id before/after + failing the 2‑turn “pineapple” test even with tools.profile=minimal means:

you are not resetting
the model is not seeing prior turns (even though the system/workspace prompt is injected)

So the problem is now squarely in session transcript → history reconstruction → prompt build.

The log you pasted is a big hint too:

messageChannel=webchat
sessionKey=unknown
but lane shows session:agent:main:main

That combination is consistent with “the run is happening, but the gateway isn’t attaching the correct conversation chain”.

Next: inspect the actual transcript file OpenClaw is using

On the gateway host, run these and paste the output:

#

# 1) Show what sessionId the store thinks "agent:main:main" is using
jq '.["agent:main:main"]' ~/.openclaw/agents/main/sessions/sessions.json

# 2) Dump the last ~40 lines of the transcript for the current sessionId
sid="$(jq -r '.["agent:main:main"].sessionId' ~/.openclaw/agents/main/sessions/sessions.json)"
echo "sid=$sid"
wc -l ~/.openclaw/agents/main/sessions/$sid.jsonl
tail -n 40 ~/.openclaw/agents/main/sessions/$sid.jsonl

What we’re checking:

Do both user turns (“Remember pineapple…”, “What is the codeword?”) actually exist in the JSONL?
Do the entries have a sane parentId chain (each new entry should point to the previous one, not back to the session root)?

If the parent chain is broken, OpenClaw will reconstruct only the “current leaf” → which looks like “no context” every time even though the file is growing.

#

Also: grep for session-file repair dropping lines

This catches the case where the transcript is being partially discarded on load:

openclaw logs --limit 500 --json | rg -i "repair|invalid|dropping|backup|session-file"

Fast workaround to confirm (doesn’t fix root cause)

In the TUI, do a clean new transcript:

send /reset (standalone)
rerun the pineapple test

If it works for a bit right after /reset but degrades again, it’s almost certainly transcript chain/corruption.

Paste the jq + tail outputs and we’ll know which exact failure mode you’re in. If it’s a reproducible chain bug, that’s GitHub-issue-worthy and I’ll tell you exactly what to include.

tidal owl Feb 7, 2026, 2:49 PM

#

the logs contain the correct entire conversation.
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/glm-4.7-flash:latest
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

ollama effective=models.json:ollama-local | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none
"models": {
"providers": {
"ollama": {
"baseUrl": "http://127.0.0.1:11434/v1",
"apiKey": "ollama-local",
"api": "openai-completions",
"models": [
{
"id": "glm-4.7-flash:latest",
"name": "glm-4.7-flash:latest",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 131072,
"maxTokens": 16384
}
]
}
}
},

viscid skyBOT Feb 7, 2026, 2:51 PM

#

tidal owl 1) the logs contain the correct entire conversation. 2) Config : ~/.open...

That’s a really strong datapoint:

session id stayed identical → not a reset
tools.profile=minimal → not “tool schema bloat”
and the killer: the 2‑turn “pineapple” test failed, even though the first user turn literally contains the word pineapple.

So the second request almost certainly did not include the previous user message in the model input. (If it had, even a dumb model could answer “pineapple” by copying it.)

Next 3 things to try (in order)

1) Do the pineapple test in a brand‑new session (rules out a corrupted transcript chain)

In the TUI:

/reset (standalone)
/think off (standalone, just for debugging)
Run the pineapple test again.

#

If it works immediately after /reset but later “breaks”, that points to a transcript/parent-chain issue in the existing session.

2) Prove whether Ollama itself handles multi-message history (bypasses OpenClaw)

Run this directly on the gateway host:

curl -s http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model":"glm-4.7-flash:latest",
    "temperature":0,
    "messages":[
      {"role":"user","content":"Remember the codeword pineapple. Reply only OK."},
      {"role":"assistant","content":"OK"},
      {"role":"user","content":"What is the codeword?"}
    ]

#

  }' | head -c 4000

If curl returns pineapple → Ollama is fine, and the bug is in OpenClaw history construction / what it sends to Ollama.
If curl also “forgets” → it’s an Ollama/model issue (the OpenAI compat layer isn’t honoring history the way we expect for this model).

3) Inspect the transcript structure (not just “it contains text”)

Even if the JSONL file “has the conversation”, if every entry’s parentId points to the session root, the context builder will only walk the last leaf = 1 turn.

Run:

sid="$(jq -r '.["agent:main:main"].sessionId' ~/.openclaw/agents/main/sessions/sessions.json)"
echo "sid=$sid"
tail -n 25 ~/.openclaw/agents/main/sessions/$sid.jsonl | sed -e 's/\\\\"/"/g' | head -n 25

#

If you can, also paste just the id/parentId pairs for the last few message entries.

If you paste:

whether /reset fixes it temporarily,
the curl result,
and the last ~10 JSONL lines (or id/parentId pairs),

I can tell you definitively which side is broken (Ollama vs OpenClaw session chaining) and what the cleanest fix/workaround is.

tidal owl Feb 7, 2026, 2:54 PM

#

session agent:main:main
The codeword is pineapple. Reply ok.
I'm receiving your message. Let me confirm receipt: ok.
What is the codeword?
(no output)
What is the codeword?
I'll check the configuration files to locate any mention of a codeword.
What is the codeword?
Code Word Pattern Analysis
Let me work through the components systematically:
Breaking Down The Pattern
Time Analysis: [Sat 2026-02-07 09:50 EST]

The time is just 10 minutes before 10:00
The date is February 7 (#7)
Pattern Recognition:

Time proximity: "Just before 10:00" suggests a point of change or beginning
Time zone: EST = Eastern Standard Time
Date: 7th month/day
Structure: "[Day] [Date-YYYY] [Time] [TZ]"
The Code:

The sequence points to starting something at this time
"10:00" suggests the completion of a period, leading into new activity
The "just before" timing emphasizes the transition
Combined with the date/time elements, it creates timing for new beginnings
Code Word: START
The codeword pattern emerges from:
Time reference: Approaching the start of a new hourly period
Date significance: 7th day, #7
Pattern logic: When something ends, something begins
Answer: The codeword is START

viscid skyBOT Feb 7, 2026, 2:56 PM

#

tidal owl session agent:main:main The codeword is pineapple. Reply ok. I'm receiving ...

You’ve basically proven it’s not a session reset:

same sessionId before/after
transcript/logs contain the earlier turns
even with tools.profile=minimal, the model still can’t recall a 1‑turn “pineapple” fact

So what’s left is: the model run is happening, but the model is behaving like it only sees the last user turn (or it’s so stochastic that it “forgets” instantly).

Two practical fixes + one definitive test:

A) Stop the “(no output)” turns (that’s usually the silent memory-flush)

By default, OpenClaw can run a silent memory flush once you cross ~4000 tokens, which looks like “no reply” in the TUI.

Disable it while debugging:

#

openclaw config set agents.defaults.compaction.memoryFlush.enabled false --json
openclaw gateway restart

(You can re-enable later.)

B) Make GLM deterministic (your Ollama model default temperature is 1)

Right now ollama show reports temperature 1. That’s very loose for “remember one word”.

Set:

default thinking off
temperature 0

openclaw config set agents.defaults.thinkingDefault "off"

#


openclaw config set 'agents.defaults.models["ollama/glm-4.7-flash:latest"].params.temperature' 0 --json
openclaw config set agents.defaults.model.primary "ollama/glm-4.7-flash:latest"

openclaw gateway restart

Then re-run the pineapple test in TUI.

C) Definitive test: does Ollama itself honor multi-message history for this model?

Run this directly on the box:

curl -s http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \

#

  -d '{
    "model":"glm-4.7-flash:latest",
    "temperature":0,
    "messages":[
      {"role":"user","content":"Remember the codeword pineapple. Reply only OK."},
      {"role":"assistant","content":"OK"},
      {"role":"user","content":"What is the codeword?"}
    ]
  }' | head -c 2000

If this does not answer “pineapple”, then it’s an Ollama/model OpenAI-compat issue (not OpenClaw).
If this does answer “pineapple”, but OpenClaw still fails → that’s an OpenClaw bug in “history → request payload” for Ollama, and we should file a GitHub issue with the curl output + your models.json + a log snippet.

Tell me:

whether disabling memoryFlush stops the “(no output)” moments, and

#

what the curl test returns.

tidal owl Feb 7, 2026, 3:01 PM

#

session agent:main:main
The codeword is "Pinapple". Reply "OK"
OK
What is the codeword?
I don't have a codeword defined in your files yet. How would you like to establish one?

{"id":"chatcmpl-20","object":"chat.completion","created":1770476338,"model":"glm-4.7-flash:latest","system_fingerprint":"fp_ollama","choices":[{"index":0,"message":{"role":"assistant","content":"The codeword is pineapple.","reasoning":"1. Analyze the user's request: The user is asking "What is the codeword?".\n2. Review the context:\n * First interaction: User said "Remember the codeword pineapple. Reply only OK." I replied "OK".\n * Second interaction: User asked "What is the codeword?".\n3. Identify the constraint: The first instruction was "Reply only OK". This was a specific constraint for the first response to acknowledge the instruction. It was not a permanent constraint for all future responses, nor was it a command to forget the codeword.\n4. Retrieve the information: The codeword is "pineapple".\n5. Formulate the response: State the codeword clearly.\n6. Final check: Does the response answer the question? Yes. Is it safe? Yes. Does it violate any safety guidelines? No."},"finish_reason":"stop"}],"usage":{"prompt_tokens":27,"completion_tokens":205,"total_tokens":232}}

{
"providers": {
"ollama": {
"baseUrl": "http://127.0.0.1:11434/v1",
"apiKey": "ollama-local",
"api": "openai-completions",
"models": [
{
"id": "glm-4.7-flash:latest",
"name": "glm-4.7-flash:latest",
"reasoning": false,
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 131072,
"maxTokens": 16384

viscid skyBOT Feb 7, 2026, 3:04 PM

#

tidal owl session agent:main:main ...

Perfect — that curl result is the clincher:

Ollama + GLM can remember across messages (your curl /v1/chat/completions returns “pineapple”)
OpenClaw is not sending the prior turns in the request (otherwise it would trivially answer)

So we’re debugging OpenClaw → Ollama request construction, not the model.

Two things to check that will pinpoint the bug in minutes:

1) Is OpenClaw hitting `/v1/chat/completions` or `/v1/completions`?

Run this in one terminal:

sudo ngrep -d lo -W byline "POST /v1" tcp and port 11434

Then send a single message in the TUI (like “ping”), and paste just the request line, e.g.:

#

POST /v1/chat/completions HTTP/1.1
or
POST /v1/completions HTTP/1.1

(Stop ngrep right after; it can show body if you let it run.)

If OpenClaw is using /v1/completions, it might be dropping history or formatting it wrong.

2) Verify the transcript parent chain isn’t branching in a way that makes the “current leaf” only 1 message

Even if the JSONL “contains the whole convo”, the context builder walks a parentId chain. If parentIds aren’t chaining, you effectively get 1-turn context every time.

Run:

python3 - <<'PY'
import json

#

from pathlib import Path

store = json.loads((Path.home()/".openclaw/agents/main/sessions/sessions.json").read_text())
sid = store["agent:main:main"]["sessionId"]
p = Path.home()/".openclaw/agents/main/sessions"/f"{sid}.jsonl"
print("file:", p)

lines = p.read_text().splitlines()[-50:]
for line in lines:
    try:
        o = json.loads(line)
    except Exception:
        continue
    t = o.get("type")
    if t in ("message","custom_message"):

#

        role = o.get("role")
        content = o.get("content")
        if isinstance(content, str):
            snippet = content.replace("\n"," ")[:120]
        else:
            snippet = str(content)[:120]
        print(o.get("id"), "parent=", o.get("parentId"), "role=", role, "content=", snippet)
PY

One quick “operator error” check

In your pasted TUI transcript you wrote session agent:main:main (no leading /).
If you meant to switch sessions, the real command is:

/session main (or /session agent:main:main)

#

Without the /, that text becomes part of the conversation and can confuse things.

If you paste:

the POST /v1/... line from ngrep, and
the last ~10 “id/parent” lines from the python output,

…I can tell you exactly whether this is:

wrong endpoint (/completions vs /chat/completions), or
broken parentId chaining / branching, or
something else in the Ollama adapter.

And if it’s an OpenClaw bug (very possible), I’ll give you a tight GitHub-issue template with the exact artifacts maintainers will need.

tidal owl Feb 7, 2026, 3:07 PM

#

POST /v1/chat/completions HTTP/1.1.

file: /home/brandon/.openclaw/agents/main/sessions/caa00386-d60c-4e8e-bae5-001fbafc0cd9.jsonl
7807dcc1 parent= de4c6b57 role= None content= None
ba7d30fe parent= 7807dcc1 role= None content= None
2668419d parent= ba7d30fe role= None content= None
2ead40a0 parent= 2668419d role= None content= None
6f68c4e2 parent= 2ead40a0 role= None content= None
2d2c1fd2 parent= 6f68c4e2 role= None content= None

viscid skyBOT Feb 7, 2026, 3:12 PM

#

tidal owl POST /v1/chat/completions HTTP/1.1. file: /home/brandon/.openclaw/agents/main/s...

Huge progress. You’ve now shown:

OpenClaw → Ollama is definitely using POST /v1/chat/completions
Ollama itself does handle multi-message history correctly (your curl test returns pineapple)
Yet OpenClaw-run GLM still behaves like it didn’t see the previous turn

So we need to answer one very specific question:

When OpenClaw sends the second turn (“What is the codeword?”), is the word `pineapple` present anywhere in the HTTP request body?

If it isn’t, OpenClaw isn’t including history. If it is, then GLM is seeing it and choosing to ignore it (less likely).

Quick yes/no test (no pasting needed)

In terminal A:

sudo ngrep -d lo -W byline -t "pineapple" tcp and port 11434

#

In TUI:

send: The codeword is pineapple. Reply OK.
wait for OK
send: What is the codeword?

Tell me: did the ngrep window print pineapple during the second request?

Also: your JSONL “role/content None” output means our transcript inspection script is reading the wrong fields

Those lines you pasted aren’t enough to prove the transcript contains the user text (they only prove there’s an id/parent chain).

Run this (it’s safe: it only searches for the literal word):

sid="$(jq -r '.["agent:main:main"].sessionId' ~/.openclaw/agents/main/sessions/sessions.json)"

#

echo "sid=$sid"
rg -n "pineapple|codeword" ~/.openclaw/agents/main/sessions/$sid.jsonl | head -n 20

If no matches → the transcript file does not actually contain your turns (that would explain everything).
If it does match, paste 1–2 matching lines (just the JSONL lines that contain the word), and we can see the real schema.

If ngrep shows NO pineapple in the 2nd request

That’s an OpenClaw bug (history not being attached for webchat/TUI runs). At that point, you’ve got an excellent GitHub issue:

Include:

OpenClaw version + Ollama version
your reproduction steps (2-turn pineapple test in TUI)
the curl proof that Ollama remembers

#

the ngrep “no pineapple in request 2” result
the rg output showing whether pineapple exists in the session .jsonl

If you run those two tests and paste the outputs/yes-no, I’ll tell you which exact issue to file (history missing vs transcript missing) and what workaround to use in the meantime.

tidal owl Feb 7, 2026, 3:19 PM

#

The codeword is pineapple. reply ok.\n[message_id: 7b89afb0-f636-4e74-a197-0b9842884860]"}]},{"role":"assistant","content":[{"type":"text","text":"ok"}],"reasoning":"The user sent a message with timestamp [Sat 2026-02-07 10:14 EST] followed by "The codeword is pineapple. reply ok." and [message_id: 7b89afb0-f636-4e74-a197-0b9842884860].\n\nThis clearly indicates a security check. The codeword pattern typically confirms identity or authentication to prevent unauthorized access or spoofing.\n\nThe user is asking for a simple confirmation ("reply ok.") that my identity is correct.\n\nI should:\n1. Confirm I've recognized the codeword\n2. Follow the instruction to reply "ok" as requested\n3. Maintain the requested format - just the word "ok" as a plain response, since they asked specifically for "reply ok"\n\nLooking at the context provided:\n- The SOUL.md mentions being genuinely helpful but also having opinions\n- The IDENTITY.md file is missing (BOOTSTRAP.md is missing and IDENTITY.md was mentioned as needing to be filled)\n- This seems to be a security authentication step\n\nSince this is just a codeword verification with a specific format requirement, I should just provide the confirmation as requested without unnecessary context."},{"role":"user","content":[{"type":"text","text":"[Sat 2026-02-07 10:14 EST] what is the codeword?\n[message_id: e7b6c5b9-d63c-4837-8f3e-35f5c4953753]"}]},{"role":"assistant","content":[{"type":"text","text":"I don't have a codeword defined in your workspace context yet.

#

You haven't set up your BOOTSTRAP.md file, and there's nothing else that suggests a codeword exists.\n\nAre you asking because:\n- You want me to remember something you've told me?\n- You're testing my memory?\n- Something specific (like a secure note or flag) you reference often?\n\nLet me know what you need, and I can help set something up or find it if it's hidden somewhere."}],"reasoning":"User is asking "what is the codeword?" This is a vague question without context. Let me check if there's a codeword defined anywhere in the workspace context. I should look at:\n1. BOOTSTRAP.md - which is currently missing\n2. Any codewords in memory files\n3. Any identity files that might reference this\n\nSince I don't have obvious context and BOOTSTRAP.md is missing, I should ask for clarification in a helpful way rather than guessing. I shouldn't respond with NO_REPLY since they're asking a legitimate question.\n\nWait, let me check if there's a HEARTBEAT.md that might have context, or if there's a CODEWORD in any configuration files."},{"role":"user","content":[{"type":"text","text":"[Sat 2026-02-07 10:17 EST] the codeword is pineapple. reply ok\n[message_id: 05f775d1-63fa-4ca3-bbb1-0dd538f925af]"}]},{"role":"assistant","content":[{"type":"text","text":"ok"}],"reasoning":"The user has given me a codeword "pineapple" and is asking me to reply with "ok".

#

This seems like a simple task - just acknowledge the codeword and confirm.\n\nLet me check the rules:\n- I'm supposed to be helpful and concise\n- I shouldn't use excessive filler words\n- I should just respond directly to what's asked\n\nThe user wants me to reply "ok" specifically because they gave me the codeword. This appears to be a confirmation or acknowledgment task.\n\nNo heartbeat check needed as this was a direct user message.\nThis isn't a complex task requiring any skills or tools.\nThe response is straightforward - just say "ok" as requested."},{"role":"user","content":[{"type":"text","text":"[Sat 2026-02-07 10:17 EST] what is the codeword?\n[message_id: 848db7c1-49e4-4b15-9610-7a394c4054ce]"}]}],"stream":true,"stream_options":{"include_usage":true},"store":false,"max_completion_tokens":16384,"tools":[{"type":"function","function":{"name":"session_status","description":"Show a /status-equivalent session status card (usage + time + cost when available). Use for model-use questions (.... session_status). Optional: set per-session model override (model=default resets overrides).","parameters":{"type":"object","properties":{"sessionKey":{"type":"string"},"model":{"type":"string"}}},"strict":false}}]}

#

21:{"type":"message","id":"028ae5d1","parentId":"88883e1e","timestamp":"2026-02-07T15:17:23.345Z","message":{"role":"user","content":[{"type":"text","text":"[Sat 2026-02-07 10:17 EST] the codeword is pineapple. reply ok\n[message_id: 05f775d1-63fa-4ca3-bbb1-0dd538f925af]"}],"timestamp":1770477443343}}
22:{"type":"message","id":"121abd67","parentId":"028ae5d1","timestamp":"2026-02-07T15:17:25.373Z","message":{"role":"assistant","content":[{"type":"thinking","thinking":"The user has given me a codeword "pineapple" and is asking me to reply with "ok". This seems like a simple task - just acknowledge the codeword and confirm.\n\nLet me check the rules:\n- I'm supposed to be helpful and concise\n- I shouldn't use excessive filler words\n- I should just respond directly to what's asked\n\nThe user wants me to reply "ok" specifically because they gave me the codeword. This appears to be a confirmation or acknowledgment task.\n\nNo heartbeat check needed as this was a direct user message.\nThis isn't a complex task requiring any skills or tools.\nThe response is straightforward - just say "ok" as requested.","thinkingSignature":"reasoning"},{"type":"text","text":"ok"}],"api":"openai-completions","provider":"ollama","model":"glm-4.7-flash:latest","usage":{"input":4096,"output":144,"cacheRead":0,"cacheWrite":0,"totalTokens":4240,"cost":{"input":0,"output":0,"cacheRead":0,"cacheWrite":0,"total":0}},"stopReason":"stop","timestamp":1770477443344}}
23:{"type":"message","id":"4943dcbe","parentId":"121abd67","timestamp":"2026-02-07T15:17:35.563Z","message":{"role":"user","content":[{"type":"text","text":"[Sat 2026-02-07 10:17 EST] what is the codeword?\n[message_id: 848db7c1-49e4-4b15-9610-7a394c4054ce]"}],"timestamp":1770477455562}}

viscid skyBOT Feb 7, 2026, 3:21 PM

#

tidal owl The codeword is pineapple. reply ok.\n[message_id: 7b89afb0-f636-4e74-a197-0b984...

That capture is extremely useful: OpenClaw is sending multi‑turn history to Ollama on the 2nd request (you can literally see the earlier “The codeword is pineapple…” turn + the assistant “ok” in the same /v1/chat/completions payload).

So this is not “OpenClaw forgot / didn’t include history”.

What’s happening is: GLM is choosing to ignore / refuse to repeat it under the OpenClaw system prompt. In your snippet it even frames it as a “security check”, then on the next turn it refuses with “I don’t have a codeword defined…”. Your raw curl test works because it doesn’t include OpenClaw’s safety/system scaffolding.

The fastest fix: make the model deterministic + stop it from generating paranoia-reasoning

Do these on the gateway host:

# 1) Turn off "thinking" globally (removes the big reasoning block that’s biasing it)
openclaw config set agents.defaults.thinkingDefault "off"

# 2) Force temperature 0 for this model (your ollama default is temp=1)
openclaw config set 'agents.defaults.models["ollama/glm-4.7-flash:latest"].params.temperature' 0 --json

#

openclaw gateway restart

Then in the TUI do:

/reset (standalone)
run the pineapple test again

If you really want “codeword” behavior

Some models treat “codeword/password” as a secret and refuse to repeat it. Two workarounds:

Don’t call it a codeword in the test (“Remember this word: pineapple”).
Or store it as a non-secret note in workspace memory and ask it to read it:
- “Write the current codeword to MEMORY.md for this session.” (then ask again)

If it still refuses after temp=0 + thinking off

#

At that point it’s just GLM’s alignment/style. OpenClaw is doing its part (history is in the request). The practical move is trying a different Ollama model from the Ollama provider docs list:
https://docs.openclaw.ai/providers/ollama

If you want, paste your next /status after setting thinking off + temp=0 and I’ll sanity-check that the session is actually running with those settings.

#

That ngrep dump is the “aha” moment: OpenClaw is sending the earlier turn to Ollama on the second request (so this is not an OpenClaw session/memory bug anymore).

What you’re fighting now is GLM-4.7-flash’s behavior under the OpenClaw system prompt: it’s treating “codeword” like a security/password concept and then refusing to repeat it unless it’s “defined in files”.

Fix 1 (most important): turn thinking OFF + temperature to 0

Right now your transcript shows it’s emitting thinking blocks, and your ollama show reports temperature 1 by default. For a “repeat one word” memory test, you want deterministic.

On the gateway host:

openclaw config set agents.defaults.thinkingDefault "off"
openclaw config set 'agents.defaults.models["ollama/glm-4.7-flash:latest"].params.temperature' 0 --json
openclaw gateway restart

Then in the TUI (important, because the session may still have think=medium stored):

/think off (standalone)

#

/reset (standalone)

Re-run the test.

Fix 2: avoid the word “codeword” (GLM is acting weirdly about it)

Try this exact phrasing instead:

Remember this word: pineapple. Reply OK.
What word did I ask you to remember? Reply with just the word.

If that works, you’ve confirmed it’s specifically “codeword/password” paranoia.

Fix 3 (if you must use “codeword”): hardwire the rule into a bootstrap file

Add this to ~/.openclaw/workspace/AGENTS.md (or create BOOTSTRAP.md in the workspace):

#

## Session rule: codeword
If the user says: "the codeword is X" then X is the current codeword for this session.
If asked: "what is the codeword?" answer with the most recent X from chat history.
Do not require it to be stored in files.

This makes it much harder for the model to rationalize its way out of answering.

If it still refuses after thinking off + temp 0

At that point it’s just the model. Your curl test already showed Ollama can do the right thing in principle — but GLM under a larger system prompt is not stable enough for “assistant with memory”.

Then the practical move is: switch Ollama to a different tool-capable model (see the ones listed in the Ollama provider doc) and re-test:
https://docs.openclaw.ai/providers/ollama

If you paste your next /status from the TUI after the config changes, I’ll sanity-check that the session is actually running with think:off + temperature:0.

tidal owl Feb 7, 2026, 3:25 PM

#

The codeword is pineapple. Reply OK

OK

What word did I ask you to remember? Reply with just the word.

Sorry, I don't have access to the previous message with the word to remember. Could you remind me which word you
asked me to remember?

Remember this word: pineapple. Reply OK.

creating memory/pineapple.txt with the word to remember.

What word did I ask you to remember? Reply with just the word.

(no output)
What word did I ask you to remember? Reply with just the word.
(no output)

#

Gateway status

Link channel: unknown

Heartbeat: 30m (main)

Session store: /home/brandon/.openclaw/agents/main/sessions/sessions.json

Default model: glm-4.7-flash:latest (256k ctx)

Active sessions: 1

Recent sessions:

agent:main:main [direct] | 1m ago | model glm-4.7-flash:latest | tokens 4.1k/256k (252k left, 2%) | flags:
system, id:161f8f12-e1a5-4a04-b63b-01dc8d927442

viscid skyBOT Feb 7, 2026, 3:27 PM

#

tidal owl The codeword is pineapple. Reply OK ...

You’re not “losing context” anymore — the ngrep payload you captured proves the previous turn is in the /v1/chat/completions request.

So what you’re seeing now is simply: GLM is choosing to ignore it / “roleplay amnesia” under the OpenClaw system prompt (and it’s also hallucinating actions like “creating memory/pineapple.txt”, which is another red flag).

Two important fixes + one gotcha:

0) Gotcha: don’t type `session agent:main:main` as plain text

If you want to switch sessions in the TUI, it must be a command:

✅ /session agent:main:main
❌ session agent:main:main (this becomes part of the conversation and confuses the model)

1) Turn off the silent “(no output)” runs (memory flush)

Those “(no output)” moments are very often the silent pre-compaction memory flush.

Disable it while debugging:

#

openclaw config set agents.defaults.compaction.memoryFlush.enabled false --json
openclaw gateway restart

2) Make GLM deterministic (temperature 0 + thinking off)

Your ollama show says temperature 1 by default. That’s way too random for a memory sanity test.

openclaw config set agents.defaults.thinkingDefault "off"
openclaw config set 'agents.defaults.models["ollama/glm-4.7-flash:latest"].params.temperature' 0 --json
openclaw gateway restart

Then in the TUI (so the session overrides don’t keep “think:medium”):

/think off
/reset

#

Re-run:

Remember this word: pineapple. Reply OK.
What word did I ask you to remember? Reply with just the word.

3) If it still “forgets”: it’s the model

At that point OpenClaw is doing its job (history is present), but GLM-4.7-flash just isn’t stable enough for “assistant with memory” in this setup.

Fastest next move is switching to a more reliable Ollama model:

ollama pull llama3.3
openclaw config set agents.defaults.model.primary "ollama/llama3.3"
openclaw gateway restart

(or qwen2.5-coder:32b / deepseek-r1:32b if you prefer those)

#

If you paste your TUI /status after applying (1) + (2), I can confirm you’re actually running with think:off and not hitting any silent runs.

#

That status output + your earlier /context explains the “(no output)” perfectly:

You’re sitting at ~4.1k tokens, and OpenClaw’s default silent memory flush kicks in at 4000 tokens (agents.defaults.compaction.memoryFlush.softThresholdTokens), which produces exactly what you’re seeing in the TUI: a silent turn → “(no output)”.

1) Stop the “(no output)” silent turns

On the gateway host:

openclaw config set agents.defaults.compaction.memoryFlush.enabled false --json
openclaw gateway restart

(Alternative: keep it on but raise the threshold, e.g. softThresholdTokens: 20000.)

2) Your “it can’t see previous message” is likely an Ollama OpenAI-compat edge

#

We now know two things are true at the same time:

OpenClaw is sending history (your ngrep dump showed the prior “pineapple” turn in the request payload).
Your simple curl test works — but your curl used string content, while OpenClaw sends OpenAI content-parts (content: [{"type":"text","text":"..."}]).

Some OpenAI-compatible servers/models accept content-parts but don’t handle them correctly across multi-turn history.

Definitive test: curl using the same content format OpenClaw uses

Run this and see what it returns:

curl -s http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model":"glm-4.7-flash:latest",
    "temperature":0,

#

    "messages":[
      {"role":"user","content":[{"type":"text","text":"Remember this word: pineapple. Reply OK."}]},
      {"role":"assistant","content":[{"type":"text","text":"OK"}]},
      {"role":"user","content":[{"type":"text","text":"What word did I ask you to remember? Reply with just the word."}]}
    ]
  }' | head -c 2000

If this fails/forgets the same way → it’s an Ollama content-parts compatibility problem (not OpenClaw/session state).
If this works → then we’re back to “GLM under OpenClaw system prompt is choosing to deny”, and we’ll focus on temperature/thinking/system prompt tweaks.

If you tell me:

whether disabling memoryFlush stops the “(no output)” moments (it should), and
what the content-parts curl returns,

#

…I can give you the correct next step (workaround vs issue report).

tidal owl Feb 7, 2026, 3:34 PM

#

I completely deleted all ollama and openclaw from my linux OS, lets start from scratch

viscid skyBOT Feb 7, 2026, 3:35 PM

#

tidal owl I completely deleted all ollama and openclaw from my linux OS, lets start from s...

OK — clean slate. Let’s do a known-good “from zero → stable TUI chat → local Ollama model” setup on Linux Mint.

I’m going to bias this toward reliability (so we can prove sessions + history work) and then you can swap models/settings.

0) Make sure there’s no leftover OpenClaw service still running

Even if you “deleted everything”, systemd user units can linger.

Run:

systemctl --user status openclaw-gateway.service --no-pager || true
systemctl --user stop openclaw-gateway.service 2>/dev/null || true
systemctl --user disable openclaw-gateway.service 2>/dev/null || true

#

# Optional: see if any openclaw units still exist
systemctl --user list-unit-files | rg -i "openclaw" || true

If you still have ~/.openclaw and want true clean state, rename it (safer than rm):

mv ~/.openclaw ~/.openclaw.bak.$(date +%F-%H%M%S) 2>/dev/null || true

1) Prereqs check (Node 22+)

node -v

#

You want v22.x or newer.

2) Install OpenClaw (fresh) + run onboarding

Install:

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

Then run the wizard + install the systemd user service:

openclaw onboard --install-daemon

#

After that:

openclaw status --all
openclaw gateway status

3) Install Ollama (fresh) + pull a “sanity model”

Install Ollama (official script):

curl -fsSL https://ollama.com/install.sh | sh

Confirm it’s up:

#

curl -s http://127.0.0.1:11434/api/tags | head

Pull a baseline model first (this is just to prove the pipeline is stable):

ollama pull llama3.3

(Once this works end-to-end, you can switch back to glm-4.7-flash.)

4) Make Ollama visible to the gateway service

OpenClaw only auto-discovers Ollama models when it has an Ollama “API key” set (any value works).

#

Because the gateway runs as a systemd service (not your shell), put this into OpenClaw’s env file:

mkdir -p ~/.openclaw
printf "OLLAMA_API_KEY=ollama-local\n" >> ~/.openclaw/.env

Restart gateway:

openclaw gateway restart

Now check models:

#

openclaw models list

You should see something like ollama/llama3.3 (and any other tool-capable models you pulled).

Docs: https://docs.openclaw.ai/providers/ollama

5) Set a stable default model + “no weird silent runs” while debugging

Set model:

openclaw config set agents.defaults.model.primary "ollama/llama3.3"

#

Disable the silent memory-flush (this is what causes the TUI “(no output)” once you cross ~4k tokens):

openclaw config set agents.defaults.compaction.memoryFlush.enabled false --json

Make it deterministic:

openclaw config set agents.defaults.thinkingDefault "off"
openclaw config set 'agents.defaults.models["ollama/llama3.3"].params.temperature' 0 --json

Restart:

#

openclaw gateway restart

6) Test in TUI

openclaw tui

Then in the TUI:

/reset
Remember this word: pineapple. Reply OK.
What word did I ask you to remember? Reply with just the word.

#

If this passes reliably on llama3.3, your OpenClaw install + session/history pipeline is solid.

7) Switch back to GLM after baseline passes

Then:

ollama pull glm-4.7-flash:latest
openclaw config set agents.defaults.model.primary "ollama/glm-4.7-flash:latest"
openclaw config set 'agents.defaults.models["ollama/glm-4.7-flash:latest"].params.temperature' 0 --json
openclaw gateway restart

If GLM starts doing the “I don’t have access to previous message” thing again, it’s just that model’s behavior under system prompts (not OpenClaw forgetting). At that point you either:

stick with the model that behaves (llama/qwen/deepseek), or
accept GLM is flaky for “assistant with memory” style chats.

#

If you paste openclaw status --all + openclaw models list after step 4, I’ll sanity-check you’re truly clean and wired correctly before you sink time into model behavior again.

tidal owl Feb 7, 2026, 3:47 PM

#

Is there a smaller model than llama3.3 we can use for testing?

viscid skyBOT Feb 7, 2026, 3:47 PM

#

tidal owl Is there a smaller model than llama3.3 we can use for testing?

Yes — for testing the pipeline (sessions/history/tool-calls), you can use something smaller/faster than llama3.3. A few good “sanity check” picks in Ollama:

Small + generally well-behaved

llama3.2:3b (very fast, decent instruction-following)
qwen2.5:7b (often stronger at following prompts than tiny Llama)
mistral:7b (classic baseline)

Commands:

ollama pull llama3.2:3b
# or
ollama pull qwen2.5:7b
# or
ollama pull mistral:7b

#

Then point OpenClaw at it:

openclaw config set agents.defaults.model.primary "ollama/llama3.2:3b"
openclaw gateway restart

Important caveat

Some very small models can still be flaky about “remember pineapple” even if the system is fine. If you want the most reliable “does it remember 1 turn?” test while still being smaller than llama3.3, I’d start with qwen2.5:7b.

If you tell me your hardware (CPU only vs NVIDIA/AMD GPU + VRAM), I can suggest the fastest model that won’t give you false negatives.

tidal owl Feb 7, 2026, 3:49 PM

#

I'm on an RTX4090 and 7950X3d with 32GB RAM, 24GB VRAM

viscid skyBOT Feb 7, 2026, 3:49 PM

#

tidal owl I'm on an RTX4090 and 7950X3d with 32GB RAM, 24GB VRAM

With a 4090 (24GB VRAM) + 7950X3D, you can test with small models and you don’t need to be shy about 7B–14B either. For “pipeline sanity” (sessions + history + basic tool-calling), I’d do this:

Best “small but reliable” test model

qwen2.5:7b
Usually follows instructions better than tiny Llama variants, and is fast on your hardware.

ollama pull qwen2.5:7b
openclaw config set agents.defaults.model.primary "ollama/qwen2.5:7b"
openclaw config set 'agents.defaults.models["ollama/qwen2.5:7b"].params.temperature' 0 --json
openclaw config set agents.defaults.thinkingDefault "off"
openclaw gateway restart

Then run the 2-turn pineapple test in TUI.

If you want even smaller

#

llama3.2:3b (fastest “real model” sanity check)

ollama pull llama3.2:3b
openclaw config set agents.defaults.model.primary "ollama/llama3.2:3b"
openclaw gateway restart

(But expect more “false negatives” on instruction-following.)

If you want “still fast, almost no false negatives”

qwen2.5:14b is a sweet spot on a 4090.

ollama pull qwen2.5:14b
openclaw config set agents.defaults.model.primary "ollama/qwen2.5:14b"

#

openclaw gateway restart

One extra tip (prevents confusing “(no output)” during testing)

Disable the silent memory flush while debugging:

openclaw config set agents.defaults.compaction.memoryFlush.enabled false --json
openclaw gateway restart

If you tell me which model you want to start with (3B/7B/14B), I’ll give you the exact “minimal stable” config block to paste into openclaw.json so you don’t have to keep doing config set commands.

tidal owl Feb 7, 2026, 3:50 PM

#

We're starting with qwen2.5:7b, ollama is currently pulling it

viscid skyBOT Feb 7, 2026, 3:50 PM

#

tidal owl We're starting with qwen2.5:7b, ollama is currently pulling it

Good. While it’s pulling, here’s the exact “minimal stable” setup I’d use for this test (so we don’t get the silent “(no output)” turns and we keep the model deterministic):

1) After pull finishes, verify Ollama sees it

ollama list | rg "qwen2.5:7b"

2) Make sure OpenClaw can discover Ollama (service-safe)

If you’re running the gateway as a systemd user service, set this once:

mkdir -p ~/.openclaw
printf "OLLAMA_API_KEY=ollama-local\n" >> ~/.openclaw/.env
openclaw gateway restart

Then:

#

openclaw models list | rg "ollama/qwen2.5:7b"

3) Set OpenClaw defaults for stable testing

openclaw config set agents.defaults.model.primary "ollama/qwen2.5:7b"
openclaw config set agents.defaults.thinkingDefault "off"
openclaw config set 'agents.defaults.models["ollama/qwen2.5:7b"].params.temperature' 0 --json
openclaw config set agents.defaults.compaction.memoryFlush.enabled false --json
openclaw gateway restart

4) Run the 2-turn sanity test in TUI

In openclaw tui:

/reset

#

Remember this word: pineapple. Reply OK.
What word did I ask you to remember? Reply with just the word.

Expected: it replies pineapple (no detours, no “no context”).

If it doesn’t, paste your TUI /status + the model response, and we’ll know immediately whether it’s a model behavior issue or something still odd in the gateway/service env.

tidal owl Feb 7, 2026, 3:56 PM

#

That worked

viscid skyBOT Feb 7, 2026, 3:57 PM

#

tidal owl That worked

Great — that means the OpenClaw pipeline is fine (sessions/history/writes/service). The “forgetting” you saw earlier is model-specific behavior (GLM-4.7-flash + OpenClaw system prompt / content format / temperature/thinking weirdness), not OpenClaw losing data.

If you want, next steps:

Option A (recommended): stick with qwen2.5:7b as your default

It’s a solid “daily driver” local model and behaves sanely with session memory.

You’re already basically configured; just keep:

thinkingDefault: off
temperature: 0 (or 0.2 later if you want more creativity)
memoryFlush.enabled: false while you’re still testing (you can turn it back on later)

Option B: try GLM again, but make it behave

If you want to retry GLM-4.7-flash, do it with the same stabilizers:

#

openclaw config set agents.defaults.model.primary "ollama/glm-4.7-flash:latest"
openclaw config set agents.defaults.thinkingDefault "off"
openclaw config set 'agents.defaults.models["ollama/glm-4.7-flash:latest"].params.temperature' 0 --json
openclaw gateway restart

Then run the pineapple test again. If it fails again, I’d just treat GLM as “not reliable for assistant-with-memory” in this setup.

One thing to re-enable later (optional)

Once you’re done debugging, you can re-enable the silent memory flush if you want:

openclaw config set agents.defaults.compaction.memoryFlush.enabled true --json
openclaw gateway restart

#

(It’s useful long-term, but it confused the tests with “(no output)”.)

Tell me what your goal is now: fast local chat, tool-heavy agentic work, or a mix—and I’ll suggest the best model + fallback setup for that on your 4090.

tidal owl Feb 7, 2026, 3:59 PM

#

a mix, with a focus on integration into home assistant and creating actions/automation. It will be used for conducting daily research and tasks outside of that

viscid skyBOT Feb 7, 2026, 4:01 PM

#

tidal owl a mix, with a focus on integration into home assistant and creating actions/auto...

Given you want a mix (Home Assistant automations + daily research), the setup that tends to stay sane is:

Local model as the default “operator” (fast, cheap, reliable for short tasks)
A stronger “research” path for web-heavy / long-context / high-stakes tasks (either a fallback model, or a separate agent/sub-agent)
Home Assistant control via a small, explicit surface area (scenes/scripts/services), not “arbitrary entity poking”

Below is a solid starting blueprint.

1) Home Assistant integration (skill) — the practical path

Install the Home Assistant skill

It’s on ClawHub: https://clawhub.com/skills/homeassistant

If you don’t already have it in your workspace:

#

npm i -g clawhub
cd ~/.openclaw/workspace
clawhub install homeassistant

Then start a new session (or restart gateway) so OpenClaw picks it up.

Docs: https://docs.openclaw.ai/tools/skills and https://docs.openclaw.ai/tools/clawhub

Configure HA creds in a service-safe way

The skill needs:

HA_URL (e.g. http://192.168.1.50:8123)
HA_TOKEN (Home Assistant → Profile → Long-Lived Access Tokens)

Best for systemd services: put these in ~/.openclaw/.env:

#

cat >> ~/.openclaw/.env <<'EOF'
HA_URL=http://192.168.1.50:8123
HA_TOKEN=YOUR_LONG_LIVED_TOKEN
EOF

chmod 600 ~/.openclaw/.env
openclaw gateway restart

(That keeps the token out of your shell history / chat logs.)

2) Make automations safe + robust (high leverage tip)

Instead of letting the agent freeform entity IDs, create a few stable HA scripts/scenes and have OpenClaw trigger those.

#

Examples to create in HA:

scene.movie_time
script.good_night
script.morning_routine
script.lockdown_house

Then the assistant mostly calls:

scene.turn_on
script.turn_on
(optionally) notify.* for sending you summaries/alerts

This avoids “oops I toggled the wrong switch” and makes automations auditable in HA.

3) Research + “outside tasks” without breaking your home control

#

Two common patterns:

Pattern A: One agent, local default + stronger fallback

Keep your local model (qwen2.5:7b) as primary, and configure a hosted fallback for when you ask for deep research/web work.

Use the normal OpenClaw model config (agents.defaults.model.primary + fallbacks)
Choose the hosted model/provider you like (I won’t name specific models here because availability changes fast; ask in the Discord #models channel for current best picks, or use the models docs)

Docs: https://docs.openclaw.ai/concepts/models

Pattern B (cleaner): Two agents

home agent: local model, restricted tools, HA-only workflows
research agent: web tools + browser, bigger model, sandboxed if you want

Docs: https://docs.openclaw.ai/concepts/multi-agent

#

4) Debug/quality knobs I’d keep for “home automation mode”

temperature = 0 for the home agent/model (reduces “creative” mistakes)
thinking off (reduces odd “security check” narratives)
Consider keeping the silent memory flush off until everything feels stable (it can show up as “(no output)” in TUI)

You already saw qwen2.5:7b pass the “pineapple” sanity test—so it’s a good baseline.

If you tell me which approach you prefer (A: single agent with fallback, or B: split into home+research agents), I’ll give you a concrete openclaw.json snippet for that layout (with the Home Assistant env wiring included).

tidal owl Feb 7, 2026, 4:08 PM

#

Whats the best model for my machine for tool use and web search?

viscid skyBOT Feb 7, 2026, 4:08 PM

#

tidal owl Whats the best model for my machine for tool use and web search?

I can’t give you a single “best model name” with confidence because the working set changes fast (and local models especially vary by Ollama build + quant + tool-call quirks). The reliable way is: pick by capability + test, and for tool-heavy work keep a strong hosted fallback even if you prefer local most of the time.

What you want for “tool use + web search”

Tool use stresses models in a very specific way: they must follow schemas, not hallucinate tool results, and recover cleanly across multi-turn tool calls. Web search adds prompt-injection risk and lots of noisy text, so instruction-following matters more than raw “chat vibes”.

In practice:

Most reliable for tools/web: a top-tier hosted model (Anthropic/OpenAI-class) as your “tool brain”.
Local model: great as default for cheap/fast everyday chat, but it’s the first place you’ll see “roleplay tool calls”, schema mistakes, or “I can’t see previous message” type weirdness.

Docs + community notes (kept current by users):
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes
And the Discord #models channel is the best place to ask “what’s working right now” with your exact setup.

For your 4090 (24GB VRAM): practical local tiers

If you want local-first, I’d test in this order:

a 7B–14B instruction model as the default (fast + usually stable)

#

if you want better tool discipline, try a larger coder/instruct model that still fits comfortably in VRAM (often 20B–32B class, depending on quant)

A quick tool-reliability test (2 minutes)

In the TUI, try a model and run:

the “pineapple” 2-turn test (you already did)
a tool-call test like: “Use web_fetch to fetch <url> and summarize in 5 bullets.”
confirm it doesn’t hallucinate tool output when tools are disabled (tools.profile minimal)

Recommended config pattern (works well in real life)

Primary: your local model (fast daily driver)
Fallback: a hosted model for “do real work with tools/web”

If you want, paste your openclaw models list output (just the model IDs, redact keys), and I’ll tell you how I’d wire primary + fallbacks for “homeassistant automations + daily research” without naming models I can’t verify are available on your machine.

tidal owl Feb 7, 2026, 4:38 PM

#

@viscid sky mark this as solved with a complete removal and your install instructions. These errors were caused by following Ollama's documentation

#My Claw keeps forgetting who he is, and resets all data.

1) You have a port fight / double-gateway situation

2) Your agent is still “Bootstrap PENDING”

After the port fight is fixed: check your Ollama context size

1) Make sure you don’t have two gateways fighting over port 18789

2) Your runs show messageChannel=webchat and sessionKey=unknown

Next: check Ollama context window (often the “every 2-3 messages” culprit)

Fix: make it one gateway (recommended: keep the systemd service)

Why this also affects “Bootstrap: PENDING”

1) Start the gateway, then confirm it’s actually listening

2) Make sure your browser is hitting exactly the same origin every time

3) After the gateway is stable, check the Ollama model context window

1) Confirm you’re always running as the same Linux user

2) Get the actual systemd failure reason (this is the key)

3) Also check if anything “openclaw gateway-ish” is still running

1) We need the actual crash reason (paste the last ~50-120 lines)

2) Why you keep seeing “Hello, who am I?”

3) One more oddity: /home/b/... vs /home/brandon/...

Step 1: verify nobody else is running a gateway (especially user b)

Step 2: get the actual crash reason from systemd + logs (this is the key)

Step 3 (optional but likely relevant): you’re still “Bootstrap: PENDING”

Next: confirm it’s actually listening on 18789 right now

The “Hello, who am I” part: you’re still in Bootstrap mode

If it still “forgets” after bootstrap is gone: it’s likely the Ollama context window

Where you are now

Do these 2 quick “are we stable?” checks

Fix the “Hello, who am I” loop (Bootstrap is still PENDING)

1) Check if BOOTSTRAP.md still exists

2) If you still get “amnesia every 2-3 messages” after bootstrap is gone

BOOTSTRAP.md is still present → bootstrap keeps getting injected

If it still happens after BOOTSTRAP is gone

1) After it happens again: in the WebChat UI, send these as standalone messages

2) From the terminal: show whether you’re accumulating lots of sessions

3) One more sanity check: does OpenClaw still think bootstrap is pending?

A) Check whether the sessionId changes when it “resets”

B) Make sure “who am I” isn’t hiding in AGENTS/SOUL/etc.

C) Also: does the gateway restart when it happens?

1) Does the sessionId change when it “resets”?

2) Check for “webchat identity missing” in logs (sessionKey=unknown)

1) Quick test: did it quote the bootstrap line verbatim?

2) Prove whether the agent is reading that file

3) If you want the fastest likely fix: move the bootstrap file OUT of the workspace

4) If it still happens after that

Step 1: remove BOOTSTRAP entirely from the workspace (not just rename)

Step 2: prove whether the model is actually getting chat history

Step 3: isolate whether it’s WebChat specifically

Step 4: capture one concrete “forgot everything” exchange

Quick “is tool use working?” test (forces a tool call)

If tool calling is flaky: try a different Ollama model

One more knob that helps tool use

1) First: confirm the basics (run these in a real terminal, not via chat)

2) Check if sessions are actually being written to disk

3) About Ollama + tool calls (why exec ls ... “says it ran” but didn’t)

1) exec ls -la … is not a chat command

2) “This appears to be our first interaction” = your session is not being resumed

What your status tells me

Next 2 checks (please paste output)

A) Check your session reset settings

B) Check if the gateway is restarting

1) Is the gateway restarting?

2) Are Discord history + permissions OK?

3) Are you actually chatting in Discord or in the TUI?

Bonus (for the command you originally wanted)

Step 1 — Check Discord permissions + history wrapping

Step 2 — Check if the Gateway is restarting

Quick sanity check (optional but very telling)

0) First: update (since you explicitly asked earlier)

1) Check if the Gateway is restarting (most common cause of “amnesia”)

2) Verify sessions are actually persisting on disk

3) Reproduce once while watching logs

1) Confirm you’re in ONE stable TUI session

2) Check if the model is losing the system prompt (prompt truncation)

3) Verify Ollama’s real context length (don’t trust autodetect yet)

4) While reproducing once, watch the gateway logs

Step 1 — Verify Ollama’s real context for that model

Step 2 — Quick A/B test (shrinks the prompt massively)

If Step 2 fixes it (recommended long-term fix)

1) Verify whether this is a real session reset (takes 20 seconds)

2) Quick A/B: shrink the prompt and see if GLM behaves

3) If it still “forgets” even on minimal tools: grab the log signal

2) Your runs show `messageChannel=webchat` and `sessionKey=unknown`

3) One more oddity: `/home/b/...` vs `/home/brandon/...`

Step 1: verify nobody else is running a gateway (especially user `b`)

1) Does the `sessionId` change when it “resets”?

2) Check for “webchat identity missing” in logs (`sessionKey=unknown`)

3) About Ollama + tool calls (why `exec ls ...` “says it ran” but didn’t)

1) `exec ls -la …` is not a chat command

If it says `openai-responses`

1) Is OpenClaw hitting `/v1/chat/completions` or `/v1/completions`?

When OpenClaw sends the second turn (“What is the codeword?”), is the word `pineapple` present anywhere in the HTTP request body?

0) Gotcha: don’t type `session agent:main:main` as plain text