Report: why everything on this machine launched slowly, and what was actually to blame

Architect_Dovetail, Claude seat, session bd4f70f6, 2026-09-01. This is a report, not a walk. It records one investigation from start to finish so the next folk who sees a two-second git call does not repeat it.

Durable objects: FIND-1348 (first attribution, wrong), FIND-1349 (the cause, eclipses 1348), FIND-1350 (the git helper cut). Status line script: ‹redacted: local coordinate›, outside the repo.

The short version

Every program on this machine started in about 15 milliseconds, except any file named python.exe, which waited half a second to over a second. AMD Radeon Software was detecting Python by name on every launch and holding the launch until it finished. Stopping Radeon Software fixed Python, the status line, and git in one stroke. Git was never the problem.

How it started

Human said the status line was not updating fluently and the Fable usage figure sat at 2 percent until they left the chat. Two separate things were true:

• The figure was stale by design. The host’s status payload carries only the 5-hour and 7-day windows. The per-model number lived in the host’s own cache in ~/.claude.json, which the host fetches at session start and rewrites at most every five minutes. The script now fetches usage itself, keeps it 90 seconds, and refreshes in a detached child so a render never waits on the network.
• The render was slow. Two git calls inside the script took 1.8 seconds of a 1.8-second render. The script now reads the branch off the git HEAD file and takes the dirty mark from a small cache, and launches nothing at render time. In-process work per render went from 1,792 milliseconds to 12.

The wrong turn

With git launches swinging from 40 milliseconds to 2.4 seconds, and bare Python from 30 milliseconds to 3.6 seconds, I blamed Windows process creation and Defender’s on-access scanning, and wrote FIND-1348 saying so with four remedies. Human added Defender exclusions. They bought about 20 percent. Git got fast on its own once the other folk went idle. Python stayed at 600 to 1,200 milliseconds for an empty program on an idle 9900X.

The lesson is in the method that followed, not in the miss.

The method that found it

1. Same bytes, different names. Copies of the Python binary named pyx.exe, pythonw.exe, perl.exe, node.exe, powershell.exe all started in 11 to 22 milliseconds. Named python.exe, the same bytes waited 500 to 1,200. Named python3.exe, half the time. So the tax keyed on the filename, and it was not a generic script-interpreter rule.
2. Where in the launch. Creating the process suspended and timing CreateProcess alone put the whole wait inside process creation, before Python’s first instruction. That is where kernel drivers run their callbacks. No Image File Execution Options, no AppInit DLLs, no injected modules, Smart App Control off.
3. Who does the work. Six launches of python.exe added 2.2 to 2.6 seconds of CPU to RadeonSoftware.exe. Six launches of pyx.exe added none. NVIDIA’s app-timestamp file never moved. Adrenalin’s profile blob at C:\Program Files\AMD\CNext\CNext\cn.blb carries "standalone_executable": "\\Python.exe".
4. Stop the suspect and re-measure.

The AMD GPU on this host is the 9900X’s integrated graphics. The RTX 4080 drives the display. Radeon Software also held 7,919 seconds of CPU, the most of any process on the machine.

What Human should do

Keep Radeon Software from starting: Task Manager, Startup apps, disable the AMD Software entry. Or uninstall AMD Software: Adrenalin Edition and keep the driver. The executable is C:\Program Files\AMD\CNext\CNext\Radeonsoftware.exe if it is wanted back. Python cannot be renamed for Corpus; every child launch uses sys.executable, which is python.exe.

What it changes for Corpus

FIND-1348 proposed four cuts on the theory that a launch cost 300 milliseconds. With launches at 15 milliseconds:

• Defender exclusions. Applied, harmless, small gain. Done.
• One shared git helper calling the real binary. Git for Windows ships a launcher in cmd\git.exe that starts the real program in mingw64\bin\git.exe, so every call is two launches. Measured healthy: 34 to 52 milliseconds through the launcher, 25 to 30 direct. Corpus has 114 git call sites and six private _git helpers. FIND-1350 gives the resolver and the fold. Worth doing for the consolidation; the speed is a footnote.
• Read git files instead of running git on read-only paths. Done for the status line; ordinary tidiness elsewhere.
• Run the test suite in-process. The suite launches corpus.py as a child about 140 times and took 31 to 33 minutes. A child launch now costs 15 milliseconds and the Corpus import 130, so launches account for about 20 seconds of that. A full run with Radeon Software stopped is in progress as this is written; if it is still long, the cost is inside the tests, not the launches, and that is a separate question.

Other objects from this seat today, for the record

PROP-286 to PROP-290 (post-teardown hygiene, acceptance packets, exact-model contract), FIND-1341 (code sweep), FIND-1344 (silent model fallback), FIND-1346 (first PATCH through the unified job rail), FIND-1347 (suite triage), PATCH-205 (mail file inputs), PATCH-206 (parser witness mouth), PATCH-208 (slice cleanup fixture), MSG-2395 (REQ-405 path cut). Each is readable with python house/offices/archivist/story.py <id>.