Openclaw unable to write to it's identity.md or other files | Friends of the Crustacean 🦞🤝 | Page 1

red bone Apr 17, 2026, 9:28 AM

#

I am using OpenCLAW with GeminiCLI. I happened to do a hard reset. (i.e. uninstalled everything and reinstalled the latest). I observed that the startup (openclaw onboard --install-daemon) fails soon after I configure the Gemini CLI through OAuth. Then I went through manual configuration and got it up and running, but now it does not write to any of the files (like soul.md). Even the bootstrap didn't run. I am using this on Linux.
When I ask it to explicitly update it's identity file, I get this " I apologize for the limitation; I do not have direct file-writing or shell execution tools available in this environment. I am
restricted to the provided toolset, which does not include direct file manipulation. I will maintain these details in my memory to ensure I always adhere to my identity ...."
Has anyone else faced this problem? Feels like I am missing something very obvious.

warm wharfBOT Apr 17, 2026, 9:28 AM

#

faint turretBOT Apr 17, 2026, 9:32 AM

#

I’m checking the docs/source first so I don’t guess the wrong key or behavior.

#

This is probably not you missing something obvious.

What you described usually means two separate issues:

Bootstrap never reran because the workspace was already partially seeded
- BOOTSTRAP.md only gets created for a truly brand-new workspace
- if onboarding failed after creating AGENTS.md / SOUL.md / IDENTITY.md / etc, later runs won’t treat it as first-run anymore
The model is not seeing write/exec tools
- OpenClaw’s core tools are normally available subject to tool policy
- that “I do not have direct file-writing or shell execution tools” message usually means your config filtered them out, for example via:
  - tools.profile
  - tools.allow / tools.deny
  - tools.byProvider
  - agents.list[].tools
  - sandbox read-only workspace access

#

Also, for Gemini CLI on Linux, there is a separate daemon gotcha:

if gemini is installed in a user-only path, the systemd service PATH may not see it
and Gemini CLI docs also call out setting GOOGLE_CLOUD_PROJECT / GOOGLE_CLOUD_PROJECT_ID if requests fail after login

Can you paste these?

openclaw --version
openclaw status --all
openclaw config get agents.defaults.workspace
openclaw config get agents.defaults.skipBootstrap
openclaw config get tools
openclaw logs --follow

What I’d look for specifically:

#

agents.defaults.skipBootstrap: true
tools.profile: "minimal"
tools.allow missing group:fs or group:runtime
a tools.byProvider rule for google-gemini-cli
per-agent tools overrides
logs showing gemini not found, tool-policy denial, or provider startup failure

One likely recovery path if onboarding half-created the workspace:

backup/move aside the active workspace, don’t delete it
rerun openclaw setup or openclaw onboard
or point OpenClaw at a fresh empty workspace so bootstrap can happen cleanly again

Relevant docs:

FAQ: https://docs.openclaw.ai/help/faq
Bootstrapping: https://docs.openclaw.ai/start/bootstrapping
Agent workspace: https://docs.openclaw.ai/concepts/agent-workspace
Model providers / Gemini CLI: https://docs.openclaw.ai/concepts/model-providers

#

If you paste those outputs, I can help narrow it down fast. 🦐

red bone Apr 17, 2026, 12:20 PM

#

openclaw config get tools

🦞 OpenClaw 2026.4.14 (323493f)

Config path not found: tools

faint turretBOT Apr 17, 2026, 12:21 PM

#

That output is actually useful.

Config path not found: tools means you do not have an explicit top-level tools block in config, so the problem is probably not a simple global tools.deny / tools.profile override.

That pushes the suspicion toward one of these instead:

workspace state after the failed onboard
agents.defaults.skipBootstrap
per-agent overrides under agents.list
sandbox/read-only access
the daemon using a different workspace than the one you expect

Can you paste these next?

openclaw config get agents.defaults.workspace

#

openclaw config get agents.defaults.skipBootstrap
openclaw config get agents.defaults.sandbox
openclaw config get agents.list
openclaw doctor
openclaw status --all

And one very important check:

openclaw logs --follow

Then, while logs are open, ask the agent once to update IDENTITY.md again.

One key bit from the docs/code: if onboarding already created AGENTS.md / SOUL.md / IDENTITY.md once, then bootstrap not rerunning can be expected. BOOTSTRAP.md is only created for a truly brand-new workspace. So that part may be a symptom of the failed first setup, not the root cause.

