Flow.Launcher/Helper/AutoStartup.cs (1)

173-200: Refactor suggestion

Add error handling for administrator privilege settings.

The method doesn't explicitly check if setting the RunLevel was successful, which could lead to silent failures.

private static bool ScheduleLogonTask(bool alwaysRunAsAdministrator)
{
using var td = TaskService.Instance.NewTask();
td.RegistrationInfo.Description = LogonTaskDesc;
td.Triggers.Add(new LogonTrigger { UserId = WindowsIdentity.GetCurrent().Name, Delay = TimeSpan.FromSeconds(2) });
td.Actions.Add(Constant.ExecutablePath);

+ bool requestedElevation = false;
// Only if the app is running as administrator, we can set the run level to highest
if (Win32Helper.IsAdministrator() && alwaysRunAsAdministrator)
{
td.Principal.RunLevel = TaskRunLevel.Highest;
+ requestedElevation = true;
}

td.Settings.StopIfGoingOnBatteries = false;
td.Settings.DisallowStartIfOnBatteries = false;
td.Settings.ExecutionTimeLimit = TimeSpan.Zero;

try
{
- TaskService.Instance.RootFolder.RegisterTaskDefinition(Logon TaskName, td);
+ var registeredTask = TaskService.Instance.RootFolder.RegisterTaskDefinition(Logon TaskName, td);
+
+ // Verify that elevation was set if requested
+ if (requestedElevation && registeredTask.Definition.Principal.RunLevel != TaskRunLevel.Highest)
+ {
+ App.API.LogWarning(ClassName, "Failed to set task to run with highest privileges");
+ // We don't fail the operation, just log a warning
+ }
+
return true;
}
catch (Exception e)
{
App.API.LogError(ClassName, $"Failed to schedule logon task: {e}");
return false;
}
}

Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml (1)

56-66: Consider adding a warning about security implications.

Running applications with administrator privileges can have security implications. Consider adding a more detailed tooltip or warning about the potential risks of always running with elevated privileges.

Example enhancement:

Title="{DynamicResource alwaysRunAsAdministrator}"
Icon=""
- Sub="{DynamicResource alwaysRunAsAdministratorToolTip}">
+ Sub="{DynamicResource alwaysRunAsAdministratorToolTip}"
+>
IsOn="{Binding AlwaysRunAsAdministrator}"
OffContent="{DynamicResource disable}"
OnContent="{DynamicResource enable}" />

Note: This assumes a WarningCardStyle exists or would need to be created.

Plugins/Flow.Launcher.Plugin.Program/UACDialog.xaml.cs (3)

12-13: Consider adding XML documentation and using consistent naming conventions for static fields.

Both msgBox and _result are static fields, but they use inconsistent naming conventions. Consider prefixing both with underscore for consistency, or use a consistent naming style.

- private static UACDialog msgBox;
+ private static UACDialog _msgBox;
private static MessageBoxResult _result = MessageBoxResult.None;

---

68-78: Clean up dialog instance consistently in button handlers.

The Button_Click method sets the dialog instance to null, but the field is static and might be accessed from other threads. Consider applying the same pattern to the KeyEsc_OnPress method.

private void KeyEsc_OnPress(object sender, ExecutedRoutedEventArgs e)
{
DialogResult = false;
Close();
+ _result = MessageBoxResult.None;
+ _msgBox = null;
}

private void Button_Click(object sender, RoutedEventArgs e)
{
if (sender == btnYes)
_result = MessageBoxResult.Yes;
else if (sender == btnNo)
_result = MessageBoxResult.No;
else
_result = MessageBoxResult.None;
- msgBox.Close();
- msgBox = null;
+ _msgBox.Close();
+ _msgBox = null;
}

---

80-85: Use consistent naming in Button_Cancel method.

The Button_Cancel method references msgBox directly, but should use the renamed field if you adopt the suggestion above.

