A tool name is not an installation identity. Two copies of Node can both be present, a shim can forward to another program, and an interactive shell can apply an alias that a desktop process never sees.
Start with what can be observed
Benchlight checks its process PATH in order and records the first match alongside shadowed matches. It keeps the executable location visible. This is an observation of the application's environment, not a promise to reproduce every shell configuration.
Version probes use standard arguments with time and output limits. Batch wrappers and Windows application aliases are not executed. Where adjacent package metadata supplies a version, the interface labels it as metadata rather than pretending a runtime command returned it.
An origin is an inference
Local uninstall records, installation-directory containment and package-manager storage paths can support an origin. A familiar display name by itself is weak evidence. Finding a package in an online catalog would say even less about how a particular local executable arrived.
The application therefore retains the reason and confidence. Some installations remain Unknown. This is more useful than assigning a plausible package manager and making the user debug an assumption.
Keep observation separate from action
Refreshing tools is explicit. Inspecting an arbitrary executable path explains metadata; it does not run that path. Observations are saved locally so the interface can show what was actually recorded instead of silently changing the answer on each visit.
The version probe has process limits, but those limits are not a sandbox for malicious software. Installed tools are executable code; that boundary should remain clear.
Based on tools and installation evidence. See the full case study →