Windows: launch crashes on registry save (os.rename) and every command crashes (os.kill(pid, 0))

[omerlefaruk]

Two Windows-only crashes prevent the CLI from working at all on Windows (verified on Win 11, chrome-agent 0.5.7, Python 3.13, Chrome 151).

Bug 1: launch fails with FileExistsError on every launch after the first

registry.py:83 (_save_registry) uses os.rename(tmp_path, registry_path) for atomic save. On POSIX rename(2) overwrites the destination; on Windows it does not — it raises FileExistsError: [WinError 183] Cannot create a file when that file already exists whenever registry.json already exists (i.e. every launch after the first).

File "chrome_agent/registry.py", line 83, in _save_registry
    os.rename(tmp_path, registry_path)
FileExistsError: [WinError 183] Cannot create a file when that file already exists: 'C:\tmp\chrome-agent\registry.json.tmp' -> 'C:\tmp\chrome-agent\registry.json'

Fix: os.replace(tmp_path, registry_path) — atomic overwrite on both platforms.

Worse, the crash happens after Chrome was launched, so the browser process is orphaned with no registry entry — cleanup can't find it.

Bug 2: every command (status, one-shot, etc.) crashes in the liveness check

utils.py process_is_running / process_is_ours use os.kill(pid, 0) as an existence probe — a POSIX signal-0 idiom. On Windows this raises OSError: [WinError 87] The parameter is incorrect instead of returning, so every command that enumerates the registry dies:

File "chrome_agent/utils.py", line 42, in process_is_ours
    os.kill(pid, 0)
OSError: [WinError 87] The parameter is incorrect

Also process_start_time can only read /proc/<pid>/stat or ps -o lstart= — both absent on Windows — so the PID-recycling protection silently degrades to None.

Fix: probe via OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) + GetExitCodeProcess (STILL_ACTIVE), and derive the start token from the GetProcessTimes creation FILETIME. I verified this ctypes approach locally and it restores full functionality.

Tested working after local patches

• launch / status / stop / cleanup
• one-shot Runtime.evaluate, Page.navigate, Page.captureScreenshot
• attach event streaming (Page.frameNavigated, Page.loadEventFired)
• attach auto-exits when the instance is retired

Happy to open a PR with both fixes (both are small and stdlib-only).

[captivus]

Heya! I don't run Windows anywhere so I have no way to observe this bug directly. If we can get some additional validation of the bug from other Windows users, I'd welcome a PR / patch.

[katsugtgz]

Confirmed on Windows: both crashes, plus one more

Second Windows repro. Win 10 Pro (19045), Python 3.13.15, Chrome 151, chrome-agent 0.5.7 from PyPI.

Bug 1: with registry.json already on disk, launch dies before Chrome even starts, in the pre-flight cleanup_sessions sweep. Same FileExistsError: [WinError 183] at registry.py:83. os.replace is the fix, as proposed.

Bug 2: bug 1 blocks registration, so I seeded a live PID into the registry by hand. status then throws the exact reported OSError: [WinError 87] at utils.py:42. Live and dead PIDs both raise 87, so the probe can't tell them apart. The ctypes approach works, and staying stdlib-only is the right call.

One more, not in the issue: on a fresh install launch never reaches either crash. Windows chrome.exe is a stub: it hands off to a child and exits 0, and the phase-5 wait loop in launcher.py treats that as "Chrome exited immediately" while the browser is up and serving CDP. Port-readiness needs to beat stub-liveness there. Worth folding into the same PR.

Minor: the os.kill(pid, 15) fallbacks in registry.py become TerminateProcess() hard kills on Windows. Works, just not graceful; a comment would do.

This box is available to test any PR branch.

PS: Love your AIE videos man! Very insightful! @captivus

The Dark Arts of Web Automation: Teaching Agents to Use Websites Like Humans — Corey Gallon, Rexmore

[captivus]

@katsugtgz thanks for confirming, and for the kind words!

@omerlefaruk and @katsugtgz I'd welcome a collaborative PR from both of you, if you're up for it! @omerlefaruk if you'll fork the repo create a branch (e.g. fix/windows-support) and then the two of you can collaborate in that branch, pushing commits to your fork. Please make sure that you include tests that fully validate the fix. I'll leave it to the two of you (assuming you're both keen) to sort out who does what.

Then, submit a PR and we'll get this fixed for everyone! How's that sound?