gh repo clone leaves a non-interactively unusable HTTPS origin despite authenticated gh.

Reported (UTC): 2026-07-15 23:51

What was being attempted: clone CodexCoder21Organization/kompile-core with the github-repos skill's recommended command, gh repo clone CodexCoder21Organization/kompile-core /code/workspace/fix1-kompile-core -- --recurse-submodules, then perform the mandatory git fetch origin before building.

What went wrong: the clone itself succeeded, but origin was https://github.com/CodexCoder21Organization/kompile-core.git and git fetch origin failed exactly with: fatal: could not read Username for 'https://github.com': No such device or address. The authenticated gh session was not wired into Git's credential helper.

Impact: the skill says gh repo clone handles authentication automatically, but the resulting checkout cannot perform the mandatory fetch/rebase, push, or normal PR workflow without an undocumented repair.

Workaround used: git remote set-url origin git@github.com:CodexCoder21Organization/kompile-core.git, then use SSH for fetch and push.

Suggested durable fix: have the github-repos skill either configure gh as Git's credential helper before cloning (gh auth setup-git), explicitly request the repository SSH URL, or immediately normalize origin to SSH after clone; update its cloning guidance to guarantee subsequent Git operations work non-interactively.

Production verification — 2026-07-17

Status: STILL EXISTS. The current image still ships gh 2.23.0. A fresh gh repo clone produced an HTTPS origin whose git fetch failed non-interactively, and neither repository-local nor global Git author identity was configured before this audit.

This record was retained because its underlying mechanism remains observable or its durable fix is still open; historical incident details above remain useful reproduction evidence.