Windows CLI shows Bun help instead of Tailwind functionality when run in elevated/administrator terminal

[MichaelSchmidle]

What version of Tailwind CSS are you using?

v4.1.11

What build tool (or framework if it abstracts the build tool) are you using?

N/A (standalone CLI executable)

What version of Node.js are you using?

N/A (standalone executable)

What browser are you using?

N/A (CLI issue)

What operating system are you using?

Windows

Reproduction URL

This is a CLI distribution issue that doesn't require a typical web reproduction. The bug can be reproduced with the standalone Windows executable directly using the following steps.

Describe your issue

The Windows standalone Tailwind CSS CLI executable (tailwindcss-windows-x64.exe) exhibits inconsistent behavior when run in an elevated (Administrator) terminal. When called directly, it works as expected. When called via symlink (as created by WinGet installation), it shows Bun help output instead of Tailwind CSS functionality.

Important: This issue ONLY occurs in elevated/administrator terminals. In normal user terminals, everything works correctly.

Steps to reproduce

1. Open an elevated (Administrator) terminal
2. Install Tailwind CSS CLI via WinGet: winget install TailwindLabs.TailwindCSS
3. Verify installation: where tailwindcss → Points to C:\Users\...\AppData\Local\Microsoft\WinGet\Links\tailwindcss.exe
4. Check symlink target: Points to C:\Users\...\AppData\Local\Microsoft\WinGet\Packages\TailwindLabs.TailwindCSS_Microsoft.Winget.Source_8wekyb3d8bbwe\tailwindcss.exe

Elevation-specific behavior

In elevated terminal via symlink (INCORRECT):

> tailwindcss --help

Shows Bun help output:

Bun is a fast JavaScript runtime, package manager, bundler, and test runner. (1.2.15+df017990a)
Usage: bun <command> [...flags] [...args]
Commands:
  run, test, x, install, add, remove, etc.

In elevated terminal direct invocation (CORRECT):

> "C:\Users\...\AppData\Local\Microsoft\WinGet\Packages\TailwindLabs.TailwindCSS_Microsoft.Winget.Source_8wekyb3d8bbwe\tailwindcss.exe" --help

Shows proper Tailwind CSS help with options like --input, --output, --watch, --minify, etc.

In normal user terminal (ALL CORRECT):

• tailwindcss --help → Shows Tailwind CSS help properly
• Direct path execution → Works correctly
• All Tailwind-specific commands work as expected

Additional evidence

• Even Tailwind-specific commands fail via symlink in elevated terminals: tailwindcss --watch and tailwindcss --minify both show Bun help
• Same commands work correctly when called directly OR when run in normal user terminals
• File verification: SHA256 hash 6631A41DE25A96EB8506F07B07AB56192DF117A29849C7D7A995BD343329E900 matches GitHub release
• File size: ~131MB (suggesting Bun wrapper with embedded JavaScript)
• Version shown: Bun v1.2.15 when invoked incorrectly

Expected behavior

The CLI should behave identically regardless of:

1. Invocation method (direct path vs symlink)
2. Terminal elevation status (normal vs administrator)

When called as tailwindcss --help or tailwindcss --watch, it should show Tailwind CSS functionality in all contexts.

Impact

This affects users who need to run terminals with administrator privileges for various reasons (corporate policies, other tools requiring elevation, etc.). They cannot use tailwindcss commands naturally and must resort to typing the full executable path.

Technical analysis & potential root cause

The executable appears to have different behavior based on both invocation method AND privilege level. This suggests the issue might be in:

1. Bun's runtime detection logic under elevated privileges - The Bun runtime may use different process/path detection when running as administrator
2. Windows symlink resolution differences in elevated contexts
3. Security-related path resolution that differs between normal and elevated terminals

Potential Bun packaging issue: Given that the executable shows Bun v1.2.15 help when invoked via symlink IN ELEVATED TERMINALS ONLY, this appears to be a bug in Bun's executable packaging/runtime detection that manifests specifically under elevated privileges.

Recommendation: This issue likely needs investigation from the Bun team, as it appears to be related to how Bun's runtime detects whether it should run in "app mode" vs "runtime mode" when executed with administrator privileges via symlink.

[thecrypticace]

Did a local build and could reproduce this. It appears to have gotten fixed (whether intentional or not) in Bun 1.2.19 but we haven't shipped a version with that because of some build failures.

The newly release 1.2.20 seems to have addressed those though so we'll get that change merged and a new release out soon-ish.