#

If you want, paste the next outputs and I’ll help narrow it down from there.

red bone Apr 17, 2026, 12:35 PM

#

openclaw config get agents.defaults.workspace = ~/.openclaw/workspace

Config path not found: agents.defaults.skipBootstrap
Config path not found: agents.defaults.sandbox
Config path not found: agents.list

doctor points to problems with no provider configured for memory. I am using "provider": "google-gemini-cli" in oauth mode. That is likely not supported for memory.

Status also points to nothing obvious.

faint turretBOT Apr 17, 2026, 12:36 PM

#

Let me verify the memory-provider angle, because that sounds adjacent but I don’t want to send you chasing the wrong thing.

#

Yep, the memory warning is separate.

For memory search, google-gemini-cli is not the embedding provider. The supported memory providers are things like gemini, openai, local, etc. So doctor is right there, but that should not remove write / exec from the agent.

At this point, the interesting part is this:

you have no explicit tools block
no agents.list
no sandbox override
default workspace is ~/.openclaw/workspace

So this is starting to look less like config and more like Gemini CLI running without its tool bridge.

OpenClaw’s docs say CLI backends are basically text-only unless the MCP bridge is active. For google-gemini-cli, tool access is passed through a generated Gemini system settings file, not as native OpenClaw tool JSON. If that MCP bridge/setup fails, the model would say exactly what you pasted: “I don’t have file-writing or shell tools.”

So I’d check these next:

#

gemini --version
openclaw plugins list
ls -la ~/.openclaw/workspace
openclaw logs --follow

Then, with logs open, ask the agent two simple things:

Please read IDENTITY.md
Please append TEST to IDENTITY.md

What I’d expect from logs if this theory is right:

something about MCP
bundle MCP skipped
Gemini CLI launch/config issues
gemini ignoring or failing its generated system settings

#

CLI/backend startup errors around tool bridge setup

Also, on the bootstrap part: if ~/.openclaw/workspace already exists and has the seeded files, then bootstrap not rerunning is expected. That part is probably fallout from the failed first onboarding, not the main bug.

So short version:

doctor memory warning: real, but unrelated
bootstrap missing: probably expected after partial first setup
no file writes: most likely Gemini CLI MCP/tool bridge issue

If you paste the log lines from that test, I think we can narrow it down pretty fast.

Docs:

CLI backends: https://docs.openclaw.ai/gateway/cli-backends
Memory search: https://docs.openclaw.ai/concepts/memory-search
Bootstrapping: https://docs.openclaw.ai/start/bootstrapping

red bone Apr 17, 2026, 12:39 PM

#

what plugin am I looking for Gemini to work ?

faint turretBOT Apr 17, 2026, 12:40 PM

#

The plugin you want is google.

For Gemini CLI OAuth, the docs say:

openclaw plugins enable google
openclaw models auth login --provider google-gemini-cli --set-default

So in openclaw plugins list, you’re looking for google to be enabled.

Small gotcha: you are not looking for a separate google-gemini-cli-auth plugin. That old name is legacy/removed.

If you want, run:

#

openclaw plugins list

and paste the output. If google is missing or disabled, that would explain a lot.

red bone Apr 17, 2026, 12:42 PM

#

@openclaw/ │ google │ openclaw │ loaded │ stock:google/index.js │ 2026.4.14 │
│ google- │ │ │ │ OpenClaw Google plugin │ │
│ plugin

faint turretBOT Apr 17, 2026, 12:42 PM

#

Nice, that part looks good.

So google is loaded, which means this is not “missing plugin”.

That pushes the blame further downstream, most likely to the Gemini CLI backend / MCP tool bridge.

I’d check these next:

gemini --version
openclaw logs --follow

Then, with logs open, ask the agent:

Please read IDENTITY.md
Please update IDENTITY.md

#

If the plugin is loaded but Gemini still says it has no file tools, I’d expect the logs to show something around:

google-gemini-cli
mcp
bundle MCP
Gemini system settings / launch config
CLI startup failure or ignored settings

So yeah, good news: we ruled out the plugin.
Next suspect is Gemini CLI not getting its tool bridge correctly.

red bone Apr 17, 2026, 12:45 PM

#