private void Button_Cancel(object sender, RoutedEventArgs e)
{
_result = MessageBoxResult.Cancel;
- msgBox.Close();
- msgBox = null;
+ _msgBox.Close();
+ _msgBox = null;
}

Flow.Launcher/Helper/AutoStartup.cs (1)

120-131: Document startup method changes for administrator mode.

The code includes a good comment explaining why registry startup doesn't support administrator mode, but could benefit from additional documentation.

public static void ChangeToViaLogonTask(bool alwaysRunAsAdministrator)
{
Disable(false);
Enable(true, alwaysRunAsAdministrator);
}

public static void ChangeToViaRegistry()
{
Disable(true);
+ // Registry startup doesn't support running as administrator because it doesn't have an option
+ // to elevate privileges like the Task Scheduler does with RunLevel.Highest
// We do not need to use alwaysRunAsAdministrator for registry, so we just set false here
Enable(false, false);
}

Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs (5)

4-5: Namespace collision risk between WPF and WinForms types

Adding using System.Windows; to a file that is already importing System.Windows.Forms increases the likelihood of ambiguous type resolutions (MessageBox, Screen, DragEventArgs, ...).
Although you currently reference the enumerations by their full namespace (MessageBoxButton, MessageBoxResult) the next developer who tries to call MessageBox.Show (or similar) will hit a compile-time ambiguity.

Two low-effort mitigations:

-using System.Windows;
+using Wpf = System.Windows;

or import only the specific WPF types you need:

using System.Windows.MessageBoxButton;
using System.Windows.MessageBoxResult;

Either option keeps the intent clear and shields you from hidden compilation errors down the road.

---

26-27: Static cache of elevation status can become stale after restart-in-place

_isAdministrator is captured once when the SettingsPaneGeneralViewModel type is first touched.
If (in a future enhancement) you decide to elevate the process without a full application restart, this flag will remain false, giving you inconsistent behaviour.

Safer alternative: turn it into a computed property or refresh it inside CheckAdminChangeAndAskForRestart() right before the comparison.

-private static readonly bool _isAdministrator = Win32Helper.IsAdministrator();
+private static bool IsAdministrator => Win32Helper.IsAdministrator();

Then replace usages accordingly.

---

72-78: Restart prompt executes even when startup-task creation fails

CheckAdminChangeAndAskForRestart() is invoked regardless of whether AutoStartup.ChangeToViaLogonTask threw.
In the failure path we show the user two dialogs: one for the error and then another asking for a restart--yet we know the scheduled task is still out of sync.

Consider short-circuiting when the startup change fails or basing the restart prompt on the success flag returned by the helper.

---

94-113: Duplicate logic - consider extracting a helper

The UseLogonTaskForStartup setter repeats almost the same try/catch & restart-check block found in StartFlowLauncherOnSystemStartup.
Extracting this into a private method (e.g. UpdateStartupMethod(bool viaLogonTask)) would keep the two setters terse and DRY.

---

141-154: Restart helper could lose original command-line context

App.API.RestartApp(AlwaysRunAsAdministrator ? "runas" : string.Empty); forwards only the elevation flag.
If the user had started Flow Launcher with extra CLI arguments (portable mode, debug flags, etc.) they will be dropped during restart.

Recommend overloading RestartApp to accept an argument builder or capture Environment.GetCommandLineArgs() and re-use them when invoking the new process.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

Flow.Launcher/MainWindow.xaml.cs:598

• [nitpick] Variable name 'text' is too generic; consider renaming to 'notifyIconText' or similar to clarify its purpose.

Flow.Launcher/PublicAPIInstance.cs:93

• Verify that UpdateManager.RestartApp supports an overload with arguments; if not, this call will fail at runtime or cause a breaking change in the public API.

Flow.Launcher.sln (1)

