Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329

[agent] Found by the scheduled Poetry bug-hunt routine (ledger #311).

Summary

On Windows, socket-patch scan --mode agent in a plain Poetry project (default config, so the venv lives under %LOCALAPPDATA%\pypoetry\Cache\virtualenvs\<name>-<hash>-py3.X) never finds that venv. The crawl falls through to the global interpreter (scannedPackages: 10), reports the patch skipped / package_not_installed, and exits 0 with "status": "success". The venv's six.py stays unpatched. The identical project passes on Linux and macOS ("action": "added", file patched).

Impact

Agent mode, the default and smallest-footprint mode, silently does nothing for every default Windows Poetry user, and CI gating on the exit code passes. Poetry's docs, and ours (docs/testing/poetry-compatibility.md, "Mode notes": "a bare socket-patch scan --mode agent / rollback in a default-configured Poetry checkout works"), say this should work. The Poetry compatibility workflow is POSIX-only (poetry-compatibility.yml: "POSIX only"), so nothing tests it on Windows.

Repro (windows-latest, Git Bash)

mkdir agent-named && cd agent-named
cat > pyproject.toml <<'EOF'
[tool.poetry]
name = "probe-named"
package-mode = false

[tool.poetry.dependencies]
python = ">=3.8"
six = "1.16.0"
EOF
poetry install --no-root     # -> C:\Users\runneradmin\AppData\Local\pypoetry\Cache\virtualenvs\probe-named-_osmcDyb-py3.12
SOCKET_API_URL=http://127.0.0.1:<mock> SOCKET_API_TOKEN=fake SOCKET_ORG_SLUG=test-org \
  socket-patch scan --mode agent --json --yes
# -> scannedPackages 10, apply.patches[0] = {"action":"skipped","errorCode":"package_not_installed"}, exit 0

(The mock serves the same routes as tests/e2e_vex_build/poetry.rs. The full probe script is inlined in the workflow runs below.)

Expected vs actual

• Expected: the crawler resolves poetry env info -p and patches it, as on Linux and macOS.
• Actual: no Poetry venv found, package_not_installed, exit 0.

OS × Poetry matrix (agent mode, default out-of-tree venv, named project)

On the same Windows runners, hosted and vendored mode work (LF and CRLF locks: poetry install installs the patched wheel, and rollback restores the lock byte for byte), so this is specific to agent-mode venv discovery.

First bad version

Never worked on Windows. Out-of-tree Poetry venv discovery was added in ff6aaae (#241, unreleased), and released 4.0.0 has none on any OS.

Suspect code

crates/socket-patch-core/src/crawlers/python_crawler.rs:489 poetry_normalized_cwd hashes std::fs::canonicalize(cwd). On Windows that returns a verbatim \\?\C:\… path. Poetry hashes os.path.normcase(os.path.realpath(cwd)), which has no \\?\ prefix (and a lowercased drive), so the 8-char base64 hash never matches and find_poetry_virtualenv_site_packages finds no <name>-<hash>-py prefix. Stripping the verbatim prefix (e.g. dunce::canonicalize) before normcase should fix it. A Windows known-answer test for poetry_env_name_prefix against a real poetry env info -p would guard against a regression. The discovery of %LOCALAPPDATA%\pypoetry\Cache itself looks right: the root is what Poetry reports.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36733821105 (agent discovery, 3 OS × Poetry 1.8.5 / 2.0.1 / 2.4.3)
• https://github.com/SocketDev/socket-patch/actions/runs/36734791994 (long-path agent + hosted/vendored LF/CRLF, 3 OS × Poetry 1.8.5 / 2.4.3)

Related: #327 (Poetry env-name derivation gaps on every OS).