Summary
The built-in gh/pr/view filter unconditionally rewrites the user's command to append its own --json number,title,state,author,headRefName,baseRefName,reviewDecision,labels,assignees,milestone,body. When the user has already supplied --json <field> and/or -q/--jq <expr> to extract a specific value, the rewritten command produces output that doesn't match the filter's expected schema, and the JSON-extraction step silently emits an empty template.
Reproduction
# Direct gh — correct boolean output:
$ gh pr view 2337 --json isDraft -q '.isDraft'
true
# Through tokf — empty template, no value:
$ tokf run gh pr view 2337 --json isDraft -q '.isDraft'
🗜️ #
state:
author:
branch: ->
review:
assignees:
labels:
milestone:
--
🗜️ compressed — run `tokf raw 702` for full output
$ tokf raw 702
true
Environment
- tokf 0.2.44 (Homebrew/cargo install on macOS 15, Darwin 25.3.0)
- gh 2.x
- Filter resolved: gh/pr/view [built-in] (confirmed via tokf which "gh pr view 2337 --json isDraft -q '.isDraft'")
Root cause
tokf show gh/pr/view reveals:
command = "gh pr view *"
run = "gh pr view {args} --json number,title,state,author,headRefName,baseRefName,reviewDecision,labels,assignees,milestone,body"
The run rewrite is unconditional. When user args already contain --json isDraft -q '.isDraft', the resulting command becomes:
gh pr view 2337 --json isDraft -q '.isDraft' --json number,title,...
gh's later --json wins (or its behavior is otherwise inconsistent), and -q '.isDraft' extracts a boolean. The JSON-extract step then runs against true, every $.number/$.title/ etc. path resolves to nothing, and the on_success template renders empty fields.
This is especially harmful because:
- The original command's intent (extract a specific boolean/string) is completely destroyed.
- The output silently looks like a real PR with no fields, which is misleading rather than failing loudly.
- Tooling/scripts that pipe gh pr view ... --json X -q '.X' through tokf-wrapped shells (e.g. via the Claude Code hook) get garbage back without any indicator that the filter didn't apply properly.
- This sometimes force the LLM to hallucinate
Summary
The built-in
gh/pr/viewfilter unconditionally rewrites the user's command to append its own--json number,title,state,author,headRefName,baseRefName,reviewDecision,labels,assignees,milestone,body. When the user has already supplied--json <field>and/or-q/--jq <expr>to extract a specific value, the rewritten command produces output that doesn't match the filter's expected schema, and the JSON-extraction step silently emits an empty template.Reproduction
Environment
Root cause
tokf show gh/pr/viewreveals:The run rewrite is unconditional. When user args already contain --json isDraft -q '.isDraft', the resulting command becomes:
gh's later
--jsonwins (or its behavior is otherwise inconsistent), and-q '.isDraft'extracts a boolean. The JSON-extract step then runs against true, every$.number/$.title/etc. path resolves to nothing, and theon_successtemplate renders empty fields.This is especially harmful because: