Repository navigation
Show the queries, not the name of the tool that ran them - #36
Merged
Merged
Conversation
Research works: a run reported eight searches and cited five external sources. The trace listed those eight as the strings "web_search" and "webrun", because the extractor named one field and the query was not in it, so the fallback printed the tool name where a query belongs. Both the worker and the hook now find the query by shape: any string under a query-like key at any reasonable depth, including an input encoded as JSON text rather than an object. Where there genuinely is none, the entry names the fields that were present, so one run corrects the extractor instead of another round of guessing. A permitted call appears in both records, the hook seeing it before it runs and the event stream after. Merging them would have doubled the count the moment the queries became distinct. The hook record wins outright, because it alone sees a refused call and it alone carries the input, and it is deliberately not deduplicated: two identical queries are two searches. One earlier claim is corrected in the source rather than left standing. A refused call emits no event item; a permitted one does. That was drawn from a run whose calls were all blocked. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FxxEQsJEXq9hZmjpNH5PxY
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Research works. A production run reported 8 searches and the review cited 5 external sources. The reviewer is looking things up.
One defect in what it showed. The eight queries rendered as:
Those are tool names, not queries — the extractor named one field, the query wasn't in it, and the fallback printed the tool name where a query belongs. Same mistake as the tool allowlist, one layer over.
Find it by shape
Both the worker and the hook now take any string under a query-like key (
query,q,search,search_query,searchQuery,term,text,input,prompt,url) at any reasonable depth, and handle an input encoded as JSON text rather than an object. Verified against four real shapes:{query: "…"}{action: {search: {q: "…"}}}'{"query": "…"}'(JSON string){searchQuery: "…"}{id, status}— genuinely no queryweb_search (query text not found; fields: id, status)The last row is the point: when there is no query, say so and name the fields that were there, so one run corrects the extractor instead of another round of guessing.
Counted once
A permitted call appears in both records — the hook sees it before it runs, the event stream after. The previous merge deduplicated by text, which silently hid the double-count while every entry was the identical string
web_search; the moment queries became distinct it would have reported 16.The hook record now wins outright (it alone sees a refused call and carries the input), and is deliberately not deduplicated, because two identical queries are two searches.
A correction, in the source
PR #35 claimed Codex never emits an item for a web call. Wrong — that was drawn from a run whose calls were all blocked. A refused call emits no item; a permitted one does. Corrected in the worker comment and
docs/ARCHITECTURE.mdrather than left standing.117 unit tests (116 pass / 1 Windows-only skip), mocked e2e, lint, build clean.
Generated by Claude Code