Add PowerShell 7.6.3 with enhanced console configuration and Nerd Font support

[N6REJ]

No description provided.

[qodo-code-review]

PR Summary by Qodo

Add PowerShell 7.6.3 bundle with Nerd Font auto-setup and safer launcher flags
✨ Enhancement ⚙️ Configuration changes 📝 Documentation 🕐 40+ Minutes

Description

• Add a new PowerShell 7.6.3 bundle with an enhanced profile and console experience.
• Auto-detect/register Nerd Fonts and apply UTF-8 + console registry settings for glyph support.
• Standardize PowerShell launchers to use ExecutionPolicy Bypass for consistent startup behavior.

Diagram

graph TD
  U([User]) --> L["powershell.bat launcher"] --> R[("Windows Console Registry")]
  L --> F["vendor/fonts"] --> RF["register-fonts.ps1"] --> R
  L --> P["PowerShell profile"] --> V["Oh My Posh + modules"]

  subgraph Legend
    direction LR
    _u([Actor]) ~~~ _p["Script/Process"] ~~~ _r[(Registry)]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Avoid ExecutionPolicy Bypass (sign/ship modules differently)

• ➕ Reduces security concerns and aligns with stricter enterprise defaults
• ➕ Avoids relying on policy overrides that some environments monitor/block
• ➖ Adds operational overhead (code signing, certificate distribution) for a portable bundle
• ➖ May complicate first-run experience if prerequisites are missing

2. Limit registry writes to HKCU + avoid HKLM modifications

• ➕ No admin elevation needed; fewer side effects on the machine
• ➕ Less risk of silently failing operations when not elevated
• ➖ Some conhost setups may still not recognize fonts without HKLM entries
• ➖ May reduce reliability of the “just works” font experience across systems

3. Prefer Windows Terminal profile configuration over conhost registry forcing

• ➕ Cleaner separation: terminal owns font selection; launcher stays simple
• ➕ Avoids brittle conhost refresh workarounds (title toggling/cls hacks)
• ➖ Does not help users launching via classic console host
• ➖ Requires user/installer-managed terminal settings

Recommendation: The PR’s approach is reasonable for a self-contained Windows bundle where consistent glyph rendering is a key goal. However, consider tightening the registry strategy: explicitly detect elevation and conditionally skip HKLM writes (with a clear log/message), while keeping HKCU console defaults as the baseline. ExecutionPolicy Bypass is pragmatic for a launcher, but should be documented as an intentional tradeoff (what it enables and what it does not protect against).

Files changed (13) +482 / -11

Enhancement (3) +379 / -0

Microsoft.PowerShell_profile.ps1Add enhanced 7.6.3 PowerShell profile (Oh My Posh + PSReadLine) +52/-0

Add enhanced 7.6.3 PowerShell profile (Oh My Posh + PSReadLine)

• Adds a bundled profile that initializes Oh My Posh (paradox theme), imports Terminal-Icons, and configures PSReadLine editing, history, predictions, and keybindings. Includes a conditional interactive welcome banner and sets module paths to bundled modules.

bin/powershell7.6.3/config/Microsoft.PowerShell_profile.ps1

register-fonts.ps1Add script to register/install bundled fonts for console usage +137/-0

Add script to register/install bundled fonts for console usage

• Adds a font registration utility that copies font files to the user fonts directory, registers them under HKCU\...\Fonts, and updates Console\TrueTypeFont entries. Broadcasts WM_SETTINGCHANGE to encourage font setting refresh and returns the selected font family name for the launcher to use.

bin/powershell7.6.3/config/register-fonts.ps1

powershell.batIntroduce 7.6.3 launcher with font auto-detection and registry console setup +190/-0

Introduce 7.6.3 launcher with font auto-detection and registry console setup

• Adds a new launcher that sets UTF-8, detects/installs Nerd Fonts (optionally from vendor/fonts), updates console font registry keys, and starts PowerShell with the bundled profile. Uses a title-refresh technique and spawns a new process to ensure conhost picks up font settings reliably, always using -ExecutionPolicy Bypass.