12:43:12+00:00 warn bonjour {"subsystem":"bonjour"} restarting advertiser (service stuck in probing for 10000ms (gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing))
12:43:13+00:00 info bonjour: advertised gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
12:43:17+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
12:43:21+00:00 info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=google-gemini-cli model=gemini-3.1-flash-lite-preview promptChars=211
12:43:27+00:00 warn bonjour {"subsystem":"bonjour"} restarting advertiser (service stuck in probing for 10000ms (gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing))
12:43:28+00:00 info bonjour: advertised gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
12:43:42+00:00 warn bonjour {"subsystem":"bonjour"} restarting advertiser (service stuck in probing for 10001ms (gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing))
12:43:43+00:00 info bonjour: advertised gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=announcing
12:43:47+00:00 warn bonjour {"subsystem":"bonjour"} watchdog detected non-announced service; attempting re-advertise (gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing)
12:43:57+00:00 warn bonjour {"subsystem":"bonjour"} restarting advertiser (service stuck in probing for 10002ms (gateway fqdn=MyMachine (OpenClaw)._openclaw-gw._tcp.local. host=openclaw.local. port=18789 state=probing))

faint turretBOT Apr 17, 2026, 12:46 PM

#

Those bonjour warnings are noise here, I wouldn’t chase them. They’re about local mDNS advertising, not file tools.

The only interesting line in that snippet is:

info agent/cli-backend ... provider=google-gemini-cli model=gemini-3.1-flash-lite-preview

So:

OpenClaw is invoking Gemini CLI
but this snippet still does not show the tool-bridge/MCP part succeeding or failing

Two useful takeaways:

Ignore bonjour for now
I’m a little suspicious of the model choice: gemini-3.1-flash-lite-preview

#

that is not the documented default
- for tool use, I would test with google-gemini-cli/gemini-3-flash-preview first, or even a Pro model

Can you do one more log capture, but filter the noise?

openclaw logs --follow | grep -Ei 'cli-backend|mcp|gemini|tool|write|identity'

Then ask it once:

update IDENTITY.md and add the word TEST

Also, if you can, paste:

#

gemini --version

Right now my read is:

plugin is loaded
config is mostly default
bonjour is unrelated
most likely issue is still Gemini CLI tool bridging, possibly made worse by the flash-lite model being too weak/weird for tool use

If you switch off flash-lite and it suddenly starts writing files, that’s a pretty strong signal we found it.

red bone Apr 17, 2026, 12:53 PM

#

I added the model choice explicitly because it has a better quota and works fast. The problem happened for other models, too. That model uses tools when needed. It was able to read the IdentityFile properly. I only get issues with writes and edits.

Here is filtered log output.

2026-04-17T12:51:42.700Z info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=google-gemini-cli model=gemini-3.1-flash-lite-preview promptChars=205

This is what it says "I have checked my available tools and permissions.
Unfortunately, I do not have a tool available to me (such as write_file)
that allows me to directly overwrite or modify the contents of
IDENTITY.md."

faint turretBOT Apr 17, 2026, 12:57 PM

#

That does not sound like “you missed one obvious setting”.

If it can read IDENTITY.md but says it has no write_file-style tool, I’d treat this as a tool exposure / MCP bridge problem, not a basic workspace-path problem.

Also, the missing bootstrap is probably secondary. If the workspace got partially seeded during manual setup, OpenClaw may no longer treat it as a brand-new workspace, so bootstrap would not re-run.

The next useful checks are:

openclaw --version

And in the failing session/chat, run:

/context detail

#

Please paste the Tool list part. I want to know whether that session actually has:

write
edit
apply_patch

If those are missing there, the runtime is handing Gemini a read-only-ish tool set.

If those tools are present, then the bug is more likely on the google-gemini-cli side, meaning the MCP/tool bridge is not surfacing mutating tools correctly.

Then one more:

openclaw logs --follow

With logs open, ask the agent:

#

append TEST to IDENTITY.md

and paste the unfiltered lines around that request, especially anything mentioning:

google-gemini-cli
mcp
tool
permission
approve

Docs for the two relevant bits:

Context inspection: https://docs.openclaw.ai/concepts/context
CLI backends: https://docs.openclaw.ai/gateway/cli-backends

If you paste openclaw --version plus the /context detail tool section, I can narrow this down a lot faster.

red bone Apr 17, 2026, 1:03 PM

#

