Bug hunt ledger: Poetry

[Mikola Lysenko (mikolalysenko)]

[agent] Progress ledger for the scheduled Poetry bug-hunt routine (label pm:poetry).

Last updated: 2026-10-01 (run 6), main 61cfb9b (includes #330, #446, #452, #456), latest release 4.0.0 (previous 3.3.0).

Coverage matrix

Cells are "pass", "fail #N" or "untested". Hosted and vendored cells use a local mock of the patch API (patches-api.socket.dev is blocked from the sandbox) serving a patched six-1.16.0 wheel, then a real poetry install / poetry sync and a byte check of the installed file. The existing poetry-compatibility.yml matrix (Linux + macOS) covers the plain cells against production. Rows before run 3 were measured on main f6b7fb9 (pre-v5). Run 3 re-measured the cells marked "v5". Run 5 re-measured the cells marked "r5" on 6e7ef74 (after #330); #327 cells on macOS / Windows still show the pre-fix result because probe branches are blocked.

OS	Poetry	Agent (in-project .venv)	Agent (default out-of-tree venv)	Agent: nameless package-mode=false / [project].name override / in-project=false + stray .venv	Agent + hosted VEX: in-project=true, no .venv, existing out-of-tree env	Hosted (scan, install, rollback)	Hosted VEX with undiscovered venv	Vendored	Mode switch hosted ⇄ vendored	Vendored repair (lock-only, wheel deleted)
Linux	0.12.17	untested	untested	n/a	untested	pass v5 (refused, redirect_poetry_lock_unsupported)	n/a	pass v5 ([metadata.hashes])	n/a	untested
Linux	1.0.10	untested	untested	n/a	untested	pass v5 (lock 1.0 native-empty + populated; pip ≥ 23.1)	untested	pass v5 (populated lock 1.0)	untested	untested
Linux	1.1.15	pass v5	untested	n/a	fail #476	pass v5 (lock 1.1, extras + dev); r5 dotted name jaraco.context rewrite/install/vex/rollback	untested	pass v5 (LF + CRLF, unicode/space path)	untested	untested
Linux	1.2.2	untested	untested	n/a	untested	pass v5 (lock 1.1, extras + dev, warm-venv stale check)	untested	pass (lock 1.1)	untested	untested
Linux	1.8.5	untested	pass	pass r5 (fixed by #330; nameless, in-project=false, unicode path)	fail #476	pass v5 (LF + CRLF)	pass r5 (#330)	pass v5 (LF + CRLF, unicode/space path)	untested	pass v5 (#380 fixed)
Linux	2.0.1	untested	pass	pass r5 (fixed by #330; nameless, in-project=false, unicode path, both names)	fail #476	pass v5 (LF + CRLF)	pass r5 (#330)	untested	untested	untested
Linux	2.1.1	untested	untested	untested	untested	pass v5 (repo e2e, up to rollback)	untested	pass v5 (repo e2e)	untested	untested
Linux	2.3.3	pass	pass	fail #327 (pre-#330, not re-run)	untested	pass (groups, markers, path/url deps, supersede, dry-run, get)	untested	pass (path/url deps)	fail #328	fixed (#380)
Linux	2.4.3	untested	pass	fail #327 (pre-#330, not re-run)	untested	pass (LF + CRLF)	untested	pass (LF + CRLF, CI)	untested	fixed (#380)
Linux	2.5.1	pass v5	pass r5 (full agent cycle incl. rollback + vex)	pass r5 (all 3 cases, plus long names, symlinked dir, relative / {cache-dir} / ~ virtualenvs.path, XDG_CACHE_HOME, .venv symlink)	fail #476 (poetry.toml + user config)	pass v5 (LF + CRLF, PEP 621 extras/groups/markers, sync, remove, dry-run, get, relock/add, directory targets)	pass r5 (#330: stale check fires)	pass v5 (LF + CRLF, unicode/space path)	hosted→vendored pass r5; vendored→hosted fail #328	pass v5 (#380 fixed)
macOS	1.8.5	untested	pass	fail #327	untested	pass (LF + CRLF)	untested	pass (LF + CRLF)	untested	untested
macOS	2.0.1	untested	pass	fail #327	untested	untested	untested	untested	untested	untested
macOS	2.4.3	untested	pass	fail #327	untested	pass (LF + CRLF)	untested	pass (LF + CRLF)	untested	untested
macOS	2.5.1	untested	untested	untested	untested	untested	untested	untested	untested	untested
Windows	1.8.5	untested	fail #329	fail #327	untested	pass (LF + CRLF)	untested (likely #327/#329)	pass (LF + CRLF)	untested	untested
Windows	2.0.1	untested	fail #329	fail #327	untested	untested	untested	untested	untested	untested
Windows	2.4.3	untested	fail #329	fail #327	untested	pass (LF + CRLF)	untested (likely #327/#329)	pass (LF + CRLF)	untested	untested
Windows	2.5.1	untested	untested	untested	untested	untested	untested	untested	untested	untested

Global mode (-g / --global-prefix / SOCKET_GLOBAL=1), agent patches (run 4)

Global installs aren't Poetry-specific (Poetry never installs globally unless virtualenvs.create = false), so these cells were run from inside a Poetry 2.1.1 project (in-project .venv) against a real pip install --user copy and a pip install --target prefix.

OS	Cell	Result
Linux	scan -g report-only (--json): global user-site six found, project .venv and lock-only packages don't leak in	pass
Linux	scan -g sees Debian/apt .egg-info installs	fixed by #452 (but see #501)
Linux	scan -g sees Poetry's official-installer venv (~/.local/share/pypoetry/venv)	fail (commented on #415)
Linux	scan -g --mode hosted, --global-prefix --mode hosted, SOCKET_GLOBAL=1 --mode hosted: exit 2, poetry.lock untouched	pass
Linux	scan -g --mode agent, re-run idempotent, get <uuid> -g, SOCKET_GLOBAL=1 get: global copy patched, .venv and lock untouched	pass
Linux	vex -g attests applied global patch; plain vex refuses (not_applied)	pass
Linux	rollback -g restores the global copy byte for byte	pass
Linux	Cross-scope rollback (project apply + rollback -g, or -g apply + rollback)	fail #450 (still on 61cfb9b, r6)
Linux	scan -g / create = false project scan with the same release in user site and a system dir (apt egg-info or /usr/local dist-info)	fail #501 (patches the shadowed system copy; apt case regressed in #452)
Linux	#436/#445 on a hosted Poetry project: get -g --mode hosted|vendored, scan -g --mode hosted|vendored refuse; rollback -g / remove -g leave poetry.lock alone	pass (r6)
Linux	Poetry virtualenvs.create = false, single system copy	pass (r6: 1.8.5, 2.0.1, 2.2.1, 2.5.1)
Linux	vex -g from a hosted, synced Poetry project with an unpatched global copy: refuses (not_applied)	pass (r5)
Linux	list -g from a hosted Poetry project lists the project's hosted pin	not filed (PR #446 notes it)
Linux	Read-only --global-prefix (non-root user, path with space + é): human mode shows the error, exit 1	pass; JSON drops the error (#424)
Linux	Project scan without -g, Poetry venv undiscovered / not created yet: falls back to and patches the global interpreter	#327 layouts fixed by #330 (r5); still happens for in-project = true + no .venv (#476, re-confirmed r6 on 61cfb9b; now lands in apt's dist-packages)
macOS / Windows	all of the above	untested (probe branches blocked)

Backlog

1. Global mode on macOS / Windows (maintainer request), including With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501's ordering on macOS (user site ~/Library/Python/3.X/... vs Homebrew / python.org framework site-packages). This needs probe branches.
2. macOS / Windows: verify Fix Poetry venv discovery to match Poetry (#327, #329) #330 (Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329 Windows hash; macOS case-preserving realpath), plus hosted/vendored on 2.5.1 and long paths (> 260 chars). This needs probe branches.
3. Probe branches are blocked: git push --delete still fails (runs 1–6). A maintainer needs to delete bughunt/poetry/20260930-venv-discovery and bughunt/poetry/20260930-windows-modes.
4. Venv precedence corners: VIRTUAL_ENV set while envs.toml has an entry for the project, conda CONDA_PREFIX, several poetry env use minors.
5. socket.yml policy (minSeverity, package filters, maxNewPatches) on a Poetry project with several patches.
6. Poetry 0.12 / 1.0 agent mode with an out-of-tree venv (pre-1.2 hash).
7. Hosted rollback when PyPI's file list differs from the lock (confirm the refusal is loud).
8. Fix agent scan/get skipping apply for recorded patches (#454) #456 on Poetry: after a poetry sync reinstall, scan --mode agent re-applies the recorded patch.

Known non-bugs

• patches-api.socket.dev / patch.socket.dev / api.socket.dev are blocked by the sandbox proxy (403). Use a local mock API (SOCKET_API_URL).
• The CLI's rustls client doesn't trust the sandbox's re-terminating proxy CA. So vendored PyPI fetches (vendor_fetch_failed) and v5 hosted rollback/remove (re-resolves https://pypi.org/pypi/<name>/<ver>/json) fail in the sandbox. Point SOCKET_PYPI_JSON_API at a local HTTP forwarder that also rewrites files.pythonhosted.org. The repo's e2e_vex_build -- poetry:: hosted test scrubs SOCKET_*, so its rollback step fails in the sandbox for the same reason. Not a product bug.
• A poetry.lock with a UTF-8 BOM is rejected by Poetry itself ("Invalid statement (at line 1, column 1)").
• A lock whose packages come from a custom [[tool.poetry.source]] (even a PyPI mirror, priority = "primary") is refused by hosted (redirect_poetry_lock_unsupported, exit 0) and vendored (pypi_poetry_source_already_exists, exit 1) before any write. Documented ("a user-authored [package.source] on another origin").
• Agent-mode vex on a project with no install hook reports ecosystem_not_setup / no_applicable_patches. Documented.
• vex on a package-mode = false project with no version needs --product (product_undetected). Expected.
• Poetry 1.8 ignores PEP 621 [project] dependencies, so "[project].name + [tool.poetry].name" is n/a before 2.0.
• CLI_CONTRACT.md lives at crates/socket-patch-cli/CLI_CONTRACT.md, not the repo root.
• Running from a subdirectory of a Poetry project doesn't find it: pypi is cwd-only (CLI_CONTRACT.md "Monorepo / multi-project discovery model"; use --cwd or a directory target).
• On Poetry < 1.4, vendored emits pypi_poetry_integrity_unverified and hosted emits redirect_poetry_stale_install_risk. Both are deliberate advisories.
• On Poetry 1.1–1.3, a warm venv keeps the upstream bytes after a hosted rewrite, even when Poetry prints "Updating six (1.16.0 -> 1.16.0 )". Documented. v5 flags it as redirect_pypi_stale_install and refuses VEX.
• poetry check --lock fails on Poetry 1.1 / 1.2 (1.2 has no --lock option, and 1.1's check crashes). This isn't caused by socket-patch.
• Poetry 1.0 + pip 22.3 / 23.0 (e.g. venvs seeded with pip 23.0.1) refuses the hosted wheel's #sha256=…&#egg= fragment. Documented, and named in the redirect_poetry_stale_install_risk detail. Use pip ≤ 22.2 or ≥ 23.1.
• Poetry 1.0 writes empty [metadata.files] against today's PyPI. Documented (backtest "populated" shape).
• Vendored --vex on a warm, unpatched venv still attests, with the warning vendored_tree_out_of_sync. Documented in CLI_CONTRACT.md.
• list / standalone vex only recognise hosted pins on Socket's origin. A mock origin needs --patch-server-url.
• scan --json with several directory targets is refused ("--json takes one project directory").
• v5 removed --vendor-source build (local artifact construction). Repair re-downloads from the service.
• Agent rollback needs the "before" blob from /v0/orgs/<org>/patches/blob/<hash>. A mock without that route gives missing_blob.
• scan --mode agent re-run after a failed apply says [skip] … (already recorded) and exits 0 with the file unpatched. That's by design (it prints "run socket-patch apply to re-apply them"), and apply / vex then report the failure correctly.
• My mock answers every per-ecosystem batch with the same patch, so a mode-less multi-ecosystem scan lists six twice. That's a mock artifact; pass --ecosystems pypi.
• In the sandbox, /usr/lib/python3/dist-packages/six is an apt .egg-info install, invisible to the crawler (Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447). Use pip install --user --ignore-installed for a real global copy.
• POETRY_VIRTUALENVS_IN_PROJECT=yes / on is true to socket-patch and false to Poetry (boolean_normalizer accepts only "true" / "1"). Theoretical, not filed.
• The CLI's PyPI requests (hosted rollback, hosted → vendored takeover) need SOCKET_PYPI_JSON_API pointed at a local forwarder in the sandbox. Without it the takeover fails closed with redirect_revert_failed. A forwarder script that rewrites files.pythonhosted.org works.
• Concurrent scan runs in one project: the extra runs exit 1 with "Another socket-patch process is operating in this directory" (use --lock-timeout). This is by design.
• Dotted names (jaraco.context): Poetry 1.1 keeps the dotted name in the lock (quoted [metadata.files] key), Poetry ≥ 1.8 canonicalizes it. Hosted rewrite, install, vex and rollback all work with both purl spellings (r5).
• rollback -g --json with no manifest returns error as a plain string ("Manifest not found"), not a {code, message} object. This is a shape nit, not Poetry-specific, and not filed.
• Poetry 1.8 – 2.2 with virtualenvs.create = false running as root in this image reinstall a user-site package into /usr/local/lib/python3.11/dist-packages. That's Poetry's behaviour, not socket-patch.

[github-actions[bot]]

[agent] 2026-09-30: Poetry bug-hunt run

This is the first run, so the ledger started empty and there were no pm:poetry issues to re-triage.

Tested: main f6b7fb9 (CLI reports 4.0.0), latest release 4.0.0, previous release 3.3.0 (4.0.0 is used for first-bad checks).

Setup: the sandbox can't reach the Socket patch API (proxy 403), so a local mock API served a real patched six-1.16.0 wheel (plus jaraco.functools-3.5.0). Every cell ran a real Poetry release: poetry lock / install / sync / check --lock, then a byte check of the installed file. macOS and Windows ran through two probe workflows.

Cells

• Agent, default out-of-tree venv, named project:
  • pass: Linux 1.8.5 / 2.0.1 / 2.3.3 / 2.4.3, macOS 1.8.5 / 2.0.1 / 2.4.3.
  • fail on Windows 1.8.5 / 2.0.1 / 2.4.3 → Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329. Reproduced on an 8.3 temp path and on a long D:\ path.
• Agent: nameless package-mode = false, [project].name + [tool.poetry].name, in-project = false + stray .venv: fail on every OS and version → Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327.
• Agent lifecycle on Linux 2.3.3 (scan, idempotent rescan, poetry sync keeps patch): pass. rollback, repair and remove were blocked by my mock (no blob route), so these aren't bugs.
• Hosted, Linux 2.3.3: pass for groups (optional) + markers, transitive package, poetry sync / --with, path + url deps, superseding uuid re-pin, --dry-run, get --mode hosted, VEX, and byte-exact rollback.
• Hosted, legacy lock 1.1 with a dotted name (jaraco.functools: quoted [metadata.files] key on 1.1.15, normalized on 1.2.2): pass, including install and rollback.
• Hosted and vendored, LF + CRLF locks (install, check --lock, rollback exact): pass on Linux 1.8.5 / 2.4.3, macOS 1.8.5 / 2.4.3 and Windows 1.8.5. Windows 2.4.3 was still running when this entry was written.
• Vendored, Linux 2.3.3 with path/url deps: pass.
• Mode switch hosted ⇄ vendored: fail → Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328. PyPI-wide (uv too), so a handover went to entries/uv/.
• Vendored repair of a deleted wheel on a lock-only checkout: fail, reproduced twice. Held for next run by the 3-issue cap (backlog 1).

Issues

• Filed Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327: Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327
• Filed Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328: Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328
• Filed Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329: Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329

False positives ruled out

• The BOM lock case is Poetry's own parse error.
• The custom-source refusal is documented.
• vendor_fetch_failed against pypi.org is a sandbox TLS artifact (rustls vs the proxy CA). The workaround is a local forwarder via SOCKET_PYPI_JSON_API.
• Agent VEX ecosystem_not_setup is documented.

Probe runs

• https://github.com/SocketDev/socket-patch/actions/runs/36733821105
• https://github.com/SocketDev/socket-patch/actions/runs/36734791994

I couldn't delete either probe branch: the git proxy returned HTTP 403 on git push --delete. A maintainer needs to delete bughunt/poetry/20260930-venv-discovery and bughunt/poetry/20260930-windows-modes.

Next

1. File the vendored repair lock-only bug, after checking whether uv, PDM and Pipenv share it.
2. Windows hosted/vendored on Poetry 2.x, and agent mode with an in-project .venv.
3. Agent mode on Poetry 1.0–1.7 out-of-tree venvs, virtualenvs.path variants, and poetry env use with multiple minors.
4. Scan from a subdirectory of a Poetry project.
5. Legacy 1.0 / 1.1 locks with extras and category = "dev", and a warm venv on 1.2–1.3 after hosted.

[github-actions[bot]]

[agent] 2026-09-30: Poetry bug-hunt run

Tested: main f6b7fb9 (unchanged since run 1). Latest release 4.0.0, previous 3.3.0, both installed from PyPI for first-bad checks.

Setup: the vendored cells used a synthetic .socket/manifest.json + blob for six-1.16.0, so no API was needed. SOCKET_PYPI_JSON_API pointed at a local HTTP forwarder for pypi.org / files.pythonhosted.org. Each cell ran a real Poetry lock / install / check --lock, then a byte check of the installed six.py. Linux only.

Re-triage

#327, #328 and #329 are still open. The fix for #327/#329 is draft PR #330, not merged. Main hasn't moved, so there was nothing to re-check.

Cells

• Vendored repair, lock-only checkout, vendored wheel deleted, no venv: fail → Vendored Poetry repair and vendor re-run can't rebuild a deleted wheel on a lock-only checkout because they fetch PyPI by the patched wheel's hash #380 on Poetry 1.1.15 (lock 1.1), 1.2.2 (lock 1.1), 1.8.5 (lock 2.0), 2.0.1 / 2.3.3 / 2.4.3 (lock 2.1). Reproduced 3× on 2.3.3 across two runs. A vendor re-run in the same state also fails (vendor_fetch_unverifiable).
  • uv as a contrast: pass (rebuilt), so the bug is Poetry-only.
  • Not reproducible on releases 4.0.0 / 3.3.0, which can't vendor a lock-only Poetry checkout at all.
• Vendored, dev dependency (category = "dev" on 1.1 / 1.2, group.dev on 1.8 / 2.3): pass on 1.1.15, 1.2.2, 1.8.5 and 2.3.3 (vendor, install, patched bytes, byte-exact revert).
• Vendored, optional extra (-E compat): pass on 1.1.15, 1.2.2 and 1.8.5. 2.3.3 / 2.4.3 were blocked by sandbox damage (see below).
• Scan from a subdirectory: documented as cwd-only (CLI_CONTRACT.md "Monorepo / multi-project discovery model": pypi is cwd-only, use --cwd). Moved to known non-bugs.

Issues

• Filed Vendored Poetry repair and vendor re-run can't rebuild a deleted wheel on a lock-only checkout because they fetch PyPI by the patched wheel's hash #380: Vendored Poetry repair and vendor re-run can't rebuild a deleted wheel on a lock-only checkout because they fetch PyPI by the patched wheel's hash #380

False positives ruled out

• On Poetry < 1.4, pypi_poetry_integrity_unverified is a deliberate advisory (1.x doesn't verify local wheel hashes).
• On Poetry 1.1 / 1.2, poetry check --lock fails: that Poetry has no --lock option (1.2) or crashes in check (1.1). It's not caused by the rewrite, and poetry install succeeds.
• Running from a subdirectory is documented as cwd-only.

Blocked / environment

• A typo in one of my commands replaced /dev/null in the sandbox. Restoring it was refused by the sandbox's permission policy, so late Poetry 2.x runs (virtualenv creation, lock) failed with [Errno 2] /dev/null. Those cells are blocked, not failures.
• No probe branches this run: deleting a branch (git push --delete) is refused by permission policy, as in run 1. Creating branches that can't be deleted would leave litter. The two stale probe branches from run 1 still need a maintainer to delete them.

Next

1. Windows / macOS hosted and vendored on Poetry 2.x, and in-project .venv agent mode. This needs probe branches, which are blocked until branch deletion is allowed.
2. Vendored optional extra on Poetry 2.3 / 2.4 (blocked this run), including PEP 621 [project.optional-dependencies].
3. Agent mode on Poetry 1.0–1.7 out-of-tree venvs, virtualenvs.path variants, and poetry env use with several minors.
4. Hosted on legacy lock 1.1 with category = "dev" + extras (needs a mock patch API), and poetry install --sync on 1.2 / 1.3 with a warm venv.
5. VEX for vendored Poetry after the vendored wheel is deleted: does it still attest? Related to Vendored Poetry repair and vendor re-run can't rebuild a deleted wheel on a lock-only checkout because they fetch PyPI by the patched wheel's hash #380.

[github-actions[bot]]

[agent] 2026-10-01: Poetry bug-hunt run

Tested: main 2463257 (#277, "feat!: consolidate the v5 patching workflow"; the CLI still reports 4.0.0). Latest release 4.0.0, previous 3.3.0. Poetry 0.12.17, 1.0.10, 1.1.15, 1.2.2, 1.8.5, 2.0.1, 2.1.1 and 2.5.1 (the newest release, first coverage). Linux only.

Setup:

• A local Python mock of the patch API on the routes from tests/e2e_vex_build/poetry.rs (batch, by-package, package grant, view, blob, and the hosted wheel). It serves a deterministic patched six-1.16.0 wheel.
• SOCKET_PYPI_JSON_API pointed at a local forwarder for pypi.org / files.pythonhosted.org, because v5 hosted rollback re-resolves upstream from PyPI and rustls doesn't trust the sandbox proxy.
• Each cell ran a real poetry lock / install / sync, then a byte check of the installed six.py.
• The repo's own e2e_vex_build -- poetry:: on Poetry 2.1.1: vendored passes. Hosted passes up to its final rollback step, which hit the sandbox PyPI TLS limitation (the test scrubs SOCKET_*). That's a sandbox artifact.

Re-triage

• Vendored Poetry repair and vendor re-run can't rebuild a deleted wheel on a lock-only checkout because they fetch PyPI by the patched wheel's hash #380 fixed → closed. v5 prerelease: scan → vex → vendor workflow, hosted by default #277 removed local artifact building, and repair now re-downloads the service artifact. On a lock-only checkout with the wheel and venv deleted: repair gives rebuilt, and the scan --mode vendored re-run gives rebuilt + already_vendored. The wheel sha256 matches the lock, and poetry install installs the patched bytes. Passed on 2.5.1 and 1.8.5. Vendored Poetry repair and vendor re-run can't rebuild a deleted wheel on a lock-only checkout because they fetch PyPI by the patched wheel's hash #380 (comment)
• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 still reproduces on Poetry 2.5.1, in both directions, twice each. Commented: Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (comment)
• Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 / Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329: the suspect code in python_crawler.rs is unchanged on main. See the new Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 comment below.

Cells

• Hosted scan → poetry install → re-scan → rollback (v5 upstream re-resolution), byte-exact lock: pass on 1.0.10 (lock 1.0, native empty [metadata.files] and populated), 1.1.15 / 1.2.2 (lock 1.1), 1.8.5 (lock 2.0) LF + CRLF, 2.0.1 LF + CRLF, and 2.5.1 LF + CRLF.
• Hosted, Poetry 2.5.1, PEP 621 project with an optional extra, a dev group and markers: pass for poetry sync, --without dev (removes six), -E compat, remove <purl> / remove <uuid> (byte-exact), --dry-run (lock untouched), and get pkg:pypi/six@1.16.0.
• Hosted, lock 1.1 with [tool.poetry.extras] and dev-dependencies (1.1.15, 1.2.2): pass (install -E compat, --no-dev, byte-exact rollback).
• Poetry 2.5.1 relock after hosted / vendored: poetry lock and poetry add idna --lock keep the [package.source]. Pass.
• Hosted stale-install check (redirect_pypi_stale_install):
  • Named project with an out-of-tree venv (2.5.1): warns on the warm venv, then is clean after install and VEX attests. Pass.
  • Poetry 1.2.2 warm in-project venv: Poetry prints "Updating six" but keeps the upstream bytes (documented < 1.4). socket-patch warns and refuses VEX (not_applied). Pass.
• Hosted VEX with an undiscovered Poetry venv: fail → new evidence on Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327. The nameless package-mode = false project, [project].name + [tool.poetry].name, and in-project = false + a stray .venv all attest not_affected (same-run and standalone vex, the latter reporting verified) while the venv holds unpatched six. Reproduced on 1.8.5, 2.0.1 and 2.5.1 (twice on 2.5.1); the named control is correctly refused. Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 (comment)
• Vendored scan → install → rollback, project path with spaces and é: pass on 1.1.15, 1.8.5 and 2.5.1, LF + CRLF (CRLF preserved, byte-exact, .socket emptied). Also pass on 1.0.10 (populated lock 1.0) and 0.12.17 ([metadata.hashes]).
• Poetry 0.12 hosted refusal (redirect_poetry_lock_unsupported, lock untouched): fires correctly, twice. Pass.
• Agent mode, in-project .venv (1.1.15 and 2.5.1): scan added, re-run skipped, survives poetry sync / --remove-untracked, rollback restores the file, re-scan re-applies. Pass.
• Directory targets (v5), from a monorepo root with apps/a and apps/b, Poetry 2.5.1, out-of-tree venvs:
  • scan --mode hosted apps/a matches the result from inside the project, including the stale-install warning.
  • scan --mode vendored apps/b writes .socket/ under apps/b, and the project-relative path installs.
  • A 'apps/*' glob works without --json; --json with 2 dirs is refused ("--json takes one project directory").
  • Pass.
• macOS / Windows: blocked. Deleting a branch (git push --delete) is still refused by the session's permission policy, so I created no probe branches.

Issues

• Closed Vendored Poetry repair and vendor re-run can't rebuild a deleted wheel on a lock-only checkout because they fetch PyPI by the patched wheel's hash #380 (fixed by v5 prerelease: scan → vex → vendor workflow, hosted by default #277).
• Commented on Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (still reproduces on Poetry 2.5.1 + v5 main).
• Commented on Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 (new hosted-mode false VEX impact).
• No new issues filed.

False positives ruled out

• Poetry 1.0 + pip 23.0.1 refuses the hosted wheel ("THESE PACKAGES DO NOT MATCH THE HASHES"). This is the documented pip 22.3–23.0 fragment window, and the redirect_poetry_stale_install_risk advisory names it. With pip 24.0 it installs.
• Vendored --vex on a warm unpatched venv attests, with the warning vendored_tree_out_of_sync. Documented in CLI_CONTRACT.md: the attestation stands on the committed artifact.
• list / standalone vex don't see hosted pins on a non-Socket origin unless you pass --patch-server-url. That's expected for the mock origin.
• get CVE-…: my mock lacked the by-cve route. That's a mock gap.
• scan --vendor-source build was removed in v5 (documented in --help).

Observations (not filed)

• VEX product auto-detection emits pkg:pypi/Pep_App.X@1.2.3 verbatim from [project].name (vex/product.rs:164). The purl spec wants PyPI names lowercased with _ → -. This path is shared across PyPI managers, not Poetry-specific, and the impact is unclear.
• After rollback, reinstall_required says patched bytes persist "until the next package-manager install". On Poetry < 1.4 a plain poetry install doesn't replace them either. That's a minor wording issue.

Next

1. macOS / Windows (needs probe branches, so branch deletion must be allowed): Poetry 2.5.1 hosted/vendored, the Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329 false VEX, and in-project .venv agent mode (Lib\site-packages).
2. Hosted rollback when PyPI's current file list differs from the lock (wheels added after locking, yanked files), and for packages with non-canonical names (Foo_Bar, dotted names).
3. Interrupted / concurrent scan on a Poetry lock (kill mid-write), and poetry install racing a scan.
4. socket.yml policy (minSeverity, package filters, maxNewPatches) on a Poetry project with several patches. This needs a multi-package mock.
5. Agent mode on Poetry ≤ 1.7 out-of-tree venvs, virtualenvs.path with {cache-dir} / ~, and poetry env use with several minors.

[github-actions[bot]]

[agent] 2026-10-01: maintainer note: test global (-g) mode for hosted patches

This is a maintainer request, not a run report. Add it to the top of the backlog and keep it there until the cells below are covered.

Ask: make sure we correctly scan global installs when -g / --global is passed, on every major Poetry version and on Linux, macOS and Windows.

Where Poetry puts global installs: Poetry has no global install; check -g from inside a Poetry project scans the global interpreter's site-packages (and pipx's Poetry venv only if that's intended), never the project venv, and that a globally pip-installed copy of a project dependency is reported correctly.

What to check (prove each with a real global install, not by reading source):

1. socket-patch scan -g (no --mode) is report-only. It must find every globally installed Poetry package that has a hosted patch: none missing, no project packages leaking in, correct versions. Also check --json.
2. scan -g run from inside a Poetry project versus outside one: -g must scan only the global location, and a scan without -g must never touch it.
3. scan -g --mode hosted and scan --global-prefix <dir> --mode hosted must refuse loudly, as designed ("global installs have no project lockfile to redirect"). They must exit non-zero and write nothing.
4. get -g defaults to agent mode. Check scan -g --apply, apply -g, rollback -g and vex -g: the globally installed copy is actually patched (run the installed tool or import it), rollback restores it byte for byte, and vex only attests what's applied.
5. --global-prefix <dir> and SOCKET_GLOBAL=1 behave the same as -g. That covers custom prefixes, version managers, paths with spaces or unicode, and a non-root user's prefix.
6. A global directory you can't write to (root-owned prefix, Windows Program Files) must fail loudly with a clear error, never exit 0 unpatched.

Add OS × Poetry version cells for -g (scan report / apply / rollback) to the coverage matrix, and use probe branches for macOS and Windows.

[github-actions[bot]]

[agent] 2026-10-01: Poetry bug-hunt run

Tested: main 2463257 (unchanged since run 3), latest release 4.0.0 (previous 3.3.0). Also PR #446 head 92c71ad and d5e1815 (#231) for bisecting. Poetry 2.1.1 (uv tool) and 1.8.5 (official installer). Linux only.

Focus: the maintainer request at the top of the backlog: global (-g) mode. Poetry has no global install, so the cells ran from inside a Poetry project with an in-project .venv, against a real pip install --user six==1.16.0, a pip install --target prefix (path with a space and é), and Poetry's own installer venv. The mock patch API (agent routes plus /patches/blob/<hash>) served a six.py patch.

Re-triage

Main is the same commit run 3 re-triaged, so I didn't re-run #327 / #328 / #329. I added new #327 evidence, below.

Cells

• scan -g report-only (--json): finds the global user-site six. Project-only packages (iniconfig 2.0.0 in the .venv and lock) don't leak into the batch request. Pass.
• scan -g --mode hosted, --global-prefix … --mode hosted, SOCKET_GLOBAL=1 --mode hosted: exit 2 with "global installs have no project lockfile to redirect", poetry.lock byte-identical. Pass.
• scan -g --mode agent, then a re-run: the global copy is patched, .venv and lock untouched, the re-run gives skipped. get <uuid> -g and SOCKET_GLOBAL=1 get default to agent and give the same result. Pass.
• vex -g attests the applied global patch. Plain vex from the project refuses (not_applied, the .venv copy is unpatched). Pass.
• rollback -g restores the global six.py byte for byte. Pass.
• Cross-scope rollback: fail → filed Agent-mode rollback in the other scope (rollback -g after a project apply, or rollback after a -g apply) deletes the manifest entry and blobs while the patched copy stays patched, and exits 0 #450. A project apply followed by rollback -g, or a -g apply followed by rollback, drops the manifest entry (and GCs its blobs) because the copy in the crawled scope is already_original. Exit 0, and the patched copy stays patched. 2/2 in each direction on main and on the PR Fix -g touching the cwd project's state (#436, #445) #446 head. Release 4.0.0 is good. First bad commit: d5e1815 (feat!: scan↔rollback duality — full-state rollback default, --preserve-state, path targeting #231).
• Read-only --global-prefix (run as uid 65534 against a root-owned prefix): human mode prints Permission denied and exits 1. Pass. JSON gives exit 1 with failed: 0, action added and no error, which is scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 (Maven sibling), the same symptom on pypi. The re-run's "already recorded" skip with exit 0 is by design (it points at apply, and apply reports apply_failed).
• Poetry official-installer venv (~/.local/share/pypoetry/venv, Poetry 1.8.5, 47 dists): scan -g never crawls it. Same class as pipx → commented on Global scan (-g) never crawls pipx venvs, so the dependencies of a pipx-installed Hatch are never reported, patched or rolled back on any OS #415: Global scan (-g) never crawls pipx venvs, so the dependencies of a pipx-installed Hatch are never reported, patched or rolled back on any OS #415 (comment)
• Apt .egg-info installs (/usr/lib/python3/dist-packages/six) are invisible to -g. Already Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447 (pip sibling).
• Project scan without -g, Poetry venv undiscovered or not created yet: the crawler falls back to the global interpreter and patches it (added, exit 0). That happened for the nameless package-mode = false + out-of-tree venv case, and for a fresh clone before poetry install. Poetry's venv stays unpatched. New evidence on Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327: Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 (comment)
• macOS / Windows: blocked. git push origin --delete still fails ("remote end hung up"), so I created no probe branches. The two stale branches from run 1 remain.

Issues

• Filed Agent-mode rollback in the other scope (rollback -g after a project apply, or rollback after a -g apply) deletes the manifest entry and blobs while the patched copy stays patched, and exits 0 #450: Agent-mode rollback in the other scope (rollback -g after a project apply, or rollback after a -g apply) deletes the manifest entry and blobs while the patched copy stays patched, and exits 0 #450
• Commented on Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 (the global-write consequence) and Global scan (-g) never crawls pipx venvs, so the dependencies of a pipx-installed Hatch are never reported, patched or rolled back on any OS #415 (Poetry installer venv).
• Not commented: scan/get --json drop the agent-mode apply failure: exit 1 with failed: 0, the patch shown as "added", and no error anywhere (e.g. a read-only global ~/.m2) #424 and Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447 (already cover pypi), and get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 / rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 (PR Fix -g touching the cwd project's state (#436, #445) #446 in flight; Poetry re-test is in the backlog).

False positives ruled out

• The re-run "already recorded" skip after a failed apply is by design, see above.
• six showed up twice in a mode-less scan because my mock answers every ecosystem's batch. Mock artifact.
• Debian's six is egg-info. I used a pip install --user --ignore-installed copy as the real global install.

Next

1. The global-mode table on macOS / Windows (needs probe branch deletion to work).
2. -g with virtualenvs.create = false (Poetry installing into the global interpreter), plus vex -g / list -g with a hosted Poetry project in cwd.
3. Re-test get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 / rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 on a Poetry lock once PR Fix -g touching the cwd project's state (#436, #445) #446 merges (the mock needs the grant route).
4. Hosted rollback when PyPI's file list differs from the lock, and non-canonical names.
5. Interrupted / concurrent scan on a Poetry lock.

[github-actions[bot]]

[agent] 2026-10-01: Poetry bug-hunt run

Tested: main 6e7ef74 (it now includes #330 5678b76, "Fix Poetry venv discovery to match Poetry (#327, #329)"). Latest release 4.0.0. Linux only. Real Poetry 1.1.15 (py3.9), 1.8.5, 2.0.1 and 2.5.1 installs. Two local mock patch APIs (agent, hosted grant and wheel, blob routes): one for six 1.16.0, one for jaraco.context 4.3.0 with a dotted or canonical purl. A local pypi.org forwarder (SOCKET_PYPI_JSON_API) for the hosted rollback and takeover legs.

Re-triage

• Agent-mode scan misses Poetry's venv for nameless non-package-mode projects, [project].name overrides, and in-project = false with a stray .venv, and still exits 0 #327 / Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329 were closed by Fix Poetry venv discovery to match Poetry (#327, #329) #330. I verified the Linux side of the fix with real Poetry: agent scan patches the env Poetry installed into, 2/2 each, in 18 layouts:

  • nameless package-mode = false (1.8.5, 2.0.1, 2.5.1)
  • [project].name + [tool.poetry].name (2.0.1, 2.5.1)
  • in-project = false + a stray .venv (1.8.5, 2.0.1, 2.5.1)
  • PEP 621 [project]-only (2.5.1)
  • a 60-char dotted/underscored name truncated to 42 characters, with a hash containing - (2.5.1)
  • a symlinked project dir (2.5.1)
  • relative virtualenvs.path in poetry.toml (2.5.1)
  • {cache-dir}/custom-envs (2.5.1)
  • POETRY_VIRTUALENVS_PATH='~/alt envs' (2.5.1)
  • .venv as a symlink to a venv (2.5.1)
  • XDG_CACHE_HOME (2.5.1)
  • a project path with a space and é (1.8.5, 2.0.1)

  The hosted half also works now: for the nameless, both-names, in-project = false, 1.8.5 and relative-path layouts, a stale env gives redirect_pypi_stale_install and vex_omitted, and after poetry sync VEX attests. Windows (Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329) wasn't verified because probe branches are blocked.

• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328: I commented with the new status (Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (comment)). Hosted → vendored now works on Poetry 2.5.1 (vendor_takeover_reverted_redirect, exit 0, poetry check --lock OK, poetry sync installs the patched vendored wheel, and rollback restores the lock byte for byte). Without the PyPI forwarder it fails closed with redirect_revert_failed, which is a sandbox artifact. Vendored → hosted still reproduces (redirect_poetry_lock_unsupported, redirected: 0, exit 0). The issue stays open.

• Agent-mode rollback in the other scope (rollback -g after a project apply, or rollback after a -g apply) deletes the manifest entry and blobs while the patched copy stays patched, and exits 0 #450: still reproduces on 6e7ef74 (-g apply then project rollback gives success, the manifest is emptied, and the global copy stays patched), 2/2. rollback.rs is unchanged since the report. No comment.

Cells

• Agent venv discovery, the 18 layouts above: pass.
• Agent and hosted with virtualenvs.in-project = true but no ./.venv, after Poetry already created its out-of-tree env: fail. Filed Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476. Poetry keeps using the out-of-tree env (EnvManager.get() only takes ./.venv when it exists), but socket-patch skips the out-of-tree probe for an explicit true. Agent mode patches the global user-site copy instead (added, exit 0), or skips with package_not_installed (exit 0). Hosted scan --vex attests not_affected while the env holds upstream bytes. This happens on 1.1.15, 1.8.5, 2.0.1 and 2.5.1, with poetry.toml and with user config.toml. It never worked (it isn't a Fix Poetry venv discovery to match Poetry (#327, #329) #330 regression).
• Full agent cycle on the nameless out-of-tree project (2.5.1): apply, re-run skipped, vex attests, rollback restores byte for byte. Pass 2/2.
• Hosted, dotted name jaraco.context with both the dotted purl and the canonical jaraco-context purl, lock 1.1 (Poetry 1.1.15, quoted "jaraco.context" = [...] in [metadata.files]), 2.0 (1.8.5) and 2.1 (2.5.1): rewrite, real poetry install (patched bytes land), vex, and rollback (lock byte-identical). Pass in every cell.
• 6 concurrent scan --mode hosted runs on one Poetry project: one wins and the other 5 get "Another socket-patch process is operating in this directory", exit 1. The lock is valid (poetry check --lock). Pass.
• vex -g from a hosted, synced Poetry project with an unpatched global six: refuses (not_applied). Pass.
• list -g from that project lists the project's hosted pin (mode: hosted, lockfiles: [poetry.lock]). Not filed: PR Fix -g touching the cwd project's state (#436, #445) #446 already says "vex -g and list -g still read cwd lockfile discovery. Neither one writes to the project."
• virtualenvs.create = false: blocked. The sandbox's system Python already has apt six (egg-info, Python crawler ignores .egg-info installs, so packages pip ≤ 23.0 installed from sdists are never patched, never get a stale-install warning, and are invisible to scan -g #447), so Poetry installs nothing.
• macOS / Windows: blocked. git push origin --delete still fails ("remote end hung up"), so I created no probe branches.

Issues

• Filed Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476: Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476
• Commented on Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (partially fixed).

False positives ruled out

• I first saw the Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476 symptom with the jaraco.context dotted purl and suspected name canonicalization. The canonical-purl control passed, but that project also had no poetry.toml. The real trigger was the in-project = true I'd set in the dotted-name project. Dotted purls work in every cell.
• POETRY_VIRTUALENVS_IN_PROJECT=yes / on: socket-patch reads them as true, Poetry as false (boolean_normalizer accepts only "true" / "1"). It's a theoretical divergence and not worth filing.
• When VIRTUAL_ENV is set and envs.toml has an entry for the project, Poetry ignores VIRTUAL_ENV, but socket-patch always prefers it. Contrived, so not filed. It's in the backlog.

Next

1. macOS / Windows verification of Fix Poetry venv discovery to match Poetry (#327, #329) #330 (Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329 Windows hash, macOS case-preserving realpath vs Rust canonicalize case) once probe branches can be deleted.
2. Re-test get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 / rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 on a Poetry project after PR Fix -g touching the cwd project's state (#436, #445) #446 merges.
3. VIRTUAL_ENV + poetry env use (envs.toml) precedence; conda CONDA_PREFIX as Poetry's active env.
4. socket.yml policy (minSeverity, maxNewPatches) on a Poetry project with several patches (the mocks are now parameterized by package).
5. Poetry 0.12 / 1.0 agent mode out-of-tree (Poetry 1.0's pre-1.2 hash used the unnormalized cwd).

[github-actions[bot]]

[agent] 2026-10-01: Poetry bug-hunt run

Tested: main 61cfb9b (adds #446, #452, #456 since run 5). Latest release v4.0.0. Linux only. Real Poetry 1.8.5, 2.0.1, 2.2.1 and 2.5.1, all on py3.11. A local Python mock of the patch API (batch, view, /patches/package grant plus wheel, blob routes, same shapes as tests/vex_pypi_real_common). Bisect builds of 2035cbb^ and 2035cbb.

Re-triage

• Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476 (in-project = true, no .venv, out-of-tree env exists): still reproduces on 61cfb9b, 2/2 (Poetry 2.5.1). Since Fix Python crawler missing .egg-info installs (#447) #452 the global fallback now patches apt's /usr/lib/python3/dist-packages/six.py. I commented: Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476 (comment)
• Agent-mode rollback in the other scope (rollback -g after a project apply, or rollback after a -g apply) deletes the manifest entry and blobs while the patched copy stays patched, and exits 0 #450 (cross-scope rollback): still reproduces. scan -g then project rollback gives success, rolledBack: 0, alreadyOriginal: 1, removedEntries: [six], and the global copy stays patched. Fix -g touching the cwd project's state (#436, #445) #446 didn't change this. No new comment.

Cells

• Agent scan -g / project scan with virtualenvs.create = false, same release in user site and a system site dir: fail. Filed With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501. The shadowed system copy is patched and the user-site copy that Python imports isn't. apply re-runs report already_patched, vex attests not_affected, and rollback sees both copies.
  • apt egg-info + user site: v4.0.0 and 2035cbb^ pass; 2035cbb (Fix Python crawler missing .egg-info installs (#447) #452) and main fail. That's a regression.
  • /usr/local/.../dist-packages + user site: fails on every build.
• get -g --mode hosted|vendored and scan -g --mode vendored rewrite the current project's yarn.lock instead of refusing, leaving the global copy unpatched #436 / rollback -g and remove <purl> -g also unwind the current project's hosted pins and vendored wiring; on vlt they delete node_modules/left-pad too #445 on a hosted Poetry 2.5.1 project (backlog item 4): pass. get <uuid> -g --mode hosted|vendored, scan -g --mode hosted|vendored exit 2. rollback -g exits 1 with "Manifest not found". remove -g exits 1 with manifest_not_found. poetry.lock stays byte-identical and no .socket/ is created.
• Agent scan in-project .venv (2.5.1): pass.
• Hosted scan + poetry sync (2.5.1): pass (patched bytes installed).
• Poetry 1.8.5 / 2.0.1 / 2.2.1 with create = false in this image reinstall six into /usr/local/lib/python3.11/dist-packages, which comes first on sys.path. Agent scan patches the right copy there: pass.
• macOS / Windows: blocked. git push origin --delete still fails ("unexpected disconnect while reading sideband packet"), so I created no probe branches.

Issues

• Filed With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501: With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501
• Commented on Poetry with virtualenvs.in-project = true but no ./.venv keeps using its out-of-tree env, which socket-patch never probes: agent patches the global interpreter and hosted VEX falsely attests #476.

False positives ruled out

• I first read apply -g's already_patched as a hash bug (grep on user site showed it unpatched). The apt copy really was patched by the previous run. That led to With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501.
• rollback -g --json on a hosted project with no manifest returns "error": "Manifest not found" as a plain string, not a {code, message} object. It's a JSON shape nit and not Poetry-specific, so not filed.

Next

1. macOS: user site ~/Library/Python/3.X/lib/python/site-packages vs Homebrew site-packages ordering for With the same release in user site-packages and a system site-packages dir, agent mode patches the shadowed system copy, leaves the copy Python imports unpatched, and VEX attests it (worse since #452: now hits apt-installed packages) #501 (needs probe branches).
2. VIRTUAL_ENV + envs.toml (poetry env use) precedence; conda CONDA_PREFIX.
3. socket.yml policy (minSeverity, maxNewPatches) on a Poetry project with several patches.
4. Poetry 1.0 agent mode out-of-tree venv (pre-1.2 hash).
5. Fix agent scan/get skipping apply for recorded patches (#454) #456 re-check: after poetry sync --no-cache reinstalls six, scan --mode agent re-applies the recorded patch.