gh search subcommand still unhandled by hook in 0.37.2 — appears related to #446

Summary

Despite issue #446 being marked CLOSED COMPLETED on 2026-03-16, rtk hook claude in rtk 0.37.2 (current latest) does not rewrite any gh search ... invocation. As a result, gh search commands run by Claude Code (and other agents) bypass RTK entirely and return raw, uncompressed output to the model.

I cannot find any commit, PR, or CHANGELOG entry that actually added gh search handling, so this may be a "false-completed" close rather than a regression — but I wanted to surface the user-visible behavior either way, since #446 is closed and would otherwise not show up on the bug radar.

Environment

• rtk --version: 0.37.2 (latest, released 2026-04-20)
• OS: macOS Darwin 24.5.0 (arm64)
• Shell: zsh
• Hook registration: rtk hook claude as Claude Code PreToolUse for Bash

Reproduction

Each command was sent to rtk hook claude via the standard PreToolUse JSON envelope:

echo '{"tool_name":"Bash","tool_input":{"command":"<CMD>"}}' | rtk hook claude

A command is "not handled" if the hook returns no updatedInput (no rtk ... rewrite).

gh search family — all variants fail

Input	Hook output
gh search repos foo	(no updatedInput) ❌
gh search issues kubectl	(no updatedInput) ❌
gh search prs claude	(no updatedInput) ❌
gh search code 'function'	(no updatedInput) ❌
gh search commits initial	(no updatedInput) ❌
gh search repos --owner microsoft	(no updatedInput) ❌
gh search repos foo --limit 5	(no updatedInput) ❌

Other gh subcommands — all rewritten correctly (control)

Input	Hook output
gh api repos/foo/bar	rtk gh api repos/foo/bar ✅
gh pr list	rtk gh pr list ✅
gh issue list	rtk gh issue list ✅
gh repo view	rtk gh repo view ✅

Direct invocation works (passthrough)

$ rtk gh search repos foo --limit 1
arobson/rabbot   Deprecated: ...   public   2026-04-18T19:27:01Z

So the binary itself is happy to run rtk gh search (presumably via passthrough). The gap is purely in the hook-side matcher: gh search ... is never rewritten to rtk gh search ....

Why I think this is "false completed" rather than a regression

• gh issue view 446 --json closedByPullRequestsReferences returns [] — no PR closed it
• Searching the master CHANGELOG.md for gh search or #446 returns 0 hits
• All gh CHANGELOG entries reference unrelated subcommands (pr merge, issue view, api, run view, pr diff, ...)

So I don't believe a working implementation ever shipped that later regressed; #446 just appears to have been closed without the work landing.

User impact

In one local 30-day Claude Code session scan (rtk discover, 162 sessions / 5,302 Bash commands), gh search invocations were observed 28 times, all bypassing RTK.

Suggested action

• Reopen #446, or treat this as a fresh hook-coverage issue and close as duplicate of whichever route the maintainers prefer
• Add search to the gh subcommand matcher (next to api, pr, issue, repo, run)