Set GitHub CLI Defaults Without Losing Track of Them

gh config set changes a GitHub CLI default for good, so the habit that saves you is reading the old value back before you overwrite it. This covers changing a setting, confirming what was saved, and keeping host-specific settings separate from global defaults. Allow about five minutes for a single change. This guide uses the installed GitHub CLI 2.87.3 on Linux; check your own version if a script must work across machines.

1. Check the command before changing anything

Start by confirming which executable you will run and reading its local syntax. No elevated privileges are needed for a normal per-user configuration change.

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)
$ gh config set --help
Update configuration with a value for the given key

The command takes a key, a value and optional flags:

gh config set <key> <value> [flags]

Keep the key and value as separate shell arguments. Quote a value when it contains spaces, such as an editor command. Do not put an untrusted string into a shell command and expect gh to validate it for you.

2. Record the current value

Configuration changes replace the existing value. The manual does not provide an undo flag, so record the old value before changing a setting you may need to restore. gh config get reads the current value without editing it.

$ gh config get editor
vim

If the key has not been set, the result may be empty. That is different from a value such as vim, and it can mean that gh will fall back to another source such as the environment. Save the exact old value, including whether it was blank, before continuing.

3. Set a global value

Set the editor used by GitHub CLI commands that open text. The value below contains no spaces, so it needs no extra quoting:

$ gh config set editor vim
$ gh config get editor
vim

A successful gh config set normally prints no confirmation text. Use the follow-up get command as the checkpoint. If the command fails, do not assume a partial change: run gh config get editor and inspect the error before retrying.

For an editor command with an argument, quote the complete value so the shell passes it as one argument:

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

This stores the command string for GitHub CLI to use. It does not install Visual Studio Code, check that the executable exists, or make an editor available to other programs.

4. Change a supported setting deliberately

The installed command recognises settings including git_protocol, editor, prompt, pager, browser and accessibility-related options. Values with documented choices should use those choices exactly.

For example, disable interactive prompting only when non-interactive behaviour is what you want:

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

Commands that need an answer may then fail or behave differently when run without a terminal. Restore the normal default with:

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

For a pager, an empty value allows the environment to decide what happens; setting cat disables paging according to the installed configuration help. Treat changes to prompts, editors and browsers as workflow changes, not cosmetic preferences.

5. Set a value for one GitHub host

Use --host when a setting belongs to one host rather than your general GitHub CLI configuration. This is useful for a GitHub Enterprise Server hostname or for making the Git transport explicit for one host.

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

The host name is data, not a label to guess. Use the exact hostname that appears in your authentication and repository URLs. A host-specific value should not be assumed to change the global value, so verify the scope you intended.

The setting changes how later GitHub CLI operations obtain Git URLs. It does not convert existing repository remotes and does not create SSH keys. Check the current repository separately with git remote -v before expecting a clone or checkout to use SSH.

6. Inspect the final configuration

Use gh config list when you need to review several settings together:

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

The exact list depends on the settings already present and the installed release. Blank entries are meaningful defaults or fallbacks, not evidence that the command ignored the setting. Use gh config list --host HOSTNAME when checking a host-specific view.

7. Recover from a mistaken change

There is no separate delete or undo operation in gh config set. Restore the value you recorded in step 2 by setting it again:

$ gh config set editor vim
$ gh config get editor
vim

If the previous value was blank, use the configuration editor or the supported configuration command for your installed release rather than inventing a placeholder value. First run gh config list and gh config set --help to establish what this version supports.

Do not use sudo gh config set to fix a per-user setting. It can write configuration for a different account, leaving your own GitHub CLI unchanged and making the problem harder to diagnose. Use elevated privileges only when an administrator has explicitly asked you to configure a separate system account, and verify that account's configuration afterwards.

8. Avoid the common traps

Done means