Agent is not reading soul/identity | Friends of the Crustacean 🦞🤝 | Page 1

solar delta Apr 16, 2026, 10:01 AM

#

Looks like the agent is stucked in a subagent task, it got multiple time outs and out of token yesterday I tried to fix it with multiple restarts, but today when I do a /reset it just throws the last message of the subagent of yesterday to me, and looks like it doesn't have any identity soul files in the context.

steel doveBOT Apr 16, 2026, 10:03 AM

#

I found the relevant docs and a likely gotcha already. Let me pull the exact sections so I don’t guess.

#

Two separate things here:

Missing SOUL.md / IDENTITY.md in a subagent is expected
Subagents only get AGENTS.md + TOOLS.md by design, not SOUL.md, IDENTITY.md, USER.md, etc. So that part is actually a clue that you’re still landing in the child/subagent context, not the main agent context.
/reset replaying yesterday’s subagent reply is not expected
That smells like a stale thread binding / stuck subagent task delivery / stale session store entry.

Can you paste these, in this order:

openclaw --version
openclaw status --all
openclaw tasks list --runtime subagent
openclaw config get agents.defaults.skipBootstrap

#

And in the affected Discord thread, run:

/agents
/tasks
/context list

What I’d check first:

If /agents shows the thread is still focused/bound to a child session, do /unfocus first, then /reset.
If /context list in the “main” thread still only shows AGENTS.md + TOOLS.md, you’re not actually back in the main session yet.
If agents.defaults.skipBootstrap is true, that would also explain missing soul/identity files for normal sessions.

Relevant docs:

#

Paste those outputs and I’ll help narrow it down fast.

tame sinew Apr 16, 2026, 10:04 AM

#

By default identity file is not injected
Can you tell ai to read identity.md and see what it does ?

steel doveBOT Apr 16, 2026, 10:05 AM

#

Only for subagents.

For a normal/main session, OpenClaw injects:

AGENTS.md
SOUL.md
TOOLS.md
IDENTITY.md
USER.md
HEARTBEAT.md
BOOTSTRAP.md when applicable
MEMORY.md / memory.md

But for a subagent, it intentionally injects only:

AGENTS.md
TOOLS.md

#

So yes, you can tell the agent to explicitly read IDENTITY.md, and if it has the read tool it may use it, but that’s a workaround, not the default behavior.

So the key distinction is:

main session missing IDENTITY.md → suspicious
subagent missing IDENTITY.md → expected

Best check: run /context list in the thread. If it only shows AGENTS.md + TOOLS.md, you’re still in child/subagent context.

Docs:

If you want, paste the /context list output and I’ll tell you immediately whether it’s main-session or subagent context.

solar delta Apr 16, 2026, 10:05 AM

#

tame sinew By default identity file is not injected Can you tell ai to read identity.md an...

I think it has no tools I've tried to make it use any tool and failed

tame sinew Apr 16, 2026, 10:05 AM

#

Which ai model you are using ,?

steel doveBOT Apr 16, 2026, 10:06 AM

#

Let me check the tool-policy docs so I don’t hand-wave this.

#

Yeah, if it really has no read tool, telling it to read IDENTITY.md won’t help.

That would point to one of these:

You’re still inside the stale subagent session
Tool policy filtered tools out
The model/tool-calling is broken, so it has tools on paper but never uses them

Fastest checks:

/context list
This is the big one. It shows:
- which files are injected
- which tools are available
/agents
/tasks

#

If /context list shows only AGENTS.md + TOOLS.md, you’re still in subagent context.
If it also shows basically no tools, then I’d inspect tool policy next.

Config bits to check:

openclaw --version
openclaw config get tools
openclaw config get agents
openclaw tasks list --runtime subagent
openclaw status --all

The main policy knobs are:

tools.profile
tools.allow

#

tools.deny
agents.list[].tools.*
tools.subagents.tools

And one easy footgun: allowlists must use real tool names / groups, like message, web_fetch, group:web, group:sessions, not made-up names.

Docs:

If you paste /context list plus openclaw config get tools, I can probably tell you in one pass whether this is a stuck binding vs a tool-policy issue.

solar delta Apr 16, 2026, 10:06 AM

#

gemini cli, anyh model inside of it.

steel doveBOT Apr 16, 2026, 10:06 AM

#

I wouldn’t trust me to answer that from memory, runtime model info gets stale fast.

For your actual session/model, check:

/status in chat
openclaw models status locally

For model recommendations, ask in #models and use:

If you want, paste your openclaw models status output and I can help interpret it.

tame sinew Apr 16, 2026, 10:07 AM

#

So you have configured gemini cli as llm provider,
Is it able to answer normal questions,
And just failing to do tool call ?

steel doveBOT Apr 16, 2026, 10:07 AM

#

Got it, so it happens with Gemini CLI regardless of which Gemini model is selected.

That makes me think this is less likely a specific model choice and more likely one of:

stale thread/subagent binding
tool policy filtering tools out
broken/stale task/session delivery after the old timeout run

So I’d focus on these next, not the model:

/context list
/agents
/tasks

And locally:

#

openclaw config get tools
openclaw config get agents
openclaw tasks list --runtime subagent
openclaw status --all

If you paste /context list + openclaw config get tools, I can tell pretty quickly whether the child session is just stuck with no tools vs the thread still being bound to the wrong session.

#

Yep, that’s absolutely possible.

A setup can be:

fine for normal chat/questions
but bad at tool calling

Those are different paths.

So if your Gemini CLI setup can answer plain questions, but it won’t read, exec, etc., that usually means one of these:

tools are not actually available in that session
tool policy filtered them out
the model/provider is seeing the tools but failing to call them correctly

That’s why /context list is so useful:

#

if the tools are missing there, it’s a config/policy/session issue
if the tools are present there, but the agent still never uses them, it’s more of a model/provider tool-calling issue

So yes, “normal answers work, tool calls fail” is a very believable failure mode here.
Paste /context list and we can separate those two quickly.

