CLI: reuse the elevated broker instead of requiring an elevated shell

[mazany]

The problem

windhawk-cli carries no self-elevation manifest, so every writing command fails when run
from an ordinary shell:

Command	Unelevated result
mod install --file <path>	exit 12 REGISTRY_FAILED (RegCreateKeyEx … os error 5)
mod enable / mod remove	exit 11 / 12
mod config set, mod settings set	exit 12 at the write gate
app settings set	exit 12

Reads (mod list/show, * get, repo *, source meta, data export) work fine unelevated.

The install path is the expensive one. Unelevated, mod install --file compiles every
declared architecture first and only then hits the registry write, failing and rolling the
whole install back — so the user pays a full multi-architecture compile and gets nothing.
Verified on alpha.1 and re-verified on alpha.3: 242 mods before and after, no source, no
DLLs, no registry residue, mod show returns exit 4.

For anything scripted this leaves two bad options:

1. Run the entire session elevated — a far larger privilege grant than the individual
   operations need, and it makes every unrelated command in that session run as admin too.
2. One UAC prompt per operation — the caller builds its own elevation wrapper, and a
   normal edit → compile → deploy → test loop turns into a prompt per iteration, each of
   which a human has to be present to click.

Why this is askable

The UI does not have this problem any more. The privilege separation added in alpha.3 runs
an unelevated windhawk-ui.exe window alongside an elevated helper, talking over a named
pipe:

\\.\pipe\Windhawk.Broker.<id>

So a mechanism for "unelevated front end asks a privileged component to perform a Windhawk
operation" already exists and already ships. The CLI simply does not use it.

The request

Let windhawk-cli reach that same broker when it is running — either automatically, or
behind an explicit opt-in (--use-broker), falling back to today's behavior when there is
no broker. One prompt-free path for scripted use, reusing the trust boundary the product
has already drawn, rather than asking every caller to invent an elevation wrapper.

A smaller alternative, if exposing the broker is undesirable

If the broker should stay private to the UI, a much narrower change would still help a lot:
let the CLI elevate itself for one command — a manifest, or a --elevate flag that
relaunches via ShellExecute with runas. That is still one UAC prompt per command, but it
puts the elevation inside the tool (which knows exactly which operations need it) instead of
in every caller, and it removes the compile-then-fail-then-retry round trip: the tool would
prompt before doing the work rather than discovering the problem after it.

Why it matters

Local automation around Windhawk is real and growing — batch configuration, reproducible
setups, scripted dev loops, and agent-assisted mod development. All of it currently has to
choose between over-privileging a whole session and prompting the user on every write.
Everything else in the 2.x CLI is built for scripting: --json envelopes, distinct exit
codes 0–14, data export/import. Elevation is the one place where the CLI still assumes a
human at an admin prompt.

Notes

• Exit codes 11/12 are already a clean signal, so a broker path would not need new ones —
  the CLI could simply succeed where it currently returns 12.
• The alpha.3 error text already ends with hint: run this command as administrator, which
  is exactly the advice this request is trying to make unnecessary for scripted callers.

[m417z]

If the broker should stay private to the UI

It should for security reasons. Otherwise, you can as well just run the session elevated, which you rightfully noted is a large "privilege grant".

The install path is the expensive one. Unelevated, mod install --file compiles every declared architecture first and only then hits the registry write, failing and rolling the
whole install back — so the user pays a full multi-architecture compile and gets nothing.

I'll improve this to fail early before compilation begins.

For AI-assisted development for customizing non-elevated processes, you might prefer using the portable Windhawk version that can run unelevated.

[mazany]

Thank you. I'm already using custom elevated broker script, so I have to approve the UAC prompt just once per session.

What's your view on the smaller alternative?

let the CLI elevate itself for one command — a manifest, or a --elevate flag that
relaunches via ShellExecute with runas

[m417z]

I'll wait for more feedback from users. So far, there was no demand for it.

[muhammadrizo-y]

+1 for this. It would be really awesome if there was an easier way to do this without manually spawning an elevated terminal first.

[m417z]

@muhammadrizo-y what's your use case? AI? Automation?

Are you looking for a way for it to just work? Or will a UAC prompt work for you as well?

[muhammadrizo-y]

Raycast extension. UAC prompt would work but it would probably be too much if it appears every time when installing/uninstalling or enabling/disabling a mod

[m417z]

I see, that's a different use case. Disabling a mod doesn't have the same security implications as compiling a new mod (which allows running arbitrary code in any elevated process).