Warn when a Bash(rtk:*) allow rule is present #4649

Activity

1. rtk-wshm-sync-bot

   added

   area:cli

   area:security

   enhancementNew feature or requestNew feature or request

   priority:medium

   on Oct 18, 2026
2. rtk-wshm-sync-bot commented on Oct 18, 2026

   

   rtk-wshm-sync-botBot

   on Oct 18, 2026 – with rtk-wshm-sync-bot

   More actions

   wshm · Automated triage by AI

   🔍 Automated Triage

   ✨ Category	feature
   🟡 Priority	medium
   🎯 Confidence	82%

   Summary

   Request to warn on overly broad Bash(rtk:*) allow rules in rtk init/verify, since they silently grant all rtk-filtered commands despite deny/ask rules intending to restrict them.

   📁 Relevant files

   • src/init/mod.rs
   • src/hook/verify.rs
   • src/discover/registry.rs

   Suggested Actions

   1. Coordinate with Permission verdict is computed on a command that is not the one that runs — a model-authored rtk prefix escapes the host allowlist #3970 (rtk-prefix verdict) and fix(hooks): honor permission rules for already-rtk-prefixed commands #3195 (fix under review) before implementing the warning
   2. Reuse settings-file parsing from fix(uninstall): strip stale rtk permission rules from settings.json #4128 (uninstall cleanup of Bash(rtk …) rules) for detecting the rule
   3. Define the exact match logic for 'allow rule matches every rtk … command' across Bash(rtk:*) and Bash(rtk *) syntaxes
   4. Add warning output to both rtk init (install/upgrade) and rtk verify per the proposed message format

   ---

   Triaged automatically by wshm · This is an automated analysis, not a human review.
3. xiaozou-second commented on Oct 21, 2026

   

   xiaozou-second

   on Oct 21, 2026

   More actions

   I'd like to take this one.

   Plan. rtk init (install and upgrade) and rtk verify print a one-line stderr warning naming the rule and the settings file whenever a loaded Bash(...) allow rule reduces to the bare command name — Bash(rtk:*), Bash(rtk *), Bash(rtk), Bash(*rtk*). The hook path (rtk hook <agent>, rtk rewrite) stays silent, as you ask. --dry-run and init --show stay silent too; the warning is an advisory at the point the user can act on it.

   Two readings I'd like settled before opening the PR, since the issue says "matches every rtk … command":

   • Bash(*) — grants every command rtk filters, but it isn't rtk-specific, and "consider narrower rules such as Bash(rtk git status:*)" is misleading advice for someone who deliberately allowed everything. I lean towards not flagging it.
   • Bash(rtk git:*) — covers rtk git push but not rtk cargo test. The literal wording says it does not match every rtk command, so I lean towards not flagging it either. Flagging it would catch the headline risk but the message would overstate what the rule grants.

   A prefix test on the pattern (strip Bash(, ), then */:/whitespace, compare to rtk) gets both readings without a glob matcher, and keeps Bash(rtk git push) — the example the warning itself names — out of the warning.

   On the premise: #3970 and #3195 are both still open, so the warning's wording describes the exposure as it stands today rather than after a fix. Happy to hedge the text if you'd rather it read that way.

   ~80 lines including unit tests for both spellings. Will link the PR here once it's up.