PR #68366: Google Gemini CLI: pass --yolo so non-interactive --prompt invocations expose write/edit tools (#68216)

• Repository: openclaw/openclaw
• Author: neeravmakwana
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/68366

Description (problem / solution / changelog)

Summary

• Problem: Under OpenClaw's google-gemini-cli model provider, the Gemini CLI is driven non-interactively via --prompt, and its default per-tool approval mode silently strips built-in tools that require confirmation (write_file, edit, run_shell_command). The model then truthfully replies that it has no file-writing tool, as reported in #68216 on both Gemini CLI 0.27.3 and 0.38.1.
• Why it matters: agents routed through google-gemini-cli could not write or edit workspace files like IDENTITY.md or SOUL.md, making the backend effectively read-only for any prompt that expected tool use.
• What changed: extensions/google/cli-backend.ts now prepends --yolo to both args and resumeArgs. This mirrors the pattern already used by the Claude CLI backend (--permission-mode bypassPermissions) and the OpenAI Codex CLI backend (--sandbox workspace-write). Doc/fixture/test-helper copies of the default args were updated in lockstep, and a focused regression assertion pins --yolo as the first entry in both arg arrays.
• What did NOT change (scope boundary): no changes to provider hooks, OAuth flow, tool-schema normalization, bundleMcp / gemini-system-settings behavior, OpenClaw's tool-policy pipeline, or the skills/gemini/SKILL.md guidance for manual Gemini invocations.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #68216
• Related #
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: extensions/google/cli-backend.ts registered Gemini CLI defaults that did not include any approval/yolo flag. Under non-interactive --prompt execution on Gemini CLI 0.27.x/0.38.x, destructive built-in tools (write_file, edit, run_shell_command) require a TTY-delivered approval that cannot be answered when OpenClaw pipes the prompt through. Gemini CLI therefore omits those tools from the toolset exposed to the model, which then correctly reports that it has no write_file tool.
• Missing detection / guardrail: the closest existing coverage (resolveCliBackendConfig google-gemini-cli defaults in src/agents/cli-backends.test.ts) locked in the no-yolo args. It asserted shape but did not assert that the non-interactive invocation was actually runnable with tools.
• Contributing context (if known): the Claude and Codex CLI backends already carry their equivalent flag (bypassPermissions and workspace-write), so the fix brings Gemini into parity. The fix deliberately relies on the runtime flag rather than prompt-side guidance.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
• Target test or file: src/agents/cli-backends.test.ts::resolveCliBackendConfig google-gemini-cli defaults
• Scenario the test should lock in: resolveCliBackendConfig("google-gemini-cli") must resolve args and resumeArgs with --yolo as the first entry so non-interactive --prompt runs expose write/edit/shell tools.
• Why this is the smallest reliable guardrail: it asserts the exact config shape that flows into buildCliArgs, and the buildCliArgs + image-path tests in src/agents/cli-runner.helpers.test.ts also lock the same arg ordering as it reaches the executor.
• Existing test that already covers this (if any): none at HEAD — existing tests asserted the broken defaults.
• If no new test is added, why not: N/A; a regression assertion (config.args[0] === "--yolo", config.resumeArgs[0] === "--yolo") was added.

User-visible / Behavior Changes

• google-gemini-cli agent turns can now invoke Gemini CLI's built-in write_file, edit, read_file, run_shell_command, web_fetch, and web_search tools without per-tool approval prompts, restoring parity with the Claude and Codex CLI backends.
• Users who relied on the previous implicit read-only behavior can still override agents.defaults.cliBackends.google-gemini-cli.args in their config to drop --yolo, same as they can override the equivalent Claude/Codex flags today.

Diagram (if applicable)

Before:
openclaw -> spawn `gemini --output-format json --prompt "..."`
         -> Gemini CLI default approval mode prompts for write_file
         -> no TTY to answer -> tool stripped from model
         -> model: "I have no write_file tool"

After:
openclaw -> spawn `gemini --yolo --output-format json --prompt "..."`
         -> Gemini CLI skips per-tool approval (yolo)
         -> write_file / edit / run_shell_command stay in the toolset
         -> model actually edits the requested workspace file

Security Impact (required)

• New permissions/capabilities? No. Gemini CLI's built-in tools were always part of the intended contract for this backend; --yolo only removes the interactive approval gate that cannot be satisfied in non-interactive --prompt mode.
• Secrets/tokens handling changed? No.
• New/changed network calls? No.
• Command/tool execution surface changed? No net change relative to intent. The subprocess CLI's own interactive approval UI was previously the only gate, and it was unreachable from OpenClaw's non-interactive driver, so the practical effect was that tools were silently unavailable rather than genuinely protected. OpenClaw's own tool-policy pipeline (owner-only allowlist, tool-policy rules, sandbox policy, subagent policy, bundled MCP/LSP filtering — see src/agents/tool-policy.ts and #68195) continues to be the runtime authority around CLI-backend sessions; that surface is unchanged by this PR.
• Data access scope changed? No. The CLI subprocess already inherits the workspace trust boundary of the parent OpenClaw process. This PR does not expand that boundary or introduce new filesystem reachability.

