CLI runs `gh auth token` at startup, triggering keyring unlock prompts on Linux

Bug

On Linux, starting the Claude Code CLI shows a GNOME Keyring unlock dialog, and a second one appears when the first prompt is sent. The dialogs come from gh, not from Claude Code's own credential storage: Claude Code runs gh auth token on its own, and gh keeps its token in the system keyring by default. When the keyring is locked (for example, with automatic login), each call shows an unlock dialog.

Nothing tells the user that Claude Code is reading their GitHub token. A keyring dialog that appears at startup with no explanation looks alarming.

Evidence

strace -f -e trace=connect,execve claude:

14385 execve("/usr/bin/gh", ["gh", "auth", "token"], ...) = 0
14388 connect(4, {sa_family=AF_UNIX, sun_path="/run/user/1000/bus"}, 21) = 0

dbus-monitor --session "interface='org.freedesktop.Secret.Service'" shows one Unlock call on /org/freedesktop/secrets/collection/login, from a D-Bus connection opened just before it.

Claude Code's own credentials are in ~/.claude/.credentials.json (plain text on Linux), so they aren't the cause.

Expected

• Don't call gh auth token at startup, or only call it when a feature actually needs a GitHub token (for example, a private marketplace).
• Document the call, and add a setting to turn it off.
• Avoid calls that can prompt (for example, check GH_TOKEN first).

Environment

• Claude Code 2.1.296 (native install)
• Fedora 44, GNOME, gnome-keyring, GDM automatic login (the login keyring is locked at session start)
• gh version 2.97.0 (2026-07-31)

Workaround

gh auth login --insecure-storage, or set GH_TOKEN env variable

Related

#97462 reports the Desktop app running gh auth token undocumented and respawning it. This issue is about the CLI.