Please confirm these before moving forward
Environment
- UniGetUI: 2026.2.7, build 107
- Also observed with: 2026.2.5
- macOS: 26.5.2 (25F84)
- Architecture: ARM64
- Hardware: MacBook Air M5 (Mac17,4)
Description
UniGetUI can remain on the splash screen indefinitely when the user's zsh login configuration does not terminate promptly.
In this case, the user's .zprofile accidentally contained a recursive exec zsh -l. That configuration was incorrect, but UniGetUI remained blocked for hours rather than timing out and retaining its existing PATH.
After correcting the shell configuration, the same command completes immediately and UniGetUI starts normally.
Steps to reproduce
- Configure a zsh login startup file that blocks or does not terminate.
- Start UniGetUI from Finder.
- Observe the splash screen.
Expected behavior
The shell PATH lookup times out after approximately five seconds, UniGetUI retains its existing PATH, and startup continues. Ideally this work should not block the UI thread.
Actual behavior
The splash screen remains indefinitely. A process sample taken from UniGetUI 2026.2.7 contained 2,596 identical samples of the main thread blocked here:
UniGetUI.Avalonia.App.StartMainWindow
ProcessEnvironmentConfigurator.PrepareForCurrentPlatform
ProcessEnvironmentConfigurator.ExpandMacOSPath
System.IO.StreamReader.ReadToEnd
System.IO.Pipes.PipeStream.ReadCore
System.Net.Sockets.Socket.Receive
SystemNative_Read
__read_nocancel
Probable cause
In tag v2026.2.7, the code reads stdout to completion before applying its timeout:
process.Start();
string shellPath = process.StandardOutput.ReadToEnd().Trim();
process.WaitForExit(5000);
Source:
https://github.com/Devolutions/UniGetUI/blob/v2026.2.7/src/UniGetUI.Avalonia/Infrastructure/ProcessEnvironmentConfigurator.cs
Because ReadToEnd() blocks until the child closes stdout, WaitForExit(5000) is never reached when the login shell does not exit. The intended timeout is therefore ineffective.
Suggested direction
Read stdout asynchronously, wait with cancellation/timeout first, kill the child process on timeout, and continue startup using the inherited PATH. Avoid performing the blocking lookup on the UI thread.
Please confirm these before moving forward
Environment
Description
UniGetUI can remain on the splash screen indefinitely when the user's zsh login configuration does not terminate promptly.
In this case, the user's
.zprofileaccidentally contained a recursiveexec zsh -l. That configuration was incorrect, but UniGetUI remained blocked for hours rather than timing out and retaining its existing PATH.After correcting the shell configuration, the same command completes immediately and UniGetUI starts normally.
Steps to reproduce
Expected behavior
The shell PATH lookup times out after approximately five seconds, UniGetUI retains its existing PATH, and startup continues. Ideally this work should not block the UI thread.
Actual behavior
The splash screen remains indefinitely. A process sample taken from UniGetUI 2026.2.7 contained 2,596 identical samples of the main thread blocked here:
Probable cause
In tag
v2026.2.7, the code reads stdout to completion before applying its timeout:Source:
https://github.com/Devolutions/UniGetUI/blob/v2026.2.7/src/UniGetUI.Avalonia/Infrastructure/ProcessEnvironmentConfigurator.cs
Because
ReadToEnd()blocks until the child closes stdout,WaitForExit(5000)is never reached when the login shell does not exit. The intended timeout is therefore ineffective.Suggested direction
Read stdout asynchronously, wait with cancellation/timeout first, kill the child process on timeout, and continue startup using the inherited PATH. Avoid performing the blocking lookup on the UI thread.