Skip to content

discover: sudo RTK_DISABLED=1 … is not counted as a bypass when sudo is a transparent prefix #3756

Closed

Description

@KuSh

Summary

Since #2810 the hook no longer rewrites sudo … (see #146): rtk rewrite "sudo docker ps" prints nothing. So in a default configuration sudo RTK_DISABLED=1 docker ps is not a missed saving — dropping the RTK_DISABLED=1 recovers nothing — and rtk discover / rtk gain are right not to count it. They report it as an unhandled sudo … command, which is what it is.

It becomes a real bypass only when the user declared the wrapper transparent (hooks.transparent_prefixes = ["sudo", "sudo -E"]): then sudo docker ps does rewrite, and sudo RTK_DISABLED=1 docker ps is recoverable savings that rtk discover currently misses, because strip_disabled_prefix never sees an RTK_DISABLED= that sits after the wrapper.

What a fix should do

  • Detect the assignment behind a wrapper with an analytics-only peel. strip_disabled_prefix stays as it is: it is shared with the rewrite path (rewrite_segment_inner), and putting sudo back into it reintroduces the sudo rtk … rewrite fix(rewrite): stop rewriting sudo commands (pass them through) #2810 removed.
  • Judge it with would_be_covered_without_bypass, asked about the line the user typed minus the RTK_DISABLED= assignment — wrapper included. Asking about the peeled remainder (docker ps) answers for a command that was never run and reports savings that do not exist.
  • Leave gain's cmd_has_rtk_disabled_prefix on the syntactic check: its warning has no coverage gate (gain: RTK_DISABLED bypass warning counts commands the hook would not have rewritten anyway #4277), so a wrapper-aware peel there can only inflate the percentage.

Tests

  • default config: sudo RTK_DISABLED=1 docker ps and sudo -E RTK_DISABLED=1 docker ps → not counted by discover or gain
  • transparent_prefixes = ["sudo", "sudo -E"]: both → counted by discover
  • RTK_DISABLED=1 docker ps → still counted (regression guard)
  • strip_disabled_prefix("sudo RTK_DISABLED=1 docker ps") still returns an empty prefix, pinning that the shared helper did not change

Related: #4278 covers the wrappers the hook does rewrite through by default (nice, timeout, command), which are genuinely uncounted today. Work in progress in #3808.

Activity

  1. amandeavor commented on Sep 1, 2026

    @amandeavor
    Contributor

    I have submitted PR #3808 adding \strip_disabled_prefix_for_analytics\ to skip leading \sudo\ (and flags) for analytics bypass detection without modifying the shared \strip_disabled_prefix\ helper.

  2. changed the title [-]discover/gain: `sudo RTK_DISABLED=1 …` is not counted as an RTK bypass[/-] [+]discover: `sudo RTK_DISABLED=1 …` is not counted as a bypass when `sudo` is a transparent prefix[/+] on Sep 26, 2026
  3. rtk-wshm-sync-bot commented on Sep 26, 2026

    @rtk-wshm-sync-bot

    wshm · Automated triage by AI

    🔍 Automated Triage

    🐛 Category bug
    🟢 Priority low
    🎯 Confidence 90%

    Summary

    discover/gain miss sudo RTK_DISABLED=1 … as a bypass when sudo is a configured transparent prefix; fix must peel the assignment while judging coverage on the wrapper-included remainder.

    This looks like a simple fix that could be auto-resolved. Repo maintainers can use /wshm fix to attempt it.

    📁 Relevant files
    • src/discover.rs
    • src/gain.rs
    • src/rewrite.rs

    Suggested Actions

    1. Review PR fix(discover): count sudo RTK_DISABLED=1 commands as bypass in analytics #3808, which already implements this fix — verify it matches the spec here
    2. Confirm strip_disabled_prefix is left unchanged per the issue, shared with rewrite_segment_inner
    3. Add the four listed test cases (default config, transparent_prefixes, regression guard, strip_disabled_prefix pin)
    4. Cross-check against discover/gain: RTK_DISABLED= after a wrapper the hook rewrites through (nice, timeout, command) is never counted as a bypass #4278 (sibling issue for nice/timeout/command wrappers) for consistent approach

    Triaged automatically by wshm · This is an automated analysis, not a human review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions