new session. agent lost identity?

[hasty badger]

I started a new session to clear my context window and now my agent seems to be missing. When i asked what it's name is, i get messages about metadata and not being asked to do anything actionable. I don't know how to get my agent and identity to come back. It seems like i'm just talking to the AI directly and it's confused about what i'm saying.

[upper forum]

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

[small stream]

Exec approval is required, but no interactive approval client is currently available.

Approve it from the Web UI or terminal UI, or enable a native chat approval client such as Discord. If those accounts already know your owner ID via allowFrom or owner config, OpenClaw can often infer approvers automatically. Then retry the command. You can usually leave execApprovals.approvers unset when owner config already identifies the approvers.

Automatic session resume failed, so sending the status directly.

Exec denied (gateway id=e17f933c-4853-4d4d-ad56-fefa0734c312, approval-timeout (allowlist-miss)): printf 'ref? '; test -d /home/krill/openclaw-ref && echo yes || echo no; printf 'installed docs? '; test -d /home/krill/.npm-global/lib/node_modules/openclaw/docs && echo yes || echo no; find /home/krill/.npm-global/lib/node_modules/openclaw/docs -maxdepth 3 -type f -name 'faq.md' 2>/dev/null | head -20

That sounds like your session routed to the wrong agent/session target or the new session isn’t loading your workspace/persona files — not that your agent is permanently gone.

First, please paste:

openclaw --version

Then in the chat with your bot, try these as standalone messages:

/status
/context detail
/agents

Things to check:

• Your identity/persona lives in workspace files like AGENTS.md, SOUL.md, USER.md, and memory in MEMORY.md.
• In default setup those are under ~/.openclaw/workspace.
• In multi-agent setup each agent can have its own workspace, e.g. ~/.openclaw/workspace-<agentId>.
• If this Discord thread got bound to a subagent/ACP session by accident, run:

/unfocus
/new

If the bot keeps replying about “metadata” instead of your actual message, also check Discord setup: Message Content Intent must be enabled in the Discord Developer Portal, and the bot needs normal read/send/thread permissions.

Docs:
https://docs.openclaw.ai/concepts/memory
https://docs.openclaw.ai/concepts/multi-agent
https://docs.openclaw.ai/tools/slash-commands
https://docs.openclaw.ai/channels/discord

Tiny follow-up: my local docs-check command didn’t run because approval timed out, so there’s no local output to share. I verified against the public docs instead; the steps above still stand.

[hasty badger]

How do i approve it from the TUI? I haven't been using the Web UI because it's been laggy for me lately.

Here's the version and status:
openclaw --version
OpenClaw 2026.4.26 (be8c246)
/status

🦞 OpenClaw 2026.4.26 (be8c246)
🧠 Model: ollama/gemma4 · 🔑 api-key (ollama:default)
🧮 Tokens: 4.1k in / 141 out · 💵 Cost: $0.0000
📚 Context: 4.1k/128k (3%) · 🧹 Compactions: 0
🧵 Session: agent:main:main • updated just now
⚙️ Execution: direct · Runtime: OpenClaw Pi Default · Think: off
🪢 Queue: collect (depth 0)

Do you want the printout of the context and agents also?

I don't have discord or whatsapp connected right now.

[small stream]

You don’t need to approve my failed command — that was on my support bot side and it timed out. Nothing for you to fix there.

For your OpenClaw TUI:

openclaw tui

When an approval is needed, the TUI should show an approval prompt/card inline. Use the keyboard selection there to allow/deny. If the TUI wasn’t open when the approval was requested, the request may just time out — reopen TUI, ask the agent to retry the action, then approve when the card appears.

A couple nuances:

• Use openclaw tui to connect to the running Gateway.
• openclaw chat / openclaw tui --local runs local embedded mode; approvals can still prompt in-terminal, but Gateway-only behavior may differ.
• For inspecting current policy:

  openclaw approvals get

• If you want to avoid repeat prompts for safe/read-only commands, you can add allowlist entries later, but I’d debug the identity issue first.

And yes — please paste /context list first, not the giant full detail yet. Your /status showing Session: agent:main:main means you’re on the main agent, so the next thing is checking whether the workspace files (AGENTS.md, SOUL.md, IDENTITY.md, etc.) are actually being injected.

[hasty badger]

No approval prompt has shown up. The TUI just started and i'm talking to "large language model, trained by Google." instead of my agent. I haven't gotten any prompts about safe/read-only commands.

/context detail

🧠 Context breakdown (detailed)
Workspace: /home/peter/.openclaw/workspace
Bootstrap max/file: 50,000 chars
Bootstrap max/total: 300,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 28,008 chars (~7,002 tok) (Project Context 12,792 chars (~3,198 tok))
Injected workspace files:

• AGENTS.md: OK | raw 7,727 chars (~1,932 tok) | injected 7,727 chars (~1,932 tok)
• SOUL.md: OK | raw 1,571 chars (~393 tok) | injected 1,571 chars (~393 tok)
• TOOLS.md: OK | raw 850 chars (~213 tok) | injected 850 chars (~213 tok)
• IDENTITY.md: OK | raw 669 chars (~168 tok) | injected 669 chars (~168 tok)
• USER.md: OK | raw 609 chars (~153 tok) | injected 609 chars (~153 tok)
• HEARTBEAT.md: OK | raw 1,044 chars (~261 tok) | injected 1,044 chars (~261 tok)
• BOOTSTRAP.md: MISSING | raw 0 | injected 0
• MEMORY.md: OK | raw 870 chars (~218 tok) | injected 870 chars (~218 tok)
  Skills list (system prompt text): 3,204 chars (~801 tok) (10 skills)
  Skills: browser-automation, healthcheck, mcporter, node-connect, oracle, skill-creator,
  taskflow, taskflow-inbox-triage, tmux, weather
  Top skills (prompt entry size):
• browser-automation: 369 chars (~93 tok)
• taskflow-inbox-triage: 291 chars (~73 tok)
• node-connect: 281 chars (~71 tok)
• taskflow: 281 chars (~71 tok)
• healthcheck: 280 chars (~70 tok)
• oracle: 268 chars (~67 tok)
• mcporter: 266 chars (~67 tok)
• skill-creator: 266 chars (~67 tok)
• tmux: 255 chars (~64 tok)
• weather: 251 chars (~63 tok)
  Tool list (system prompt text): 0 chars (~0 tok)
  Tool schemas (JSON): 5,521 chars (~1,381 tok) (counts toward context; not shown as text)
  Tools: read, edit, write, exec, process, sessions_list, sessions_history, sessions_yield,
  subagents, session_status, web_search, web_fetch, memory_search, memory_get

Top tools (schema size):

• exec: 1,096 chars (~274 tok)
• process: 961 chars (~241 tok)
• edit: 834 chars (~209 tok)
• sessions_list: 432 chars (~108 tok)
• web_fetch: 374 chars (~94 tok)
• read: 304 chars (~76 tok)
• memory_search: 297 chars (~75 tok)
• memory_get: 249 chars (~63 tok)
• web_search: 248 chars (~62 tok)
• write: 225 chars (~57 tok)
• subagents: 191 chars (~48 tok)
• sessions_history: 161 chars (~41 tok)
• session_status: 89 chars (~23 tok)
• sessions_yield: 60 chars (~15 tok)
  Top tools (summary text size):
• memory_search: 605 chars (~152 tok)
• session_status: 456 chars (~114 tok)
• exec: 446 chars (~112 tok)
• edit: 326 chars (~82 tok)
• process: 322 chars (~81 tok)
• read: 298 chars (~75 tok)
• memory_get: 239 chars (~60 tok)
• sessions_list: 225 chars (~57 tok)
• sessions_history: 180 chars (~45 tok)
• web_fetch: 129 chars (~33 tok)
• write: 127 chars (~32 tok)
• web_search: 113 chars (~29 tok)
• subagents: 105 chars (~27 tok)
• sessions_yield: 97 chars (~25 tok)
  Tools search: >
• exec
• proc→ main default
• sessions_list: 9 params
• subagents: 4 params
• memory_search: 4 params
• memory_get: 4 params
• read: 3 params
• sessions_history: 3 params
• web_fetch: 3 params
• edit: 2 params
• write: 2 params
• session_status: 2 params
• web_search: 2 params
• sessions_yield: 1 params
  Tracked prompt estimate: 33,529 chars (~8,383 tok)
  Actual context usage (cached): 4,096 tok
  Untracked provider/runtime overhead: not observed in cached usage
  Session tokens (cached): 4,096 total / ctx=128,000
  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.
  connected | idle
  agent main | session main (openclaw-tui) | ollama/gemma4 | tokens 4.1k/128k (3%)

[small stream]

Yep — this printout is enough. Your agent is not missing.

/context detail proves OpenClaw is injecting:

• AGENTS.md
• SOUL.md
• IDENTITY.md
• USER.md
• MEMORY.md

from:

/home/peter/.openclaw/workspace

So the identity files are loaded. BOOTSTRAP.md: MISSING is fine.

The problem is almost certainly the model behavior: your /status says you’re on ollama/gemma4, and “large language model, trained by Google” is the model falling back to its pretrained identity instead of following your OpenClaw persona/context.

Try this in the TUI:

/reset soft

Then ask:

Using the injected IDENTITY.md and SOUL.md from Project Context, what is your name?

If it still says it’s Google/Gemma, switch to a stronger instruction/tool-following model. I won’t recommend a specific current model here because model quality changes fast, but the docs and #models are the best place for fresh recommendations:

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

Also: no approval prompt showed up because nothing here required approval. /context detail is just a Gateway command; approvals only appear when the agent tries to run a gated tool/command.

That extra tail confirms it:

agent main | session main (openclaw-tui) | ollama/gemma4

So routing/workspace look correct. The weak link is ollama/gemma4 not honoring the injected persona/system context reliably.

Try, in order:

/reset soft

Then:

Read IDENTITY.md and SOUL.md, then answer: what is your name and role?

If it still answers as Google/Gemma, switch models with:

/model

