feat: explain tool auto-approval - #12494
Conversation
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
Code Review SummaryStatus: No Issues Found | Recommendation: Merge Previous WARNING is resolved: Files Reviewed (incremental, 24 files)
Previous Review Summary (commit 69960b1)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 69960b1)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
Files Reviewed (19 files)
Reviewed by claude-sonnet-5 · Input: 36 · Output: 13K · Cached: 1.1M Review guidance: REVIEW.md from base branch |
|
What happens when global and project config contribute different patterns under the same permission key? For example, global config has: {
"permission": {
"bash": {
"git status": "allow"
}
}
}And project config has: {
"permission": {
"bash": {
"npm test": "allow"
}
}
} |
Good catch, this was actually a bug. Provenance was tracked per permission key, so both patterns landed under bash and it just reported the last scope ( Fixed by tracking per key + pattern, so we'd now get something like: { bash: { "git status": "global", "npm test": "project" } }for the config you described. |
marius-kilocode
left a comment
marius-kilocode
left a comment
There was a problem hiding this comment.
@bagatao-anaconda please fix the typecheck and manually retest. Then this is good to merge.
…/kilocode into feat/explain-tool-auto-approval
…o-approval feat: explain tool auto-approval
2 participants
Issue
Fixes the issue described here: https://docs.google.com/document/d/1GSiAEQ7DQatMxEmyTplobWtxJWHOs_4OXKtI_3nsDf8/
Context
Users often can't tell why a tool call ran without a prompt — auto-approval can come from agent defaults, global config, project config, or YOLO mode, and the last matching rule wins (not the most specific). This wastes time for users and support.
This surfaces the reason inline: expanding a tool call now shows whether it ran automatically or after your approval, and which rule allowed it — attributed to its source: agent, project config, global config, YOLO mode, or manual.
Implementation
instruction_originspattern.Permission.asknow returns the deciding rule, and a Kilo-ownedPermissionProvenancemodule classifies it (including YOLO and saved-"always" approvals).state.metadata, so it rides existing SSE/SDK plumbing — no schema or route changes. AcarryApprovalhelper keeps the provenance from being clobbered by later tool metadata writes.BasicTool), including the extension's custom bash/todo cards.Scope: backend (opencode) + VS Code webview. TUI/JetBrains are unchanged but the metadata is available to them for a follow-up. Project config is cached per instance and not hot-reloaded on edits (pre-existing behavior), which is now documented in the auto-approve docs.
Screenshots / Video
How to Test
Manual/local verification
Reviewer test steps
echo hi").{ "permission": { "bash": { "echo *": "allow" } } }to.kilo/kilo.json, reload the window, rerun, and confirm the line now cites the project config.ask, approve manually, and confirm it shows Approved by you.Blocked checks and substitute verification
@kilocode/kilo-jetbrains#typecheckcould not run locally (requires JDK 21; only JDK 26 installed). Not touched by this change; CI runs it on a Java 21 runner. All affected packages pass locally:bun test(newprovenance.test.ts/permission-origins.test.ts+ updated permission suites), opencode/ui/kilo-vscode typecheck, lint, knip, and the opencode annotation check.Checklist
Get in Touch