bin/powershell7.6.3/powershell.bat

Documentation (1) +67 / -0

README.mdDocument Nerd Font requirement and customization points +67/-0

Document Nerd Font requirement and customization points

• Documents the required Nerd Font, how to configure fonts in Windows Terminal/conhost, and what the profile configures. Provides pointers for changing Oh My Posh theme and PSReadLine settings.

bin/powershell7.6.3/config/README.md

Other (9) +36 / -11

deps.propertiesBump Oh My Posh download URL to v29.18.0 +1/-1

Bump Oh My Posh download URL to v29.18.0

• Updates the pinned Oh My Posh binary download URL from v29.14.0 to v29.18.0 for the 7.5.4 bundle.

bin/powershell7.5.4/deps.properties

powershell.batAdd ExecutionPolicy Bypass to the 7.5.4 launcher +2/-2

Add ExecutionPolicy Bypass to the 7.5.4 launcher

• Ensures the launcher starts PowerShell with -ExecutionPolicy Bypass in both NoExit and exit-after-run modes to prevent policy from blocking startup/profile behavior.

bin/powershell7.5.4/powershell.bat

bearsampp.confSwitch configured Nerd Font name for 7.6.0 +1/-1

Switch configured Nerd Font name for 7.6.0

• Updates the configured console font to the Windows family name "CaskaydiaMono NF" for better Nerd Font compatibility.

bin/powershell7.6.0/bearsampp.conf

powershell.batAdd ExecutionPolicy Bypass to the 7.6.0 launcher +2/-2

Add ExecutionPolicy Bypass to the 7.6.0 launcher

• Adds -ExecutionPolicy Bypass to the PowerShell start command to improve reliability of launching with the bundled command/profile.

bin/powershell7.6.0/powershell.bat

powershell.batAdd ExecutionPolicy Bypass to the 7.6.1 launcher +2/-2

Add ExecutionPolicy Bypass to the 7.6.1 launcher

• Adds -ExecutionPolicy Bypass to standardize launcher behavior and avoid execution policy blocking on startup.

bin/powershell7.6.1/powershell.bat

powershell.batAdd ExecutionPolicy Bypass to the 7.6.2 launcher +2/-2

Add ExecutionPolicy Bypass to the 7.6.2 launcher

• Adds -ExecutionPolicy Bypass to the start command in both NoExit and exit modes.

bin/powershell7.6.2/powershell.bat

bearsampp.confAdd 7.6.3 bundle configuration +9/-0

Add 7.6.3 bundle configuration

• Introduces a new bundle config for PowerShell 7.6.3 including executable, launcher, profile path, font name, and console dimensions.

bin/powershell7.6.3/bearsampp.conf

deps.propertiesDefine 7.6.3 dependencies and Nerd Font name +16/-0

Define 7.6.3 dependencies and Nerd Font name

• Adds dependency definitions for Oh My Posh (latest), theme URL, Nerd Font family name, and PowerShell Gallery modules (Terminal-Icons and PSReadLine) for the 7.6.3 bundle.

bin/powershell7.6.3/deps.properties

build.propertiesBump bundle release date +1/-1

Bump bundle release date

• Updates the bundle release value from 2026.5.31 to 2026.6.25.

build.properties

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (0) 📜 Skill insights (0)

1. Unpinned dependency downloads 🐞 Bug ⛨ Security

Description

The 7.6.3 deps use moving targets (GitHub releases/latest, PowerShell Gallery unversioned package
endpoints, and a theme from main), and the build downloads them without any integrity
verification; the profile then executes oh-my-posh init output via Invoke-Expression, turning any
upstream change/compromise into startup-time code execution. This also makes builds non-reproducible
because the same versioned bundle can contain different binaries over time.

Code

bin/powershell7.6.3/deps.properties[R1-16]

+oh_my_posh = https://github.com/JanDeDobbeleer/oh-my-posh/releases/latest/download/posh-windows-amd64.exe
+oh_my_posh_theme = https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/paradox.omp.json
+
+# Cascadia Mono Nerd Font - Nerd Font required for Oh My Posh glyphs/icons in the terminal
+# font_name - must be the windows system name for the font
+oh_my_posh_font_name = "CaskaydiaMono NF"
+
+# Terminal-Icons - PowerShell module for colorful file/folder icons
+# Automatically downloads the latest version from PowerShell Gallery during build
+terminal_icons = https://www.powershellgallery.com/api/v2/package/Terminal-Icons
+
+# PSReadLine - Enhanced command-line editing with syntax highlighting, predictive IntelliSense, and history search
+# Provides advanced editing features like multi-line editing, undo/redo, and customizable key bindings
+# Automatically updated to the latest version from PowerShell Gallery during build process
+# Note: PowerShell 7+ includes PSReadLine by default, but this ensures the latest version with newest features
+psreadline = https://www.powershellgallery.com/api/v2/package/PSReadLine

Evidence

The new 7.6.3 deps file uses moving URLs, the build system downloads whatever those URLs return
without integrity checks, and the PowerShell profile executes oh-my-posh-generated script text via
Invoke-Expression, creating a clear supply-chain execution path.

bin/powershell7.6.3/deps.properties[1-16]
build.gradle[659-689]
build.gradle[888-943]
build.gradle[165-206]
bin/powershell7.6.3/config/Microsoft.PowerShell_profile.ps1[18-24]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/deps.properties` references moving URLs (e.g., GitHub `releases/latest`, PowerShell Gallery `.../package/<Name>`, and a theme from the `main` branch). `build.gradle` downloads these artifacts with `downloadFile()` but does not verify hashes/signatures, and `Microsoft.PowerShell_profile.ps1` executes oh-my-posh init output via `Invoke-Expression`, amplifying any upstream compromise into code execution at shell startup.

### Issue Context
This is both a reproducibility problem (different artifacts for the same bundle version) and a supply-chain risk (remote executable/modules fetched at build time without integrity checks).

### Fix Focus Areas
- bin/powershell7.6.3/deps.properties[1-16]
- build.gradle[659-689]
- build.gradle[888-943]
- build.gradle[165-206]
- bin/powershell7.6.3/config/Microsoft.PowerShell_profile.ps1[18-24]

### Suggested remediation
- Replace moving URLs with version-pinned URLs:
 - Oh My Posh: use a specific tag URL (like the 7.5.4 approach) instead of `releases/latest`.
 - Theme: pin to a specific commit/tag (avoid `main`), or vendor the theme into the repo/build inputs.
 - PowerShell Gallery modules: use versioned package URLs (`.../package/Terminal-Icons/<version>`, `.../package/PSReadLine/<version>`).
- Add integrity verification in `build.gradle`:
 - Extend `deps.properties` with SHA256 (or similar) fields per artifact and have `downloadFile()` verify the hash before copying/using.
- (Optional hardening) If feasible, reduce reliance on `Invoke-Expression` by using oh-my-posh’s recommended safer initialization pattern, or at minimum only run it when the binary/theme hash matches expected values.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. ExecutionPolicy forced bypass 🐞 Bug ⛨ Security ⭐ New

Description

The launchers now start PowerShell with -ExecutionPolicy Bypass, explicitly overriding the
user/system execution policy for the entire launched session (including the dot-sourced bundled
profile). This weakens execution-policy-based controls on managed machines and makes the launcher
ignore an expected security boundary by default.

Code

bin/powershell7.6.3/powershell.bat[R181-184]

+    start "!WINDOW_TITLE!" "!PS_EXE!" -NoExit -NoProfile -ExecutionPolicy Bypass -Command "!PS_COMMAND!"
+    exit
+) else (
+    start "!WINDOW_TITLE!" "!PS_EXE!" -NoProfile -ExecutionPolicy Bypass -Command "!PS_COMMAND!; exit"

Evidence

PS_COMMAND dot-sources the bundled profile, and the subsequent start command runs that command
under -ExecutionPolicy Bypass, which disables execution-policy enforcement for the launched
session; the same pattern exists across the other versioned launchers affected by the focus hunks.

bin/powershell7.6.3/powershell.bat[169-185]
bin/powershell7.5.4/powershell.bat[169-185]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
All versioned `powershell.bat` launchers were changed to include `-ExecutionPolicy Bypass` when starting PowerShell. This forces the launched session to ignore the configured execution policy (Process/User/Machine), which can be undesirable/forbidden in enterprise environments.

### Issue Context
The launcher already explicitly dot-sources the bundled profile from the command line, so `-ExecutionPolicy Bypass` applies directly to that script load and anything it triggers.

### Fix approach
Implement one of the following (preferred top-down):
1. **Default to honoring policy**: remove `-ExecutionPolicy Bypass` from the `start ... pwsh.exe` invocations.
2. **If bypass is required for some users**: gate it behind an explicit opt-in (e.g., env var `BEARSAMPP_EXECUTIONPOLICY_BYPASS=1` or a `--bypassExecutionPolicy` flag).
3. **Alternative compromise**: use a less-permissive policy such as `RemoteSigned` for the process, and/or sign the bundled scripts.

### Fix Focus Areas
- bin/powershell7.5.4/powershell.bat[181-184]
- bin/powershell7.6.0/powershell.bat[181-184]
- bin/powershell7.6.1/powershell.bat[181-184]
- bin/powershell7.6.2/powershell.bat[181-184]
- bin/powershell7.6.3/powershell.bat[181-184]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Pinned handle not freed 🐞 Bug ☼ Reliability

Description

In register-fonts.ps1, a pinned GCHandle is freed only on the success path; exceptions can leave
memory pinned, and PrivateFontCollection instances are never disposed, leaking GDI/font handles
during failures or repeated runs. This can accumulate resource pressure over time on systems where
the launcher runs often.

Code

bin/powershell7.6.3/config/register-fonts.ps1[R37-41]

+                $fileBytes = [System.IO.File]::ReadAllBytes($file.FullName)
+                $handle = [System.Runtime.InteropServices.GCHandle]::Alloc($fileBytes, 'Pinned')
+                $fc.AddMemoryFont($handle.AddrOfPinnedObject(), $fileBytes.Length)
+                $handle.Free()
+            } catch {}

Evidence

The script allocates a pinned handle and frees it only before leaving the try block, while
exceptions are swallowed; additionally, multiple PrivateFontCollection objects are created with no
disposal, which is observable from the code paths shown.

bin/powershell7.6.3/config/register-fonts.ps1[34-42]
bin/powershell7.6.3/config/register-fonts.ps1[60-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/config/register-fonts.ps1` allocates a pinned `GCHandle` but frees it only after `AddMemoryFont()` succeeds; if an exception occurs after allocation, the handle remains pinned. The script also creates `System.Drawing.Text.PrivateFontCollection` objects without disposing them.

