docs/host-setup.md prescribes gh auth login --hostname github.com --git-protocol ssh. On the maintainer's Windows host, gh auth status reports:
github.com
✓ Logged in to github.com account ptr727 (keyring)
- Git operations protocol: https
- Token scopes: 'gist', 'read:org', 'repo', 'workflow'
That host is otherwise fully set up: key present, commits signing and verifying locally, gh at 2.97.0, and scripts/host_gate.py exits 0 over all seven declared tools. So this is drift on a host that passes every check the fleet currently runs.
The consequence is quiet rather than loud. gh repo clone and gh pr checkout set an https remote, so a checkout made through gh authenticates by token where every other checkout on that host authenticates by key. Revoking the host's SSH key would not cut that checkout's access, which is the opposite of what the key-based setup is for.
Neither host-setup/linux/setup-github.sh nor the new host-setup/windows/setup-github.ps1 looks at gh at all, so the drift is invisible to both. The new Windows script does report it, as one line in its status output:
GitHub CLI
[ ok ] authenticated as ptr727
[ ] git protocol is ssh, it is https, set it with: gh config set git_protocol ssh
The narrow fix is that same reported line in the Linux script too, so both platforms surface it and neither writes it.
The wider question, worth settling rather than assuming: should --configure set it, or stay a reported gap? Rewriting a working authentication configuration is arguably the operator's call, which is why the Windows script reports and does not act. The Linux script currently touches gh nowhere, and the two should agree either way.
docs/host-setup.mdprescribesgh auth login --hostname github.com --git-protocol ssh. On the maintainer's Windows host,gh auth statusreports:That host is otherwise fully set up: key present, commits signing and verifying locally,
ghat 2.97.0, andscripts/host_gate.pyexits 0 over all seven declared tools. So this is drift on a host that passes every check the fleet currently runs.The consequence is quiet rather than loud.
gh repo cloneandgh pr checkoutset an https remote, so a checkout made throughghauthenticates by token where every other checkout on that host authenticates by key. Revoking the host's SSH key would not cut that checkout's access, which is the opposite of what the key-based setup is for.Neither
host-setup/linux/setup-github.shnor the newhost-setup/windows/setup-github.ps1looks atghat all, so the drift is invisible to both. The new Windows script does report it, as one line in its status output:The narrow fix is that same reported line in the Linux script too, so both platforms surface it and neither writes it.
The wider question, worth settling rather than assuming: should
--configureset it, or stay a reported gap? Rewriting a working authentication configuration is arguably the operator's call, which is why the Windows script reports and does not act. The Linux script currently touchesghnowhere, and the two should agree either way.