Launch on login (planned)

Short answer

Auto-launch on Windows login is on the roadmap. When it ships, Abliteration will be able to start with your Windows session and go straight to the tray, so the local HTTP bridge and deep links are already answering before you open the browser. Not enabled in the current release.

Detailed explanation

Why it’s coming. Two of Abliteration’s job-to-be-done depend on the app being available, not necessarily foregrounded:

• The local HTTP bridge can only give the site exact hardware numbers while Abliteration is running. If the app isn’t up when you open abliteration.org, the catalog falls back to browser guesses until you launch it.
• Deep links (abliteration://install-model?...) route into a running instance; if the app is closed, Windows has to spin it up before the URL can be handled, which adds a couple of seconds to the first click.

Both cases improve if the app is already resident, minimised to the tray, from the moment you sign in.

How it’ll work. The MSIX manifest gains a <uap5:StartupTask> entry so Windows treats Abliteration as a first-class startup app. That means:

• It shows up under Settings → Apps → Startup, where you can toggle it off just like any other app - Windows manages the on/off state, not us.
• On first launch after enabling, the app announces the feature once and asks you to confirm. Silent enrollment isn’t allowed by Store policy anyway.
• Launched from startup, the app opens directly to the tray - no window pops up, nothing steals focus.

Why it’s not in this release. The rebrand landed first. Autostart interacts with Store certification requirements around startup behavior and needs a small settings surface (a single toggle under Appearance, or a new Behaviour section) so the choice lives in-app as well as in Windows’ startup list. Both are one small PR each, and land in a follow-up.

What you can do today. If you specifically want the bridge available before you open the app, you can put a shortcut to Abliteration in your Windows Startup folder (shell:startup) - it’s a workaround, not the eventual design, and the app opens its main window rather than going straight to the tray. Once the real feature lands, delete that shortcut and use the in-app toggle.

Why it matters

The whole “site probes the app” story only works if the app is running when the browser looks for it. Making it running-by-default (with a real, respectful opt-in, not a stealth registration) is what makes the site → app loop feel instant instead of “wait, is it up?”.

Related

• Local HTTP bridge - what the app being up buys you
• Deep links - the other integration that benefits from a running instance
• System tray - where the app lives after startup