Module proc 

Spawning child processes without putting a window on the operator’s screen.

Every external program magi runs - the agent CLIs, git, gh, the configured verification commands - is a console application. What happens when one is spawned depends on whether the parent has a console, and magi has two kinds of parent:

• magi run / magi review in a terminal. The child inherits that console, writes nowhere visible because its pipes are redirected, and nothing appears.
• magi web, which serves the deck. Its successor is spawned DETACHED_PROCESS on purpose (see crate::web): it has to outlive the process that started it and must not hold a pipe a terminal is waiting on. That process has no console at all, so Windows allocates a brand new one for each console child - and draws it. An implement wave is three agents, so three black windows opened over whatever the operator was doing, in front of the browser they were reading the deck in.

CREATE_NO_WINDOW is the answer to exactly that: the child still gets a console for its standard handles, and that console is never shown. It is not the same as DETACHED_PROCESS, which gives the child no console and would make a grandchild pop a window of its own for the same reason.

Nothing here is conditional on how magi was started. A hidden console is correct in a terminal too: the pipes are redirected either way, so there was never anything to look at.

Traits

Quiet

Spawn without a visible console window.

Functions

pid_alive

Best-effort liveness check for a process id, with no dependency beyond what the platform ships.

pid_status

A three-valued liveness read, for a caller that displays whether a process is running rather than deciding whether it is safe to reclaim a lock. pid_alive’s Err-means-alive policy exists to protect a lock a live process still holds — the wrong bias for a report that must never tell an operator a process is confirmed dead just because this build could not ask the platform. None here is the honest “could not tell”, left for the caller to render as its own “unknown” rather than folded into either Some answer.

process_started_at

An opaque marker identifying which process currently holds pid, not merely whether the number is in use — the OS-reported moment it started. Compared only for equality by the caller, never parsed as a timestamp: the two platform formats are not on the same scale, and nothing here needs to be.