Repository navigation
Elevate automatically #4
Description
Hey,
Just discovered this project and it's a great tool! I've been thinking about improving ergonomics here and there, so a few issues might be coming your way ;)
How do you feel about trying to elevate automatically if not started as administrator? There are some libraries that already do it:
https://lib.rs/crates/privilege
https://lib.rs/crates/xelevate
You're already using the windows crate, so the best way might be how self_runas does it:
https://github.com/rustonbsd/self_runas/blob/main/src/lib.rs
I can create a PR, just let me know if you'd prefer a crate, or reimplementing it as part of throttle.
Activity
FrancescoCoding commentedon Sep 16, 2026
Hey @MCOfficer, thanks, as I said in #5 glad you like it, and more issues are very welcome!
Release builds already do this:
build.rsembeds arequireAdministratormanifest, sothrottle.exefrom the release zip triggers the UAC prompt on launch and never runs unelevated. The manifest is skipped for debug builds though, because it would also land in the test binaries and break cargo test (error 740). So if you ran cargo run from source you'd hit the "run as Administrator" error window, which I'm guessing is what happened?If that's the case I'd happily take a PR for a runtime fallback: check the token elevation and relaunch via ShellExecuteW with runas when needed. I'd prefer doing it with the windows crate we already depend on rather than adding a crate. It could be gated to debug builds only, or run unconditionally as a belt-and-braces fallback, I don't mind either way. One thing to watch: it has to happen before the single-instance mutex is taken, since that lives in the Global\ namespace and assumes the process is already elevated.
MCOfficer commentedon Sep 16, 2026
Oh, I guess I always explicitly ran the release binary as administrator and simply assumed it would fail otherwise. Oops x)
With that in mind, this issue seems useful, but low-priority. Might pick it up in the future.