Gemini CLI headless: ask_user acts as deny, so paid Sume calls skip

Gemini CLI's policy engine treats a decision of ask_user as deny in non-interactive (headless) mode, because nobody is there to answer the prompt. So if a policy asks before every paid Sume tool, a scripted gemini -p run will never call generate_image; the call is refused rather than approved. To run paid calls headlessly you must allow the specific tool in policy and bound it with Sume's own gates.

The behaviour is from Gemini CLI's Policy engine page, read on 2026-10-02. Sume's gates are from MCP tools and gates and Jobs and results.

What does the policy page say about ask_user?

The page lists three decisions: allow, which executes the tool automatically, deny, which blocks the tool and excludes it from the model's memory, and ask_user, which prompts for confirmation and is treated as deny in non-interactive or headless mode. The practical effect is that an interactive session and a cron job behave differently with the same policy file, and the cron job is the stricter one.

What does that do to a Sume job?

Read tools are unaffected if you allow them: tools_list, mcp_health, jobs_status and jobs_result can run unattended. A paid tool such as generate_image set to ask_user fails the run silently from your point of view, which can look like Sume returning nothing. Check the Gemini CLI output for the refusal before you suspect Sume, and call mcp_health to confirm the connection is fine.

If you do allow a paid tool headlessly, lean on Sume's gates because the human is gone. Every paid call needs a stable idempotency_key, so a retry of the same run does not submit twice. dry_run=true previews a cost, and max_spend_usd caps a call when passed. Use a fresh key per intended generation and the same key only for a retry of that one.

How should I set this up for a scheduled run?

Keep the rule list short and name the tool. A broad mcpName = "*" allow, which the page documents as a wildcard across servers, would also allow every other server's tools.

• Name the server sume, with no underscore, so the policy engine splits the tool name correctly.
• Allow only the tools the job needs, for example generate_image and the job read tools, with toolName set to the simple name.
• Set max_spend_usd in the tool call from your prompt or script so a runaway loop stops at a budget.
• Use an API key from an environment variable for headless auth; OAuth consent needs a browser.

Why not OAuth for a cron job?

Sume's OAuth sign-in happens on a consent page in a browser, and the default grant is read-only. Sume's docs say an API key remains the path for automation that does not speak OAuth, and that an API-key session sees the full tool set. That is also why the key must be kept out of logs and rotated if it leaks.

What does this not cover?

Policy behaviour is Gemini CLI's and may change in a release; nightly builds in particular are moving. This post does not claim anything about how -p handles prompts beyond what the policy page says. If a headless run stops on a paid call, the fix is a narrow allow rule, not trust: true, which Gemini CLI documents as bypassing all confirmation for that server.