rtk proxy returns stale/incorrect git + filesystem state (caching not bypassed)

[oluies]

Summary

rtk (including rtk proxy, documented as "execute raw command without filtering") returns stale / incorrect results for filesystem and git commands. Output diverges from what the underlying binaries report when invoked by absolute path. Because the wrong output looks like a normal clean result, it silently misleads — I committed a doc change, and rtk-routed git status/git log/grep all reported the working tree was clean and the change was absent, while the file was in fact modified on disk and the commit had not happened.

This is a correctness bug, not a verbosity/cosmetic one: rtk proxy is the documented escape hatch for unfiltered execution, and it was also wrong.

Environment

• rtk 0.42.0 (/opt/homebrew/bin/rtk, Homebrew)
• macOS, Darwin 25.5.0 arm64
• Used as a Claude Code Bash hook that rewrites git ... → rtk git ...

Observed behavior

In a git worktree (.../.worktrees/task/..., branch chore/archive-nightly-stress):

1. Modified README.md (added 7 lines) and ran a commit + push through rtk-routed git.
2. rtk git commit reported ok (nothing to commit).
3. rtk git status --short → empty (clean).
4. rtk git log --oneline → HEAD unchanged, no new commit.
5. rtk proxy grep -c badge README.md → 0 (no match).
6. rtk proxy git diff -- README.md → 0 lines.
7. rtk proxy git show HEAD:README.md | grep -c badge → 0.

All of the above said "nothing changed."

Expected behavior (ground truth via absolute-path binaries)

Calling the real binaries directly — /usr/bin/git, /usr/bin/grep, /usr/bin/sed — bypassing the rtk hook:

• /usr/bin/sed -n '1,6p' README.md → showed the original content (so disk truly had no badges at that point), confirming the file state.
• After writing the change via /usr/bin/python3, /usr/bin/grep -c badge README.md → 6.
• /usr/bin/git add/commit/push → succeeded, new commit 41fcd66, pushed cleanly.

The divergence: rtk proxy reported state that did not match what the same command returns when run directly, even though proxy is documented as unfiltered.

Hypothesis (root cause)

It looks like rtk caches and returns stale filesystem + git state, and the cache is consulted (or staleness is served) even under rtk proxy. A worktree context and/or a write that happened outside rtk's view appears to leave the cache out of sync, after which rtk keeps answering from the stale snapshot instead of re-reading from disk. The fact that proxy — the documented "raw, no filtering" path — also returned the stale result suggests the caching layer sits above the proxy bypass rather than below it.

Impact

Silent, high-trust failure mode: an agent or user relying on rtk git status/log/diff to verify work will believe a change didn't land (or did land) when the opposite is true. This can cause duplicate work, lost commits, or commits to the wrong state. Worktrees seem especially prone.

Suggested fixes

• Ensure rtk proxy <cmd> truly bypasses any caching layer (exec the underlying binary and stream its real output).
• Invalidate/skip cache for git state-mutating and state-reporting commands (status, diff, log, show, commit, add), and for grep/file reads when the target file mtime changes.
• Detect git worktrees and disable caching (or key the cache on the resolved worktree + HEAD) so worktree state isn't confused with the main checkout.

Repro sketch

# in a git worktree
echo "new line" >> README.md
rtk git status --short        # may report clean / stale
rtk proxy git diff -- README.md   # may report 0 lines
/usr/bin/git status --short   # ground truth: shows the modification

[pszymkowiak]

wshm · Automated triage by AI

🔍 Automated Triage

🐛 Category	bug
🟠 Priority	high
🎯 Confidence	91%

Summary

rtk proxy returns stale cached git/filesystem state even on the documented unfiltered path; caching layer sits above the proxy bypass, silently misleading agents about commit and file state.

---

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