I'd already traced it back to Headroom. Nothing was actually broken, but the window was distracting, and I wanted to know what was causing it.

I'd wanted to contribute to open source for a while, so I decided to investigate and opened a PR. I thought it would be a small change to hide the window.

It turned into a bit more than that.

Why was the window appearing?

Headroom runs background health checks on Windows to keep its runtime working. In one fallback setup, Windows Task Scheduler launches these checks through PowerShell.

That was where the flashing window came from.

The fix was to launch PowerShell through a small VBScript wrapper that keeps the window hidden.

Before, the scheduled check could open a console. After, the same check runs without showing one.

The important line looks like this (simplified):

Set shell = CreateObject("WScript.Shell")
shell.Run "powershell.exe ...", 0, True

The 0 hides the window. The True tells the script to wait until PowerShell finishes.

That second part turned out to matter more than I initially realized.

Why waiting matters

If you change True to False, the console is still hidden:

shell.Run "powershell.exe ...", 0, False

But the VBScript launcher now exits immediately, even if PowerShell is still running.

The problem is that Task Scheduler tracks the launcher. Once it exits, Windows can treat the scheduled task as finished while the actual health check is still working in the background.

That matters because Headroom tries to avoid overlapping checks. It also needs to stop recovery work cleanly when shutting down. Both are harder if Windows thinks a task has already finished.

False lets the launcher exit early. True keeps it alive until PowerShell finishes.

I'd started out thinking about how the process looked on screen. The review helped me see why its lifetime mattered too.

Two more things we fixed

While working on the PR, a couple of related Windows cases needed attention.

Starting without the usual startup task

On some Windows setups, Headroom can't create the usual privileged startup task and uses a fallback instead. But its startup path could still try to run the task that wasn't there.

Simply ignoring that failure wasn't enough. The next scheduled health check could be several minutes away, while Headroom only waited a short time for startup.

The fix was to start the runtime directly when that missing task is expected in the fallback setup, without hiding unrelated errors.

A shutdown check that treated “unknown” as “wrong”

Headroom checks a process's identity before acting on it during shutdown. Sometimes Windows can't provide that information while a process is exiting.

The old condition was:

if _process_identity(pid, manifest) is not True:

The updated condition is:

if _process_identity(pid, manifest) is False:

The difference is how None is handled. False means the process doesn't match; None means Headroom couldn't confirm either way.

Treating an unknown result as a definite mismatch could stop shutdown polling too early. The new check avoids that.

Getting the PR merged

Jerrett Davis reviewed PR #4627 and caught important details I'd missed, particularly the wait behavior and fallback startup. I updated the code and tests based on his feedback.

The PR was merged on November 5, 2026, and included in Headroom v0.43.0.

It's my first open-source contribution, and it's now part of a tool I use myself. That feels pretty good.

I went in to get rid of a flashing window. I came out understanding Windows background tasks a lot better.

Thanks to Jerrett for taking the time to review it so carefully.

PR: headroomlabs-ai/headroom #4627
Release: Headroom v0.43.0
Related issues: Console flashing #2453 · Windows installation permissions #3418