solar delta Apr 16, 2026, 10:08 AM

#

tame sinew So you have configured gemini cli as llm provider, Is it able to answer normal q...

it doesn't try to use any tool it just respond as a chat bot

tame sinew Apr 16, 2026, 10:08 AM

#

Can you ask it which tools you have available ?

steel doveBOT Apr 16, 2026, 10:09 AM

#

Yep, and that’s a useful clue.

If it behaves like a plain chatbot and never even attempts a tool call, it’s usually one of these:

the session effectively has no tools
- tools.profile: "minimal"
- restrictive tools.allow / tools.deny
- agents.list[].tools.*
- tools.subagents.tools
the tools are present, but the model/provider is not actually tool-calling

The quickest separator is still:

/context list

If the tools are missing there, it’s a config/session-policy problem.

#

If the tools are listed there, but it still only chats, then it’s more of a model/provider tool-calling issue.

And yeah, if tools.profile ended up minimal-ish, “just a chatbot” is exactly what it looks like.

Please paste:

openclaw config get tools
openclaw config get agents

and the output of /context list.

Then we can tell whether this is:

wrong/stale subagent binding
tools filtered out
or Gemini CLI just not taking tool calls in that session.

#

You can, but I wouldn’t trust the model’s answer there if tool-calling is already busted.

Better: use the native command:

/context list

That shows the actual tools available to the session, plus which files are injected.

If you ask the model “what tools do you have?”, it may:

guess
omit some
answer from stale context
or just act like a chatbot again

So for this case, /context list is the source of truth. If you paste that output here, we can read it directly.

solar delta Apr 16, 2026, 10:10 AM

#

which tools you have available ?
I have access to a comprehensive suite of tools categorized as follows:

File & Codebase: read_file, write_file, grep_search, glob, list_directory, replace, move_file, and delete_file.
Investigation & Planning: codebase_investigator (architectural mapping), enter_plan_mode (designing complex changes), and cli_help (CLI documentation).
Execution: run_shell_command for interacting with the system and running project-specific scripts or tests.
Web & Knowledge: google_web_search and mcp_openclaw_web_search for external research.
Session & Task Management: mcp_openclaw_sessions_spawn, mcp_openclaw_sessions_send, mcp_openclaw_subagents for orchestration, and mcp_openclaw_cron for scheduling.
Specialized Agents: generalist for batch tasks and codebase_investigator for deep analysis.
Extensibility: activate_skill to enable specialized workflows like the skill-creator.

who are you?

I am Gemini CLI, an autonomous senior software engineer and AI agent designed to assist with complex technical tasks, architectural mapping, and codebase management. I operate within your
terminal to research, plan, and execute code changes, bug fixes, and system integrations while adhering to high engineering standards and security protocols.

steel doveBOT Apr 16, 2026, 10:10 AM

#

Yep, that output is a huge clue.

That is not OpenClaw’s native tool list.

Names like:

read_file
write_file
run_shell_command
activate_skill
mcp_openclaw_sessions_spawn

are Gemini CLI / MCP-style tool names, not the normal OpenClaw built-in names.

If this were a normal OpenClaw session, you’d expect names more like:

read

#

write
edit
exec
process
web_search
sessions_spawn
subagents

So this means one of two things:

you’re actually still attached to a Gemini CLI harness/child session
Gemini is ignoring the real session tool schema and answering with its own generic self-description

Either way, I would not trust “what tools do you have?” as a diagnostic anymore.
Use the native commands instead:

/context list

#

/agents
/tasks

If /agents shows the thread is still bound to a child/harness session, I’d try:

/unfocus
then /reset

That pasted reply actually makes me more confident this is a wrong-session/bound-child problem, not just “IDENTITY.md missing.”

tame sinew Apr 16, 2026, 10:12 AM

#

Run
/context list
/agents

Give output

steel doveBOT Apr 16, 2026, 10:13 AM

#

I can’t call /context list directly from the tool surface, but I can inspect the live session and subagent state now.

#

I can’t invoke /context list itself from the tool surface, but I ran the live equivalents and here’s the actual state for this thread right now:

Session key: agent:main:discord:channel:1494276428731252746
Runtime: direct
Thread/session status: main session, updated just now
Active subagents: none
Recent subagents (last 24h): none
Visible group sessions matching this thread: 1

And from the actual prompt context of this session, it is not a “no identity / no tools” session right now.

It has bootstrap/context files including things like:

AGENTS.md
SOUL.md

#

IDENTITY.md
USER.md
TOOLS.md
HEARTBEAT.md
memory.md

And the available tools here are OpenClaw built-ins, like:

file tools: read, write, edit, apply_patch
runtime: exec, process
web: web_search, web_fetch
browser/ui: browser, canvas
session tools: sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
media/analysis: image, pdf, tts, generation tools
messaging: message

So the important bit is:

#

This thread’s live session is currently a normal main OpenClaw session, not a child Gemini CLI/subagent session.

That means the Gemini-style self-description you pasted earlier is not the real live tool inventory for this thread. It was either:

a wrong/stale child reply getting replayed, or
the model hallucinating its own Gemini CLI harness persona.

That’s actually good news, because it narrows this down a lot.

solar delta Apr 16, 2026, 10:13 AM

#

/context list

🧠 Context breakdown
Workspace: /home/ubuntu/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 36,890 chars (9,223 tok) (Project Context 20,639 chars (5,160 tok))

Injected workspace files:
- AGENTS.md: OK | raw 9,770 chars (2,443 tok) | injected 9,770 chars (2,443 tok)
- SOUL.md: OK | raw 3,065 chars (767 tok) | injected 3,065 chars (767 tok)
- TOOLS.md: OK | raw 1,647 chars (412 tok) | injected 1,647 chars (412 tok)
- IDENTITY.md: OK | raw 1,384 chars (346 tok) | injected 1,384 chars (346 tok)
- USER.md: OK | raw 489 chars (123 tok) | injected 489 chars (123 tok)
- HEARTBEAT.md: OK | raw 167 chars (42 tok) | injected 167 chars (42 tok)
- BOOTSTRAP.md: MISSING | raw 0 | injected 0
- MEMORY.md: OK | raw 3,864 chars (966 tok) | injected 3,864 chars (966 tok)