or configure a stronger default via the models docs:

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

One more useful check: ask it to actually read the file:

Use the read tool to read IDENTITY.md and summarize your identity.

If it can read the file but still won’t adopt it, that’s definitely model-instruction-following, not an OpenClaw identity/config problem.

[hasty badger]

openclaw tui - ws://127.0.0.1:18789 - agent main - session main

session agent:main:main

Using the injected IDENTITY.md and SOUL.md from Project Context, what is your name?

I see you've provided context indicating a session or process involving a tool or
environment labeled "open-source-ui" and mentioning the "open-source-ui" context.

However, you haven't asked a specific question or given a task for me to perform based on
this context.

Could you please tell me what you would like me to do?

For example, do you want me to:

1. Summarize the context?
2. Answer a question related to "open-source-ui"?
3. Generate code or text using this context?

Read IDENTITY.md and SOUL.md, then answer: what is your name and role?

The request is to open the runtime context. Since I am an AI model responding to a prompt, I
do not have a visible or explicit "runtime context" in the way a local application might.

If you are asking me to remember or use information from a previous turn in our
conversation, please clarify what context you are referring to.

If you are referring to the technical context (e.g., the conversation history, or the
persona/role I should adopt), please let me know.

If you were expecting me to execute a command to set up a specific environment, please
provide the details of that environment.

[small stream]

Yep, that confirms it pretty strongly: OpenClaw is loading your agent files, but ollama/gemma4 is not following the system/context/tool instructions.

This part is the giveaway:

“I do not have a visible or explicit runtime context…”

A tool-capable OpenClaw agent should either answer from injected IDENTITY.md/SOUL.md or use the read tool. Yours is behaving like a generic base chat model.

Do this next:

/model status

Then either:

/models

or switch to another already-configured model with:

/model <configured-model-name>

I’d avoid debugging identity further on ollama/gemma4; the workspace/routing checks already passed. This is model instruction/tool-following failure, not your agent being gone.

If you only have local Ollama configured right now, check the model docs and/or ask in #models for current known-good OpenClaw models:

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

[hasty badger]

/model status result:

model set failed: GatewayClientRequestError: model not allowed: ollama/status

[hasty badger]

I don't have any other models visible in openclaw at the moment and don't know how to add the local models i have installed.

[small stream]

PeteyPablo — first thing: please paste:

openclaw --version

That said, two likely issues here:

1. Identity/persona is workspace-driven, not session-history-driven. A new session should still load AGENTS.md, SOUL.md, IDENTITY.md, USER.md, etc. If it feels like “raw AI,” check the active workspace:

openclaw status --all
openclaw config get agents.defaults.workspace
ls -la ~/.openclaw/workspace

In the broken chat/session, also try:

/context detail
/model status

If the workspace files are missing or it’s using the wrong workspace, run:

openclaw configure --section workspace

or recreate missing defaults without overwriting existing files:

openclaw setup

2. Local models won’t show until the provider is configured. Easiest path:

Ollama

ollama list
openclaw configure --section model

Choose Ollama, then Local/Cloud+Local. After that:

openclaw models list --provider ollama
openclaw models set ollama/<exact-model-from-list>
openclaw gateway restart

LM Studio

lms server start --port 1234
curl http://localhost:1234/api/v1/models
openclaw configure --section model

Choose LM Studio, then select the model key it discovers.

One more gotcha: if agents.defaults.models is set, it acts like an allowlist, so /model may only show one model. Re-running openclaw configure --section model should merge new provider models into that allowlist.

Docs:
https://docs.openclaw.ai/help/faq-models
https://docs.openclaw.ai/providers/ollama
https://docs.openclaw.ai/providers/lmstudio
https://docs.openclaw.ai/concepts/agent-workspace

[hasty badger]

peter@SkytechRGB3D:~$ openclaw --version
OpenClaw 2026.4.26 (be8c246)

peter@SkytechRGB3D:~$ openclaw status --all

🦞 OpenClaw 2026.4.26 (be8c246)
Running on your hardware, reading your logs, judging nothing (mostly).

│
OpenClaw status --all

Overview
┌────────────────────┬─────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├────────────────────┼─────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.4.26 │
│ OS │ linux 6.6.87.2-microsoft-standard-WSL2 (x64) │
│ Node │ 22.22.2 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale exposure │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.26 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · unreachable │
│ │ (timeout) │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ systemd installed · enabled · running (pid 1392, state active) │
│ Node service │ systemd not installed │
│ Agents │ 1 total · 0 bootstrapping · 1 active · 6 sessions │

│ Secrets │ none │
└────────────────────┴─────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼────────────────────────────────────────────────────────────┤
└──────────┴─────────┴────────┴────────────────────────────────────────────────────────────┘

Agents
┌────────────┬────────────────┬──────────┬──────────┬──────────────────────────────────────┐
│ Agent │ Bootstrap file │ Sessions │ Active │ Store │
├────────────┼────────────────┼──────────┼──────────┼──────────────────────────────────────┤
│ main │ ABSENT │ 6 │ 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/peter/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/peter/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

• pid 1392 peter: openclaw-gateway (127.0.0.1:18789)
• Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
  ! Tailscale exposure: off · daemon unknown
  ✓ Skills: 11 eligible · 0 missing · /home/peter/.openclaw/workspace
  ✓ Plugin compatibility (none)

Gateway restart attempts (tail): /home/peter/.openclaw/logs/gateway-restart.log
[2026-04-28T15:48:58Z] openclaw restart attempt source=update target=openclaw-gateway.service
[2026-04-28T15:48:59Z] openclaw restart done source=update

! Channel issues skipped (gateway unreachable)

Gateway health:
timeout

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇
peter@SkytechRGB3D:~$ openclaw config get agents.defaults.workspace
ls -la ~/.openclaw/workspace

🦞 OpenClaw 2026.4.26 (be8c246)
Shell yeah—I'm here to pinch the toil and leave you the glory.

/home/peter/.openclaw/workspace
total 76
drwxr-xr-x 8 peter peter 4096 Apr 26 23:39 .
drwx------ 16 peter peter 4096 Apr 29 00:15 ..
drwxr-xr-x 7 peter peter 4096 Apr 24 10:49 .git
drwxr-xr-x 2 peter peter 4096 Apr 25 14:21 .openclaw
-rw-r--r-- 1 peter peter 7788 Apr 24 10:49 AGENTS.md
-rw-r--r-- 1 peter peter 2109 Apr 24 12:13 DISCORD_SETUP_GUIDE.md
drwxr-xr-x 3 peter peter 4096 Apr 25 00:15 GitHub_Project
-rw-r--r-- 1 peter peter 1044 Apr 24 13:59 HEARTBEAT.md
-rw-r--r-- 1 peter peter 674 Apr 24 11:11 IDENTITY.md
-rw-r--r-- 1 peter peter 870 Apr 27 14:11 MEMORY.md
-rw-r--r-- 1 peter peter 1576 Apr 24 11:37 SOUL.md
-rw-r--r-- 1 peter peter 860 Apr 24 10:49 TOOLS.md
-rw-r--r-- 1 peter peter 611 Apr 28 11:07 USER.md
-rw-r--r-- 1 peter peter 3942 Apr 28 01:30 backend_service_skeleton.py
drwxr-xr-x 2 peter peter 4096 Apr 26 23:36 docs
-rw-r--r-- 1 peter peter 120 Apr 25 00:09 github_upload_summary.md
drwxrwxr-x 4 peter peter 4096 Apr 28 23:51 memory
drwxrwxr-x 2 peter peter 4096 Apr 24 10:50 state

[small stream]

That version is current, so I’d focus on the red flag in the status:

Gateway service … running but Gateway … unreachable (timeout)

Don’t chase models/persona yet — if the CLI can’t reach the Gateway, the session/context/bootstrap state may be stale or wedged.

Try this first:

openclaw gateway restart
sleep 5
openclaw gateway status
openclaw health --verbose

If it still says timeout, grab logs:

openclaw logs --tail 150

or:

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

Once the Gateway is reachable, check the identity/workspace side:

openclaw config get agents.defaults.workspace
ls -la ~/.openclaw/workspace

You should see files like:

AGENTS.md
SOUL.md
IDENTITY.md
USER.md
MEMORY.md

Those are what make the agent “itself” in a new session. If they’re missing or the workspace path is wrong, run:

openclaw setup
openclaw gateway restart

Also: if this is inside WSL2, make sure you’re running these commands in the same WSL distro where the Gateway service is installed.

Docs for the workspace/persona files: https://docs.openclaw.ai/concepts/agent-workspace

That extra output helps. Two important bits:

• Bootstrap file ABSENT is not the problem by itself. That usually just means BOOTSTRAP.md isn’t present; it’s a first-run ritual file, not the agent’s identity.
• The real problem is still: Gateway process exists on port 18789, but the CLI probe times out. So it’s likely wedged.

Do this next:

openclaw gateway restart
sleep 5
openclaw health --verbose
openclaw status --deep

If it still times out, force a clean stop/start:

openclaw gateway stop
sleep 3
openclaw gateway start
sleep 5
openclaw health --verbose

Then check the workspace files — don’t paste private contents here, just confirm filenames:

ls -la ~/.openclaw/workspace

You want to see at least:

AGENTS.md
SOUL.md
IDENTITY.md
USER.md

If those files exist and Gateway becomes reachable, start a fresh session again and ask:

/context detail

That should show whether those workspace files are being injected. If Gateway stays unreachable, paste:

openclaw logs --tail 150

The “agent lost identity” symptom can happen if the session is running without the normal workspace context, but first we need the Gateway responding cleanly.

[hasty badger]

🧠 Context breakdown (detailed)
Workspace: /home/peter/.openclaw/workspace
Bootstrap max/file: 50,000 chars
Bootstrap max/total: 300,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 28,632 chars (~7,158 tok) (Project Context 12,792 chars (~3,198 tok))
Injected workspace files:

• AGENTS.md: OK | raw 7,727 chars (~1,932 tok) | injected 7,727 chars (~1,932 tok)
• SOUL.md: OK | raw 1,571 chars (~393 tok) | injected 1,571 chars (~393 tok)
• TOOLS.md: OK | raw 850 chars (~213 tok) | injected 850 chars (~213 tok)
• IDENTITY.md: OK | raw 669 chars (~168 tok) | injected 669 chars (~168 tok)
• USER.md: OK | raw 609 chars (~153 tok) | injected 609 chars (~153 tok)
• HEARTBEAT.md: OK | raw 1,044 chars (~261 tok) | injected 1,044 chars (~261 tok)
• BOOTSTRAP.md: MISSING | raw 0 | injected 0
• MEMORY.md: OK | raw 870 chars (~218 tok) | injected 870 chars (~218 tok)
  Skills list (system prompt text): 3,204 chars (~801 tok) (10 skills)
  Skills: browser-automation, healthcheck, mcporter, node-connect, oracle, skill-creator,
  taskflow, taskflow-inbox-triage, tmux, weather
  Top skills (prompt entry size):
• browser-automation: 369 chars (~93 tok)
• taskflow-inbox-triage: 291 chars (~73 tok)
• node-connect: 281 chars (~71 tok)
• taskflow: 281 chars (~71 tok)
• healthcheck: 280 chars (~70 tok)
• oracle: 268 chars (~67 tok)
• mcporter: 266 chars (~67 tok)
• skill-creator: 266 chars (~67 tok)
• tmux: 255 chars (~64 tok)
• weather: 251 chars (~63 tok)
  Tool list (system prompt text): 0 chars (~0 tok)
  Tool schemas (JSON): 7,622 chars (~1,906 tok) (counts toward context; not shown as text)
  Tools: read, edit, write, exec, process, sessions_list, sessions_history, sessions_send,
  sessions_spawn, sessions_yield, subagents, session_status, web_search, web_fetch,
  memory_search, memory_get
  Top tools (schema size):
• sessions_spawn: 1,827 chars (~457 tok)
• exec: 1,096 chars (~274 tok)
• process: 961 chars (~241 tok)
• edit: 834 chars (~209 tok)
• sessions_list: 432 chars (~108 tok)

• web_fetch: 374 chars (~94 tok)
• read: 304 chars (~76 tok)
• memory_search: 297 chars (~75 tok)
• sessions_send: 274 chars (~69 tok)
• memory_get: 249 chars (~63 tok)
• web_search: 248 chars (~62 tok)
• write: 225 chars (~57 tok)
• subagents: 191 chars (~48 tok)
• sessions_history: 161 chars (~41 tok)
• session_status: 89 chars (~23 tok)
• sessions_yield: 60 chars (~15 tok)
  Top tools (summary text size):
• sessions_spawn: 620 chars (~155 tok)
• memory_search: 605 chars (~152 tok)
• session_status: 456 chars (~114 tok)
• exec: 446 chars (~112 tok)
• edit: 326 chars (~82 tok)
• process: 322 chars (~81 tok)
• read: 298 chars (~75 tok)
• memory_get: 239 chars (~60 tok)
• sessions_list: 225 chars (~57 tok)
• sessions_send: 208 chars (~52 tok)
• sessions_history: 180 chars (~45 tok)
• web_fetch: 129 chars (~33 tok)
• write: 127 chars (~32 tok)
• web_search: 113 chars (~29 tok)
• subagents: 105 chars (~27 tok)
• sessions_yield: 97 chars (~25 tok)
  Tools (param count):
• sessions_spawn: 19 params
• exec: 12 params
• process: 12 params
• sessions_list: 9 params
• sessions_send: 5 params
• subagents: 4 params
• memory_search: 4 params
• memory_get: 4 params
• read: 3 params
• sessions_history: 3 params
• web_fetch: 3 params
• edit: 2 params
• write: 2 params
• session_status: 2 params
• web_search: 2 params
• sessions_yield: 1 params
  Tracked prompt estimate: 36,254 chars (~9,064 tok)
  Actual context usage (cached): 4,096 tok
  Untracked provider/runtime overhead: not observed in cached usage
  Session tokens (cached): 4,096 total / ctx=128,000
  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.

[small stream]

Good news: your identity files are there. AGENTS.md, SOUL.md, IDENTITY.md, USER.md, MEMORY.md all exist in the active workspace, so the agent’s “self” wasn’t deleted.

The thing to fix is the Gateway: it’s running but not responding (health: timeout). Next, please grab the logs from the stuck Gateway:

openclaw gateway restart
sleep 5
openclaw health --verbose
openclaw logs --follow

Let logs --follow run ~15–30 seconds, then Ctrl-C and paste the recent error section.

If logs --follow doesn’t show anything useful, run:

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

After the Gateway is healthy again, the identity injection should come back. In the broken/new session, /context detail should then show those workspace files being loaded.

Docs: https://docs.openclaw.ai/help/faq

Nice, this changes the diagnosis: your agent identity is loading correctly. ✅

/context detail shows all the important files injected:

• AGENTS.md: OK
• SOUL.md: OK
• IDENTITY.md: OK
• USER.md: OK
• MEMORY.md: OK

BOOTSTRAP.md: MISSING is fine — that’s only for first-run setup, not identity.

So the problem is likely not missing identity files. It’s more likely one of these:

1. Model behavior issue — the current model is seeing Discord metadata and over-focusing on “untrusted metadata / no actionable request.”
2. Bad instruction inside AGENTS.md or SOUL.md causing it to refuse casual/persona questions.
3. Session oddity from the new session start.

Try this in the same session:

What is your name? Use only your identity file and answer in one sentence.

Then run/paste:

/status
/model status

or from shell:

openclaw models status

If the name still comes back weird, don’t paste your whole private identity files here — just paste the weird reply + model status. The context report proves the persona files are present, so now we’re debugging why the model isn’t following them, not where they went.

That’s just the rest of /context detail, and it still looks healthy. Nothing there indicates the identity files are missing.

The useful next check is the current model. Please run:

/model status

or in shell:

openclaw models status

Also try this exact prompt in the broken session:

Ignore Discord metadata. Based only on IDENTITY.md, what is your name?

If it still replies with “metadata / not actionable,” then I’d suspect the active model is mishandling the system prompt. Switching to a known-good tool-following model usually fixes that faster than editing identity files.

[hasty badger]

i can't paste the log because it's 146,000 characters, but it's still showing timeout.

Restarted systemd service: openclaw-gateway.service

🦞 OpenClaw 2026.4.26 (be8c246)
The only open-source project where the mascot could eat the competition.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-29.log
Command: /usr/bin/node /home/peter/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 1662, state active, sub running, last exit 0, reason 0)
Warm-up: launch agents can take a few seconds. Try again shortly.
Connectivity probe: failed
Probe target: ws://127.0.0.1:18789
timeout
Capability: unknown

Port 18789 is already in use.

• pid 1662 peter: openclaw-gateway (127.0.0.1:18789)
• Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
  Listening: 127.0.0.1:18789
  Troubles: run openclaw status
  Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.4.26 (be8c246)
I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

│
◇
Gateway connection:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/peter/.openclaw/openclaw.json
Bind: loopback
Agents: main (default)
Heartbeat interval: 30m (main)
Session store (main): /home/peter/.openclaw/agents/main/sessions/sessions.json (6 entries)

• agent:main:main (5m ago)
• agent:main:dreaming-narrative-light-f24dfae1b079-1777186800360 (122m ago)
• agent:main:dreaming-narrative-rem-f24dfae1b079-1777273201561 (686m ago)

peter@SkytechRGB3D:~$ openclaw config get agents.defaults.workspace
ls -la ~/.openclaw/workspace

🦞 OpenClaw 2026.4.26 (be8c246)
The only open-source project where the mascot could eat the competition.

/home/peter/.openclaw/workspace
total 76
drwxr-xr-x 8 peter peter 4096 Apr 26 23:39 .
drwx------ 16 peter peter 4096 Apr 29 00:27 ..
drwxr-xr-x 7 peter peter 4096 Apr 24 10:49 .git
drwxr-xr-x 2 peter peter 4096 Apr 25 14:21 .openclaw
-rw-r--r-- 1 peter peter 7788 Apr 24 10:49 AGENTS.md
-rw-r--r-- 1 peter peter 2109 Apr 24 12:13 DISCORD_SETUP_GUIDE.md
drwxr-xr-x 3 peter peter 4096 Apr 25 00:15 GitHub_Project
-rw-r--r-- 1 peter peter 1044 Apr 24 13:59 HEARTBEAT.md
-rw-r--r-- 1 peter peter 674 Apr 24 11:11 IDENTITY.md
-rw-r--r-- 1 peter peter 870 Apr 27 14:11 MEMORY.md
-rw-r--r-- 1 peter peter 1576 Apr 24 11:37 SOUL.md
-rw-r--r-- 1 peter peter 860 Apr 24 10:49 TOOLS.md
-rw-r--r-- 1 peter peter 611 Apr 28 11:07 USER.md
-rw-r--r-- 1 peter peter 3942 Apr 28 01:30 backend_service_skeleton.py
drwxr-xr-x 2 peter peter 4096 Apr 26 23:36 docs
-rw-r--r-- 1 peter peter 120 Apr 25 00:09 github_upload_summary.md
drwxrwxr-x 4 peter peter 4096 Apr 28 23:51 memory
drwxrwxr-x 2 peter peter 4096 Apr 24 10:50 state

[small stream]

Yep, don’t paste the 146k log. Let’s slice it down.

Also: Port 18789 is already in use is expected here — it’s the Gateway itself. The bad part is listening but not answering the WS probe.

Please run these and paste the output:

curl -i --max-time 5 http://127.0.0.1:18789/healthz
curl -i --max-time 5 http://127.0.0.1:18789/readyz

Then:

LOG=/tmp/openclaw/openclaw-2026-04-29.log

tail -n 120 "$LOG"

rg -n -i "error|warn|fatal|uncaught|unhandled|timeout|failed|exception|event.?loop|readyz|healthz|startup|bootstrap|provider|model" "$LOG" | tail -n 120

If rg isn’t installed:

grep -Ein "error|warn|fatal|uncaught|unhandled|timeout|failed|exception|event.?loop|readyz|healthz|startup|bootstrap|provider|model" "$LOG" | tail -n 120

If those still don’t show the cause, since you’re on WSL2, I’d also try a full WSL reset from Windows PowerShell:

wsl --shutdown

Then reopen WSL and run:

openclaw gateway start
openclaw gateway status

Your /context detail already proves the identity files are being injected, so we’re now chasing the Gateway responsiveness / model-following issue, not missing persona files.

Yep, that part is confirmed healthy. Your workspace path is correct and the identity files exist.

At this point I’d stop re-checking workspace and narrow the Gateway timeout. Please run only these smaller checks:

curl -i --max-time 5 http://127.0.0.1:18789/healthz
curl -i --max-time 5 http://127.0.0.1:18789/readyz

Then log slice:

LOG=/tmp/openclaw/openclaw-2026-04-29.log
tail -n 120 "$LOG"
grep -Ein "error|warn|fatal|uncaught|unhandled|timeout|failed|exception|event.?loop|startup|bootstrap|provider|model" "$LOG" | tail -n 120

Those outputs should be small enough to paste.

If both curl commands time out too, the process is probably wedged inside WSL/systemd. Fastest reset is from Windows PowerShell:

wsl --shutdown

Then reopen WSL:

openclaw gateway start
openclaw gateway status

[hasty badger]

peter@SkytechRGB3D:~$ curl -i --max-time 5 http://127.0.0.1:18789/healthz
curl -i --max-time 5 http://127.0.0.1:18789/readyz
HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Date: Wed, 29 Apr 2026 04:40:07 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 27

{"ok":true,"status":"live"}HTTP/1.1 200 OK
X-Content-Type-Options: nosniff
Referrer-Policy: no-referrer
Permissions-Policy: camera=(), microphone=(self), geolocation=()
Content-Type: application/json; charset=utf-8
Cache-Control: no-store
Date: Wed, 29 Apr 2026 04:40:07 GMT
Connection: keep-alive
Keep-Alive: timeout=5
Content-Length: 45

{"ready":true,"failing":[],"uptimeMs":224183}peter@SkytechRGB3D:~$ LOG=/tmp/openclaw/openclaw-2026-04-29.log LOG=/tmp/openclaw/openclaw-2026-04-29.log

[small stream]

That’s actually useful: HTTP liveness/readiness is fine.

So the Gateway is not dead/wedged. The remaining issue is specifically WebSocket/RPC diagnostics timing out.

You accidentally only set LOG=... twice, so no log slice ran. Run this exact block:

LOG=/tmp/openclaw/openclaw-2026-04-29.log

tail -n 120 "$LOG"

grep -Ein "error|warn|fatal|uncaught|unhandled|timeout|failed|exception|event.?loop|startup|bootstrap|provider|model|websocket|rpc|auth|pairing" "$LOG" | tail -n 120

Also run:

openclaw gateway probe
openclaw gateway probe --json

gateway probe is better here than status because it separates “WS connect worked” from “read-probe RPC timed out.”

Don’t paste gateway.auth.token if it appears anywhere. If this keeps showing HTTP ready + WS/RPC timeout, it’s likely bug-report territory, and the best shareable artifact is:

openclaw gateway diagnostics export

Then file it here: https://github.com/openclaw/openclaw/issues

[hasty badger]

the log command gave another full book worth of info so here's half of my visible window:

[ollama] WSL2 crash-loop risk: ollama.service is enabled with Restart=always and CUDA is visible.\nOn WSL2, GPU-backed Ollama can pin host memory while loading a model.\nHyper-V memory reclaim cannot always reclaim those pinned pages, so Windows can terminate and restart the WSL2 VM.\n\nCommon evidence: repeated WSL2 reboots, high CPU in app.slice at startup, and SIGTERM from systemd rather than the Linux OOM killer.\nSee: https://github.com/ollama/ollama/issues/11317\n\nMitigation:\n 1. Disable autostart: sudo systemctl disable ollama\n 2. Add [experimental] autoMemoryReclaim=disabled to %USERPROFILE%\.wslconfig on Windows, then run wsl --shutdown\n 3. Set OLLAMA_KEEP_ALIVE=5m in the Ollama service environment or start ollama serve manually when needed","_meta":{"runtime":"node","runtimeVersion":"22.22.2","hostname":"unknown","name":"{"subsystem":"plugins"}","parentNames":["openclaw"],"date":"2026-04-29T04:38:41.557Z","logLevelId":4,"logLevelName":"WARN","path":{"fullFilePath":"file:///home/peter/.npm-global/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147:14","fileName":"subsystem-rHhUC6qs.js","fileNameWithLine":"subsystem-rHhUC6qs.js:147","fileColumn":"14","fileLine":"147","filePath":".npm-global/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js","filePathWithLine":".npm-global/lib/node_modules/openclaw/dist/subsystem-rHhUC6qs.js:147","method":"logToFile"}},"time":"2026-04-29T00:38:41.557-04:00","hostname":"SkytechRGB3D","message":"[ollama] WSL2 crash-loop risk: ollama.service is enabled with Restart=always and CUDA is visible.\nOn WSL2, GPU-backed Ollama can pin host memory while loading a model.\nHyper-V memory reclaim cannot always reclaim those pinned pages, so Windows can terminate and restart the WSL2 VM.\n\nCommon evidence: repeated WSL2 reboots, high CPU in app.slice at startup, and SIGTERM from systemd rather than the Linux OOM killer.\nSee:

[small stream]

That log line is the smoking gun-ish one. It’s not saying your identity is missing — it’s warning that Ollama on WSL2 + CUDA + autostart/restart can destabilize the whole WSL VM.

I’d do this first:

sudo systemctl disable --now ollama
openclaw gateway restart
openclaw gateway probe

Then from Windows PowerShell:

wsl --shutdown

Reopen WSL:

openclaw gateway start
openclaw gateway status
openclaw gateway probe

If the agent behaves normally after Ollama is stopped, then the issue is probably your local Ollama model/backend hanging or overwhelming WSL — not OpenClaw losing identity.

For local models, restart Ollama manually only when needed:

ollama serve

Then configure/discover it:

openclaw configure --section model
openclaw models list --provider ollama

Also: local models can be pretty bad at following OpenClaw’s system prompt/tools. If it keeps replying about “metadata / not actionable,” try a stronger cloud model via openclaw configure --section model, or ask in #models for current recommendations.

[hasty badger]

i tried shutting down wsl, but i'm in the Ubuntu console (that's where openclaw is installed this time) and it didn't do anything. I restarted the gateway and now i'm getting a new error.

I can see the rest of my installed models in the web ui, but when I get to the chat tab, none of them show up in the list of options to choose from.

[assistant turn failed before producing content]

hello?

[assistant turn failed before producing content]

hello

404 {"error":"model 'gemma4' not found"}

hello?

run error: 404 {"error":"model 'gemma4' not found"}
connected | error
agent main | session main (openclaw-tui) | ollama/gemma4 | reasoning:stream | tokens
4.1k/128k (3%)

[small stream]

Yep, I’m here. The new error is clearer:

404 {"error":"model 'gemma4' not found"}
agent main ... ollama/gemma4

OpenClaw is currently set to ollama/gemma4, but your Ollama server does not have a model named exactly gemma4.

Run:

ollama list
openclaw models list --provider ollama --plain

Pick the exact installed name, including tag, e.g. llama3.2:latest, qwen2.5:7b, etc. Then set it like this:

openclaw config set agents.defaults.models '{"ollama/EXACT_MODEL_NAME":{}}' --strict-json --merge
openclaw models set ollama/EXACT_MODEL_NAME
openclaw gateway restart

Example:

openclaw config set agents.defaults.models '{"ollama/llama3.2:latest":{}}' --strict-json --merge
openclaw models set ollama/llama3.2:latest
openclaw gateway restart

Why the chat tab is blank: if agents.defaults.models exists, it becomes the model picker allowlist. So the web UI can discover installed models, but chat only shows models allowed in that config list.

And for WSL: wsl --shutdown has to be run from Windows PowerShell / Command Prompt, not inside the Ubuntu shell.

[hasty badger]

it looks like the name is in there already the right way:

peter@SkytechRGB3D:~$ ollama list
openclaw models list --provider ollama --plain
NAME ID SIZE MODIFIED

🦞 OpenClaw 2026.4.26 (be8c246)
I'm not magic—I'm just extremely persistent with retries and coping strategies.

ollama/gemma4

