On Windows gh-aw upgrade can't update gh-aw

[dsyme]

On Windows we get

Checking gh-aw extension version...
ℹ Upgrading gh-aw extension from v0.68.1 to v0.68.3...
[aw]: failed to remove previous extension update state: unlinkat C:\Users\scott\AppData\Local\GitHub CLI\extensions\gh-aw\gh-aw.exe: Access is denied.
X Failed upgrading extension aw: some extensions failed to upgrade
✗ failed to upgrade gh-aw extension
  exit status 1

>gh extension upgrade gh-aw
X Failed upgrading extension aw: unable to retrieve latest version for extension "aw"
>gh extension upgrade github/gh-aw
X Failed upgrading extension aw: unable to retrieve latest version for extension "aw"12 replies

I think on Windows gh-aw upgrade simply can't self- upgrade gh-aw. If it's possible to do it we should fix it, if it's not possible we should handle this more gracefully, telling the user they shold run

gh extension upgrade gh-aw

or, if that doesn't work, try this:

gh extension remove gh-aw
gh extension install github/gh-aw

[ericsciple]

Suspected root cause (from analyzing cli/cli + gh-aw source). Filed separately as #27272 before I saw this one; closing that as a duplicate and moving the analysis here.

Two things compound:

1. cli/cli destructively wipes the install directory on Windows

cli/cli pkg/cmd/extension/manager.go calls cleanExtensionUpdateDir at the start of every install/upgrade/remove:

func (m *Manager) cleanExtensionUpdateDir(name string) error {
    if err := os.RemoveAll(m.UpdateDir(name)); err != nil {
        return fmt.Errorf("failed to remove previous extension update state: %w", err)
    }
    return nil
}

UpdateDir = StateDir()/extensions/<name>, installDir = DataDir()/extensions/<name>. On Linux/macOS XDG splits these, but on Windows go-gh/pkg/config resolves both StateDir() and DataDir() to %LOCALAPPDATA%\GitHub CLI, so the two paths collide. os.RemoveAll then walks the installed extension's own folder, deleting the non-locked files (notably manifest.yml, written by writeManifest(targetDir, ...) in the same manager.go) and finally erroring out on the running gh-aw.exe with Access is denied. That's exactly Scott's first error.

Because manifest.yml is already gone, the follow-up gh extension upgrade gh-aw hits:

if latestVersion := f.LatestVersion(); latestVersion == "" {
    return fmt.Errorf("unable to retrieve latest version for extension %q", name)
}

— which is the second error (extension "aw" comes from normalizeExtension short-name handling). Not SAML. Reinstall fixes it because install rewrites the manifest. Probably introduced by cli/cli#9934.

2. gh-aw's rename+retry workaround is gated to Linux

pkg/cli/update_extension_check.go already has the right idea for Linux (ETXTBSY) — rename the running binary to .bak, retry gh extension upgrade, restore on failure — but bails on anything else:

if runtime.GOOS != "linux" {
    return false, "", fmt.Errorf("failed to upgrade gh-aw extension: %w", firstErr)
}

Windows has the same problem class and is actually more amenable: NTFS allows renaming a running executable, and Go's os.Rename maps to MoveFileEx which works on locked binaries.

Caveat on the fix order

The damage (manifest wipe) happens inside cli/cli's cleanExtensionUpdateDir before the binary write, so a purely reactive retry after the first gh extension upgrade failure isn't enough — by the time we retry, the manifest is already gone and gh extension upgrade can't resolve the repo. On Windows we'd want to:

1. Lift the Linux-only gate.
2. Rename gh-aw.exe → gh-aw.exe.bak proactively (before the first gh extension upgrade call), so RemoveAll doesn't hit a locked file and abort.
3. Snapshot manifest.yml before invoking upgrade and restore it if upgrade fails, so a failed self-upgrade doesn't leave users needing remove && install.
4. If all else fails, surface a clear actionable error pointing at gh extension remove gh-aw && gh extension install github/gh-aw.

Follow-up

Worth filing a companion issue in cli/cli: on Windows, UpdateDir collides with installDir, so cleanExtensionUpdateDir destructively wipes the installed extension's folder. Fixing it there (e.g. put update state under StateDir/extension-updates/..., or skip the wipe when the paths are equal, or only remove the specific state JSON) would eliminate this failure mode for every binary extension, not just gh-aw.