Skills list (system prompt text): 7,020 chars (1,755 tok) (15 skills)
Skills: clawhub, gemini, healthcheck, node-connect, skill-creator, taskflow, taskflow-inbox-triage, tmux, trello, weather, icloud-caldav, news-scraper, playwright-cli, self-improvement,
universal-scraper
Tool list (system prompt text): 0 chars (0 tok)
Tool schemas (JSON): 0 chars (~0 tok) (counts toward context; not shown as text)
Tools: (none)

Session tokens (cached): unknown / ctx=200,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.

/agents

-> main default

steel doveBOT Apr 16, 2026, 10:14 AM

#

Perfect, this isolates it.

Your output says:

main/default agent
SOUL.md / IDENTITY.md / USER.md are injected correctly
Tools: (none)

So the real problem is not missing identity files, and it’s not subagent context right now.

It’s this:

Tool list: 0 chars
Tool schemas: 0 chars
Tools: (none)

#

That means OpenClaw is giving the model zero tools, so of course it just behaves like a chatbot and never calls read, exec, etc.

So the likely cause is a tool policy/config issue, not the model itself.

Please paste these next:

openclaw --version
openclaw config get tools
openclaw config get agents

What I’d inspect first in config:

tools.profile
tools.allow
tools.deny

#

agents.list[].tools.*

Since your /context list shows sandboxed=false, sandbox policy is probably not the main culprit here.

Also, this explains the weird Gemini CLI self-description earlier: with no real tools injected, it was basically freestyling a tool list instead of reporting a real one.

Docs:

Paste openclaw config get tools and I’ll help pinpoint the exact bad setting.

solar delta Apr 16, 2026, 10:15 AM

#

solar delta `/context list` ``` 🧠 Context breakdown Workspace: /home/ubuntu/.openclaw/works...

there are a lot of parts that shows like that ~~asdasd~~

steel doveBOT Apr 16, 2026, 10:16 AM

#

If you mean values like:

~/.openclaw/...
~/workspace

that part is normal. ~ just means your home directory.

So ~/.openclaw/workspace is basically the same as something like:

/home/ubuntu/.openclaw/workspace

That is not the problem.

#

The real red flag is still this:

Tools: (none)
Tool schemas: 0

So I’d ignore the ~... paths for now and paste these exactly:

openclaw config get tools
openclaw config get agents

Even if they contain lots of ~ paths, that’s fine. I’m looking for the tool-policy bits, especially things like:

tools.profile

#

tools.allow
tools.deny
agents.list[].tools.*

That’s where the actual breakage probably is.

tame sinew Apr 16, 2026, 10:16 AM

#

steel dove That means OpenClaw is giving the model **zero tools**, so of course it just beh...

Run these commands and paste out put

steel doveBOT Apr 16, 2026, 10:16 AM

#

I can’t run commands on your Ubuntu box from this Discord thread, only inspect the live Discord session here.

Please run these locally and paste the output:

openclaw --version
openclaw config get tools
openclaw config get agents

If the output is long, just paste the tools block and the agents.list / agents.defaults parts. That should be enough to spot why the effective tool list is empty.

solar delta Apr 16, 2026, 10:17 AM

#

OpenClaw 2026.4.14 (323493f)

🦞 OpenClaw 2026.4.14 (323493f) — I can grep it, git blame it, and gently roast it—pick your coping mechanism.

{
  "profile": "coding",
  "web": {
    "search": {
      "enabled": true,
      "provider": "gemini"
    }
  }
}

🦞 OpenClaw 2026.4.14 (323493f) — I can't fix your code taste, but I can fix your build and your backlog.

{
  "defaults": {
    "model": {
      "primary": "google-gemini-cli/gemini-3-flash-preview",
      "fallbacks": [
        "google-gemini-cli/gemini-2.5-flash"
      ]
    },
    "models": {
      "google-gemini-cli/gemini-3.1-pro-preview": {},
      "google-gemini-cli/gemini-3-flash-preview": {},
      "google-gemini-cli/gemini-2.5-pro": {},
      "google-gemini-cli/gemini-2.5-flash": {},
      "google-gemini-cli/gemini-3.1-flash-lite-preview": {}
    },
    "workspace": "/home/ubuntu/.openclaw/workspace",
    "memorySearch": {
      "enabled": false
    },
    "heartbeat": {
      "model": "google-gemini-cli/gemini-3-flash-preview"
    },
    "maxConcurrent": 4,
    "subagents": {
      "maxConcurrent": 8
    }
  }
}

tame sinew Apr 16, 2026, 10:22 AM

#

solar delta ``` OpenClaw 2026.4.14 (323493f) 🦞 OpenClaw 2026.4.14 (323493f) — I can grep i...

There is no tools in this @steel dove

steel doveBOT Apr 16, 2026, 10:22 AM

#

This is useful. It rules out the obvious config mistake. Let me line it up with the code path I just checked.

#

I found one more angle that actually could explain part of the weirdness around /reset: the built-in reset hook + startup-context prelude. I’m checking that now.

#

Okay, I think we’ve got a real lead now, not just hand-waving. /reset is not always “empty session, nothing from before.” OpenClaw can intentionally carry some recent memory into the first post-reset turn. Let me grab the exact config knobs.

#

Nice, this narrows it down a lot.

Your pasted config looks sane:

tools.profile: "coding" , so tools are not globally disabled by config
the google-gemini-cli/... model block also looks normal
I checked source, and tools only get hard-disabled when a model resolves with compat.supportsTools === false
I could not find google-gemini-cli being explicitly marked supportsTools: false

So my updated read is:

Tools: (none) is probably not caused by the config you pasted
/reset replaying yesterday’s subagent text may be explained by reset-memory behavior

Important bit from docs/source:

/reset is just the reset alias for /new

#

bare /new and /reset can preload recent daily memory
the bundled session-memory hook saves the previous session on /reset

So /reset is not guaranteed to be a sterile blank slate.

Docs:

What I want next

Please paste these:

openclaw status --all

#

openclaw hooks info session-memory
openclaw config get hooks
openclaw config get agents.defaults.startupContext

Then tail logs, trigger /reset, and paste the relevant lines:

openclaw logs --follow

And one very telling check:

ls -lt /home/ubuntu/.openclaw/workspace/memory | head

#

If you can, also search for a unique phrase from the stale subagent reply inside that memory folder.

Current best hypothesis

If the stale text is in workspace/memory, then /reset is probably resurfacing it via startup context, not because you are still live-bound to a child session.
If it is not in memory, and /context list still shows Tools: (none), then this smells like a 2026.4.14 runtime bug around reset/session state or effective tool inventory, not a bad tools config.

If you paste agents.defaults.startupContext and hooks info session-memory, I can tell you pretty quickly which branch we’re in.

#

Right, but the important distinction is:

the first JSON block is the tools config
it has profile: "coding"
the second JSON block is agents, and it does not need a separate tools block unless you want per-agent overrides

So, missing agents.defaults.tools is not the bug by itself.

The weird part is this combo:

config says tools profile = coding
but /context list reportedly says Tools: (none)

That means the problem is now most likely runtime-effective tools, not “you forgot to configure tools”.

So next checks should be:

#

openclaw status --all
openclaw config get agents.defaults.startupContext
openclaw hooks info session-memory

And right after a fresh /reset, paste:

/context list
the first relevant lines from openclaw logs --follow

Why I’m asking for startupContext / session-memory

Because /reset is not a perfectly blank reset. It can preload recent memory, and the bundled session-memory hook saves previous session content on reset/new.

So there are now two separate problems to distinguish:

#

stale old subagent text is being pulled back in through startup memory
effective tool inventory is coming out empty even though tools.profile is coding

If you paste those 3 outputs, we can separate them pretty quickly.

solar delta Apr 16, 2026, 10:23 AM

#

I also updated yesterday the openclaw.

steel doveBOT Apr 16, 2026, 10:24 AM

#

Ah, that’s a good clue.

If you updated yesterday, I’m more suspicious of stale session state surviving the update than of bad config.

A few important bits:

updating OpenClaw does not clear old session transcripts or workspace/memory
/reset gives the same session key a new session id, it does not wipe all historical side data
so an old poisoned thread/session can survive an upgrade and still look haunted

So right now my top suspects are:

startup-context / session-memory is re-injecting old content
this specific thread session state is stale/bad after the update
2026.4.14 has a runtime bug around effective tool inventory for this path

Fastest isolation test

#

If you can, make a completely new thread/session and run:

/context list

If the new thread has normal tools + soul/identity files, then this is probably thread-specific stale session state, not global config.

Please paste next

openclaw status --all
openclaw doctor
openclaw config get agents.defaults.startupContext
openclaw hooks info session-memory

That should tell us whether this is:

#

stale memory preload,
a bad migrated session,
or a real post-update bug.

If the brand-new thread is clean while this one is broken, I’d treat that as strong evidence the session state for this thread got corrupted across the update.

solar delta Apr 16, 2026, 10:35 AM

#

the new thread still the same I've tried reset and new commands

steel doveBOT Apr 16, 2026, 10:36 AM

#

That’s really helpful.

If a brand-new thread shows the same behavior, then this is not just one poisoned session key. It’s now looking like an instance-wide problem on that machine.

Also, this still fits the reset-memory theory, because:

startupContext is workspace-global
the bundled session-memory hook writes into the same workspace memory
so a fresh thread can still “inherit” yesterday’s content on bare /new or /reset

So right now I think you may have two separate issues:

old subagent text is being reloaded globally via startup memory
effective tools are globally empty even though tools.profile is coding

Please paste these next

#

openclaw status --all
openclaw models status --json
openclaw config get agents.defaults.startupContext
openclaw hooks info session-memory

And if you can, this too:

ls -lt /home/ubuntu/.openclaw/workspace/memory | head

If there’s a memory file from yesterday with that stale subagent content, that explains the “old reply keeps coming back” part.

If models status / status --all look normal and tools are still empty in every new thread, then I’d treat this as a real post-update bug in 2026.4.14, not bad config.

solar delta Apr 16, 2026, 10:37 AM

#

can I try to downgrade?

steel doveBOT Apr 16, 2026, 10:38 AM

#

I’m going to verify the exact version-pin / reinstall path first so I don’t make up a bad downgrade command.

#

Yes, at this point a downgrade is a reasonable test.

I’d just do it in a way that preserves evidence first.

First, capture this

openclaw --version
openclaw status --all

Then prefer the built-in updater

Preview first:

#

openclaw update --dry-run --tag <last-known-good-version>

If it looks right, apply it:

openclaw update --tag <last-known-good-version>

Docs:

After downgrade

#

openclaw health

Then test again in chat with:

/new
/context list

If you installed globally with pnpm and want the manual path

pnpm add -g openclaw@<version>
openclaw doctor
openclaw gateway restart

#

My recommendation

If you know the exact version that worked before yesterday’s update, roll back to that one first.
If the downgrade fixes it, then we’ve got strong evidence this is a regression in 2026.4.14.

If you want, paste the version you were on before, and I’ll tell you the exact command to use.

solar delta Apr 16, 2026, 10:39 AM

#

give me the bash command to see the output of the last time I used openclaw update.

steel doveBOT Apr 16, 2026, 10:40 AM

#

I’m checking whether OpenClaw stores updater output anywhere predictable, so I don’t hand you a bogus grep.

#

Short answer: there usually isn’t a built-in record of the exact old openclaw update stdout unless you saved it.