### Issue Context
This script is called from the launcher to register fonts and may run multiple times across launches; failures/partial loads increase the chance of leaking pinned memory or GDI resources.

### Fix Focus Areas
- bin/powershell7.6.3/config/register-fonts.ps1[24-43]
- bin/powershell7.6.3/config/register-fonts.ps1[60-71]

### Suggested remediation
- Wrap the pinned handle in `try { ... } finally { if ($handle.IsAllocated) { $handle.Free() } }`.
- Dispose font collections:
 - `$fc` should be disposed at the end (e.g., `try/finally` around its usage).
 - `$fileFc` should be disposed per-iteration (e.g., `try/finally { $fileFc.Dispose() }`).
- Avoid empty `catch {}` blocks for critical cleanup paths; at least ensure cleanup always runs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Silent HKLM registry failures 🐞 Bug ◔ Observability

Description

The launcher performs best-effort HKLM reg add writes (fonts/TrueTypeFont) while suppressing all
output and not checking exit codes, so non-admin runs will silently fail and produce inconsistent
font availability across consoles. This makes font configuration brittle and hard to debug when
HKCU-only settings aren’t sufficient.

Code

bin/powershell7.6.3/powershell.bat[R134-141]

+REM Ensure the font is registered as a valid console font in HKCU and HKLM
+REM HKLM is often required for conhost.exe to recognize the font
+for /f "tokens=2,*" %%A in ('reg query "HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" /v "!FONT_NAME! (TrueType)" 2^>nul') do (
+    set "FONT_PATH=%%B"
+    if not "!FONT_PATH!"=="" reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" /v "!FONT_NAME! (TrueType)" /t REG_SZ /d "!FONT_PATH!" /f >nul 2>&1
+)
+reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v "000" /t REG_SZ /d "!FONT_NAME!" /f >nul 2>&1
+reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v "0000" /t REG_SZ /d "!FONT_NAME!" /f >nul 2>&1

