rtk-ai / rtk-ai/rtk

Claude Code WebFetch/WebSearch tool calls bypass RTK and are invisible in analytics

Open
#2,863 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

area:cli enhancement needs-triage priority:medium
Dominant language
Rust
Stars
81.1k
Forks
5.1k
Avg merge
4d 11h
Merged PRs (30d)
40

Description

Summary

Claude Code's WebFetch / WebSearch tool calls appear to be outside RTK's current savings boundary. They do not go through the Bash hook, are not compressed/tracked by RTK, and are not surfaced by rtk gain, rtk discover, or rtk session as unreachable token sources.

This is related to #538 and #2246, but this issue is specifically about the web tools. Users can reasonably assume that token-heavy web fetch/search results are being optimized, while the current hook/analytics only make Bash reach visible.

Environment

  • RTK: rtk 0.43.0
  • Install: Homebrew on macOS
  • Claude Code hook is installed and healthy:
[ok] Hook: rtk hook claude (native binary command)
[ok] RTK.md: /Users/.../.claude/RTK.md (slim mode)
[ok] Global (~/.claude/CLAUDE.md): @RTK.md reference
[ok] settings.json: RTK hook configured

The configured hook only targets Bash:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "command": "rtk hook claude" }
        ]
      }
    ]
  }
}

Local evidence

From rtk discover:

Scanned: 1181 sessions (last 30 days), 18461 Bash commands
Already using RTK: 135 commands (0.7%)
Total: 6390 commands -> ~1.9M tokens saveable

From rtk gain / the RTK history database:

Total commands: 68654
Input tokens:   42.9M
Output tokens:  18.7M
Tokens saved:   24.1M (56.3%)

Searching the RTK history DB for webfetch, websearch, web_fetch, and web_search found no actual web-tool records. The only match was an ls command over a Claude tool-result directory path containing the word webfetch, not a WebFetch tool invocation. parse_failures also had 0 web-tool matches.

From Claude Code JSONL history on the same machine, actual tool_use counts included:

13946 Bash
 6636 Read
  417 WebSearch
  343 WebFetch
  355 ToolSearch

So at least 760 WebFetch/WebSearch tool calls occurred in the same local history, but RTK's tracking and analytics only account for the Bash side.

Actual behavior

  • WebFetch / WebSearch tool results bypass the rtk hook claude Bash hook.
  • They are not represented in RTK history as saved, missed, or unreachable output.
  • rtk discover and rtk session present Bash adoption/savings, but do not make the non-Bash web-tool boundary visible.

Expected behavior

One of these would make the boundary clear:

  1. Document explicitly that Claude Code WebFetch / WebSearch are outside RTK's savings boundary.
  2. Include WebFetch/WebSearch in a reach/unreachable analysis, possibly as part of #2246.
  3. If Claude Code's hook API can safely intercept non-Bash tool results, add filtering/tracking support for web tool outputs.

I do not think this is a Bash hook bug. It is mainly a coverage/expectation/analytics gap: web tool calls can be token-heavy, but RTK currently cannot save or even report on them.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Claude hook configuration and the rtk hook claude, rtk discover, and rtk session entry points described in the issue. Determine whether non-Bash WebFetch/WebSearch results can be intercepted safely; done means the boundary is documented clearly or the tools are represented in reach, tracking, and analytics without misclassifying Bash data.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
cli, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.