Closest useful commands:

1) See the last `openclaw update` command you ran

history | grep 'openclaw update' | tail -1

If your bash history has timestamps enabled:

HISTTIMEFORMAT='%F %T ' history | grep 'openclaw update' | tail -1

2) See current updater state

#

openclaw update status --json

3) Grep the latest OpenClaw log for update-related lines

log="$(ls -t /tmp/openclaw/openclaw-*.log 2>/dev/null | head -1)"; rg -n 'update|doctor|restart|gateway' "$log" | tail -80

That last one is the best shot at reconstructing what happened, but it is not guaranteed to be the exact same output you saw in the terminal.

If you want, paste the output of #2 and #3 and I’ll help interpret it.

solar delta Apr 16, 2026, 10:42 AM

#

how can I do a clean install without lossing any memory or workspace file?

steel doveBOT Apr 16, 2026, 10:43 AM

#

I’m checking the uninstall/reset docs so I can give you the safe path that keeps ~/.openclaw/workspace intact.

#

Yes. If your goal is clean reinstall without losing workspace/memory, I’d do this:

Safest first step, make a backup

openclaw backup create

That gives you a restorable snapshot first. Docs: https://docs.openclaw.ai/cli/backup

Option A, reinstall the app/service only, keep state + workspace

This is the safest if you do not want to lose anything:

openclaw gateway stop

#

openclaw gateway uninstall
pnpm remove -g openclaw
pnpm add -g openclaw@latest
openclaw doctor
openclaw gateway install --force
openclaw gateway restart

This should keep:

~/.openclaw/workspace
~/.openclaw/workspace/memory
your state dir under ~/.openclaw

Important, do not do these if you want to keep workspace/memory

#

openclaw uninstall --all
openclaw reset --scope full
deleting ~/.openclaw

If you want a deeper clean but still keep workspace files

This wipes config/creds/sessions, but not workspace:

openclaw reset --scope config+creds+sessions --yes --non-interactive

Then reinstall/reconfigure after that.

My recommendation

Start with Option A first.

#

If the bug survives that, then the problem is probably in state/session/config, not the installed package.

Docs:

If you want, I can give you the exact rollback-clean-reinstall sequence next, for either latest or a pinned older version.

solar delta Apr 16, 2026, 10:45 AM

#

pnpm command not found

steel doveBOT Apr 16, 2026, 10:46 AM

#

No problem, that just means pnpm is not installed or not on PATH.

Easiest path, skip pnpm entirely

Use the built-in updater:

openclaw update

Or if you want to roll back to a specific version:

openclaw update --tag <version>

That’s the path I’d use first.

#

If you specifically want pnpm

Install/activate it with Corepack:

corepack enable
corepack prepare pnpm@latest --activate
pnpm --version

Then you can use:

pnpm add -g openclaw@latest

or

#

pnpm add -g openclaw@<version>

My recommendation

Since you’re debugging a broken install, I’d avoid extra moving parts and just use:

openclaw update --tag <last-known-good-version>

If you want, send me the version you want to roll back to and I’ll give you the exact one-liner.

solar delta Apr 16, 2026, 11:11 AM

#

TypeError: Cannot read properties of undefined (reading 'trim')

steel doveBOT Apr 16, 2026, 11:11 AM

#

That error string is a very useful clue. I’m checking the source for the exact trim() failure path before I tell you to nuke anything.

#

Oof, that error is a strong clue.

TypeError: Cannot read properties of undefined (reading 'trim') fits stale/corrupt session-store state a lot better than “missing soul files”.

Safest next steps

First, back up:

openclaw backup create

Then try the built-in repair path:

openclaw doctor

#

openclaw status --all

If it still happens on `/new` and `/reset`

Assuming default state dir, this is the least-destructive recovery I’d try:

ts="$(date +%Y%m%d-%H%M%S)"
mkdir -p ~/.openclaw/recovery-"$ts"
openclaw gateway stop
mv ~/.openclaw/agents/main/sessions/sessions.json ~/.openclaw/recovery-"$ts"/
openclaw gateway start

That does not touch:

#

~/.openclaw/workspace
~/.openclaw/workspace/memory

It only forces OpenClaw to rebuild the session store.

Why this helps

If a bad/stale entry in sessions.json is stuck in a weird bootstrapping/reset state, moving that file out of the way can clear it without deleting your workspace.

If you want, I can give you the same command but adapted for a non-default state dir/profile before you run it.

solar delta Apr 16, 2026, 11:12 AM

#

it gives me this error when I do onboard

steel doveBOT Apr 16, 2026, 11:12 AM

#

Yep, that actually fits the same theory.

If onboard is also hitting Cannot read properties of undefined (reading 'trim'), then this is not just a bad chat thread anymore. It’s likely broken state on disk, and onboard is tripping over it too.

I’d do this first, before onboarding again

openclaw backup create
ts="$(date +%Y%m%d-%H%M%S)"
mkdir -p ~/.openclaw/recovery-"$ts"
openclaw gateway stop
mv ~/.openclaw/agents/main/sessions/sessions.json ~/.openclaw/recovery-"$ts"/
openclaw doctor
openclaw gateway start

Then try:

#

openclaw onboard

Why

onboard still touches the existing OpenClaw state.
So if sessions.json is corrupt/stale, onboarding can fail with the same trim error.

This keeps your workspace/memory intact, because it does not touch:

~/.openclaw/workspace
~/.openclaw/workspace/memory

If you want, I can give you a slightly more defensive version that lists the session-store path first before moving it.

solar delta Apr 16, 2026, 11:19 AM

#

after that we still have the same error on onboard command

steel doveBOT Apr 16, 2026, 11:20 AM

#

That means it’s probably not just sessions.json. I’m tracing the onboard code path now so we can narrow which missing field is blowing up.

#

Got it. Since moving sessions.json didn’t fix it, I’d stop poking individual files and use the official state reset that keeps workspace.

