The window that typed my words into the wrong place

By Brian · 6 min read · Last saved August 1, 2026

I was halfway through a sentence when the window appeared.

It was a console window, black, maybe two inches tall, and it belonged to a script that had just started doing something useful in the background. It took the keyboard with it. The rest of my sentence went into it instead of into the form I was filling in, and one of those characters was Enter, and the console did what consoles do with Enter.

Nothing crashed. There was no error. The form I had been filling in was simply gone, along with about ten minutes of typing, and the only evidence that anything had happened was a window that closed a second later.

I lost that ten minutes to a program I wrote, doing a job I asked for, working correctly.

Focus theft is data loss

It is easy to file this under annoyance. A window pops up, you swear at it, you carry on. But a window that steals the keyboard while a person is typing does not just interrupt them: it takes whatever they type next and gives it to something else. If that something else is a shell, the keystrokes are commands. If it is a dialog, one of them is an answer.

The distance between “mildly irritating” and “silently destroyed ten minutes of work” is one keystroke, and which side you land on is luck.

So the rule here is not “try to avoid popping up windows.” It is that a background job must be incapable of taking the foreground, and that has to be true by construction, because a rule you have to remember is a rule you will forget on the afternoon you are in a hurry.

The part that surprised me

The obvious mental model is wrong, and being wrong about it is what causes the bug.

You would assume a program launched quietly stays quiet, and that its children inherit that. The opposite is true on Windows. A console program attaches to its parent’s console if one exists. If the parent has no console, the child cannot attach to anything, so it allocates a brand new visible one.

Read that again, because it inverts the intuition completely: making the parent quieter is what makes the child loud. The scheduled task with no window, the always-on agent running headless, the service started at boot – those are precisely the parents whose children flash a console into the middle of your screen. The more carefully you have hidden the parent, the more reliably the child appears.

That is why this bug survives so long in a codebase. It does not show up while you are developing, because you are running things from a terminal that already has a console for the child to borrow. It shows up in production, on someone else’s machine, at a moment nobody is watching.

Launching a background process on Windows without a console window

Give the child a console it can have, and make it invisible. On Windows that is a single creation flag, and the important property is that grandchildren inherit it – so the whole process tree stays silent, including the parts you did not write and cannot change.

The fix is small. Making it stick is the real work, because the failure mode is a single ordinary spawn call written months later by someone who never lost ten minutes. So it goes in one shared helper that every spawn goes through, and a check fails the build if a raw spawn appears anywhere else. Not because the helper is clever, but because “everyone remembers to use the helper” is not a mechanism, and this is a bug you only notice by being its victim.

A few related traps, all the same shape – something that seems hideable and is not:

• The “Hidden” checkbox in a task scheduler hides the task from the list. It does not hide the window. Two different things wearing one word.
• A .bat wrapper flashes a console before it runs anything at all, so wrapping a silent program in one makes it loud.
• Opening a file through its default application hands control to a GUI you cannot suppress.
• An interactive prompt inside a hidden console does not fail. It hangs, invisibly, forever, waiting for an answer from a window nobody can see.

That last one is the worst of them, and it is the one that taught me the general lesson: hiding a thing does not remove its need to be interacted with. It just removes your ability to notice.

The rule

A background job must be unable to take the foreground, enforced in one place that every spawn goes through.

Not “avoid popping windows.” Not “remember the flag.” One helper, one check that fails when someone bypasses it, and a default that is silent even when the caller forgets to ask for silence.

The person this protects is the one typing, who has no idea any of this exists and should not have to.

Get the skill

Everything above is generic. None of it is about rats, and none of it is specific to this site. So the rule is also published on its own as a Claude skill: a single Markdown file that an AI coding assistant reads and applies when the situation comes up.

The file: windows-silent-subprocess/SKILL.md

Or take the whole set:

git clone https://github.com/blonderoofrat/agent-skills

Installing it in Claude Code. Copy the skill’s folder into one of these, so the file ends up at .../skills/windows-silent-subprocess/SKILL.md:

• ~/.claude/skills/ (available in every project on your machine)
• your-project/.claude/skills/ (that one project only)

Claude reads it at the start of the next session and applies it when what you are doing matches the description at the top of the file. You can also ask for it by name.

Using a different assistant? The file is plain Markdown with a two-line header. Paste the body into whatever system prompt, rules file or instructions file your tool uses. Nothing in the rule itself is Claude-specific.

Licence: CC0, public domain. Copy it, adapt it, ship it in commercial work, no attribution required. These are deliberately frozen snapshots rather than a maintained project, so if one is wrong for your situation, change it. That is easier than asking us to.

---

Part of Notes from building this site: articles about working practices that exist because something here went wrong first. The rule above is also published on its own, as a free public-domain instruction file for AI coding assistants — the windows-silent-subprocess skill, in blonderoofrat/agent-skills on GitHub.