I got wsl shutdown through the powershell. That makes more sense after you pointed out the obvious (i'm bad at this, obviously). I'm going to restart it all now.

[small stream]

You’re not bad at this — WSL vs Ubuntu console is genuinely easy to mix up.

The key detail: ollama list is empty:

NAME ID SIZE MODIFIED

So OpenClaw has ollama/gemma4 in its configured model list, but Ollama itself has no pulled local models right now. That’s why the run fails with:

model 'gemma4' not found

After restart, pull one model:

ollama pull gemma4

If that name fails, pick one from Ollama’s library, e.g.:

ollama pull llama3.2

Then verify:

ollama list
openclaw models set ollama/llama3.2:latest
openclaw gateway restart

Use ollama/<exact name from ollama list> — including :latest if shown.

The web UI showing ollama/gemma4 is just the OpenClaw config/catalog entry, not proof the model is actually installed.

[hasty badger]

OK. it finished downloading. Trying again after the restart. Web ui had no response or error message, it just ended its turn. Opening the TUI to try again. Showing wrong/not installed model as default.

After running (ollama list
openclaw models set ollama/gemma4:latest
openclaw gateway restart) again, it still shows llama3.2:latest as the current model in the TUI.
I tried again just pasting the name from the console "gemma4:latest" and instead of ollama/gemma4:latest , it pasted openai/gemma4:latest. So anyways, I tried again restarting the gateway to see what would happen. It still shows the wrong model:

hello?

⠏ conjuring… • 10s | connected
agent main | session main (openclaw-tui) | ollama/llama3.2:latest | tokens ?/128k

[small stream]

You’re very close — this is probably a session override now.

openclaw models set ... changes the configured default, but the TUI/Web UI session can keep its own model override. That’s why it still says:

session main (openclaw-tui) | ollama/llama3.2:latest

Do this exact sequence:

ollama list
openclaw config set agents.defaults.models '{"ollama/gemma4:latest":{}}' --strict-json --merge
openclaw models set ollama/gemma4:latest
openclaw models status
openclaw gateway restart

Then in the TUI chat itself, send the full provider-prefixed slash command:

/model ollama/gemma4:latest

Don’t send just gemma4:latest — that’s why it resolved as openai/gemma4:latest.

Alternative in Web UI: open the session/model picker and choose Default / inherit or explicitly choose ollama/gemma4:latest. The current session is pinned until you change/clear that override.

[hasty badger]

I sent over the commands. The TUI shows ollama/gemma4:latest now. It's back to acting like the LLM instead of the agent, but it's an improvement from this morning.

hello

I see you've provided context information, likely indicating the environment or source of
the preceding interaction, specifically mentioning an "open" context.

However, you haven't given me a direct request or a question to answer.

Could you please tell me what you would like me to do? For example, are you asking me to:

1. Acknowledge the context?
2. Proceed with a task based on assumed context?
3. Explain what this context means?

Once you give me a task, I will be happy to help!
connected | idle
agent main | session main (openclaw-tui) | ollama/gemma4:latest | tokens 4.1k/128k (3%)

[small stream]

Yep — this is now a model capability / prompt-following problem, not an identity/config problem.

Your context already showed AGENTS.md, SOUL.md, IDENTITY.md, etc. are injected. gemma4:latest is just treating OpenClaw’s wrapper/metadata like the actual user message instead of following the agent instructions.

Try this in the TUI first:

/think off
/model ollama/gemma4:latest
What is your name? Answer from IDENTITY.md in one sentence.

If it still gives the “you didn’t ask anything actionable” style answer, I’d test the lean local-model mode:

openclaw config set agents.defaults.experimental.localModelLean true

openclaw config set agents.defaults.models '{"ollama/gemma4:latest":{"params":{"think":false}}}' --strict-json --merge
openclaw gateway restart

Then start a new TUI/Web session and try again.

If it still acts generic after that, I’d call it: this local model isn’t strong enough for the full OpenClaw agent prompt/tool surface. Use it for simple local inference, but set your main assistant to a stronger model. For current model recommendations, #models is the best place — local model behavior changes fast. 🦐

[hasty badger]

I've posted all the provided prompts and restarted a new TUI. It's still acting wrong. I'm confused since it's the same model I've been using for over a week at this point but now it won't acknowledge the identity or anything.

[small stream]

I don’t think you broke anything. The confusing bit is: restarting the TUI doesn’t necessarily create a clean session — it can reconnect to session main, which now has a bunch of bad “metadata / no actionable request” history in it.

Try a hard clean session from inside the TUI:

/stop
/new ollama/gemma4:latest
/think off
What is your name? Answer from IDENTITY.md in one sentence.

If that still acts generic, I’d suspect one of these:

1. Different Ollama backend than last week — earlier ollama list was empty, so this WSL Ollama install did not have the old model loaded. You may have been using Windows Ollama or another daemon before.
2. Freshly pulled gemma4:latest isn’t behaving like the prior local model/tag.
3. Local model can answer raw chat but can’t reliably follow OpenClaw’s full agent prompt.

Quick sanity check:

ollama list
openclaw models status

If /new ollama/gemma4:latest still fails, I’d switch the main assistant to a stronger/cloud model for now and keep Gemma for local/simple tasks. The context report already proved the identity files are injected, so this is model behavior, not missing identity.

[hasty badger]

giving up at the moment and downloading llama3.2:latest. I started a hard clean session per the instructions above in the TUI. It's been thinking for 30 minutes. Would it be easier to uninstall openclaw and just start over again?

[small stream]

I wouldn’t uninstall yet. Reinstalling probably won’t fix this, because your workspace + identity files are loading; the failure is happening at the local Ollama/model/session layer.

First stop the hung run:

/stop

If TUI won’t respond, close it and run:

openclaw gateway restart

Then test the model outside the full agent prompt:

ollama run llama3.2:latest "Reply exactly: pong"

If that hangs too, it’s Ollama/WSL/GPU, not OpenClaw.

If raw Ollama works, test OpenClaw’s lean model path:

OLLAMA_API_KEY=ollama-local openclaw infer model run \
  --local \
  --model ollama/llama3.2:latest \
  --prompt "Reply exactly: pong" \
  --json

If you want a “fresh start” without nuking everything, reset only sessions/overrides, keeping identity/auth/config:

openclaw gateway stop
mv ~/.openclaw/agents/main/sessions ~/.openclaw/agents/main/sessions.bak.$(date +%Y%m%d-%H%M%S)
openclaw gateway start

That’s reversible and much safer than uninstalling. Full uninstall is the last resort, and if you do it, back up ~/.openclaw/workspace first — that’s where your agent identity lives.

Docs: https://docs.openclaw.ai/install/uninstall

[hasty badger]

pong displayed after the prompt, so that's working. Trying the next snippet. I sent over the api key thing and it just sat there for a bit so i pasted the next snippet and it stopped and restarted the gateway. Going to open the TUI next i'm assuming?

[small stream]

Yep — open the TUI next, but use a fresh session key so you don’t reconnect to the poisoned/hung main session.

Run:

openclaw tui --session clean-test

Then in TUI:

/model ollama/llama3.2:latest
/think off
hello

If that responds normally, try:

What is your name? Answer from IDENTITY.md in one sentence.

One note: the openclaw infer model run ... command can sit for a bit on local models, but it should eventually print JSON. If it never does while ollama run ... works, that points to OpenClaw’s Ollama routing/config rather than the model binary itself.

[hasty badger]

I opened it with session clean-test. Attempted pasting the whole next snippet and it failed to set model. Going line by line i got up to hello.
peter@SkytechRGB3D:~$ openclaw tui --session clean-test

🦞 OpenClaw 2026.4.26 (be8c246)
Your terminal just grew claws—type something and let the bot pinch the busywork.

openclaw tui - ws://127.0.0.1:18789 - agent main - session
clean-test

session agent:main:clean-test

model set failed: GatewayClientRequestError: model not
allowed: ollama/llama3.2:latest /think off hello

model set to ollama/llama3.2:latest

thinking set to off

hello

It appears that you are providing a large amount of JSON data
related to the OpenClaw runtime context and metadata. However,
you didn't specify which part of this data you would like me to
process or analyze.

If you could provide more context or clarify what you would like
me to do with this data (e.g., extract specific information,
perform calculations, or generate a summary), I'd be happy to
help!
connected | idle
agent main | session clean-test (openclaw-tui) |
ollama/llama3.2:latest | tokens 4.1k/200k (2%)

[small stream]

That first “model not allowed” was just because the pasted block got parsed as one /model ... command. Line-by-line was right.

But the generic JSON/metadata answer means the local model is not following OpenClaw’s system prompt. Before giving up, check one important thing: Ollama must be using native mode, not /v1.

Run:

openclaw config get models.providers.ollama.baseUrl
openclaw config get models.providers.ollama.api
openclaw config get agents.defaults.experimental.localModelLean

If baseUrl ends in /v1 or api is not ollama, fix it:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"

openclaw config set models.providers.ollama.api "ollama"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

Then in a new TUI session:

openclaw tui --session native-ollama-test

Send one line at a time:

/model ollama/llama3.2:latest
/think off
/context detail
What is your name? Answer from IDENTITY.md in one sentence.

If /context detail shows identity files injected but it still answers about metadata, reinstalling OpenClaw probably won’t help — it’s the local model/chat-template path failing the agent prompt.

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

[hasty badger]

i didn't see /v1 anywhere. ollama did show up in one of the responses. Not sure about the missing path on the last one.

[small stream]

“missing path” on agents.defaults.experimental.localModelLean just means it wasn’t set yet — that’s okay.

Set the known-good values anyway so we remove ambiguity:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"
openclaw config set models.providers.ollama.api "ollama"
openclaw config set models.providers.ollama.apiKey "ollama-local"
openclaw config set agents.defaults.experimental.localModelLean true
openclaw gateway restart

Then make sure both models are allowed, since you’re testing both:

openclaw config set agents.defaults.models '{"ollama/gemma4:latest":{},"ollama/llama3.2:latest":{}}' --strict-json --merge

openclaw gateway restart

Open a new session:

openclaw tui --session native-ollama-test2

Then send:

/model ollama/llama3.2:latest
/think off
/context detail

What is your name? Answer from IDENTITY.md in one sentence.

If it still talks about JSON/metadata after /context detail shows identity files OK, I’d stop fighting the install. It means the local model path is receiving the context, but the model isn’t obeying it.

[hasty badger]

OK. all of that is done and I'm up in a new session. waiting on context now... Context detail printed out. Results after sending what's your name:

Context breakdown (detailed)
Workspace: /home/peter/.openclaw/workspace
Bootstrap max/file: 50,000 chars
Bootstrap max/total: 300,000 chars
Sandbox: mode=off sandboxed=false
System prompt (estimate): 28,580 chars (~7,145 tok) (Project
Context 12,908 chars (~3,227 tok))
Injected workspace files:

• AGENTS.md: OK | raw 7,727 chars (~1,932 tok) | injected 7,727
  chars (~1,932 tok)
• SOUL.md: OK
  etc..

What is your name? Answer from IDENTITY.md in one sentence.

The error message indicates that the path argument in the tool
call is not a string, but rather an array. This suggests that
the tool expects a single string value for the path, rather than
an array of values.

To fix this issue, you can modify the tool call to pass a single
string value for the path:

  {
    "action": "read",
    "path": "/home/user/openclaw.md"
  }

Alternatively, if the path argument is intended to be an array,
you may need to adjust the tool's code to handle this format.
Without more information about the tool's functionality and
requirements, it is difficult to provide a specific solution.

Here is an example of how you might modify the tool call to pass
a single string value for the path:

  import requests

  def read_file(path):
      response = requests.get(f"{path}")
      return response.text

  args = {
    "action": "read",
    "path": "/home/user/openclaw.md"
  }

  response = read_file(args['path'])
  print(response)

This code defines a function read_file that takes a single
string value for the path and uses the requests library to fetch
the file from that location. The tool call is then modified to
pass this function as an argument, along with the required
action and path values.
connected | idle
agent main | session native-ollama-test2 (openclaw-tui) |
ollama/llama3.2:latest | tokens 4.1k/200k (2%)

[small stream]

That reply is actually diagnostic: the model is getting tangled in the tool/schema layer, not the identity files. Since /context detail shows identity injected, reinstalling OpenClaw still likely won’t fix it.

Try disabling tool schemas for the local Ollama models:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%Y%m%d-%H%M%S)

openclaw config set models.providers.ollama.models '[
  {
    "id":"llama3.2:latest",
    "name":"llama3.2:latest",
    "input":["text"],
    "compat":{"supportsTools":false},
    "params":{"think":false}
  },
  {

    "id":"gemma4:latest",
    "name":"gemma4:latest",
    "input":["text"],
    "compat":{"supportsTools":false},
    "params":{"think":false}
  }
]' --strict-json --replace

openclaw gateway restart

Then new TUI session:

openclaw tui --session no-tools-test

Send:

/model ollama/llama3.2:latest
What is your name? Answer from IDENTITY.md in one sentence.

If that still fails, I’d stop fighting the local model for the main assistant. Use a stronger/cloud model for OpenClaw, and keep Ollama for raw/simple tasks. If it used to work last week, it may have been a different Ollama daemon/model tag, especially since this install’s ollama list was empty earlier.

[hasty badger]

I tried again in a new no tools session. It's giving me a breakdown of runtime context and didn't address the question. There's a whole page of descriptions that discord won't let me paste here.

[small stream]

Oof. At this point I’d stop trying random fixes — you’ve isolated it pretty well:

• Raw Ollama works (pong)
• OpenClaw workspace/identity files are injected
• Native Ollama config is set
• Tool schemas disabled
• Fresh session still makes the model summarize runtime/context instead of answer

That means this is not an identity-file problem anymore. It’s either:

1. the local model/chat template can’t handle OpenClaw’s agent prompt, or
2. a regression/bug in how this OpenClaw version is formatting local Ollama prompts.

I would not uninstall yet. Instead, capture a shareable diagnostic and file it:

openclaw gateway diagnostics export

Then open an issue: https://github.com/openclaw/openclaw/issues

Include:

• OpenClaw 2026.4.26
• WSL2 + Ollama
• model refs tested: ollama/gemma4:latest, ollama/llama3.2:latest
• “raw ollama run ... pong works”
• “OpenClaw clean session ignores user prompt and summarizes runtime context”
• mention compat.supportsTools:false didn’t fix it

For now, use a stronger/cloud model for the main assistant if you can. Local small models can be brutal with this kind of agent prompt, even when they work fine in raw Ollama.

[hasty badger]

What would you recommend I name this "Bug"?

[small stream]

Name it:

Ollama local model ignores user prompt and summarizes OpenClaw runtime context instead

If you want a shorter title:

Ollama agent turns answer runtime context instead of user prompt

Good issue body opener:

On OpenClaw 2026.4.26 in WSL2, local Ollama models work with raw ollama run, but in clean OpenClaw TUI sessions they ignore simple prompts like “What is your name?” and instead summarize runtime/context/tool metadata. /context detail shows workspace identity files are injected, and setting compat.supportsTools:false did not fix it.

[hasty badger]

I'll use that as the summary. It's asking what steps to recreate the problem. I have no idea what I've done to get here besides tell my agent to start a new session

[small stream]

Use this for Steps to reproduce:

1. Install/run OpenClaw 2026.4.26 on Ubuntu under WSL2.
2. Configure Ollama as the model provider using native Ollama mode:
   - baseUrl: http://127.0.0.1:11434
   - api: ollama
   - apiKey: ollama-local
3. Pull a local Ollama model, e.g.:
   ```bash
   ollama pull llama3.2

4. Allow/select the model in OpenClaw:

   openclaw config set agents.defaults.models '{"ollama/llama3.2:latest":{}}' --strict-json --merge
   openclaw models set ollama/llama3.2:latest
   openclaw gateway restart

5. Start a fresh TUI session:
   ```bash
   openclaw tui --session native-ollama-test

6. In the TUI, send:

   /model ollama/llama3.2:latest
   /think off
   /context detail
   What is your name? Answer from IDENTITY.md in one sentence.
   

7. Observe that /context detail shows AGENTS.md, SOUL.md, IDENTITY.md, USER.md, and MEMORY.md injected, but the model does not answer the question. Instead, it summarizes OpenClaw runtime/context/tool metadata.
8. Repeat with compat.supportsTools:false configured for the Ollama model; behavior still occurs.

For **Expected behavior**:

The assistant should answer the user prompt using the injected workspace identity, e.g. “My name is …”, instead of summarizing runtime/context metadata.

For Actual behavior:

The assistant ignores the user prompt and responds as if the runtime/context metadata is the task, e.g. by explaining JSON/tool/runtime context or saying no actionable request was provided.

[hasty badger]

I'm not sure what to put under these areas:
OpenClaw version
*
Exact version/build tested.

2026.4.26
Operating system
*
OS and version where this occurs.

Windows 11 using Ubuntu 22.04 console
Install method
How OpenClaw was installed or launched.

npm global
Model
*
Effective model under test.

gemma4:latest and ollama:llama3.2:latest
Provider / routing chain
*
Effective request path through gateways, proxies, providers, or model routers.

[small stream]

Use these:

OpenClaw version

OpenClaw 2026.4.26 (be8c246)

Operating system

Windows 11 host, Ubuntu 22.04 under WSL2
Linux kernel shown by OpenClaw: 6.6.87.2-microsoft-standard-WSL2 (x64)
Node: 22.22.2

Install method

npm global install
Gateway running as systemd user service:
openclaw-gateway.service
Command: /usr/bin/node /home/peter/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789

Model

ollama/gemma4:latest
ollama/llama3.2:latest

Small correction: use ollama/llama3.2:latest, not ollama:llama3.2:latest.

Provider / routing chain

OpenClaw TUI -> local OpenClaw Gateway ws://127.0.0.1:18789 -> native Ollama provider -> local Ollama daemon at http://127.0.0.1:11434

Ollama config:
baseUrl: http://127.0.0.1:11434
api: ollama
apiKey: ollama-local

No /v1 endpoint, no proxy, no remote model router.

[hasty badger]

I'm assuming the exported log goes in the log section. I'm going to look for where it's saved and upload it now.

[small stream]

Yep — put the diagnostics export in the logs/attachments section.

Run:

openclaw gateway diagnostics export

It should print the saved .zip path. Attach that zip to the issue.

If you can’t find it, try:

find ~/.openclaw -type f \( -name "*diagnostic*.zip" -o -name "*support*.zip" \) -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort | tail -5

Quick check before uploading: diagnostics export is designed to redact tokens/chat text, but still glance at the filename/output if you’re worried.

[hasty badger]

There's no where to upload a zip file in the logs area. Should I just paste the contents of the 3 files in the zip log?

[small stream]

Don’t paste the full files — they’ll be huge and noisy.

If GitHub won’t take the zip in that field, submit the issue without it and add a note:

I generated `openclaw gateway diagnostics export`, but the issue form did not provide a zip upload field. I can attach it in a follow-up comment if needed.

For the Logs field, paste only a small relevant excerpt, like:

/context detail showed:
- AGENTS.md: OK
- SOUL.md: OK
- IDENTITY.md: OK
- USER.md: OK

- MEMORY.md: OK

But the model replied to “What is your name?” by summarizing runtime/tool/context metadata instead of answering from IDENTITY.md.

Raw Ollama smoke test:
`ollama run llama3.2:latest "Reply exactly: pong"` -> `pong`

After you create the issue, GitHub comments usually allow drag/drop attachments. If not, just leave the note.

[hasty badger]

OK. I added it to the issue page.

[small stream]

Nice, thank you for sticking with it — that was a slog.

For now I’d leave the broken local setup alone until someone can look at the issue. If you need the agent usable immediately, the practical workaround is:

openclaw configure --section model

Pick a stronger/cloud provider as the main model, then keep Ollama for raw/local tests only. Once the issue gets triaged, you can switch back.

If the issue gets a number/link, paste it here and I can help tighten the repro or add anything maintainers ask for.

[hasty badger]

[Bug]: Ollama local model ignores user prompt and summarizes OpenClaw runtime context instead #74579

[small stream]

Perfect — issue #74579 is a clear repro trail.

If maintainers ask for more, the most useful extra bits will be:

openclaw models status
openclaw config get models.providers.ollama
openclaw config get agents.defaults.models

But don’t paste secrets/tokens if any appear.

For now, I’d switch main back to a stronger provider so you’re not stuck while #74579 gets looked at.

[hasty badger]

Should i post the snippet and paste the results here just in case they come looking to you for answers?

[small stream]

You can post the safe parts, yes — it’ll help.

Run:

openclaw models status
openclaw config get models.providers.ollama
openclaw config get agents.defaults.models

Before pasting, remove anything that looks like:

• API keys / tokens
• passwords
• long auth blobs
• private paths you don’t want public

For this specific Ollama config, apiKey: ollama-local is fine to show — it’s just a local marker, not a secret.

Paste the output in the GitHub issue first. You don’t need to paste it here unless you want me to sanity-check/redact it before you post.

[hasty badger]

ok. I'll wait and see what happens in the issue tab. Thanks.

[small stream]

You’re welcome — sorry this turned into such a marathon. You did the right thing filing #74579; the repro is solid now.

