Windows install script throws "Only Windows x64 has a prebuilt Wayfinder bundle" on genuine x64 machines when run in an interactive session

[henrique-auler]

Windows install script throws "Only Windows x64 has a prebuilt Wayfinder bundle" on genuine x64 machines when run in an interactive session

What happened

Running irm https://raw.githubusercontent.com/conceptadev/wayfinder/main/tool/install.ps1 | iex in a normal (profile-loaded) interactive Windows PowerShell 5.1 session failed with:

Only Windows x64 has a prebuilt Wayfinder bundle.
At line:35 char:5
+     throw 'Only Windows x64 has a prebuilt Wayfinder bundle.'

despite the machine being genuine x64 hardware and OS (confirmed via Settings > System > About: AMD Ryzen 7 7800X3D, Windows 11 Home 25H2, "64-bit operating system, x64-based processor"). Root-caused to [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture silently returning $null in that interactive session (no exception thrown — just an empty value), causing the script's -ne 'X64' check to evaluate true and hit the throw. The same call resolved correctly to X64 when the identical script was run via powershell.exe -NoProfile -Command "...". Cause of the interactive-only null was not isolated — profile scripts (all 4 paths), PSReadLine, and execution/language mode were each checked and ruled out.

Expected

The installer should either succeed on a confirmed x64 Windows machine, or fail with a diagnostic that distinguishes "could not determine architecture" from "architecture is confirmed non-x64" — the current message is misleading when the true cause is an environment quirk rather than an actual unsupported CPU.

Steps to reproduce

1. On a genuine Windows x64 machine, open a normal interactive Windows PowerShell 5.1 session (profile loaded as usual).
2. Run: irm https://raw.githubusercontent.com/conceptadev/wayfinder/main/tool/install.ps1 | iex
3. Observe the throw 'Only Windows x64 has a prebuilt Wayfinder bundle.' error, even though the OS/hardware is x64.
4. Compare against running the same script via powershell.exe -NoProfile -Command "irm ... | iex", which completes successfully.

Area / repo

conceptadev/wayfinder — tool/install.ps1

Acceptance criteria

• Investigate why [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture can return $null in an interactive PowerShell 5.1 session on some machines, while working correctly with -NoProfile -Command
• Add a fallback architecture check (e.g. $env:PROCESSOR_ARCHITECTURE, [Environment]::Is64BitOperatingSystem) if the primary check returns null/empty, rather than treating null as "not X64"
• Update the thrown error message to differentiate a confirmed non-x64 architecture from an indeterminate/null result
• Document the -NoProfile workaround in install troubleshooting docs for users who hit this

[henrique-auler]

Troubleshooting steps: Wayfinder Windows install failing with "Only Windows x64 has a prebuilt Wayfinder bundle"

Summary

On a genuine x64 Windows machine, the Wayfinder install script failed its architecture check in a normal interactive PowerShell session, but succeeded when run without loading the PowerShell profile. Root cause of the interactive-only failure was not fully isolated; the working fix is to install via -NoProfile.

Steps taken

1. Reproduced the error running the documented install command:

   irm https://raw.githubusercontent.com/conceptadev/wayfinder/main/tool/install.ps1 | iex

   Result: throw 'Only Windows x64 has a prebuilt Wayfinder bundle.'

2. Inspected the install script source (tool/install.ps1) to find the exact check causing the throw:

   if ([System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture -ne 'X64') {
       throw 'Only Windows x64 has a prebuilt Wayfinder bundle.'
   }

3. Ruled out a genuine architecture mismatch. Confirmed via Windows Settings > System > About (screenshot) that the machine is:

   • AMD Ryzen 7 7800X3D (x64 CPU)
   • Windows 11 Home 25H2
   • System type: "64-bit operating system, x64-based processor"

4. Ruled out a 32-bit PowerShell host. Checked:

   $env:PROCESSOR_ARCHITECTURE        # returned AMD64
   $env:PROCESSOR_ARCHITEW6432        # not set (not running under WOW64)
   $PSVersionTable.PSVersion          # 5.1.26100.9168

   Attempted to force the 64-bit host via the Sysnative redirector; it didn't exist, which itself confirmed the session was already 64-bit (Sysnative only exists inside 32-bit processes).

5. Directly inspected the failing property to see what it actually returned:

   $arch = [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture
   $arch          # printed nothing
   $arch.GetType().FullName   # "You cannot call a method on a null-valued expression"

   This showed the property call wasn't throwing — it was silently returning $null.

6. Ruled out Constrained Language Mode (a common cause of silently neutered .NET calls):

   $ExecutionContext.SessionState.LanguageMode   # returned FullLanguage

7. Checked type resolution, which surfaced an anomaly:

   [System.Runtime.InteropServices.RuntimeInformation].Assembly.Location
   # returned: C:\Program Files\WindowsPowerShell\Modules\PSReadLine\2.0.0\Microsoft.PowerShell.PSReadLine.dll

   This pointed away from the real .NET Framework assembly and toward PSReadLine, suggesting something in the interactive session was interfering with type resolution.

8. Tested a clean, profile-free session:

   powershell.exe -NoProfile -NoLogo -Command "[System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture"
   # returned: X64

   This confirmed the check works correctly outside the normal interactive session, isolating the problem to something specific to that session type.

9. Checked all four PowerShell profile script paths for anything that could be shadowing the type:

   Test-Path $PROFILE.AllUsersAllHosts          # False
   Test-Path $PROFILE.AllUsersCurrentHost       # False
   Test-Path $PROFILE.CurrentUserAllHosts       # False
   Test-Path $PROFILE.CurrentUserCurrentHost    # False

   None of the profile scripts existed, ruling out a profile-based cause.

10. Checked loaded modules in a normal interactive session:

    Get-Module

    Only the standard Microsoft.PowerShell.Management, Microsoft.PowerShell.Utility, and PSReadLine were loaded — nothing unusual.

11. Tested removing PSReadLine from the session to see if it was the interference source:

    Remove-Module PSReadLine
    [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture

    Still returned nothing — ruled out PSReadLine as the direct cause.

12. Applied the working fix: installed using a profile-free one-shot PowerShell invocation, which bypasses whatever is interfering with the type check in the normal interactive session:

    powershell.exe -NoProfile -Command "irm https://raw.githubusercontent.com/conceptadev/wayfinder/main/tool/install.ps1 | iex"

    Result: install completed successfully —

    Installed Wayfinder 0.1.0. Open a new terminal to refresh PATH.
    Claude Code (~/.claude/skills): installed adopt-knowledge-bundle, assess-knowledge-bundle, author-knowledge-bundle, use-wayfinder (0.1.0).
    Agent Skills (~/.agents/skills): installed adopt-knowledge-bundle, assess-knowledge-bundle, author-knowledge-bundle, use-wayfinder (0.1.0).
    

13. Opened a new terminal so the updated PATH took effect.

Outcome

Wayfinder 0.1.0 installed successfully via the -NoProfile workaround. The underlying cause of why the interactive session nulls out [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture was not identified — profile scripts, PSReadLine, and language mode were each ruled out as the direct cause. This is tracked separately as a bug for the install script to add a fallback check and clearer error messaging.

[leoafarias]

Solved in #99.

The cause was not your machine. tool/install.ps1 compared the .NET architecture probe straight to 'X64':

if ([System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture -ne 'X64') {
    throw 'Only Windows x64 has a prebuilt Wayfinder bundle.'
}

In your interactive Windows PowerShell 5.1 session that property returned nothing rather than an architecture, and "nothing" compared unequal to 'X64' exactly like a real Arm64 machine would — so the installer reported the one thing that was not wrong with your x64 box. That is also why the same command worked under -NoProfile.

What changed:

• An empty probe now means unknown, not unsupported. The probe is wrapped in try/catch and falls back to Windows' own machine-scope PROCESSOR_ARCHITECTURE (then PROCESSOR_ARCHITEW6432), the way dotnet-install.ps1 does. Your session installs normally now.
• If nothing can be determined at all, the installer says so instead of naming an architecture, and prints the clean-session command.
• A genuinely unsupported machine is now named: Windows Arm64 has no prebuilt Wayfinder bundle; only Windows x64 has one.
• Windows PowerShell 5 hosts also get the standard TLS 1.2 opt-in, and the architecture check runs before any download instead of after.

Tested on Windows in CI under both Windows PowerShell 5.1 and PowerShell 7: an empty probe installs and indexes end to end, and the refusal and indeterminate paths are asserted separately, so this cannot regress silently.

No workaround needed once #99 merges. If you are curious why your session's probe came back empty, I have a short diagnostic snippet that would confirm it — happy to post it, though the fix does not depend on the answer.