Set gh's Git Protocol and Prompt Behaviour Safely

A GitHub CLI setting quietly flips your Git transport from HTTPS to SSH, and half an hour later a clone fails on a machine with no SSH key. gh config is where that setting, and every other GitHub CLI preference, lives, and this guide covers the ones most likely to affect scripts and interactive work: the Git transport, prompting, pagers, editors and host-specific values. It uses GitHub CLI 2.87.3, the version reported by gh --version on the machine used for this guide.

Allow about ten minutes. You need gh on your PATH and an ordinary shell. You do not need sudo: these settings belong to your user configuration. Before changing a real configuration, record its current value. A setting change is persistent, but it does not alter a repository or a GitHub account.

1. Check the installed command

Confirm which executable will receive your configuration commands and read the local command help:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh config --help

The exact path and release date can differ on another host. The useful check is that the command is the GitHub CLI you intend to configure. The gh config command manages values such as git_protocol, editor, prompt, pager, http_unix_socket and browser. Recent releases also show accessibility, colour and spinner settings in the help output.

Checkpoint: Stop here if command -v gh points to an unexpected installation, or if the version is different from the one you are documenting for a script.

2. Inspect the current configuration

List the effective configuration values before changing anything:

$ gh config list
git_protocol=https
editor=
prompt=enabled
prefer_editor_prompt=disabled
pager=
http_unix_socket=
browser=
color_labels=disabled
accessible_colors=disabled
accessible_prompter=disabled
spinner=enabled

Your list can contain different values, aliases or host-related entries. Empty values are meaningful. For example, an empty editor, pager or browser tells gh to consult the relevant environment or platform behaviour rather than naming a program here. The defaults shown by this installation are HTTPS Git operations and enabled prompts.

To inspect one value, use get:

$ gh config get git_protocol
https
$ gh config get prompt
enabled

A missing or misspelled key is an error, not a useful way to discover settings. Use gh config --help when you need the supported list for the installed release.

3. Change the Git transport deliberately

Set SSH only when SSH authentication and a usable key are already working for the GitHub host. This changes the URLs used for later clone and push operations; it does not convert existing remotes. Record the old value first:

$ old_protocol=$(gh config get git_protocol)
$ printf 'previous protocol: %s\n' "$old_protocol"
previous protocol: https
$ gh config set git_protocol ssh
$ gh config get git_protocol
ssh

The accepted values are https and ssh. If SSH is not ready, restore HTTPS before troubleshooting repository operations:

$ gh config set git_protocol https
$ gh config get git_protocol
https

Warning: Do not infer that a successful config set proves authentication works. Test the transport separately, and keep an existing working remote untouched until you have checked the new workflow. If you only wanted to change one repository, changing this global CLI setting is broader than necessary.

4. Control prompts for interactive and unattended use

Interactive prompts are enabled by default. Disable them when a controlled, non-interactive job must fail rather than wait for input:

$ gh config set prompt disabled
$ gh config get prompt
disabled

This is a behaviour change with operational consequences. A command that previously asked for confirmation may now return an error. Do not set this casually in a shared shell profile, and do not treat it as a substitute for supplying required inputs or credentials safely.

Restore the normal interactive behaviour when you return to terminal work:

$ gh config set prompt enabled
$ gh config get prompt
enabled

The separate prefer_editor_prompt setting controls whether editor-based prompting is preferred where supported. Set it only after checking that your configured editor can start and return correctly.

5. Set an editor or pager without breaking scripts

Use a quoted value when the program needs arguments. For example, this selects an editor that waits for the file to be closed:

$ gh config set editor "code --wait"
$ gh config get editor
code --wait

That example is safe to store only if code is installed and available to the same user. An editor that exits immediately can leave a title or description empty, while a missing editor can make a command fail at the point where it needs text.

A pager can make long output easier to read. Set it to a real program, or set it to cat to disable paging:

$ gh config set pager cat
$ gh config get pager
cat

Do not put a pager into configuration for a machine-readable pipeline unless you have tested the exact command. A pager can consume input, wait for a terminal or add behaviour that is surprising in automation. Empty the setting to return control to the environment:

$ gh config set pager ""
$ gh config get pager

The second command should print an empty value. The same empty-value technique applies to the editor and browser when you want to remove a value, but verify the resulting fallback on your installation.

6. Use a host-specific value when the scope matters

Some settings can be stored for one GitHub host rather than globally. The set, get and list subcommands accept --host:

$ gh config set git_protocol ssh --host github.example.com
$ gh config get git_protocol --host github.example.com
ssh
$ gh config list --host github.example.com

Replace github.example.com with the exact host used by your GitHub Enterprise Server. Do not use a URL with a scheme or path. A host-specific value lets another host keep its existing setting, which is usually safer than changing the global transport for a mixed environment.

Checkpoint: Compare the host-specific result with gh config get git_protocol. If the two values differ, that is expected scope, not a failed write.

7. Clear the CLI cache only when you have a reason

gh config clear-cache clears the GitHub CLI cache. It is not a general configuration reset and it does not undo values written by config set:

$ gh config clear-cache

Use it for a known stale-cache problem, then repeat the command that exposed the problem. Do not add it to routine scripts merely because it is available. Cache deletion may force later commands to fetch data again, and it will not repair a bad token, an incorrect host or an invalid editor.

Done means