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:
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").- 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.
- 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
- Launch
gemini interactively.
- Switch to YOLO mode (Ctrl+Y) or start with
--yolo.
- Ask the model to run something like
echo hi > /tmp/foo.txt via run_shell_command.
- 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
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.tomlpackages/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)
What happened?
In interactive YOLO mode, the model's
run_shell_commandtool 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:
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_commandinvocations should run without a confirmation prompt, including ones that contain redirection. The "Redirection detected" warning is appropriate fordefault/auto-editmodes 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.tomlcontains a wildcard rule withallowRedirection = true, soPolicyEngine.shouldDowngradeForRedirectionshould returnfalsein YOLO and not downgradeALLOW→ASK_USER.packages/core/src/tools/shell.tsshouldConfirmExecuteshort-circuits tosuper.shouldConfirmExecutewhengetApprovalMode() === ApprovalMode.YOLO.But on the interactive UI side,
packages/cli/src/ui/components/messages/ToolConfirmationMessage.tsxstill does: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 returningASK_USERfor 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:
PolicyEngine.checkShellCommandinpackages/core/src/policy/policy-engine.ts— verify the matched rule for a redirectedrun_shell_commandin YOLO is the YOLO wildcard rule (withallowRedirection: true), not thewrite.tomlrun_shell_commandrule (priority 10,decision = "ask_user").ruleMatches: confirm the YOLO wildcard rule'smodes = ["yolo"]is being matched against the engine's currentapprovalModeafter toggling YOLO inside an interactive session (e.g. via Ctrl+Y), not just when the CLI is launched with--yolo.run_shell_commandever wins over the YOLO wildcard (1.998) — it should, but if persisted, it would lackallowRedirection: trueand would hit the redirection downgrade path.Reproduction
geminiinteractively.--yolo.echo hi > /tmp/foo.txtviarun_shell_command.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
Client Information
Run
geminito enter the interactive CLI, then run the/aboutcommand.CLI version (from local source):
0.42.0-nightly.20260428.g59b2dea0ePlatform: macOS
Login information
N/A — independent of auth.
Anything else we need to know?
Related code:
packages/core/src/policy/policies/yolo.tomlpackages/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)