Repository navigation
Allow for standardized output format #385
Description
Activity
I haven't used it yet, but the provided example output would steer me away from ever using this. If I can't parse the output with standard tools, I can't easily leverage it in my own scripts, and therefore its utility is minimal.
In all honesty I'd take a column based approach that I can
awkeasily in all cases - any other standardized output as proposed is also welcome.Reacted by M. de Verteuil, Adin Klotz, JanRK, Shay Osler and Egon Braun@lucasyvas I don't know about your definition of "standard", but
jqis pretty great.Reacted by ITC-tharris, Tripp Lilley, Thomas Gunsch, Danny Fowler and Varun Chandak@lucasyvas I don't know about your definition of "standard", but
jqis pretty great.I agree it is standard - and I love
jq! I was merely saying I would even be ok with something merely "familiar" that could be piped and processed easily with other tools likeawk. JSON would be a totally fine option and I love command line tools that offer it.@lucasyvas oh, right, you were talking about the tool's current output, not the proposed JSON output. Yeah, agreed, everything seems very geared toward an interactive workflow.
@lucasyvas I hear you. We do intend to have more scripting interfaces— for example, even though the default output of
gh issue/pr listhas color, table-based layout, and truncation adjusting to the size of the viewport, when you pipe that command to a file or a script, we switch to a machine-parseable mode: no color, tab delimiters, and no truncation.Right now we didn't know how to best achieve this with the output of
issue/pr statusas it has sections, but as we understand more about what kind of information would people want to extract in their scripts, we will offer some more easily parseable interfaces. In my opinion, that's almost the whole point of CLI tools.I came looking for this issue because I would like to import Github issues into TaskLite. It can import JSON or I can just pipe stuff into it. When piping there is the
Issues for $org/$repofirst which makes fzf glitch a little. Perhaps this part should be left out when piping.Exporting JSON would be ideal in this case because then TaskLite can import more information as metadata, and I can more easily turn issue labels into Tasklite tags.
Reacted by Mislav Marohnić@lucasyvas I hear you. We do intend to have more scripting interfaces— for example, even though the default output of
gh issue/pr listhas color, table-based layout, and truncation adjusting to the size of the viewport, when you pipe that command to a file or a script, we switch to a machine-parseable mode: no color, tab delimiters, and no truncation.Right now we didn't know how to best achieve this with the output of
issue/pr statusas it has sections, but as we understand more about what kind of information would people want to extract in their scripts, we will offer some more easily parseable interfaces. In my opinion, that's almost the whole point of CLI tools.It's completely fair - you can't do everything at once. Just hoping to call it out for some others I've seen mention it as well - having some more raw output options could make the utility extremely attractive beyond the core hard work that has already been put in.
Reacted by Mislav Marohnić and Carlo Alberto FerrarisWhen piping there is the
Issues for $org/$repofirst which makes fzf glitch a little. Perhaps this part should be left out when piping.@hkrutzer Not a bad idea. For now, you can manually silence stderr (
2>/dev/null) when piping to work around this.Has there been any update on this? It would be extremely helpful since it would allow for developers to create native wrappers around it for language specific implementations.
Reacted by Tripp Lilley@ddonahoevibrenthealth We will start work on this from next week. 👍
Reacted by Joel Langlois, Brendan McAndrew, funrun11, Paul Plavetzki, Tripp Lilley, Sergey Ryabin, Thomas Gunsch, Joe Sharp, Eric Johnson, miheer vaidya and 2 moreOutput seems to be awk-friendly with "\t" as field separator
function gh__issues { fzfSelected=$(gh issue list -R "$1" | fzf ) fzfResult="$?" if [ "$fzfResult" = "0" -a -n "$fzfSelected" ]; then gh issue view -R "$1" "$(echo "$fzfSelected" | awk -F "\t" '{print $1}')" fi }
no matter how the json is formatted it would be nice to have to be able to use it in scripts and CI scripts, this tool is really great.
I thought automation was a primary goal of this tool but it looks like I was wrong :/Reacted by Joe SharpI thought automation was a primary goal of this tool but it looks like I was wrong :/
I won't speak for the devs on what the primary goal of this tool is but @mislav said they would be starting on this feature request this week. Were you possibly thinking they closed this issue due to the references above your comment that were closed as duplicates of this issue?
No, I know this issue was not closed but I just don't understand why json output was not a feature from the start (and it would have been probably easier to do that way than to do another pass on every command).
I saw the comment saying work on this would be started this week but that was on December 1st, a month ago, I am sure this will eventually happen but I am just really disappointed.@schmurfy you can already get whatever you want with
gh apiand format that however you like withjq@vatosarmat thanks for the tip, I will use that.
@schmurfy @joe-sharp The next release will be geared mostly towards more features for scripting. Stay tuned!
but I just don't understand why json output was not a feature from the start
Anything that we publish as output from any
ghcommand automatically becomes the API of GitHub CLI. The bigger any API is, the harder it is to maintain. We couldn't just publish JSON output from every command because, that early on, we couldn't also guarantee that we wouldn't have to change the structure of that raw data.Right now, the main API to GitHub is still the GitHub API, and you have relatively easy access to it using the
gh apicommand. But, we will make accessing all kinds of raw fields easier in the next release. 👍Reacted by Cristian Dominguez, Julien Ammous, Roz, Chad Roberts, Ross Edman and Tomochika HaraWhat would be really nice for automation would be if at least all list commands like the Azure
azcli had an output option
A really Powerful feature ofazis that you can everywhere get machine consumable output
--output -o : Output format. Allowed values: json, jsonc, none, table, tsv, yaml, yamlcand you can even query - filter and adapt the output
--query : JMESPath query string. See http://jmespath.org/ for more information and examples.this is super handy, especially in DevOps scenarios.
Reacted by Mislav Marohnić and danielI was looking for an issue matching what behavior I was interested in but this is the closest I saw. In addition to standard output formats, how about bringing back the behavior of
hubwhere you could specify an output format? I used to use hub for generating audit reports from various repos but this project makes pulling the audit data much easier. It would be nice if there was also an easy way to manually format the results in a way that it could be easily ingested into a log aggregator.@cardonator hub's
--formatstring was modeled after git log format syntax, but the syntax was hard to read and to author. GitHub CLI is not modeled after git at all, so we can invent our own approach. We're coming up with something better 👌@mislav awesome! Thanks!
Closing since the
--jsonflag is now available on most commands that list or view data. 🎉The few commands that still miss the
--jsonflag will be added time-permitting. (But we accept contributions!)Thank you all for the patience!
Reacted by Dan Fockler, BJ Cardon, Tom Thorogood, Julien Ammous, Marc Litchfield and Maciej Gawinecki- added a commit that references this issue
on Jul 21, 2025
Describe the feature or problem you’d like to solve
I think having a way to output the results of the CLI comands to JSON or some other standardized output format would be a nice way to let users extend functionality without having to change the CLI code very much.
Proposed solution
Something like
Users could then easily parse this and perform other actions using the data.
Additional context
My initial thought was using this to be able to automatically open the issue I'm working on in JIRA by extracting the JIRA tag number from our titles, but it could also be useful for other workflows.