Part of https://gitlab.com/groups/gitlab-org/-/work_items/23670+. This decides the promotion rule for https://gitlab.com/gitlab-org/gitlab/-/work_items/630345+. ## The decision When a user is in auto mode, which `ask` does it relax to `allow`: only a default `ask` (a tool the admin left unconfigured), or also an `ask` an admin explicitly wrote? **After meeting with @viktomas & @erran, option A makes the most sense. During the discussion, we did note that this is a two way door decision and the logic could be flipped later if need be. We also noted that the UI/UX is going to be most important here to indicate to users/admin what settings are respected by default and what aren't.** --- <details> <summary>Description of options</summary> ## Why it needs deciding now The design does not agree with itself, and nothing on record settles it: - The merged settings copy (`ee/app/assets/javascripts/ai/settings/components/duo_auto_mode_settings.vue` and `app/assets/javascripts/ai/settings/pages/gitlab_duo_settings.vue`) says auto mode lets users "relax governance "Always Ask" rules to "Always Allow" in the IDE and CLI". Read literally, that is Option B. - The ADR draft in https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/21067+ takes no position. It says a tool "the admin's governance requires a human to approve" still prompts, without saying whether a default `ask` counts. - The tool rules UI change in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257458+ is already written assuming Option A ("Auto mode is planned to relax only untouched cells"). - The iteration 2 reviewer agent (https://gitlab.com/gitlab-org/gitlab/-/work_items/628557+) currently acts on every `ask`, explicit or default. If it ships first, it settles this as B by default. ## Option A (recommended) **Auto mode fills silence, it does not overrule.** Only a default `ask` is promoted; an explicit admin `ask` still prompts. The admin gets two controls and one sentence that explains them: leave a tool unconfigured and auto mode may run it; write "ask" and it will always ask you. It is the only version where "the admin's explicit word wins" stays true. It also mirrors a promotion the product already does: on the background surface an `ask` nobody can answer becomes an `allow` (`Ai::ToolRules::Permissions.background_effective`), applied in `ResolutionService#fallback_permission`, which only covers tools with no explicit rule. That precedent is weaker than it looks, because an admin cannot write an explicit `ask` in the Background access column at all (it only accepts allow or deny). The one place an explicit `ask` is ignored today because nobody can answer (foundational flows, https://gitlab.com/gitlab-org/gitlab/-/work_items/630336+) is tracked as a bug, and its proposed fix fails closed rather than allowing. ## Option B **Auto mode overrules an explicit admin ask.** This matches the copy we already shipped and reduces prompts for everyone, but a user switching to auto mode can then undo a rule an admin deliberately wrote. If we choose B we should stop calling the rule "Always ask", because it is not. ## The strongest argument against A `ask` is the default for everything except read-only tools (GitLab reads and read-only MCP tools), and the Tool management tab shows that default as an ordinary "Always ask" value, indistinguishable from one an admin chose. Opening the page and saving does not persist anything (each cell is a dropdown that saves on change, and re-selecting the displayed value is a no-op). But on master a default still becomes an explicit `ask` without anyone meaning it to: - Editing one cell on a project saves the other columns' displayed defaults as explicit values. - A cell changed and changed back (for example to "Always allow", then to "Always ask") stays explicit. - There is no way to reset a cell to its default. Under A, each of these gives an auto mode that silently does nothing for that tool. https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257458+ (open) removes the trap: it adds a "Default" cell state that saves nothing, an "Override" badge on cells set on purpose, and reset to default, and a project edit then saves only the edited cell. ## What changes either way - **Settings copy:** A requires rewriting the shipped copy, which today promises to relax "Always Ask" rules. B requires renaming "Always ask", because it would no longer always ask. - **ADR:** the auto mode ADR has to state the chosen rule, so the copy and the ADR agree. - **Tool rules UI:** https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257458+ assumes A. Under B its Default versus Override distinction has no effect on auto mode. - **Compliance controls:** the drafts https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257503+ and https://gitlab.com/gitlab-org/gitlab/-/merge_requests/257509+ pass when no write or delete tool is "Always allow", treating `ask` as human approval. Under A, auto mode would run default write and delete asks without approval while the control still passes (under B, explicit ones too). The controls need to account for auto mode. - **What auto mode does not do:** the settings page should say it, not just what auto mode does. </details> ## Out of scope Two follow-ups remove the trap above more fully, and both need their own issues: - Scoping consent to privilege groups (auto mode may run file edits, never shell commands). - Giving the rulebook a fourth value meaning "ask, unless auto mode is engaged". https://gitlab.com/gitlab-org/gitlab/-/work_items/628557+ proposes an `auto-mode` governance option along these lines.