fix: unify YOLO and Auto permission mode descriptions across surfaces - #1867
Conversation
Also correct the stale 'afk' mode reference in the built-in MCP config skill guidance of both agent engines.
🦋 Changeset detectedLatest commit: 29d8b3d The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
commit: |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d1b1645c68
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
…oving them The extension-level approval handler auto-approved every request when legacy yolo/afk was on, silently swallowing the sensitive-file, plan-review, and ask-rule prompts the engine yolo mode still sends. Forward every request to the user and let the engine permission mode do the auto-approving, matching TUI and web behavior.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 29d8b3d288
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| value: 'yolo', | ||
| label: 'YOLO', | ||
| description: 'AI decides which actions need your approval.', | ||
| description: 'Auto-approve tool actions, but the agent may still ask questions.', |
There was a problem hiding this comment.
In YOLO mode, exceptional tool actions such as sensitive-file access, plan-exit review, and user-configured ask rules still surface approval prompts before the YOLO auto-approve fallback. Describing it here as auto-approving "tool actions" while only warning that the agent may ask questions can mislead users selecting the mode from this dialog; qualify this as regular tool actions and mention that some approval prompts can still appear.
Useful? React with 👍 / 👎.
- feat(cli): run kimi web and TUI /web in foreground by default (MoonshotAI#1853) - fix: unify YOLO and Auto permission mode descriptions (MoonshotAI#1867) - Resolved conflicts: kept i18n translations, adopted upstream defaultForeground logic - files: run.ts, web-alias.ts, web.ts (merged i18n + foreground semantics)
…MoonshotAI#1867) * fix(tui): correct YOLO and Auto permission mode descriptions * fix: unify YOLO and Auto permission mode descriptions across CLI, ACP, web, and docs * docs: correct YOLO and Auto mode descriptions in the interaction guide * fix: correct YOLO mode notices in session replay and vscode extension * feat(vscode): rename /afk command to /auto, keeping afk as hidden alias Also correct the stale 'afk' mode reference in the built-in MCP config skill guidance of both agent engines. * fix(vscode): forward engine approval requests instead of blanket-approving them The extension-level approval handler auto-approved every request when legacy yolo/afk was on, silently swallowing the sensitive-file, plan-review, and ask-rule prompts the engine yolo mode still sends. Forward every request to the user and let the engine permission mode do the auto-approving, matching TUI and web behavior.
1 participant
Related Issue
No linked issue — the problem is explained below.
Problem
Since the permission policy rework, both agent engines implement the same autonomy ladder:
manual<yolo<auto. YOLO auto-approves regular tool calls but still asks — sensitive files, plan-exit reviews, user-configured ask rules, and the agent may still ask questions. Auto is the fully unattended mode: everything is approved automatically (including sensitive files and plan exits) andAskUserQuestionis denied outright.User-facing copy drifted from that reality, mostly describing an older, inverted mental model in which YOLO "approves everything" and Auto is the milder "approve safe operations" mode. The TUI copy added in #1450 described YOLO as "AI decides which actions need your approval" — a mechanism that exists in neither engine (approval decisions are always made by the policy chain, never by the model). A user reading these descriptions could pick the wrong mode — e.g. choosing Auto believing it is the restrained option, when it is in fact the most permissive.
What changed
Unified every user-facing surface on one accurate wording: YOLO = auto-approve regular tool actions, but the agent may still ask questions; Auto = fully autonomous, the agent never asks.
/permissionselector descriptions and option order (now manual → YOLO → Auto, matching escalating autonomy),/yoloand/autotoggle notices, slash command list descriptions, and the YOLO notice shown during session replay.--yolo/--auto--helptext./afkrenamed to/auto, withafkkept as a hidden alias (still accepted, never shown in the menu); toasts, the/yoloentry, and thekimi.yoloModesetting description corrected. The persistedvscode_legacy_approvalmetadata shape is untouched for session compatibility.default_permission_modeentry, startup-option tables (also added the previously missing--autorow), and the interaction guide's YOLO/Auto section rewritten.Deliberately untouched: the
afk_toggletelemetry event and theafkproperty in CLIsession_started(analytics schema continuity), and legacy migration readingapproval.afk(historical data format).Verification: typecheck for kimi-code, kimi-web, acp-adapter, and the VS Code extension; test suites for the TUI (1620), CLI (478), acp-adapter (306), VS Code (288), and skill-related engine tests — all green.
Checklist
gen-changesetsskill, or this PR needs no changeset. (5 changesets included; docs-only and comment-only changes need none.)gen-docsskill, or this PR needs no doc update. (User docs are updated in this PR itself, en/zh in sync.)