rtk-ai/rtk

feat(learn): sanitize sensitive data in --write-rules output

Open

#651 opened on Mar 17, 2026

View on GitHub
 (2 comments) (0 reactions) (0 assignees)Rust (2,914 forks)batch import
area:clieffort-mediumenhancementhelp wantedpriority:medium

Repository metrics

Stars
 (48,085 stars)
PR merge metrics
 (Avg merge 11d 1h) (45 merged PRs in 30d)

Description

Problem

rtk learn --write-rules outputs raw command pairs into .claude/rules/cli-corrections.md. These commands often contain sensitive infrastructure identifiers that get auto-loaded into every Claude Code session if the file is committed:

  • AWS resource IDs (vpc-*, sg-*, subnet-*, vpce-*, i-*)
  • AWS account IDs (12-digit numbers in ARN contexts)
  • Route53 hosted zone IDs (Z0...)
  • Absolute paths containing usernames (/Users/john/...)
  • Internal repository URLs with org names

Reproduction

rtk learn --write-rules --since 60
cat .claude/rules/cli-corrections.md
# File contains raw infrastructure IDs, account numbers, file paths with usernames

Impact

The generated rules file is intended to be committed to a repo and auto-loaded by Claude Code. Sensitive data in this file:

  • Leaks infrastructure details into context windows
  • Creates a security risk if the repo is public or shared
  • Requires manual review/editing before every commit, defeating the automation purpose

Proposed Solution

Add regex-based sanitization to report.rs that redacts sensitive patterns before writing:

Pattern Replacement
AWS resource IDs (vpc-0abc123...) vpc-<ID>
AWS account IDs (12-digit in ARN-like context) <ACCOUNT_ID>
Route53 zone IDs Z<ZONE_ID>
Absolute user paths (/Users/name/..., /home/name/...) ~/...
GitHub org/repo in URLs <org>/<repo>

Sanitization should be on by default for --write-rules and available as --sanitize flag for report mode. A --no-sanitize flag would preserve raw output for debugging.

Additional Improvements (same scope)

  1. Bump --min-occurrences default from 1 to 2 — At min-occurrences=1, nearly every correction is a one-off context-dependent retry (e.g., 38 rules from 39 corrections, but only 1 recurs). Default of 2 surfaces genuinely reusable patterns.

  2. Add a noise warning — When >80% of corrections are single-occurrence, print a hint: "Most corrections are single-occurrence. Use --min-occurrences 2 to filter to recurring patterns."

Happy to submit a PR for this. Would target develop per contribution guidelines.

Contributor guide