gemini-cli - 💡(How to fix) Fix bug: redirection in run_shell_command still prompts for approval in YOLO mode (interactive) [1 comments, 2 participants]

What happened?

In interactive YOLO mode, the model's run_shell_command tool calls that contain a redirection operator (>, >>, <, <<, etc.) still display a confirmation prompt to the user, instead of being auto-approved as YOLO promises.

Example commands observed:

echo "hi" > /tmp/foo.txt
ls -la /tmp/ > /tmp/listing.txt

Both surface the standard tool-confirmation panel with the "Redirection detected. To auto-accept, press <…>" warning line — even though the session is already in YOLO.

What did you expect to happen?

In YOLO mode, all run_shell_command invocations should run without a confirmation prompt, including ones that contain redirection. The "Redirection detected" warning is appropriate for default / auto-edit modes but should be suppressed in YOLO.

Likely root cause (initial investigation)

The shell-tool path looks correct in code:

• packages/core/src/policy/policies/yolo.toml contains a wildcard rule with allowRedirection = true, so PolicyEngine.shouldDowngradeForRedirection should return false in YOLO and not downgrade ALLOW → ASK_USER.
• packages/core/src/tools/shell.ts shouldConfirmExecute short-circuits to super.shouldConfirmExecute when getApprovalMode() === ApprovalMode.YOLO.

But on the interactive UI side, packages/cli/src/ui/components/messages/ToolConfirmationMessage.tsx still does:

const containsRedirection = commandsToDisplay.some((cmd) => hasRedirection(cmd));
const isAutoEdit =
  config.getApprovalMode() === ApprovalMode.YOLO ||
  config.getApprovalMode() === ApprovalMode.AUTO_EDIT;
if (containsRedirection && !isAutoEdit) { ... }

The fact that this branch exists at all implies the confirmation message is being rendered in YOLO. That means somewhere upstream the policy engine (or a higher-priority rule for run_shell_command) is returning ASK_USER for redirected commands even in YOLO, or the policy engine is being constructed without the YOLO wildcard rule applied to the in-session approval mode.

Suggested places to inspect:

1. PolicyEngine.checkShellCommand in packages/core/src/policy/policy-engine.ts — verify the matched rule for a redirected run_shell_command in YOLO is the YOLO wildcard rule (with allowRedirection: true), not the write.toml run_shell_command rule (priority 10, decision = "ask_user").
2. The mode-matching in ruleMatches: confirm the YOLO wildcard rule's modes = ["yolo"] is being matched against the engine's current approvalMode after toggling YOLO inside an interactive session (e.g. via Ctrl+Y), not just when the CLI is launched with --yolo.
3. Whether the dynamic Always-Allow tier (4.95) for run_shell_command ever wins over the YOLO wildcard (1.998) — it should, but if persisted, it would lack allowRedirection: true and would hit the redirection downgrade path.

Reproduction

1. Launch gemini interactively.
2. Switch to YOLO mode (Ctrl+Y) or start with --yolo.
3. Ask the model to run something like echo hi > /tmp/foo.txt via run_shell_command.
4. Observe: a confirmation prompt appears with the "Redirection detected" warning.

Note: Could not reproduce from inside an agent-driven session that was already in YOLO — only via the interactive prompt-driven model loop. The agent's own tool calls were auto-approved with no prompt visible.

Client information

Run gemini to enter the interactive CLI, then run the /about command.

> /about
# paste output here

CLI version (from local source): 0.42.0-nightly.20260428.g59b2dea0e Platform: macOS

Login information

N/A — independent of auth.

Anything else we need to know?

Related code:

• packages/core/src/policy/policies/yolo.toml
• packages/core/src/policy/policy-engine.ts (shouldDowngradeForRedirection, checkShellCommand)
• packages/core/src/tools/shell.ts (shouldConfirmExecute)
• packages/cli/src/ui/components/messages/ToolConfirmationMessage.tsx (renders the "Redirection detected" line)