If someone replies there and asks for clarification, bring it back here and we’ll tighten it up.

[hasty badger]

As long as I can help, I don't mind.

[small stream]

That genuinely helps — thank you. 🦐

Bug reports like this are annoying to live through, but the detail you captured is exactly what makes them fixable for the next person.

[hasty badger]

looks like it got closed already. What should i do next:

steipete
2 minutes ago
Contributor
Closing this as non-reproducible on current main.

What I could verify:

The /context detail command-reply path that could make runtime/context diagnostics appear in the next model turn is already filtered before provider replay: src/agents/pi-embedded-runner/replay-history.ts:229 drops provider:"openclaw" transcript-only assistant entries, including model:"gateway-injected".
That behavior is covered by src/agents/pi-embedded-runner/replay-history.test.ts:137, and the targeted test passes with pnpm test src/agents/pi-embedded-runner/replay-history.test.ts.
A direct local Ollama probe against the installed small model on this maintainer machine did not reproduce the reported behavior.
There may still be local-model context-pressure tuning work to do, but without a current-main repro this is not actionable as a bug. Please reopen with the diagnostics zip and an exact latest-main repro if it still happens after updating.

[small stream]

That close is basically saying: “please test on current main, then reopen/comment if it still happens.”

I’d do this next — no uninstall:

# optional safety backups
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%Y%m%d-%H%M%S)

# preview first
openclaw update --tag main --dry-run

# if the dry run looks sane
openclaw update --tag main
openclaw --version
openclaw gateway status

Then retest with a brand-new session:

openclaw tui --session repro-main-74579

In TUI:

/model ollama/llama3.2:latest
/think off
/context detail
What is your name? Answer from IDENTITY.md in one sentence.

If it’s fixed, great — leave a comment like:

Updating from 2026.4.26 to current main resolved it for me.

If it still reproduces, run:

openclaw gateway diagnostics export
openclaw update status
openclaw models status

Then comment on #74579 with:

• “Still reproduces on current main”
• output of openclaw --version
• the exact repro commands
• attach diagnostics zip in a GitHub comment if possible

If you don’t want to run main/dev code, totally fair — then the practical move is to wait for the next stable and use another model meanwhile.

[hasty badger]

OK. Trying the update now. NPM needed an update. Updated to npm@11.13.0. Tried updating openclaw again. NPM Error:
peter@SkytechRGB3D:~$ openclaw update --tag main
Updating OpenClaw...

│
◇ ✗ Updating via package manager (244.63s)
npm error at TracingChannel.traceSync (node:diagnostics_channel:328:14)
npm error at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
npm error at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
npm error at node:internal/main/run_main_module:36:49 {
npm error code: 'MODULE_NOT_FOUND',
npm error requireStack: []
npm error }
npm error
npm error Node.js v22.22.2
npm error A complete log of this run can be found in: /home/peter/.npm/_logs/2026-04-29T20_37_29_576Z-debug-0.log
│
◇ ✗ Retrying update without optional deps (314.17s)
npm error at TracingChannel.traceSync (node:diagnostics_channel:328:14)
npm error at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
npm error at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
npm error at node:internal/main/run_main_module:36:49 {
npm error code: 'MODULE_NOT_FOUND',
npm error requireStack: []
npm error }
npm error
npm error Node.js v22.22.2
npm error A complete log of this run can be found in: /home/peter/.npm/_logs/2026-04-29T20_41_34_222Z-debug-0.log

Update Result: ERROR

[small stream]

That npm output is missing the important part: which module is missing. Let’s pull just the useful lines from the npm log.

Run:

LOG=/home/peter/.npm/_logs/2026-04-29T20_41_34_222Z-debug-0.log

grep -nE "Cannot find module|MODULE_NOT_FOUND|error|verbose stack|command|argv" "$LOG" | tail -80

Also:

node -v
npm -v
which node

which npm
which openclaw
npm config get prefix
openclaw update status

Paste those outputs.

For now, don’t uninstall and don’t keep retrying openclaw update --tag main blindly — this looks like npm/global install state broke during the update, not the original Ollama bug.

[hasty badger]

peter@SkytechRGB3D:~$ grep -nE "Cannot find module|MODULE_NOT_FOUND|error|verbose stack|command|argv" "$LOG" | tail -80
441:440 silly fetch manifest serialize-error@^8.1.0
442:441 silly packumentCache full:https://registry.npmjs.org/serialize-error cache-miss
507:506 http fetch GET 200 https://registry.npmjs.org/serialize-error 297ms (cache revalidated)
508:507 silly packumentCache full:https://registry.npmjs.org/serialize-error set size:64056 disposed:false
1052:1051 silly fetch manifest @smithy/service-error-classification@^4.3.1
1053:1052 silly packumentCache full:https://registry.npmjs.org/@smithy%2Fservice-error-classification cache-miss
1074:1073 silly fetch manifest @smithy/service-error-classification@^4.3.1
1075:1074 silly packumentCache full:https://registry.npmjs.org/@smithy%2Fservice-error-classification cache-miss
1115:1114 http fetch GET 200 https://registry.npmjs.org/@smithy%2Fservice-error-classification 451ms (cache revalidated)
1116:1115 silly packumentCache full:https://registry.npmjs.org/@smithy%2Fservice-error-classification set size:192591 disposed:false
1120:1119 http fetch GET 200 https://registry.npmjs.org/@smithy%2Fservice-error-classification 262ms (cache revalidated)
1121:1120 silly packumentCache full:https://registry.npmjs.org/@smithy%2Fservice-error-classification set size:192591 disposed:false
1122:1121 silly packumentCache full:https://registry.npmjs.org/@smithy%2Fservice-error-classification dispose
1470:1469 silly fetch manifest shebang-command@^2.0.0
1471:1470 silly packumentCache full:https://registry.npmjs.org/shebang-command cache-miss
1518:1517 silly fetch manifest http-errors@^2.0.0
1519:1518 silly packumentCache full:https://registry.npmjs.org/http-errors cache-miss
1541:1540 http fetch GET 200 https://registry.npmjs.org/shebang-command 304ms (cache revalidated)
1542:1541 silly packumentCache full:https://registry.npmjs.org/shebang-command set size:8525 disposed:false

[small stream]

That grep didn’t hit the actual failure. Let’s inspect the end of the log directly:

tail -n 120 /home/peter/.npm/_logs/2026-04-29T20_41_34_222Z-debug-0.log

And still run:

node -v
npm -v
which node
which npm
which openclaw
npm config get prefix
openclaw update status

Paste those. The npm log tail should show the missing module or the exact install command that failed.

[hasty badger]

1567:1566 silly fetch manifest http-errors@~2.0.1
1568:1567 silly packumentCache full:https://registry.npmjs.org/http-errors cache-miss
1581:1580 http fetch GET 200 https://registry.npmjs.org/http-errors 289ms (cache revalidated)
1582:1581 silly packumentCache full:https://registry.npmjs.org/http-errors set size:71987 disposed:false

[small stream]

That still looks like the previous grep tail, not the actual tail -n 120 output. No worries — the log may just be weird/truncated.

Please run this exact combined block and paste everything:

node -v
npm -v
which node
which npm
which openclaw
npm config get prefix
openclaw --version
openclaw update status

Then try the direct install repair:

npm install -g github:openclaw/openclaw#main --foreground-scripts

If that fails, paste the final ~40 lines of that command’s terminal output directly. That should be more useful than the npm debug log.

[hasty badger]

1601:1600 http fetch GET 200 https://registry.npmjs.org/http-errors 246ms (cache revalidated)
1602:1601 silly packumentCache full:https://registry.npmjs.org/http-errors set size:71987 disposed:false
1603:1602 silly packumentCache full:https://registry.npmjs.org/http-errors dispose
1612:1611 silly placeDep node_modules/openclaw @smithy/service-error-classification@4.3.1 OK for: @smithy/middleware-retry@4.5.7 want: ^4.3.1
1678:1677 silly placeDep node_modules/openclaw shebang-command@2.0.0 OK for: cross-spawn@7.0.6 want: ^2.0.0
1700:1699 silly placeDep node_modules/openclaw http-errors@2.0.1 OK for: express@5.2.1 want: ^2.0.0
1852:1851 silly placeDep node_modules/openclaw serialize-error@8.1.0 OK for: global-agent@4.1.3 want: ^8.1.0
1888:1887 silly fetch manifest es-errors@^1.3.0
1889:1888 silly packumentCache full:https://registry.npmjs.org/es-errors cache-miss
1892:1891 http fetch GET 200 https://registry.npmjs.org/es-errors 172ms (cache revalidated)
1893:1892 silly packumentCache full:https://registry.npmjs.org/es-errors set size:16918 disposed:false
1900:1899 silly placeDep node_modules/openclaw es-errors@1.3.0 OK for: define-data-property@1.1.4 want: ^1.3.0
1958:1957 silly placeDep node_modules/openclaw inherits@2.0.4 OK for: http-errors@2.0.1 want: ~2.0.4
1959:1958 silly placeDep node_modules/openclaw setprototypeof@1.2.0 OK for: http-errors@2.0.1 want: ~1.2.0
1960:1959 silly placeDep node_modules/openclaw toidentifier@1.0.1 OK for: http-errors@2.0.1 want: ~1.0.1
2193:2192 silly placeDep node_modules/openclaw type-fest@0.20.2 OK for: serialize-error@8.1.0 want: ^0.20.2
2194:2193 silly placeDep node_modules/openclaw shebang-regex@3.0.0 OK for: shebang-command@2.0.0 want: ^3.0.0

[small stream]

You’re still pasting npm log chunks, and they’re not showing the failure. Let’s skip the log for now.

Run this only and paste the output:

node -v
npm -v
which node
which npm
which openclaw
npm config get prefix
openclaw --version
openclaw update status

Don’t run the log command this time. The version/path info will tell us whether npm/openclaw is half-installed or pointed at the wrong prefix.

[hasty badger]

