Filesystem MCP write_file not available to agent in headless Gemini CLI mode

[misty pivot]

Hi! I've been trying to give my OpenClaw
agent (using google-gemini-cli provider)
filesystem write access. Here's where I am:

Setup:

• OpenClaw gateway on WSL2 Ubuntu, systemd,
  Telegram channel
• Provider: google-gemini-cli /
  gemini-2.5-flash
• Created a bundle plugin at
  ~/.openclaw/extensions/fs-bundle/ with
  .claude-plugin/plugin.json + .mcp.json
  (pointing to
  @modelcontextprotocol/server-filesystem)
• Plugin loads correctly — gateway logs
  show ready (3 plugins: acpx, fs-bundle,
  telegram)
• OpenClaw generates
  /tmp/openclaw-gemini-mcp-*/settings.json
  with filesystem in mcp.allowed and
  mcpServers — confirmed correct

What works:

• Running gemini interactively in the
  terminal: /mcp shows 🟢 filesystem - Ready
  (14 tools) including
  mcp_filesystem_write_file ✅
• loadEnabledBundleMcpConfig returns the
  correct config in isolation ✅

The problem:
When OpenClaw runs Gemini CLI in headless
mode (--output-format json --prompt "..."),
the mcp_filesystem_write_file tool is
never available to the agent. Session logs
show the model calls write_file and gets
"Tool not found. Did you mean: read_file,
cli_help, generalist?" — only OpenClaw's
own loopback tools are present.

Root cause we found:
It seems the Gemini CLI in
headless/non-interactive mode doesn't
initialize stdio-based MCP servers (those
defined with command:). Only the HTTP
loopback MCP (openclaw) connects. The
filesystem server requires spawning an npx
process that never gets started.

Question:
What's the correct way to give the agent
write_file access when using
google-gemini-cli as the provider? Should
the filesystem MCP be run as a persistent
HTTP/SSE service instead of a stdio
command:? Is there another supported path
we're missing?

[coarse bridge]

I don’t think you’re missing an OpenClaw config key.

I checked the OpenClaw side, and google-gemini-cli is already wired for this path: it has bundleMcp: true, uses Gemini system settings injection, and merges bundle MCP config into the temp settings.json. Since interactive gemini shows mcp_filesystem_write_file, your bundle itself looks fine.

So the most likely answer is:

• OpenClaw handoff is working
• Gemini CLI headless JSON mode is the weak link
• stdio command: MCP servers are not reliable enough here, especially npx-spawned ones

So yes, if you want to stay on google-gemini-cli, I’d treat persistent remote MCP as the correct workaround:

• prefer Streamable HTTP
• otherwise SSE
• avoid relying on stdio command: for background/headless Gemini runs

Two extra notes:

1. Check native OpenClaw write access too
   OpenClaw’s own file tools can disappear if the agent is effectively read-only (tools.allow/deny, sandbox policy, or read-only workspace access). Seeing read_file but not write/edit can also happen from that side.

2. Cleanest supported path is still the direct google provider
   google-gemini-cli is documented as the unofficial OAuth integration. If you switch to google (API key), tool calling stays inside OpenClaw and you avoid Gemini CLI MCP startup quirks entirely.

Docs:

• https://docs.openclaw.ai/providers/google
• https://docs.openclaw.ai/gateway/cli-backends

Relevant upstream Gemini CLI issues I found:

• stdio subprocess/MCP spawning problems: https://github.com/google-gemini/gemini-cli/issues/13604
• MCP config churn / transport config weirdness: https://github.com/google-gemini/gemini-cli/issues/15551

So my recommendation would be:

1. Best fix: use google instead of google-gemini-cli if possible