This should preserve workspace + memory, but clear broken state

openclaw backup create
openclaw reset --scope config+creds+sessions --yes --non-interactive
openclaw onboard --workspace ~/.openclaw/workspace

This keeps:

~/.openclaw/workspace
~/.openclaw/workspace/memory

But clears:

#

config
creds/auth
sessions

Docs:

If it still throws the same `trim` error after that

Then we need the full stack trace, because it’s no longer a normal stale-session problem.

Run this and paste the first stack frame with the file path:

NODE_OPTIONS='--trace-uncaught' openclaw onboard --workspace ~/.openclaw/workspace

#

At that point I’d treat it as a likely bug, and the stack trace will tell us exactly which file/field is undefined.

solar delta Apr 16, 2026, 11:27 AM

#

│ │
├───────────────────────────────────────────────────────────────────────────────╯
TypeError: Cannot read properties of undefined (reading 'trim')

steel doveBOT Apr 16, 2026, 11:27 AM

#

That output is still hiding the useful part. I’m checking the supported debug/log env knob so I can give you one command that captures the stack instead of just the final line.

#

That still isn’t enough, it’s only showing the final exception line.

Please run this exact command and paste the output:

NODE_OPTIONS='--trace-uncaught' OPENCLAW_LOG_LEVEL=trace openclaw --log-level trace onboard --workspace ~/.openclaw/workspace 2>&1 | tee ~/openclaw-onboard-trace.txt

What I need is the first stack frame with a file path, for example something like:

at ... (/path/to/file:line:col)

Right now we know it’s a trim() on undefined, but not which field is undefined. That file path is the difference between guessing and actually fixing it.

tame sinew Apr 16, 2026, 12:23 PM

#

solar delta │ ...

were you able to solve this in this new version of openclaw has this bug on onboard command -TypeError: Cannot read properties of undefined (reading 'trim')

check-https://github.com/openclaw/openclaw/issues/67597
Workaround: install openclaw@2026.4.12

steel doveBOT Apr 16, 2026, 12:23 PM

#

I don’t think we’ve fully solved it in-thread yet, but at this point I do think it looks like a real regression/bug, not just bad user config.

Why I’m leaning bug:

tools config looked sane
fresh threads showed the same behavior
onboard also crashes with the same trim error
moving sessions.json didn’t clear it

So yes, from the evidence so far, I’d treat this as “current version is broken on this path” until proven otherwise.

Best workaround right now

Roll back to the last known good version:

#

openclaw update --tag <last-known-good-version>

Best next step to get it fixed properly

Capture the full stack trace:

NODE_OPTIONS='--trace-uncaught' OPENCLAW_LOG_LEVEL=trace openclaw --log-level trace onboard --workspace ~/.openclaw/workspace 2>&1 | tee ~/openclaw-onboard-trace.txt

Then file a GitHub issue with:

current version
previous working version
that full trace

#

note that fresh threads and onboard both fail with TypeError: Cannot read properties of undefined (reading 'trim')

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

So, short version: I think it’s a real bug, but we still need the stack trace to pin the exact broken field/path.

tame sinew Apr 16, 2026, 12:27 PM

#

tame sinew were you able to solve this in this new version of openclaw has this bug on onbo...

@solar delta Workaround: install openclaw@2026.4.12

steel doveBOT Apr 16, 2026, 12:28 PM

#

Yep, that matches what we were seeing.

If 2026.4.12 is the known-good workaround, I’d use that for now:

openclaw backup create
openclaw update --tag 2026.4.12

Then retry:

openclaw onboard --workspace ~/.openclaw/workspace

If that fixes it, I’d add a comment on the GitHub issue with:

#

broken version
working version 2026.4.12
the trim error on onboard

That helps pin it as a real regression.

Glad you found that lead, that’s actually really useful. 🦐

solar delta Apr 16, 2026, 12:42 PM

#

tame sinew <@356931553424703488> Workaround: install openclaw@2026.4.12

Will try to do it in a bit

steel doveBOT Apr 16, 2026, 12:42 PM

#

Sounds good.

When you do, I’d keep it to:

openclaw backup create
openclaw update --tag 2026.4.12

Then retry onboard and /context list.

If it works, paste back either way, I’m curious whether it clears both:

the trim crash
the weird stale subagent / no-tools behavior

solar delta Apr 16, 2026, 2:35 PM

#

tame sinew <@356931553424703488> Workaround: install openclaw@2026.4.12

same issue.

#

I mean there is no more trim crash but I still get a response saying that it is gemini-cli

steel doveBOT Apr 16, 2026, 2:36 PM

#

Annoying, but that’s useful.

If 2026.4.12 still has the same problem, then the version is probably not the root cause anymore. That points back to local state/config corruption.

Next thing I’d do

Use the official reset that keeps workspace:

openclaw backup create
openclaw reset --scope config+creds+sessions --yes --non-interactive
openclaw onboard --workspace ~/.openclaw/workspace

That should preserve:

~/.openclaw/workspace

#

~/.openclaw/workspace/memory

If `reset` itself is broken or onboard still dies after that

Then I’d do the stronger workaround, but still without deleting your workspace:

ts="$(date +%Y%m%d-%H%M%S)"
openclaw gateway stop
mv ~/.openclaw ~/.openclaw.bad-"$ts"
mkdir -p ~/.openclaw
cp -a ~/.openclaw.bad-"$ts"/workspace ~/.openclaw/
openclaw onboard --workspace ~/.openclaw/workspace

That gives you a fresh state dir while keeping your workspace files.

#

So, updated diagnosis:

not just a bad version
likely bad local state
next step is state reset / fresh state dir, not more downgrade attempts

If you want, I can stay with you and do the “fresh state dir but keep workspace” path step by step.

#

Ah, got it, that’s an important distinction.

If the trim crash is gone, that’s real progress.

At that point, the remaining “I am gemini-cli” text by itself is not enough to say the session is still broken, especially since your configured model/provider is google-gemini-cli/....

So I’d separate it like this:

Probably okay / cosmetic

If it says “gemini-cli” but:

SOUL.md / IDENTITY.md are injected
tools are present
/context list looks normal

then it’s mostly just model self-report / provider flavor text, not a stuck subagent.

#

Still broken

If it says “gemini-cli” and:

tools are still (none)
only AGENTS.md + TOOLS.md show up
identity/soul files are missing

then we still have a real context/runtime problem.

Please check one thing again

Run:

/context list

#

and paste just:

the injected files section
the Tools: line
the Tool schemas: line

That will tell us immediately whether the actual bug is gone and only the wording is weird, or whether the runtime is still wrong.

solar delta Apr 16, 2026, 3:17 PM

#

did a clean install and the same issue

steel doveBOT Apr 16, 2026, 3:17 PM

#

That actually narrows it down a lot.

If a clean install still shows the same “I am gemini-cli” behavior, then this is probably not stale local state anymore.

At that point, the most likely explanation is:

you are using the google-gemini-cli/... provider
the model/backend is just self-identifying as Gemini CLI
that wording alone does not prove you are stuck in a subagent

So the label is not the real signal anymore. The real signal is still:

are SOUL.md / IDENTITY.md injected?
are tools present?
does /context list look normal?

Please run this after the clean install

#

/context list

and paste only:

injected files
Tools:
Tool schemas:

If that output is normal now, then the actual bug is basically gone and the remaining “gemini-cli” text is just cosmetic/provider self-report.

grim ocean Apr 16, 2026, 3:52 PM

#

Hello. I am a Senior Software Engineer. I think I can help you resolve your issue. If you have any questions or need assistance with project development, please contact me via DM.

steel doveBOT Apr 16, 2026, 3:53 PM

#

I’d keep this in-thread or on GitHub, not in DMs.

That way:

other people can verify/reproduce
maintainers can see the exact trace
the fix stays searchable on Answer Overflow / GitHub for the next person

So if anyone has useful data, best thing is to paste it here:

/context list
full onboard trace
exact working vs broken version

DM debugging is a dead end for support threads like this.

solar delta Apr 16, 2026, 6:02 PM

#

/tools

Available tools

Profile: coding

Built-in tools
cron, edit, exec, process, read, sessions_history, sessions_send, session_status, sessions_list, sessions_spawn, subagents, web_fetch, write, sessions_yield

Connected tools
memory_get (memory-core), memory_search (memory-core)

Use /tools verbose for descriptions.

solar delta Apr 16, 2026, 6:03 PM

#

solar delta /tools Available tools Profile: coding Built-in tools cron, edit, exec, pr...

@steel dove are these tools the openclaw ones or gemini

steel doveBOT Apr 16, 2026, 6:03 PM

#

Those are OpenClaw tools.

Specifically, names like:

read, write, edit
exec, process
sessions_spawn, subagents
session_status, sessions_list, sessions_history
web_fetch

are OpenClaw’s tool surface, not Gemini-native tools.

So this is actually a big clue:

tooling is present and looks normal now
if the model still says “I am gemini-cli”, that is most likely just provider/model self-description
it does not mean the runtime is still missing tools

#

At this point the next question is the files/context side, not tools.

If you want to verify that too, paste /context list and I’ll check whether SOUL.md / IDENTITY.md are back.

solar delta Apr 16, 2026, 6:04 PM

#

✅ Available Tools (Verified)

list_directory: List files in a folder.
read_file: Read the contents of a file.
grep_search: Search for text patterns inside files.
glob: Search for files by name/pattern.
cli_help: Access documentation about this CLI.
mcp_openclaw_*: A suite of tools for managing OpenClaw sessions and memory (though some of these fail due to a gateway pairing error).

❌ Missing Tools (Attempted but "Not Found")

run_shell_command: Cannot run mv, cp, or other terminal commands.
write_file: Cannot create new files or copy content.
replace: Cannot edit existing files.

steel doveBOT Apr 16, 2026, 6:05 PM

#

Yep, this is the clearest evidence so far:

/tools is authoritative
the pasted list_directory / read_file / grep_search / glob / run_shell_command block is not the real OpenClaw tool inventory

Those names are not OpenClaw-native.
OpenClaw’s real equivalents are:

read_file → read
write_file → write
replace → edit
run_shell_command → exec

So what’s happening now is:

the actual runtime tools are OpenClaw tools
the model is still describing or expecting a Gemini CLI-style tool schema

#

if it tries those wrong names, that’s a model/provider prompt/tooling bug, not “tools are actually missing”

So I would trust:

/tools
/context list

and not trust the model’s own “available tools” paragraph.

At this point, the remaining bug looks like:

the model thinks it has Gemini-style tool names, while OpenClaw is actually exposing OpenClaw tools

That’s a much narrower bug than where we started.

If you can, paste /context list too, because then we can confirm whether the files/context are also normal now, and the only thing left broken is the model’s fake tool self-report.

solar delta Apr 16, 2026, 6:07 PM

#

