← All Solo, Not Alone posts

ai-coding process

The Test Run That Killed My Live Game Session

An agent running tests for The Lien was told to make sure no Godot process was running. It killed every process under the shared engine install, including the Earfh session I was playing, and I spent an afternoon chasing a crash that never happened.

On 2026-09-22 an agent running The Lien's tests was told to make sure no Godot process was running. The instruction is a reasonable one. A leftover engine process can lock files, and a test run on top of one can fail for reasons that have nothing to do with the code.

The agent did what the instruction said. It ran taskkill on every Godot process under the shared engine install. That install was also the one my Earfh session was running from. The game I was playing died mid-run with an exit code of 1, no crash report and nothing in the Windows event log.

An afternoon on a crash that never happened

A process that vanishes with no dump and no log entry looks like a crash with no evidence. It cost an afternoon of looking for a crash that never happened. Nothing was wrong with Earfh. Something had ended the process from outside, and the clean failure was the only clue.

The lesson I wrote down afterward has one sentence that I keep coming back to. Picking targets by name or by install path is the same mistake as picking by name.

Not the first collision

A month earlier the same machine had a milder version. On 2026-08-21 two sessions ran two Godot suites at once, and both projects wrote their logs to a shared temporary path. The other project's run overwrote the log, and a passing total of 976 tests against the wrong project's build was almost recorded as this project's result. The notes say plainly that contention was not established as that night's cause. It was a near miss, and it pointed at the same thing: I run several games and tools on one machine, and an agent in one project has no view of the others.

What I changed

Three rules came out of it, and they are written into my global instructions so every project's agents read them.

  • If a process blocks a run, report it and wait. Never kill, stop or taskkill a process the session did not launch itself, however stale it looks, and however it was found, whether by name, by install path or by searching for a process ID.
  • Track the process IDs a session launches, and run long jobs under a timeout, so cleanup targets exactly what that session started.
  • Give each project its own engine install where possible. Earfh now runs from its own copy, so a test run in another project cannot reach it by path.

The broader point is about what an instruction like "make sure nothing is running" means to an agent. It can read as check to me and as clear to the agent. When I work alone with agents on a shared machine, I have to say which processes are theirs, because the agent can only see what the machine shows it, and the machine does not show whose process is whose.

More on the games at /games/earfh and /games/the-lien, and the rest of this series at /notes.

← All Solo, Not Alone posts