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

Finding: In a single external report, Claude Code CLI 2.1.296 (native install) on Fedora 44 with GNOME, gnome-keyring and GDM automatic login (login keyring locked at session start) showed a keyring unlock dialog at startup and a second when the first prompt was sent. The reporter attributes the dialogs to gh rather than Claude Code's own credentials (https://github.com/anthropics/claude-code/issues/101036). Reported evidence: strace -f -e trace=connect,execve output shows the claude process tree executing /usr/bin/gh with the arguments auth token, followed by a connection to the session D-Bus socket. The reporter says dbus-monitor on the Secret Service interface showed one Unlock call on the login collection. The reporter also notes that Claude Code's own credentials are in ~/.claude/.credentials.json (plain text on Linux), so they are not the cause. gh version was 2.97.0 (https://github.com/anthropics/claude-code/issues/101036). Interpretation: the reporter's hypothesis is that gh stores its token in the system keyring by default, so each gh auth token call prompts when the keyring is locked. This is the reporter's diagnosis from traces, not a maintainer-confirmed cause. Reporter-suggested mitigation, not verified: run gh auth login --insecure-storage, or set the GH_TOKEN environment variable. The reporter also requests that the CLI avoid calling gh at startup, document the call, add an opt-out setting, or check GH_TOKEN first. These are feature requests, not shipped behavior (https://github.com/anthropics/claude-code/issues/101036). Status: the issue is open, with no supplied comments, maintainer response, fix commit or release. Limitations: one environment, an external report only, and no KFA reproduction. Insecure storage keeps the gh token in plain text, so weigh that tradeoff. A related Desktop-app issue (#97462) is separate.