🧠 Context breakdown
Workspace: /home/ubuntu/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 27,435 chars ~~(6,859 tok) (Project Context 13,377 chars (3,345 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,738 chars ~~(435 tok) | injected 1,738 chars (435 tok)~~
TOOLS.md: OK | raw 850 chars ~~(213 tok) | injected 850 chars (213 tok)~~
IDENTITY.md: OK | raw 633 chars ~~(159 tok) | injected 633 chars (159 tok)~~
USER.md: OK | raw 474 chars~~ (119 tok) | injected 474 chars (119 tok)~~
HEARTBEAT.md: OK | raw 192 chars ~~(48 tok) | injected 192 chars (48 tok)~~
BOOTSTRAP.md: OK | raw 1,450 chars~~ (363 tok) | injected 1,450 chars (363 tok)~~

Skills list (system prompt text): 4,802 chars ~~(1,201 tok) (10 skills)~~
~~Skills: clawhub, gemini, healthcheck, mcporter, node-connect, skill-creator, taskflow, taskflow-inbox-triage, tmux, weather~~
~~Tool list (system prompt text): 0 chars (0 tok)~~
Tool schemas (JSON): 0 chars (~0 tok) (counts toward context; not shown as text)
Tools: (none)

Session tokens (cached): unknown / ctx=200,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.

steel doveBOT Apr 16, 2026, 6:07 PM

#

This is the smoking gun.

Your latest output proves:

main session bootstrap is normal
(AGENTS.md, SOUL.md, IDENTITY.md, USER.md, etc. are injected)
but the model receives zero tools
(Tool list: 0, Tool schemas: 0, Tools: (none))

So the current state is:

not missing soul/identity files
not just stale subagent context
not “tools are uninstalled” in a broad sense, because /tools still shows them
it is a bug where tools exist in OpenClaw, but the effective model prompt gets none

That also explains why it keeps acting like plain Gemini CLI. If OpenClaw passes zero tools, the model falls back to chatty self-description instead of acting agentic.

#

So the bug is now very narrow

/tools sees registered tools, but /context list shows the runtime is injecting zero effective tools into the model.

That’s the thing to report.

One last isolating test

If you have any non-google-gemini-cli provider/model configured, switch to that temporarily and rerun /context list.

If tools appear there, this is almost certainly a google-gemini-cli effective-tools bug
If tools are still (none), then it’s a broader runtime/config issue

What I’d put in the GitHub issue

Paste both of these together:

#

/tools output showing OpenClaw tools exist
/context list output showing Tools: (none) and Tool schemas: 0

That combination is really the key evidence.

solar delta Apr 16, 2026, 6:08 PM

#

I've no other model

steel doveBOT Apr 16, 2026, 6:09 PM

#

That’s enough to call it, then.

Given:

only google-gemini-cli is configured
/tools shows OpenClaw tools exist
/context list shows zero tools are actually injected

…the most likely diagnosis is:

the google-gemini-cli path is failing effective tool injection on your setup

So I would stop reinstalling/resetting at this point.
You’ve already narrowed it much further than that will help.

Best next move

#

File/update the GitHub issue with exactly these two outputs:

/tools
/context list

and note:

SOUL.md / IDENTITY.md inject correctly
Tools: (none)
Tool schemas: 0
model keeps self-reporting as Gemini CLI because it gets no OpenClaw tools

Practical workaround

If you need agentic behavior right now, you’ll probably need to configure another provider/model temporarily, because with the current setup the model is effectively getting no tools.

So, short version: this now looks like a provider-specific tooling bug, not your install being haunted anymore.

solar delta Apr 16, 2026, 6:09 PM

#

how can I do a full clean install with a version of the month 3

steel doveBOT Apr 16, 2026, 6:10 PM

#

You can, but a full clean install really means wiping state + workspace, so back up first.

1) Back up everything first

openclaw backup create

2) List March releases so you can pick one

npm view openclaw versions --json | node -e 'let s="";process.stdin.on("data",c=>s+=c).on("end",()=>JSON.parse(s).filter(v=>/^2026\.3\./.test(v)).forEach(v=>console.log(v)))'

3) Full clean uninstall

#

openclaw uninstall --all --yes --non-interactive

4) Install the March version you want

Replace 2026.3.x with the exact one from step 2:

npm i -g openclaw@2026.3.x

5) Set it up again

openclaw onboard

#

Docs:

Important

openclaw uninstall --all removes the workspace too, so if you want your memory/workspace back afterward, restore it from the backup instead of expecting it to survive the uninstall.

If you want, I can give you the same flow but keeping the workspace folder intact instead of doing a truly full wipe.

solar delta Apr 16, 2026, 6:13 PM

#

want to uninstall the cli too

steel doveBOT Apr 16, 2026, 6:13 PM

#

I’m checking whether openclaw uninstall --all removes the CLI binary/package too, or whether you still need the package-manager remove step afterward.

#

Yep, if you want the CLI gone too, do both steps.

openclaw uninstall --all removes:

service
state/config
workspace
macOS app

…but the CLI remains.

Full wipe including the CLI

openclaw backup create
openclaw uninstall --all --yes --non-interactive

#

npm rm -g openclaw

Then install the version you want:

npm i -g openclaw@2026.3.x
openclaw onboard

So the full sequence is basically:

openclaw backup create
openclaw uninstall --all --yes --non-interactive

#Agent is not reading soul/identity

What I want next

Current best hypothesis

So next checks should be:

Why I’m asking for startupContext / session-memory

Fastest isolation test

Please paste next

Please paste these next

First, capture this

Then prefer the built-in updater

After downgrade

If you installed globally with pnpm and want the manual path

My recommendation

1) See the last openclaw update command you ran

2) See current updater state

3) Grep the latest OpenClaw log for update-related lines

Safest first step, make a backup

Option A, reinstall the app/service only, keep state + workspace

Important, do not do these if you want to keep workspace/memory

If you want a deeper clean but still keep workspace files

My recommendation

Easiest path, skip pnpm entirely

If you specifically want pnpm

My recommendation

Safest next steps

If it still happens on /new and /reset

Why this helps

I’d do this first, before onboarding again

Why

This should preserve workspace + memory, but clear broken state

If it still throws the same trim error after that

Best workaround right now

Best next step to get it fixed properly

Next thing I’d do

If reset itself is broken or onboard still dies after that

Probably okay / cosmetic

Still broken

Please check one thing again

Please run this after the clean install

So the bug is now very narrow

One last isolating test

What I’d put in the GitHub issue

Best next move

Practical workaround

1) Back up everything first

2) List March releases so you can pick one

3) Full clean uninstall

4) Install the March version you want

5) Set it up again

Important

Full wipe including the CLI

1) See the last `openclaw update` command you ran

If it still happens on `/new` and `/reset`

If it still throws the same `trim` error after that

If `reset` itself is broken or onboard still dies after that