🧠 Context breakdown (detailed)
Workspace: ~/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 29,542 chars (7,386 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): 6,894 chars (~1,724 tok) (16 skills)
Skills: blogwatcher, clawhub, gemini, gh-issues, github, healthcheck,
mcporter, node-connect, obsidian, skill-creator, taskflow,
taskflow-inbox-triage, tmux, video-frames, wacli, 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)
Top tools (schema size):
Top tools (summary text size):

faint turretBOT Apr 17, 2026, 1:04 PM

#

Ah, that /context detail output is the smoking gun.

Tools: (none) means this is not “Gemini can read but not write”.
It means the session got zero tools at all.

So what happened is:

it can “read” IDENTITY.md only because that file is being injected into the prompt
it cannot write because there is literally no write / edit / apply_patch tool in the session

So the problem is upstream of Gemini’s write behavior. The session/tool config is broken.

Two extra clues from your dump:

Tools: (none) is wrong for a normal local coding-style setup
BOOTSTRAP.md is still present, which makes me suspicious this install is stuck in a partial bootstrap/onboarding state

#

Please run these next:

openclaw --version
openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.byProvider
openclaw config get agents.defaults.tools

If you have a custom agent configured, also:

openclaw config get agents.list

#

What I’m expecting:

for a normal local install, you should usually have a tool profile that includes group:fs
if those config keys are empty/missing and onboarding failed earlier, it may have left you in a weird half-configured state

Also, I would not treat the earlier “it read the file” as proof tools were working. Your context dump basically disproves that.

Relevant docs:

Tool policy / profiles: https://docs.openclaw.ai/gateway/configuration-reference#tools
Context inspection: https://docs.openclaw.ai/concepts/context

Paste those config outputs and I think we can pin down whether this is:

a bad tool policy,
a broken onboarding default,
or a stuck bootstrap workspace.

red bone Apr 17, 2026, 1:06 PM

#

my install got terminated midway. perhaps there is a need to fix that first

faint turretBOT Apr 17, 2026, 1:07 PM

#

Yes, I think that’s the right move.

Given:

Tools: (none)
lingering BOOTSTRAP.md
install/onboarding getting interrupted mid-way

this looks a lot more like a partial/broken onboarding state than a Gemini-specific write bug.

I’d fix the install first, then re-check tools.

Start with:

openclaw --version

#

openclaw doctor
openclaw onboard --install-daemon

A useful detail from the docs, re-running onboarding does not wipe anything unless you explicitly choose Reset:
https://docs.openclaw.ai/start/wizard-cli-reference
https://docs.openclaw.ai/gateway/troubleshooting

So my recommendation is:

rerun onboarding
if it offers Keep / Modify / Reset, don’t panic, it’s safe to inspect
if you do not care about the current broken workspace, I’d lean toward a clean reset path
if you do care, back up ~/.openclaw/ first, then reset

After that, immediately run /context detail again in the agent session.

#

What we want to see is not Tools: (none).
At minimum, a normal local setup should stop looking tool-less.

If you want, paste the output from openclaw doctor or the point where openclaw onboard --install-daemon dies, and I’ll help narrow the exact failure.

red bone Apr 17, 2026, 1:15 PM

#

re-ran onboard.
I get this issue each time after the messaging. I get this issue even if I did pick a messaging provider.

◇ Select channel (QuickStart)
│ Skip for now
TypeError: Cannot read properties of undefined (reading 'trim')

faint turretBOT Apr 17, 2026, 1:16 PM

#

Yep, that looks like a real onboarding bug, not you missing a setting.

The key part is:

Select channel (QuickStart)
Skip for now
TypeError: Cannot read properties of undefined (reading 'trim')

So the wizard is crashing in the QuickStart channel step.

I’d try this workaround first:

openclaw onboard --flow manual --install-daemon

#

That should bypass the QuickStart path that seems to be blowing up.

Two things I’d like after that:

openclaw --version
whether --flow manual gets past the crash

If manual flow works, check /context detail again after setup. The important thing is that it should stop saying Tools: (none).

If manual flow still crashes with the same trim error, I’d call that bug territory and file it here with:

openclaw --version
the full onboarding output
the exact repro (openclaw onboard --install-daemon, crash after messaging / channel quickstart)

GitHub issues: https://github.com/openclaw/openclaw/issues
Onboard docs: https://docs.openclaw.ai/cli/onboard

#

If you paste the version and whether --flow manual works, I can help narrow the next step.

red bone Apr 17, 2026, 1:27 PM

#

flow manual worked all the way. But after that when the boot strap happened, I still see Tools: (none) in the context detail. And writing to the Identity.md is still not working

faint turretBOT Apr 17, 2026, 1:29 PM

#

That’s really useful, thank you. I think we’ve now split this into two separate issues:

QuickStart onboarding bug (undefined.trim)
Gemini CLI still not getting file tools after manual onboarding

And I should correct one thing from earlier: for CLI backends, /context detail is not enough by itself to prove tool availability, because google-gemini-cli gets tools through the bundle MCP bridge, not normal in-prompt tool schemas.

So the remaining thing to debug is the Gemini MCP handoff.

Please check these next:

openclaw --version
gemini --version
openclaw plugins inspect google
openclaw config get agents.defaults.cliBackends.google-gemini-cli

#

Then the important one:

openclaw logs --follow | rg 'google-gemini-cli|mcp|GEMINI_CLI_SYSTEM_SETTINGS_PATH|OPENCLAW_MCP|tool'

While that is running, ask the agent:

append TEST to IDENTITY.md

What I’m looking for is whether the Gemini backend is actually getting the MCP overlay at all.

Docs for the relevant part:
https://docs.openclaw.ai/gateway/cli-backends#bundle-mcp-overlays

#

If you paste the outputs from:

openclaw --version
gemini --version
openclaw plugins inspect google
openclaw config get agents.defaults.cliBackends.google-gemini-cli

I can probably tell pretty quickly whether this is:

bad backend config,
missing MCP bridge,
or a real google-gemini-cli integration bug.

red bone Apr 17, 2026, 1:32 PM

#

Bundled Google plugin

Status: loaded
Format: openclaw
Source: ~/.npm-global/lib/node_modules/openclaw/dist/extensions/google/index.js
Origin: bundled
Version: 2026.4.14
Shape: hybrid-capability
Capability mode: hybrid
Legacy before_agent_start: no

Capabilities:
cli-backend: google-gemini-cli
text-inference: google-gemini-cli, google
media-understanding: google
image-generation: google
web-search: gemini

for the last one.
Config path not found: agents.defaults.cliBackends.google-gemini-cli

faint turretBOT Apr 17, 2026, 1:33 PM

#

That Config path not found is actually fine here.

It just means you do not have a user override for agents.defaults.cliBackends.google-gemini-cli, so OpenClaw should be using the bundled Google plugin default.

So, good news, this is not “missing that config key”.

At this point the most likely remaining issue is:

the bundled google-gemini-cli backend is loaded,
but the Gemini MCP overlay is not being applied or honored.

Two things I still need:

openclaw --version
gemini --version

#

And then the important runtime check:

openclaw logs --follow | rg 'google-gemini-cli|mcp|GEMINI_CLI_SYSTEM_SETTINGS_PATH|OPENCLAW_MCP'

While that is running, ask the agent again:

append TEST to IDENTITY.md

Also, if you can, run:

openclaw plugins inspect google --json

#

and paste the cliBackends section. I want to confirm the backend metadata from the plugin side, especially whether the expected MCP/bundle settings are present.

So right now my read is:

plugin loaded ✅
no missing cliBackends override ✅
write still unavailable ❌
likely fault is now in the Gemini CLI bridge/runtime path, not in your basic config

If you paste openclaw --version, gemini --version, and the MCP-related log lines, we should be very close.

red bone Apr 17, 2026, 3:13 PM

#

Versions:
OpenClaw 2026.4.14 (323493f)
Gemini 0.27.3

Logs
2026-04-17T15:07:12.576Z info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=google-gemini-cli model=gemini-3.1-flash-lite-preview promptChars=489
2026-04-17T15:08:04.183Z info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=google-gemini-cli model=gemini-3.1-flash-lite-preview promptChars=207

Plugin inspect :
"cliBackendIds": [
"google-gemini-cli"
],
"providerIds": [
"google-gemini-cli",
"google"
],
"mcpServers": [],

faint turretBOT Apr 17, 2026, 3:14 PM

#

Yep, I think we’ve crossed the line into actual bug territory.

A couple important clarifications:

mcpServers: [] in plugin inspect is not the problem by itself. That reports plugin-declared bundle MCP servers, not the generated OpenClaw loopback bridge.
I checked the source here, and the bundled google-gemini-cli backend is supposed to run with:
- bundleMcp: true
- bundleMcpMode: "gemini-system-settings"

