Skip to content

Revert pwsh preference for Windows upgrades#487

Merged
svarlamov merged 1 commit intomainfrom
codex/create-nightly-github-action-for-git-ai-versions
Feb 8, 2026
Merged

Revert pwsh preference for Windows upgrades#487
svarlamov merged 1 commit intomainfrom
codex/create-nightly-github-action-for-git-ai-versions

Conversation

@svarlamov
Copy link
Copy Markdown
Member

@svarlamov svarlamov commented Feb 8, 2026

Motivation

  • Simplify Windows upgrade behavior by reverting the pwsh-first spawn logic because the PowerShell checksum fallback implemented in install.ps1 removes the need to prefer pwsh.

Description

  • Remove the spawn_powershell closure that tried pwsh then powershell and instead invoke powershell directly via Command::new("powershell") while keeping -NoProfile, -ExecutionPolicy Bypass, -Command, CREATE_NO_WINDOW, the GIT_AI_RELEASE_ENV env var, and the silent stdout/stderr behavior.

Testing

  • No automated tests were run as part of this change (CI/integration validation is expected to run in workflows).

Codex Task


Open with Devin

@svarlamov svarlamov merged commit feda80e into main Feb 8, 2026
8 checks passed
@svarlamov svarlamov deleted the codex/create-nightly-github-action-for-git-ai-versions branch February 8, 2026 19:10
Copy link
Copy Markdown
Contributor

@devin-ai-integration devin-ai-integration Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

View 4 additional findings in Devin Review.

Open in Devin Review

Comment thread install.ps1
Comment on lines +88 to +90
if ($sha256) {
$sha256.Dispose()
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Accessing potentially uninitialized $sha256 in finally block throws under strict mode

In the SHA256 fallback path of Verify-Checksum, if [System.Security.Cryptography.SHA256]::Create() on line 83 throws before assigning to $sha256, the finally block at line 88 references $sha256 which was never set. Because Set-StrictMode -Version Latest is active (install.ps1:2), accessing an uninitialized variable throws a RuntimeException, masking the original error.

Root Cause

PowerShell try/finally blocks share the same scope, so $sha256 is visible in finally only if the assignment on line 83 succeeded. If SHA256::Create() throws, $sha256 is never assigned. Under strict mode, if ($sha256) on line 88 raises:

The variable '$sha256' cannot be retrieved because it has not been set.

This replaces the original exception, making it harder to diagnose the real failure. The fix is to initialize $sha256 = $null before the try block.

Impact: On the rare occasion that SHA256::Create() fails (e.g., FIPS policy restrictions), the user sees a confusing "variable not set" error instead of the actual SHA256 creation failure.

Suggested change
if ($sha256) {
$sha256.Dispose()
}
if ($null -ne $sha256) {
$sha256.Dispose()
}
Open in Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant