rtk gh pr comment --help outputs `ok commented` — filter discards stdout unconditionally

rtk gh pr comment --help (and rtk gh pr edit --help) output ok commented / ok edited instead of the actual gh help text. The pr_action filter unconditionally discards stdout and synthesizes a confirmation message, regardless of what gh actually produced.

Reproduction

# Raw gh — shows the help text
RTK_DISABLED=1 gh pr comment --help

# Through rtk — just "ok commented"
gh pr comment --help

I reproduced this with rtk 0.37.2 on Windows.

Cause

pr_action runs the gh command and then replaces stdout with ok_confirmation(action, pr_num) — the closure ignores its _stdout argument:

https://github.com/rtk-ai/rtk/blob/80a6fe606f73b19e52b0b330d242e62a6c07be42/src/cmds/git/gh_cmd.rs#L911-L931

gh's help output is thrown away and replaced with "ok {action} #{N}" — with an empty PR number, since --help starts with - and no positional identifier is found.

Both gh pr comment and gh pr edit go through this path:

https://github.com/rtk-ai/rtk/blob/80a6fe606f73b19e52b0b330d242e62a6c07be42/src/cmds/git/gh_cmd.rs#L214-L215

pr_create has a structurally similar pattern — its closure assumes stdout is a PR URL and extracts a number from it. I haven't tested gh pr create --help, but the code would parse help text as a URL:

https://github.com/rtk-ai/rtk/blob/80a6fe606f73b19e52b0b330d242e62a6c07be42/src/cmds/git/gh_cmd.rs#L835-L857

Impact

--help is how agents (and humans) discover what flags a command supports. When RTK replaces help output with a fake confirmation, the agent has no way to learn the right flags — it sees ok commented, concludes the command worked, and moves on. RTK_DISABLED=1 gh <cmd> --help works as a workaround, but the agent only knows to reach for it once something else tips it off that the output is wrong.

Suggestion

should_passthrough_pr_status already treats --help / -h as a passthrough trigger for gh pr status:

https://github.com/rtk-ai/rtk/blob/80a6fe606f73b19e52b0b330d242e62a6c07be42/src/cmds/git/gh_cmd.rs#L305-L312

The same check could be applied before pr_action and pr_create (and possibly other gh subcommands) — when --help or -h is present, passthrough raw so gh can print its own help.

Broader Pattern

This is the same class of bug as #720 and #730 — a filter that doesn't account for a flag silently produces wrong output, and the hook makes it invisible to the AI agent. pr_action goes one step further and fabricates a success confirmation from no data, which is the most misleading variant so far.

Related

• #720 — --comments silently dropped on gh issue/pr view (same class: flag ignored by filter)
• #730 — --name-only produces empty output on gh pr diff (same class: filter applied to non-matching data)

Environment

• rtk 0.37.2
• gh 2.x
• Claude Code
• Windows 11