Evidence

The launcher explicitly issues HKLM reg add commands and redirects all output to nul, with no
subsequent error handling, so failures (e.g., from insufficient privileges) are invisible to the
user.

bin/powershell7.6.3/powershell.bat[134-145]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/powershell.bat` writes to HKLM registry keys (machine-wide) but suppresses output (`>nul 2>&1`) and does not validate success. On standard non-elevated runs these calls typically fail, leaving users with partial configuration and no diagnostics.

### Issue Context
The script also writes HKCU keys, so it may “work” sometimes, but the HKLM step is explicitly relied on for broader conhost recognition and can be the difference between working glyphs vs missing glyphs.

### Fix Focus Areas
- bin/powershell7.6.3/powershell.bat[134-145]

### Suggested remediation
- Detect elevation/admin rights before attempting HKLM writes; if not elevated:
 - skip HKLM writes, and
 - print a single concise warning explaining that machine-wide font registration was skipped.
- If elevated, keep HKLM writes but check `%ERRORLEVEL%` after each critical `reg add` and emit a warning if it fails (even if you keep `>nul 2>&1`).
- Consider narrowing HKLM writes to only what’s strictly necessary (avoid modifying HKLM Fonts unless required).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View more (1)

5. Launcher command resolution risk 🐞 Bug ☼ Reliability

Description

The launcher runs powershell -NoProfile ... without an absolute path, so if the current working
directory contains powershell.bat (common when launching from the bundle folder), cmd.exe can
resolve powershell to the batch file instead of powershell.exe, causing recursion/launch
failure. This is conditional on how the launcher is started, but it’s a real reliability foot-gun.

Code

bin/powershell7.6.3/powershell.bat[R120-122]

+    REM Extra "kick" to force conhost to update
+    powershell -NoProfile -Command "$Host.UI.RawUI.WindowTitle='Refreshing...'; $Host.UI.RawUI.WindowTitle='!PS_WINDOW_TITLE!'" >nul 2>&1
+    

Evidence

The launcher script is named powershell.bat and contains an unqualified powershell invocation,
which is susceptible to cmd command-resolution ambiguity when run from a directory containing a
same-named .bat.

bin/powershell7.6.3/powershell.bat[107-123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/powershell.bat` invokes `powershell` unqualified. When the current directory includes `powershell.bat`, Windows command resolution may pick the batch file (this script) rather than the intended `powershell.exe`, leading to recursion/failed startup.

### Issue Context
This only triggers in certain launch contexts (e.g., starting from the bundle directory), but it’s hard to diagnose when it happens.

### Fix Focus Areas
- bin/powershell7.6.3/powershell.bat[117-123]

### Suggested remediation
- Replace the unqualified `powershell -NoProfile ...` call with one of:
 - `"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -Command ...`
 - or reuse the already-selected `!PS_EXE!` (`"!PS_EXE!" -NoProfile -Command ...`) so it can’t collide with the batch filename.
- Keep output suppression if desired, but ensure the invoked executable is deterministic (no PATH/current-dir ambiguity).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Previous review results

Review updated until commit 9e4acd1

Results up to commit 7fb6de0

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Unpinned dependency downloads 🐞 Bug ⛨ Security

Description

The 7.6.3 deps use moving targets (GitHub releases/latest, PowerShell Gallery unversioned package
endpoints, and a theme from main), and the build downloads them without any integrity
verification; the profile then executes oh-my-posh init output via Invoke-Expression, turning any
upstream change/compromise into startup-time code execution. This also makes builds non-reproducible
because the same versioned bundle can contain different binaries over time.

Code

bin/powershell7.6.3/deps.properties[R1-16]

+oh_my_posh = https://github.com/JanDeDobbeleer/oh-my-posh/releases/latest/download/posh-windows-amd64.exe
+oh_my_posh_theme = https://raw.githubusercontent.com/JanDeDobbeleer/oh-my-posh/main/themes/paradox.omp.json
+
+# Cascadia Mono Nerd Font - Nerd Font required for Oh My Posh glyphs/icons in the terminal
+# font_name - must be the windows system name for the font
+oh_my_posh_font_name = "CaskaydiaMono NF"
+
+# Terminal-Icons - PowerShell module for colorful file/folder icons
+# Automatically downloads the latest version from PowerShell Gallery during build
+terminal_icons = https://www.powershellgallery.com/api/v2/package/Terminal-Icons
+
+# PSReadLine - Enhanced command-line editing with syntax highlighting, predictive IntelliSense, and history search
+# Provides advanced editing features like multi-line editing, undo/redo, and customizable key bindings
+# Automatically updated to the latest version from PowerShell Gallery during build process
+# Note: PowerShell 7+ includes PSReadLine by default, but this ensures the latest version with newest features
+psreadline = https://www.powershellgallery.com/api/v2/package/PSReadLine

Evidence

The new 7.6.3 deps file uses moving URLs, the build system downloads whatever those URLs return
without integrity checks, and the PowerShell profile executes oh-my-posh-generated script text via
Invoke-Expression, creating a clear supply-chain execution path.

bin/powershell7.6.3/deps.properties[1-16]
build.gradle[659-689]
build.gradle[888-943]
build.gradle[165-206]
bin/powershell7.6.3/config/Microsoft.PowerShell_profile.ps1[18-24]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/deps.properties` references moving URLs (e.g., GitHub `releases/latest`, PowerShell Gallery `.../package/<Name>`, and a theme from the `main` branch). `build.gradle` downloads these artifacts with `downloadFile()` but does not verify hashes/signatures, and `Microsoft.PowerShell_profile.ps1` executes oh-my-posh init output via `Invoke-Expression`, amplifying any upstream compromise into code execution at shell startup.

### Issue Context
This is both a reproducibility problem (different artifacts for the same bundle version) and a supply-chain risk (remote executable/modules fetched at build time without integrity checks).

### Fix Focus Areas
- bin/powershell7.6.3/deps.properties[1-16]
- build.gradle[659-689]
- build.gradle[888-943]
- build.gradle[165-206]
- bin/powershell7.6.3/config/Microsoft.PowerShell_profile.ps1[18-24]

### Suggested remediation
- Replace moving URLs with version-pinned URLs:
 - Oh My Posh: use a specific tag URL (like the 7.5.4 approach) instead of `releases/latest`.
 - Theme: pin to a specific commit/tag (avoid `main`), or vendor the theme into the repo/build inputs.
 - PowerShell Gallery modules: use versioned package URLs (`.../package/Terminal-Icons/<version>`, `.../package/PSReadLine/<version>`).
- Add integrity verification in `build.gradle`:
 - Extend `deps.properties` with SHA256 (or similar) fields per artifact and have `downloadFile()` verify the hash before copying/using.
- (Optional hardening) If feasible, reduce reliance on `Invoke-Expression` by using oh-my-posh’s recommended safer initialization pattern, or at minimum only run it when the binary/theme hash matches expected values.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Launcher command resolution risk 🐞 Bug ☼ Reliability

Description

The launcher runs powershell -NoProfile ... without an absolute path, so if the current working
directory contains powershell.bat (common when launching from the bundle folder), cmd.exe can
resolve powershell to the batch file instead of powershell.exe, causing recursion/launch
failure. This is conditional on how the launcher is started, but it’s a real reliability foot-gun.

Code

bin/powershell7.6.3/powershell.bat[R120-122]

+    REM Extra "kick" to force conhost to update
+    powershell -NoProfile -Command "$Host.UI.RawUI.WindowTitle='Refreshing...'; $Host.UI.RawUI.WindowTitle='!PS_WINDOW_TITLE!'" >nul 2>&1
+    

Evidence

The launcher script is named powershell.bat and contains an unqualified powershell invocation,
which is susceptible to cmd command-resolution ambiguity when run from a directory containing a
same-named .bat.

bin/powershell7.6.3/powershell.bat[107-123]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/powershell.bat` invokes `powershell` unqualified. When the current directory includes `powershell.bat`, Windows command resolution may pick the batch file (this script) rather than the intended `powershell.exe`, leading to recursion/failed startup.