2608:2607 http cache es-errors@https://registry.npmjs.org/es-errors/-/es-errors-1.3.0.tgz 0ms (cache hit)
2615:2614 http cache serialize-error@https://registry.npmjs.org/serialize-error/-/serialize-error-8.1.0.tgz 0ms (cache hit)
2651:2650 http cache http-errors@https://registry.npmjs.org/http-errors/-/http-errors-2.0.1.tgz 0ms (cache hit)
2664:2663 http cache shebang-command@https://registry.npmjs.org/shebang-command/-/shebang-command-2.0.0.tgz 0ms (cache hit)
2683:2682 http cache @smithy/service-error-classification@https://registry.npmjs.org/@smithy/service-error-classification/-/service-error-classification-4.3.1.tgz 0ms (cache hit)
2853:2852 http cache commander@https://registry.npmjs.org/commander/-/commander-14.0.3.tgz 0ms (cache hit)
2888:2887 verbose stack Error: command failed
2889:2887 verbose stack at promiseSpawn (/home/peter/.npm-global/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/lib/index.js:22:22)
2890:2887 verbose stack at spawnWithShell (/home/peter/.npm-global/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/lib/index.js:124:10)
2891:2887 verbose stack at promiseSpawn (/home/peter/.npm-global/lib/node_modules/npm/node_modules/@npmcli/promise-spawn/lib/index.js:12:12)
2892:2887 verbose stack at runScriptPkg (/home/peter/.npm-global/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/run-script-pkg.js:79:13)

2893:2887 verbose stack at runScript (/home/peter/.npm-global/lib/node_modules/npm/node_modules/@npmcli/run-script/lib/run-script.js:9:12)
2894:2887 verbose stack at /home/peter/.npm-global/lib/node_modules/npm/node_modules/@npmcli/arborist/lib/arborist/rebuild.js:328:17
2895:2887 verbose stack at run (/home/peter/.npm-global/lib/node_modules/npm/node_modules/promise-call-limit/dist/commonjs/index.js:67:22)
2896:2887 verbose stack at /home/peter/.npm-global/lib/node_modules/npm/node_modules/promise-call-limit/dist/commonjs/index.js:84:9
2897:2887 verbose stack at new Promise (<anonymous>)
2898:2887 verbose stack at callLimit (/home/peter/.npm-global/lib/node_modules/npm/node_modules/promise-call-limit/dist/commonjs/index.js:35:69)

[small stream]

I see the failure is from an npm lifecycle script, but we’re still missing the script name/error line.

Please pause the npm-log digging and run just this command block:

node -v
npm -v
which node
which npm
which openclaw
npm config get prefix
openclaw --version
openclaw update status

Paste only that output. Then we can decide the cleanest repair path.

[hasty badger]

2900:2889 error code 1
2901:2890 error path /home/peter/.npm-global/lib/node_modules/.openclaw-update-stage-opVC6P/lib/node_modules/openclaw
2902:2891 error command failed
2903:2892 error command sh -c node scripts/preinstall-package-manager-warning.mjs
2904:2893 error node:internal/modules/cjs/loader:1386
2905:2893 error throw err;
2906:2893 error ^
2907:2893 error
2908:2893 error Error: Cannot find module '/home/peter/.npm/_cacache/tmp/git-cloneIjRSGQ/scripts/preinstall-package-manager-warning.mjs'
2909:2893 error at Function._resolveFilename (node:internal/modules/cjs/loader:1383:15)
2910:2893 error at defaultResolveImpl (node:internal/modules/cjs/loader:1025:19)
2911:2893 error at resolveForCJSWithHooks (node:internal/modules/cjs/loader:1030:22)
2912:2893 error at Function._load (node:internal/modules/cjs/loader:1192:37)
2913:2893 error at TracingChannel.traceSync (node:diagnostics_channel:328:14)
2914:2893 error at wrapModuleLoad (node:internal/modules/cjs/loader:237:24)
2915:2893 error at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:171:5)
2916:2893 error at node:internal/main/run_main_module:36:49 {
2917:2893 error code: 'MODULE_NOT_FOUND',
2918:2893 error requireStack: []
2919:2893 error }
2920:2893 error
2921:2893 error Node.js v22.22.2
2934:2906 error A complete log of this run can be found in: /home/peter/.npm/_logs/2026-04-29T20_41_34_222Z-debug-0.log
peter@SkytechRGB3D:~$ node -v
v22.22.2
peter@SkytechRGB3D:~$ npm -v
10.9.7
peter@SkytechRGB3D:~$ which node
/usr/bin/node
peter@SkytechRGB3D:~$ which npm
/home/peter/.npm-global/bin/npm
peter@SkytechRGB3D:~$ which openclaw
/home/peter/.npm-global/bin/openclaw
peter@SkytechRGB3D:~$ npm config get prefix
/home/peter/.npm-global

peter@SkytechRGB3D:~$ openclaw update status
OpenClaw update status

┌──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Install │ pnpm │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.26 │
└──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

[small stream]

You’re still in the npm log output. I need you to stop that command if it’s still running.

Press:

Ctrl-C

Then run this exact block:

node -v
npm -v
which node
which npm
which openclaw

npm config get prefix
openclaw --version
openclaw update status

Paste the result of that block only.

That error is useful. It means testing main via npm/GitHub failed before you even got to the repro:

command sh -c node scripts/preinstall-package-manager-warning.mjs
Cannot find module .../scripts/preinstall-package-manager-warning.mjs

Also: your active npm -v is still 10.9.7, not 11.13.0 — but the missing script is the more relevant failure.

Next step: comment on #74579 with this:

I tried to update/test current main using:

openclaw update --tag main

but the update failed during npm/GitHub install before I could retest:

Error: Cannot find module '/home/peter/.npm/_cacache/tmp/git-clone.../scripts/preinstall-package-manager-warning.mjs'
command failed: sh -c node scripts/preinstall-package-manager-warning.mjs

Environment:
- npm: 10.9.7
- node: v22.22.2
- openclaw install prefix: /home/peter/.npm-global

Then I’d stop for now. Don’t uninstall, don’t keep retrying the update loop.

If you really want to test main, the cleaner path is a source checkout with pnpm, but that’s more work. Docs: https://docs.openclaw.ai/install

That’s interesting: OpenClaw thinks the install method is pnpm, even though which npm/openclaw are under ~/.npm-global. That mismatch may be why the updater path is getting weird.

Add this to the issue/comment too:

`openclaw update status` reports:

Install: pnpm
Channel: stable (default)
Update: pnpm · up to date · npm latest 2026.4.26

But my executable paths are:
which openclaw -> /home/peter/.npm-global/bin/openclaw
which npm -> /home/peter/.npm-global/bin/npm
npm config get prefix -> /home/peter/.npm-global

For now, best next move is still: pause. We’ve got two separate things now:

1. the Ollama/runtime-context behavior, and
2. openclaw update --tag main failing from the package install path.

Let maintainers tell you whether they want a source-checkout repro or an updater issue split out.

[hasty badger]

ok. I'll see what happens on github.

[small stream]

Good call. You’ve done enough debugging for one day — and the GitHub thread now has the important trail.

If they ask for something specific, bring it back here and we’ll keep it tight.

[hasty badger]

With the issue closed already, how likely is it that someone will look at my comments? There are no asignees on the issue.

[small stream]

Closed issue comments are less visible than an open issue, but not invisible. Since a maintainer already commented/closed it, they’ll usually get GitHub notifications for follow-up comments — but there’s no guarantee or SLA.

No assignee is normal; I wouldn’t read much into that.

Best move:

1. Add one concise follow-up comment with the new info:
   • update-to-main failed
   • exact npm missing-script error
   • openclaw update status says Install: pnpm despite ~/.npm-global
2. Then wait a bit — maybe 24–48h.
3. If nobody replies, open a separate issue for the updater failure, because that’s now a distinct reproducible bug.

I wouldn’t keep adding small comments unless you have new, concrete output. One clean follow-up is more likely to be read than a long back-and-forth.

[hasty badger]

OK. I posted the last two things you said to comment. I'll wait and see what happens.

[small stream]

That’s the right stopping point. You’ve given them enough to work with without flooding the issue.

If it gets reopened or someone asks for a specific command/output, drop it here and we’ll handle it cleanly.

[hasty badger]

Tried to update this morning just to see what would happen.
peter@SkytechRGB3D:~$ openclaw update
Updating OpenClaw...

│
◇ ✓ Updating via package manager (31.98s)
│
◇ ✓ Running doctor checks (137.58s)

Update Result: OK
Root: /home/peter/.npm-global/lib/node_modules/openclaw
Before: 2026.4.26
After: 2026.4.27

Total time: 170.78s

Updating plugins...
No plugin updates needed.
Completion cache update failed: Error: spawnSync /usr/bin/node ETIMEDOUT

Restarting service...
Gateway did not become healthy after restart.
Gateway version mismatch: expected 2026.4.27, running gateway reported unavailable.
Service runtime: status=running, state=active, pid=11730, lastExit=0
Gateway port 18789 status: free.
Restart log: /home/peter/.openclaw/logs/gateway-restart.log
Run openclaw gateway status --deep for details.

peter@SkytechRGB3D:~$ openclaw update
Updating OpenClaw...

Stopping managed gateway service before package update...
Stopped systemd service: openclaw-gateway.service
│
◇ ✓ Updating via package manager (17.43s)
│
◇ ✓ Running doctor checks (14.13s)

Update Result: OK
Root: /home/peter/.npm-global/lib/node_modules/openclaw
Before: 2026.4.27
After: 2026.4.27

Total time: 32.75s

Updating plugins...
No plugin updates needed.
Completion cache update failed: timed out after 30s. Shell tab-completion may be stale; refresh manually with: openclaw completion --write-state

Restarting service...
Gateway did not become healthy after restart.
Service runtime: status=running, state=active, pid=12271, lastExit=0
Port 18789 is already in use.

• pid 12271 peter: /usr/bin/node /home/peter/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789 (127.0.0.1:18789)
• Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
  Restart log: /home/peter/.openclaw/logs/gateway-restart.log
  Run openclaw gateway status --deep for details.