gemini-cli provider sem tools (gemini-3.1-pro-preview)

[toxic tiger]

OpenClaw 2026.4.14 em WSL2 Ubuntu, gateway
rodando via systemd.

Provider:
google-gemini-cli/gemini-3.1-pro-preview
Canal: Telegram (DM, allowlist)
Workspace: ~/.openclaw/workspace (persona
preenchida, SOUL/IDENTITY/USER)

Agent responde com persona correta, mas
reclama que "tools are read-only".
Confirmação via systemPromptReport do
sessions.json:

  "tools": {
    "listChars": 0,
    "schemaChars": 0,
    "entries": []
  }

Ou seja: o agente recebe zero ferramentas.
A skill gemini (one-shot) não
expõe tool calls.

Perguntas:

1. O provider google-gemini-cli suporta
   tool calling (read_file,
   write_file, list_dir) nesta versão, ou é
   text-only por design?
2. O beta 2026.4.15-beta.1 muda esse
   comportamento?
3. Para ter file edit no workspace, é
   necessário trocar pra provider
   com tools (anthropic/openai) ou existe
   outro caminho nativo gemini?

Bônus: logs mostram spam contínuo do
native-approvals:
[telegram/native-approvals] connect
error: pairing required

Sem device pareado, essa cadeia falha a
cada segundo. É seguro desabilitar
native-approvals pra Telegram enquanto não
uso companion app, ou quebra
outra coisa?

[cinder shadow]

Sim, o que você viu bate com o código atual.

1. google-gemini-cli aí é CLI backend, não provider com tool calls diretos.
   Em docs/gateway/cli-backends.md está explícito: CLI backends são text-only fallback e “OpenClaw tools are not injected directly”.
   E em src/agents/cli-runner/prepare.ts o runner monta o prompt com tools: [], então esse:

"tools": { "entries": [] }

é esperado nesse caminho.

2. O buildProviderToolCompatFamilyHooks("gemini") não contradiz isso.
   Ele é compat de schema para Gemini quando houver tools para normalizar, mas não faz o CLI runner injetar read_file / write_file / list_dir.

3. Existe um caminho “Gemini nativo”, mas é via MCP bridge, não via tool list direta no systemPromptReport.
   O backend Google liga:

• bundleMcp: true

  • bundleMcpMode: "gemini-system-settings"

  Então o OpenClaw escreve config MCP para o Gemini CLI. Ou seja:

  • tool calls diretos do OpenClaw no prompt: não
  • acesso via MCP bridge para o Gemini CLI: sim, em tese

  Então entries: [] não prova ausência total de ferramentas no processo Gemini, só prova ausência de injeção direta.

4. Sobre 2026.4.15-beta.1: eu não vejo evidência de mudança nesse comportamento.
   No ref local não achei tag dessa beta para diff exato, mas do v2026.4.14 até o HEAD não apareceu mudança relevante no caminho de injeção de tools para google-gemini-cli, só refactor de hooks e coisa não relacionada.

Resposta prática à sua pergunta 3

Se você quer file edit confiável no workspace como tool calling do OpenClaw, hoje o caminho seguro é trocar para um provider com tools de primeira classe, tipo Anthropic/OpenAI.

Se quiser ficar no “mundo Gemini”, os caminhos são:

• Gemini CLI via MCP bridge, ou
• Gemini via ACP, como harness externo

mas não espere read_file/write_file/list_dir aparecerem como tools normais no systemPromptReport desse backend CLI.

Bônus, telegram/native-approvals

Sim, é seguro desabilitar enquanto você não usa isso.

Use:

{
  channels: {
    telegram: {
      execApprovals: {
        enabled: false

      }
    }
  }
}

Ou no override por conta:

channels.telegram.accounts.<account>.execApprovals.enabled: false

Pelos docs, isso só desliga o Telegram como native approval client. Não deveria quebrar o resto do canal. As aprovações caem para outras rotas/fallbacks configuradas.

Docs:

• https://docs.openclaw.ai/gateway/cli-backends
• https://docs.openclaw.ai/channels/telegram

• https://docs.openclaw.ai/tools/exec-approvals

Se quiser, eu posso te passar o próximo passo mais útil: como verificar se o MCP bridge do Gemini realmente está subindo no seu WSL2, porque acho que esse é o ponto seguinte a validar.

[toxic tiger]

▎ Pode me guiar na verificação se o MCP
▎ bridge do Gemini está subindo no meu
▎ WSL2?
▎
▎ Setup: OpenClaw 2026.4.14, WSL2 Ubuntu,
▎ gateway systemd. Provider:
▎ google-gemini-cli/gemini-3.1-pro-preview.
▎ Agente respondendo via Telegram com
▎ persona correta, mas
▎ systemPromptReport.tools.entries = [].
▎ Quero verificar se bundleMcp: true está
▎ ativo e se o Gemini CLI está recebendo
▎ tools via MCP bridge.

[cinder shadow]

Sim. E o detalhe mais importante aqui é este:

systemPromptReport.tools.entries = [] não é um bom sinal de falha para esse backend.
No caminho de CLI backend isso fica vazio por design, mesmo quando o MCP bridge estiver OK.

Eu faria em 2 camadas.

1) Check rápido, sem mudar config

No WSL2, rode um destes enquanto dispara uma mensagem de teste no Telegram:

openclaw logs --follow | rg 'agent/cli-backend|google-gemini-cli|mcp loopback|bundle MCP'

ou, se você preferir direto no service:

journalctl --user -u openclaw-gateway.service -f | rg 'agent/cli-backend|google-gemini-cli|mcp loopback|bundle MCP'

Sinais bons

• aparece algo como cli exec: provider=google-gemini-cli

Sinais ruins

• mcp loopback server failed to start: ...
• bundle MCP skipped for ...

Se aparecer cli exec e não aparecer nenhuma dessas warnings, já é um indício de que o caminho está sendo montado.

---

2) Check definitivo, vendo o settings.json que o OpenClaw entrega ao Gemini CLI

Descubra primeiro o binário real do Gemini:

command -v gemini

Agora crie um wrapper temporário:

REAL_GEMINI="$(command -v gemini)"
mkdir -p ~/.local/bin ~/.openclaw/logs

cat > ~/.local/bin/gemini-mcp-debug <<EOF
#!/usr/bin/env bash
set -eu
{

  echo "=== \$(date -Is) ==="
  echo "GEMINI_CLI_SYSTEM_SETTINGS_PATH=\${GEMINI_CLI_SYSTEM_SETTINGS_PATH:-}"
  echo "OPENCLAW_MCP_TOKEN=\${OPENCLAW_MCP_TOKEN:+set}"
  echo "OPENCLAW_MCP_SESSION_KEY=\${OPENCLAW_MCP_SESSION_KEY:-}"
  echo "OPENCLAW_MCP_MESSAGE_CHANNEL=\${OPENCLAW_MCP_MESSAGE_CHANNEL:-}"
  if [ -n "\${GEMINI_CLI_SYSTEM_SETTINGS_PATH:-}" ] && [ -f "\$GEMINI_CLI_SYSTEM_SETTINGS_PATH" ]; then
    echo "--- settings.json ---"
    cat "\$GEMINI_CLI_SYSTEM_SETTINGS_PATH"
    echo
    echo "--- end settings.json ---"
  fi
} >> ~/.openclaw/logs/gemini-mcp-debug.log
exec "$REAL_GEMINI" "\$@"
EOF

chmod +x ~/.local/bin/gemini-mcp-debug

Depois faça override temporário do backend google-gemini-cli para usar esse wrapper, em:

{
  agents: {
    defaults: {
      cliBackends: {
        "google-gemini-cli": {
          command: "/home/SEU_USUARIO/.local/bin/gemini-mcp-debug"
        }
      }
    }

  }
}

Reinicie o gateway:

openclaw gateway restart

Agora dispare uma mensagem de teste no Telegram e olhe o log:

tail -n 80 ~/.openclaw/logs/gemini-mcp-debug.log

3) O que você quer ver nesse log

Se o bridge está sendo injetado, o esperado é algo nessa linha:

• GEMINI_CLI_SYSTEM_SETTINGS_PATH= com um path real
• OPENCLAW_MCP_TOKEN=set
• no settings.json, algo como:

{
  "mcp": {
    "allowed": ["openclaw"]
  },
  "mcpServers": {
    "openclaw": {
      "url": "http://127.0.0.1:PORT/mcp",

      "headers": {
        "Authorization": "Bearer ..."
      }
    }
  }
}

4) Como interpretar

• Se isso aparecer, o bundleMcp: true está ativo e o Gemini CLI está recebendo o MCP bridge.
• Se não aparecer GEMINI_CLI_SYSTEM_SETTINGS_PATH ou não existir mcpServers.openclaw, a injeção falhou antes do Gemini.
• Se aparecer tudo certo e mesmo assim ele continuar “read-only”, então o problema já não é o OpenClaw montar o bridge, e sim o Gemini CLI não estar consumindo esse MCP como você espera, ou estar aplicando política própria de readonly.

Se quiser, cola aqui:

1. a saída do passo 1, e

2. o trecho do gemini-mcp-debug.log com GEMINI_CLI_SYSTEM_SETTINGS_PATH + settings.json

que eu te digo exatamente em qual camada está quebrando.

Docs:

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

Glad that helped! 🎉
If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution.
This helps Answer Overflow index the solution for future users.

[toxic tiger]

1. O MCP bridge está ativo —
   GEMINI_CLI_SYSTEM_SETTINGS_PATH aponta pra
   um settings.json gerado corretamente com
   mcpServers.openclaw e token de sessão.
2. O Gemini CLI está consumindo esse MCP —
   o agente usa sessions_spawn, read_file,
   sessions_history normalmente via
   mcp_openclaw_*.
3. Adicionei
   @modelcontextprotocol/server-filesystem via
   openclaw mcp set filesystem '{...}', mas
   ele não entra no bundle — o settings.json
   gerado mantém "allowed": ["openclaw"] fixo,
   ignorando o servidor que configurei.

Resultado prático: o agente tem read_file e
list_directory (via subagente ACPX), mas
nunca executa write_file diretamente — cai
em loop de sessions_spawn que estoura
timeout.

Pergunta: Existe alguma forma de adicionar
servidores MCP extras (como filesystem) ao
bundle que o OpenClaw injeta no Gemini CLI,
além do servidor openclaw padrão? Ou o
"allowed": ["openclaw"] no settings gerado
é hard-coded e não tem override?

Alternativa que considerei: configurar
diretamente em ~/.gemini/settings.json, mas
o GEMINI_CLI_SYSTEM_SETTINGS_PATH parece
sobrescrever em vez de fazer merge.

[cinder shadow]

Nice, isso estreitou bastante. O comportamento que você viu bate com o código atual.

Resposta curta:

• allowed: ["openclaw"] não é hard-coded.
• Mas openclaw mcp set ... não entra no bundle MCP do CLI runner hoje.
• Para o google-gemini-cli, os extras entram via enabled bundle plugins com .mcp.json, não via mcp.servers da config.

O ponto exato

No CLI runner, o Gemini faz:

1. carrega bundle MCP via loadEnabledBundleMcpConfig(...)
2. depois adiciona o servidor loopback openclaw
3. gera o settings.json com:

"mcp": {
  "allowed": Object.keys(normalizedConfig.mcpServers)
}

Então o allowed é derivado dos servidores carregados, não fixo em "openclaw".

Se só aparece "openclaw", significa que nenhum bundle MCP extra foi carregado.

Por que openclaw mcp set filesystem ... não apareceu

Porque esse caminho grava em mcp.servers da config, e isso é usado no embedded Pi / outros runtimes.

O CLI backend do Gemini não mescla cfg.mcp.servers hoje.
Ele usa só:

• bundle MCP de plugins habilitados

• mais o loopback openclaw

Então, hoje, para esse runtime:

• openclaw mcp set ... → não
• bundle plugin com .mcp.json → sim

Caminho suportado para adicionar filesystem

Crie um bundle plugin mínimo em um diretório de plugins, por exemplo em:

• ~/.openclaw/extensions/<plugin-id>
• ou <workspace>/.openclaw/extensions/<plugin-id>

Exemplo:

~/.openclaw/extensions/fs-bundle/.claude-plugin/plugin.json

{
  "name": "FS Bundle"
}

~/.openclaw/extensions/fs-bundle/.mcp.json

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/home/SEU_USUARIO/.openclaw/workspace"

      ]
    }
  }
}

Depois habilite:

openclaw config set plugins.entries.fs-bundle.enabled true
openclaw gateway restart

Se isso subir, o settings.json gerado para o Gemini deve passar a ter algo como:

"mcp": {
  "allowed": ["filesystem", "openclaw"]
}

Sobre ~/.gemini/settings.json

Sua leitura está certa também.

O OpenClaw não lê automaticamente ~/.gemini/settings.json.
Ele só faz merge com um arquivo base se GEMINI_CLI_SYSTEM_SETTINGS_PATH já estiver setado no ambiente do gateway/processo.

Então:

• editar ~/.gemini/settings.json sozinho → normalmente não entra
• exportar GEMINI_CLI_SYSTEM_SETTINGS_PATH=~/.gemini/settings.json antes do gateway → aí ele usa como base e gera um temp merged