### Issue Context
This only triggers in certain launch contexts (e.g., starting from the bundle directory), but it’s hard to diagnose when it happens.

### Fix Focus Areas
- bin/powershell7.6.3/powershell.bat[117-123]

### Suggested remediation
- Replace the unqualified `powershell -NoProfile ...` call with one of:
 - `"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -Command ...`
 - or reuse the already-selected `!PS_EXE!` (`"!PS_EXE!" -NoProfile -Command ...`) so it can’t collide with the batch filename.
- Keep output suppression if desired, but ensure the invoked executable is deterministic (no PATH/current-dir ambiguity).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Silent HKLM registry failures 🐞 Bug ◔ Observability

Description

The launcher performs best-effort HKLM reg add writes (fonts/TrueTypeFont) while suppressing all
output and not checking exit codes, so non-admin runs will silently fail and produce inconsistent
font availability across consoles. This makes font configuration brittle and hard to debug when
HKCU-only settings aren’t sufficient.

Code

bin/powershell7.6.3/powershell.bat[R134-141]

+REM Ensure the font is registered as a valid console font in HKCU and HKLM
+REM HKLM is often required for conhost.exe to recognize the font
+for /f "tokens=2,*" %%A in ('reg query "HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" /v "!FONT_NAME! (TrueType)" 2^>nul') do (
+    set "FONT_PATH=%%B"
+    if not "!FONT_PATH!"=="" reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Fonts" /v "!FONT_NAME! (TrueType)" /t REG_SZ /d "!FONT_PATH!" /f >nul 2>&1
+)
+reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v "000" /t REG_SZ /d "!FONT_NAME!" /f >nul 2>&1
+reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Console\TrueTypeFont" /v "0000" /t REG_SZ /d "!FONT_NAME!" /f >nul 2>&1

Evidence

The launcher explicitly issues HKLM reg add commands and redirects all output to nul, with no
subsequent error handling, so failures (e.g., from insufficient privileges) are invisible to the
user.

bin/powershell7.6.3/powershell.bat[134-145]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/powershell.bat` writes to HKLM registry keys (machine-wide) but suppresses output (`>nul 2>&1`) and does not validate success. On standard non-elevated runs these calls typically fail, leaving users with partial configuration and no diagnostics.

### Issue Context
The script also writes HKCU keys, so it may “work” sometimes, but the HKLM step is explicitly relied on for broader conhost recognition and can be the difference between working glyphs vs missing glyphs.

### Fix Focus Areas
- bin/powershell7.6.3/powershell.bat[134-145]

### Suggested remediation
- Detect elevation/admin rights before attempting HKLM writes; if not elevated:
 - skip HKLM writes, and
 - print a single concise warning explaining that machine-wide font registration was skipped.
- If elevated, keep HKLM writes but check `%ERRORLEVEL%` after each critical `reg add` and emit a warning if it fails (even if you keep `>nul 2>&1`).
- Consider narrowing HKLM writes to only what’s strictly necessary (avoid modifying HKLM Fonts unless required).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

4. Pinned handle not freed 🐞 Bug ☼ Reliability

Description

In register-fonts.ps1, a pinned GCHandle is freed only on the success path; exceptions can leave
memory pinned, and PrivateFontCollection instances are never disposed, leaking GDI/font handles
during failures or repeated runs. This can accumulate resource pressure over time on systems where
the launcher runs often.

Code

bin/powershell7.6.3/config/register-fonts.ps1[R37-41]

+                $fileBytes = [System.IO.File]::ReadAllBytes($file.FullName)
+                $handle = [System.Runtime.InteropServices.GCHandle]::Alloc($fileBytes, 'Pinned')
+                $fc.AddMemoryFont($handle.AddrOfPinnedObject(), $fileBytes.Length)
+                $handle.Free()
+            } catch {}

Evidence

The script allocates a pinned handle and frees it only before leaving the try block, while
exceptions are swallowed; additionally, multiple PrivateFontCollection objects are created with no
disposal, which is observable from the code paths shown.

bin/powershell7.6.3/config/register-fonts.ps1[34-42]
bin/powershell7.6.3/config/register-fonts.ps1[60-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`bin/powershell7.6.3/config/register-fonts.ps1` allocates a pinned `GCHandle` but frees it only after `AddMemoryFont()` succeeds; if an exception occurs after allocation, the handle remains pinned. The script also creates `System.Drawing.Text.PrivateFontCollection` objects without disposing them.

### Issue Context
This script is called from the launcher to register fonts and may run multiple times across launches; failures/partial loads increase the chance of leaking pinned memory or GDI resources.

### Fix Focus Areas
- bin/powershell7.6.3/config/register-fonts.ps1[24-43]
- bin/powershell7.6.3/config/register-fonts.ps1[60-71]

### Suggested remediation
- Wrap the pinned handle in `try { ... } finally { if ($handle.IsAllocated) { $handle.Free() } }`.
- Dispose font collections:
 - `$fc` should be disposed at the end (e.g., `try/finally` around its usage).
 - `$fileFc` should be disposed per-iteration (e.g., `try/finally { $fileFc.Dispose() }`).
- Avoid empty `catch {}` blocks for critical cleanup paths; at least ensure cleanup always runs.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

1. Unpinned dependency downloads 🐞 Bug ⛨ Security

The 7.6.3 deps use moving targets (GitHub releases/latest, PowerShell Gallery unversioned package
endpoints, and a theme from main), and the build downloads them without any integrity
verification; the profile then executes oh-my-posh init output via Invoke-Expression, turning any
upstream change/compromise into startup-time code execution. This also makes builds non-reproducible
because the same versioned bundle can contain different binaries over time.

Agent Prompt

### Issue description
`bin/powershell7.6.3/deps.properties` references moving URLs (e.g., GitHub `releases/latest`, PowerShell Gallery `.../package/<Name>`, and a theme from the `main` branch). `build.gradle` downloads these artifacts with `downloadFile()` but does not verify hashes/signatures, and `Microsoft.PowerShell_profile.ps1` executes oh-my-posh init output via `Invoke-Expression`, amplifying any upstream compromise into code execution at shell startup.

### Issue Context
This is both a reproducibility problem (different artifacts for the same bundle version) and a supply-chain risk (remote executable/modules fetched at build time without integrity checks).

### Fix Focus Areas
- bin/powershell7.6.3/deps.properties[1-16]
- build.gradle[659-689]
- build.gradle[888-943]
- build.gradle[165-206]
- bin/powershell7.6.3/config/Microsoft.PowerShell_profile.ps1[18-24]

### Suggested remediation
- Replace moving URLs with version-pinned URLs:
  - Oh My Posh: use a specific tag URL (like the 7.5.4 approach) instead of `releases/latest`.
  - Theme: pin to a specific commit/tag (avoid `main`), or vendor the theme into the repo/build inputs.
  - PowerShell Gallery modules: use versioned package URLs (`.../package/Terminal-Icons/<version>`, `.../package/PSReadLine/<version>`).
- Add integrity verification in `build.gradle`:
  - Extend `deps.properties` with SHA256 (or similar) fields per artifact and have `downloadFile()` verify the hash before copying/using.
- (Optional hardening) If feasible, reduce reliance on `Invoke-Expression` by using oh-my-posh’s recommended safer initialization pattern, or at minimum only run it when the binary/theme hash matches expected values.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

[qodo-code-review]

Code review by qodo was updated up to the latest commit 9e4acd1