292-303: Restore x64/x86 mappings for Flow.Launcher.Command
The new helper exe still maps every x64/x86 configuration back to Any CPU, so you never produce true platform-specific builds--same problem noted earlier. Please wire the mappings to their matching platforms (or drop the extra configurations entirely if the project is genuinely Any CPU).

- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x64.ActiveCfg = Debug|Any CPU
- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x64.Build.0 = Debug|Any CPU
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x64.ActiveCfg = Debug|x64
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x64.Build.0 = Debug|x64
- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x86.ActiveCfg = Debug|Any CPU
- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x86.Build.0 = Debug|Any CPU
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x86.ActiveCfg = Debug|x86
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Debug|x86.Build.0 = Debug|x86
- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x64.ActiveCfg = Release|Any CPU
- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x64.Build.0 = Release|Any CPU
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x64.ActiveCfg = Release|x64
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x64.Build.0 = Release|x64
- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x86.ActiveCfg = Release|Any CPU
- {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x86.Build.0 = Release|Any CPU
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x86.ActiveCfg = Release|x86
+ {A9976C5C-B73A-4D29-B654-EF1C0C4C9C8C}.Release|x86.Build.0 = Release|x86

Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml (1)

54-64: Consider adding explicit margin for UI consistency.

The implementation correctly follows the existing patterns for SettingsCard structure, bindings, and localization. The placement after startup settings is logical.

However, most other SettingsCards in this file have explicit Margin attributes (e.g., Margin="0 4 0 0" for related items). Consider adding a margin to maintain consistent spacing:

-
+

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Flow.Launcher/SettingPages/Views/SettingsPaneGeneral.xaml (1)

68-80: LGTM! Well-structured SettingsCard for admin mode.

The new SettingsCard follows the established patterns in the file with proper icon, localization bindings, and ToggleSwitch structure. The XAML syntax is correct and consistent with other settings cards.

Optional: Consider placement relative to startup settings.

The linked issue #2639 requested the option be placed "near" the startup setting. Currently, the admin card is positioned after "hideOnStartup" (lines 54-66), which places it several cards away from the "StartFlowLauncherOnSystemStartup" expander (lines 35-52). You might consider:

1. Placing it as a sub-item within the StartFlowLauncherOnSystemStartup expander (lines 44-51), or
2. Positioning it immediately after the expander (after line 52) with appropriate margin

However, the current placement may be intentional to group visibility/behavior settings together, so this is purely a UX consideration rather than a functional issue.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Flow.Launcher/App.xaml.cs (2)

447-457: Minor: Consider using null instead of empty string for Verb.

While an empty string works, using null more explicitly indicates "no elevation verb" when admin or forceAdmin is false.

Apply this diff if you prefer more explicit code:

- Verb = Win32Helper.IsAdministrator() || forceAdmin ? "runas" : ""
+ Verb = Win32Helper.IsAdministrator() || forceAdmin ? "runas" : null

---

62-67: Handle UAC cancellation to avoid crash and restart loop.

When RestartApp(true) is called before DI is configured, a cancelled UAC prompt (Win32Exception error 1223) will crash the app and trigger a restart loop on every subsequent launch.

Wrap the restart call in a try/catch block:

// Check if the application is running as administrator
if (_settings.AlwaysRunAsAdministrator && !Win32Helper.IsAdministrator())
{
- RestartApp(true);
- return;
+ try
+ {
+ RestartApp(true);
+ return;
+ }
+ catch (System.ComponentModel.Win32Exception ex) when (ex.NativeErrorCode == 1223)
+ {
+ // User cancelled UAC; continue startup without elevation
+ // Optionally log or notify the user
+ }
}

Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs (1)

120-144: Missing OnPropertyChanged notification breaks UI binding.

The AlwaysRunAsAdministrator setter at line 127 updates the underlying Settings property but doesn't call OnPropertyChanged(), preventing the UI from updating when the property changes programmatically (e.g., when loading settings or if changed by code).

Add the notification call after line 143:

// If we have enabled logon task startup, we need to check if we need to restart the app
// even if we encounter an error while setting the startup method
CheckAdminChangeAndAskForRestart();
}
+ OnPropertyChanged();
}