Explicit note on security/runtime controls that are unchanged:

• src/agents/tool-policy.ts owner-only/allowlist/deny pipeline — unchanged.
• src/agents/pi-tools.message-provider-policy.ts — unchanged.
• src/cli/exec-policy-cli.ts exec approval gating — unchanged.
• Bundled MCP/LSP owner-only and tool-policy filtering (#68195) — unchanged.
• gemini-system-settings bundle-mcp write path (src/agents/cli-runner/bundle-mcp.ts) — unchanged.
• OAuth/credential handling in extensions/google/oauth*.ts — unchanged.
• No prompt-text-based policy is added or relied on; the behavior change is enforced by the runtime --yolo flag on the subprocess invocation.

Repro + Verification

Environment

• OS: macOS 15 (Darwin 25.3.0); reporter saw it on Kali Linux 6.12
• Runtime/container: Node 22, local openclaw checkout
• Model/provider: google-gemini-cli/gemini-3.1-flash-lite-preview, google-gemini-cli/gemini-2.5-flash
• Integration/channel (if any): N/A (agent turn via the CLI backend path)
• Relevant config (redacted): default agents.defaults.cliBackends.google-gemini-cli (no overrides)

Steps

1. Configure OpenClaw with the google-gemini-cli provider via OAuth.
2. Start an agent turn with a prompt like "Update IDENTITY.md to …".
3. Observe the model's reply.

Expected

• The model uses Gemini CLI's write_file / edit tools to update the file and returns a confirmation.

Actual (before this PR)

• The model replies: "I do not have direct file-writing or shell execution tools available in this environment" / "I do not have a tool available to me (such as write_file) …".

Evidence

• Failing test/log before + passing after

Exact tests run locally on this branch:

• pnpm test src/agents/cli-backends.test.ts src/agents/cli-runner.helpers.test.ts — 2 files, 36 tests passed. Includes the new regression assertion that args[0] and resumeArgs[0] are --yolo.
• pnpm test:extension google — 17 files, 114 tests passed. Covers the bundled Google plugin (provider, CLI backend, OAuth, tool-schema normalization, provider registration contract).
• pnpm test src/agents/cli-runner/bundle-mcp.test.ts — 1 file, 8 tests passed. Covers the gemini-system-settings bundle-mcp path that consumes the same backend config object.
• Pre-commit gate (run by scripts/committer): pnpm check:no-conflict-markers, pnpm tool-display:check, pnpm check:host-env-policy:swift, pnpm tsgo, pnpm lint, pnpm lint:webhook:no-low-level-body-read, pnpm lint:auth:no-pairing-store-group, pnpm lint:auth:pairing-account-scope, pnpm check:import-cycles, pnpm check:madge-import-cycles. All green on the final committed tree.
• pnpm format:check on the six touched files — all formatted.

Before/after the patch, the focused assertions in resolveCliBackendConfig google-gemini-cli defaults flip from asserting the tool-less args to asserting the --yolo-prefixed args, which is the exact regression guard for #68216.

Human Verification (required)

• Verified scenarios:
  • resolveCliBackendConfig("google-gemini-cli") now resolves args[0] === "--yolo" and resumeArgs[0] === "--yolo".
  • buildCliArgs composes the --yolo-prefixed args with --model + image-path injection unchanged.
  • Google extension test suite, CLI-backends default test, and bundle-mcp gemini-system-settings test all pass.
  • Docs listing in docs/gateway/cli-backends.md matches the new runtime defaults and explains why --yolo is passed without hand-waving over the security posture.
• Edge cases checked:
  • bundleMcp: true + gemini-system-settings env seeding still returns the same backend args shape (pass-through from config).
  • resumeArgs parity: --yolo is preserved on the resume path, not only fresh invocations.
  • No prompt-text policy is introduced — the behavior change is entirely in the argv passed to the gemini subprocess.
• What I did not verify:
  • Live end-to-end run against the Gemini OAuth provider (no OAuth session on this host); the fix is behaviorally pinned by the unit regression plus parity with the existing Claude/Codex CLI backends.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes. User overrides in agents.defaults.cliBackends.google-gemini-cli.args still win.
• Config/env changes? No.
• Migration needed? No.

Risks and Mitigations

• Risk: A user who intentionally wanted per-tool confirmation inside the Gemini subprocess will lose that prompt.
  • Mitigation: They can override agents.defaults.cliBackends.google-gemini-cli.args in their config, matching the existing pattern for Claude and Codex. The behavior also lines up with the documented position that OpenClaw's tool-policy pipeline is the runtime authority for CLI-backend sessions.

Note on testing depth: lightly tested (unit + scoped extension + bundle-mcp suites green; no live Gemini OAuth run from this host). Reviewers who can run a live Gemini CLI session with the patched args are welcome to attach a transcript.

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/gateway/cli-backends.md (modified, +44/-2)
• extensions/google/cli-backend.ts (modified, +18/-2)
• src/agents/cli-backends.test.ts (modified, +20/-3)
• src/agents/cli-runner.helpers.test.ts (modified, +4/-3)
• src/agents/cli-runner.test-support.ts (modified, +10/-2)