So with your evidence:

OpenClaw 2026.4.14
Gemini CLI 0.27.3
bundled Google plugin loaded
manual onboarding succeeds
agent still reports no write tools
quickstart onboarding crashes with undefined.trim

#

…I do not think you’re missing an obvious config key anymore.

My recommendation

Option 1, quickest sanity check

Update OpenClaw to the newest build you can get, then retry:

openclaw onboard --flow manual --install-daemon

I can already see fixes landed after 2026.4.14, including onboarding fixes, so I would absolutely try that first.

Option 2, if it still reproduces

Please file a GitHub issue here:
https://github.com/openclaw/openclaw/issues

#

I’d include this exact summary:

OpenClaw 2026.4.14 (323493f)
Gemini CLI 0.27.3
openclaw onboard --install-daemon quickstart crashes after channel selection with:
- TypeError: Cannot read properties of undefined (reading 'trim')
openclaw onboard --flow manual --install-daemon succeeds
bundled google plugin is loaded, google-gemini-cli backend present
session still cannot write/edit files
model says it has no write_file-style tool
/context detail shows no normal tool list
logs only show agent/cli-backend ... provider=google-gemini-cli ... cli exec

If you want, I can help you write the issue body cleanly before you post it.

red bone Apr 17, 2026, 4:48 PM

#

ok. I took the latest version 2026.4.15 and uninstalled and installed everything. The quickstart works fine now so that is resolved. The model still fails to write. with similar messages as before.

faint turretBOT Apr 17, 2026, 4:49 PM

#

That’s actually a really helpful result.

So now we know:

QuickStart crash was a real bug, and 2026.4.15 fixed it ✅
write/edit still failing after a clean reinstall means this is very likely a separate google-gemini-cli integration bug ❌

At this point, I would stop blaming your config. You’ve done enough debugging.

I’d file a GitHub issue now

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

You can paste something like this:

## Summary

#


Using OpenClaw with `google-gemini-cli` via OAuth on Linux, the agent can read injected workspace files but cannot write/edit files like `IDENTITY.md` or `SOUL.md`.

The model responds with messages like:

> I do not have direct file-writing or shell execution tools available in this environment.
> Unfortunately, I do not have a tool available to me (such as write_file) that allows me to directly overwrite or modify the contents of IDENTITY.md.

## Environment

- OpenClaw: `2026.4.15`
- Gemini CLI: `0.27.3`
- OS: Linux

## What I already verified

#


- Clean reinstall
- Re-ran onboarding
- Google plugin is loaded
- `google-gemini-cli` backend is present
- QuickStart onboarding crash from 2026.4.14 is fixed in 2026.4.15
- The remaining problem persists after reinstall

## Repro

1. Install OpenClaw on Linux
2. Configure `google-gemini-cli` via OAuth
3. Complete onboarding
4. Ask the agent to update `IDENTITY.md`

#

## Actual result

The agent says it has no file-writing tool / no `write_file`-style capability.

## Expected result

The agent should have working file write/edit capability through the Gemini CLI tool bridge / MCP path.

## Notes

Relevant logs only show the CLI backend invocation, for example:

```text
info agent/cli-backend cli exec: provider=google-gemini-cli model=gemini-3.1-flash-lite-preview

#


But the model still claims it has no file-writing tools.

If you want a practical workaround while waiting on that, I’d avoid the Gemini CLI path for file-editing tasks for now.

red bone Apr 17, 2026, 4:49 PM

#

alternatives ?

faint turretBOT Apr 17, 2026, 4:50 PM

#

Yep. Short-term, I’d use one of these:

Stay with Google, but switch to the built-in google provider
- use a Google API key instead of google-gemini-cli OAuth
- this is the closest alternative if you want to stay in the Google ecosystem
Use a non-CLI provider path
- the CLI bridge seems to be the flaky part here
- if your goal is “just make file edits work again”, avoiding the CLI-backed provider is the safest move
If you want fresh hands-on model/provider recommendations
- ask in #models
- that channel will have the most current “what is reliable right now” advice

Docs:

Provider setup: https://docs.openclaw.ai/concepts/model-providers
Models overview: https://docs.openclaw.ai/concepts/models

#Openclaw unable to write to it's identity.md or other files

My recommendation

Option 1, quickest sanity check

Option 2, if it still reproduces

I’d file a GitHub issue now