Flow.Launcher/App.xaml.cs (1)

302-313: Consider handling UAC cancellation when restarting as admin.

If the user cancels the UAC prompt, RestartApp(true) at line 312 will throw a Win32Exception, leaving the app in an inconsistent state (startup enabled but elevation status unchanged).

Wrap the restart call to handle cancellation gracefully:

if (API.ShowMsgBox(
API.GetTranslation("runAsAdministratorChangeAndRestart"),
API.GetTranslation("runAsAdministratorChange"),
MessageBoxButton.YesNo) == MessageBoxResult.Yes)
{
- RestartApp(true);
+ try
+ {
+ RestartApp(true);
+ }
+ catch (System.ComponentModel.Win32Exception ex) when (ex.NativeErrorCode == 1223)
+ {
+ // User cancelled UAC; log or notify
+ API.LogInfo(ClassName, "User cancelled elevation prompt");
+ }
}

Flow.Launcher/SettingPages/ViewModels/SettingsPaneGeneralViewModel.cs (1)

147-162: De-elevation not supported; document or extend.

The method only handles enabling admin mode (non-admin - admin) but not disabling it (admin - non-admin). When a user disables AlwaysRunAsAdministrator while running elevated, Flow remains elevated until the next manual restart, which could persist unintended elevation.

Consider prompting for restart in both directions:

private void CheckAdminChangeAndAskForRestart()
{
- // When we change from non-admin to admin, we need to restart the app as administrator to apply the changes
- // Under non-administrator, we cannot delete or set the logon task which is run as administrator
- if (AlwaysRunAsAdministrator && !Win32Helper.IsAdministrator())
+ var shouldBeAdmin = AlwaysRunAsAdministrator;
+ var isAdmin = Win32Helper.IsAdministrator();
+ if (shouldBeAdmin == isAdmin)
+ return;
+
+ if (App.API.ShowMsgBox(
+ App.API.GetTranslation("runAsAdministratorChangeAndRestart"),
+ App.API.GetTranslation("runAsAdministratorChange"),
+ MessageBoxButton.YesNo) == MessageBoxResult.Yes)
{
- if (App.API.ShowMsgBox(
- App.API.GetTranslation("runAsAdministratorChangeAndRestart"),
- App.API.GetTranslation("runAsAdministratorChange"),
- MessageBoxButton.YesNo) == MessageBoxResult.Yes)
+ if (shouldBeAdmin)
{
- // Restart the app as administrator
App.API.RestartAppAsAdmin();
}
- }
+ else
+ {
+ App.API.RestartApp();
+ }
+ }
}

If de-elevation is intentionally excluded, add a comment documenting this limitation.

Flow.Launcher/PublicAPIInstance.cs (1)

638-638: Minor: workingDirectory parameter not used for helper invocation.

Line 638 uses Environment.CurrentDirectory as the working directory for the helper process, ignoring the workingDirectory parameter resolved at line 631. While this may work for most cases, it creates an inconsistency between admin and non-admin execution paths.

Consider using the resolved workingDirectory for consistency:

- var result = Win32Helper.RunAsDesktopUser(
Constant.CommandExecutablePath,
- Environment.CurrentDirectory,
+ workingDirectory,
$"-StartProcess " +

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Flow.Launcher/Languages/en.xaml (1)

187-188: Consider mentioning security implications in the tooltip.

The setting and tooltip are clear, but users might benefit from understanding that running as administrator affects how launched applications inherit privileges. While the PR implements safeguards, a brief mention could help users make informed decisions.

Optional enhancement:

- Run Flow Launcher as administrator on startup
+ Run Flow Launcher as administrator on startup. Note: This may affect how launched applications receive permissions.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro