Bug hunt ledger: Poetry

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-02 (run 8), 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	pass r8 (scan, re-run, vex, rollback)	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	pass r8 (scan, re-run, vex, rollback)	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

Venv selection and policy (run 7, Linux, main 61cfb9b)

Poetry	Cell	Result
1.8.5, 2.5.1	Several per-minor envs (poetry env use), active env sorts after an older one (3.11→3.12, 3.10→3.13), custom and default virtualenvs.path	fail #526 (patches the first-sorted env, VEX attests)
1.8.5, 2.5.1	Several per-minor envs, active env sorts first	pass (by luck)
2.5.1	VIRTUAL_ENV set to another venv + envs.toml entry for the project	fail #526 (comment)
2.5.1	#456: reinstall wipes the patch, scan --mode agent re-applies	pass
2.5.1	Agent socket.yml: minSeverity, ignorePackages (purl, name, case), maxNewPatches: 0, ecosystems, ignorePaths, enabled: false, retain-on-narrow	pass
2.5.1	Hosted socket.yml	untested (mock has no grant route)

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)

Run 8 cells (Linux, main 61cfb9b)

Poetry	Cell	Result
2.5.1	Hosted, then poetry export (plugin), then pip install -r	pass
2.5.1	Hosted with a supplemental / explicit mirror source, six from PyPI	pass (install, check --lock, vex)
2.5.1	Forked lock (six at two versions by marker)	hosted and vendored refuse before writing (documented)
2.5.1	Agent, virtualenvs.options.system-site-packages = true, six in system site	fail #409 (comment): Poetry 2 skips installing into .venv, agent says package_not_installed, exit 0
1.8.5	Same, agent	pass (Poetry 1.8 installs into .venv)
1.8.5, 2.5.1	Same, hosted, then install, then vex	pass
1.8.5, 2.5.1	Hosted, then install with installer.no-binary = six / :all:	pass
1.8.5, 2.5.1	Hosted rollback (PyPI forwarder), check --lock, reinstall	pass
macOS 1.2–2.x	XDG_CACHE_HOME / XDG_CONFIG_HOME set (platformdirs ≥ 4.6 honours them on macOS; socket-patch doesn't)	untested, suspected fail (needs probe)
Windows 1.0/1.1	Out-of-tree env-name hash (Poetry < 1.2 doesn't normcase; socket-patch lowercases)	untested, suspected fail (needs probe)

Backlog

1. macOS XDG (run 8 lead): with XDG_CACHE_HOME / XDG_CONFIG_HOME set and platformdirs ≥ 4.6.0 (2026-02-12; Poetry 1.2–2.x pull 4.12.x), Poetry uses $XDG_CACHE_HOME/pypoetry/virtualenvs and $XDG_CONFIG_HOME/pypoetry/config.toml. python_crawler.rs poetry_default_cache_dir / poetry_user_config_path only look in ~/Library/... on macOS. This needs a macOS probe.
2. Windows Poetry 1.0/1.1 env hash (run 8 lead): Poetry < 1.2 hashes the raw cwd, while socket-patch lowercases it (windows_normcase). This needs a Windows probe.
3. 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, plus Fix Poetry venv discovery to match Poetry (#327, #329) #330 verification (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) and long paths. This needs probe branches.
4. Probe branches are blocked: git push --delete and git push origin :refs/heads/... still fail (runs 1–8). A maintainer needs to delete bughunt/poetry/20260930-venv-discovery and bughunt/poetry/20260930-windows-modes.
5. Conda CONDA_PREFIX (with CONDA_DEFAULT_ENV != base) as Poetry's env. Needs micromamba.
6. virtualenvs.use-poetry-python / prefer-active-python with no envs.toml entry (a With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526 follow-on).
7. Hosted socket.yml policy on Poetry (the mock now has a grant route).

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.
• The uv-tool-installed Poetry in this image builds poetry env use python3.12 envs on its own 3.11 interpreter (pyvenv.cfg says 3.11.15). That's a sandbox quirk; use pip-installed Poetry for multi-interpreter cells.
• In agent scan --json, ecosystems: [npm] reports policy.counts.filtered: 2 for a single six (likely the lock and the installed copy). Cosmetic, not filed.
• Forked Poetry locks (one package at several versions by marker) are refused by hosted (redirect_poetry_lock_unsupported, "forked Poetry package requires an unambiguous source") and vendored ("forked resolution"). Documented in CLI_CONTRACT.md.
• Hosted vex attests a lock pin for a package that isn't installed (for example an optional group left uninstalled). Documented ("with nothing installed, attests a discovered lockfile reference from its integrity pin").
• rollback on a project with no manifest, ledger or hosted pin gives "Manifest not found", exit 1. Documented (truly-empty project).
• Hosted-only rollback --json reports rolledBack: 0 while it restores the lock. Cosmetic, not filed.
• uv can't install from poetry export output against the sandbox mock (it sends HEAD, which the mock doesn't answer). Mock artifact.

[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.

[github-actions[bot]]

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

Tested: main 61cfb9b, unchanged since run 6. Latest release v4.0.0, previous 3.3.0, both installed from PyPI for the regression check. Linux only. Real Poetry 1.8.5, 2.1.1 and 2.5.1, with real CPython 3.10, 3.11, 3.12 and 3.13 interpreters. A local Python mock of the patch API (batch, view, by-package and blob routes). It has no hosted grant route, so the hosted cells in this run are inconclusive.

Re-triage

Main hasn't moved since run 6, so #476, #450 and #501 are unchanged. I re-ran nothing and posted no comments. #328 is now claimed by draft PR #503.

Cells

• Agent, several per-minor Poetry envs (poetry env use 3.11, then 3.12): fail. Filed With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526. socket-patch patches the lexicographically first <name>-<hash>-py* env (python_crawler.rs:881, venvs.sort()), not the one envs.toml activates. poetry run imports the unpatched copy, apply says already_patched, and vex attests not_affected.
  • Reproduced 5/5 when the active env sorts last: Poetry 2.5.1 with custom and default virtualenvs.path, package mode and package-mode = false, 3.11→3.12 and 3.10→3.13; Poetry 1.8.5 with 3.11→3.12.
  • Passes by luck when the active env sorts first (3/3).
  • v4.0.0 and v3.3.0 report package_not_installed in this layout (the 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 family), so the bug came in with Fix Poetry venv discovery to match Poetry (#327, #329) #330 and is unreleased.
• VIRTUAL_ENV set + envs.toml entry: fail (2/2), commented on With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526. Poetry ignores VIRTUAL_ENV when envs.toml has an entry. socket-patch patches the VIRTUAL_ENV tree. With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526 (comment)
• Fix agent scan/get skipping apply for recorded patches (#454) #456 on Poetry 2.5.1, in-project .venv: after rm -rf .venv && poetry install, scan --mode agent re-applies the recorded patch (2 cycles). Pass.
• Agent socket.yml policy on Poetry 2.5.1: pass for all of these:
  • minSeverity: critical filters a high patch.
  • ignorePackages with a purl, a bare name and a differently cased name.
  • maxNewPatches: 0 defers.
  • ecosystems: [npm] filters.
  • ignorePaths: ["poetry.lock"] filters.
  • enabled: false reports only.
  • Narrowing after a patch is applied keeps it (retained, policy_package_ignored), and the file stays patched.
• Hosted policy cells: inconclusive (the mock has no grant route, so not_found).
• macOS / Windows: blocked. git push origin --delete still fails ("unexpected disconnect while reading sideband packet") on bughunt/poetry/20260930-venv-discovery, so I created no probe branches.

Issues

• Filed With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526: With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526
• Commented on With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526 (the VIRTUAL_ENV trigger).

False positives ruled out

• The uv-tool-installed Poetry 2.1.1 built its "py3.12" env on the 3.11 interpreter (pyvenv.cfg version 3.11.15). I re-ran everything with pip-installed Poetry and real separate interpreters. The bug still reproduces, and I left the 2.1.1 row out of With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526.
• ecosystems: [npm] reports filtered: 2 for a single six. It's probably counting both the lock and the installed copy. Cosmetic, not filed.

Next

1. Conda: CONDA_PREFIX with CONDA_DEFAULT_ENV != base as Poetry's env (socket-patch doesn't read CONDA_PREFIX). Needs conda or micromamba in the sandbox.
2. Hosted socket.yml policy on Poetry (add a grant route and wheel to the mock).
3. virtualenvs.prefer-active-python / use-poetry-python with no envs.toml entry: which minor Poetry picks vs the first-sorted env (a With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526 follow-on).
4. macOS / Windows global mode and Fix Poetry venv discovery to match Poetry (#327, #329) #330 verification (needs probe branches; a maintainer has to delete the two stale branches).
5. Poetry 1.0 agent mode out-of-tree (pre-1.2 hash).

[github-actions[bot]]

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

Tested: main 61cfb9b, unchanged since run 6. Latest release v4.0.0. Linux only. Real Poetry 1.0.10, 1.1.15, 1.8.5 and 2.5.1 on CPython 3.11. Test setup:

• A local Python mock of the patch API: batch, view, by-package, /patches/package grant plus a patched six-1.16.0 wheel, and blob routes.
• A local PyPI JSON forwarder (SOCKET_PYPI_JSON_API) for the vendored and hosted-rollback cells.

Re-triage

Main hasn't moved, so #526, #501, #476, #450 and #328 are unchanged. I re-ran nothing.

Cells

Poetry	Cell	Result
1.0.10, 1.1.15	Agent, default out-of-tree venv (pre-1.2 env-name hash): scan, re-run (skipped), vex, rollback, apply after rollback	pass. Rollback emptying the manifest is v5's documented full-state rollback.
2.5.1	Hosted, then poetry export -f requirements.txt (poetry-plugin-export), then pip install -r	pass (installs the patched wheel; the --hash is kept)
2.5.1	Hosted with a [[tool.poetry.source]] mirror at priority = "supplemental" / "explicit", six from PyPI	pass (rewrite, install, check --lock, vex)
2.5.1	Forked lock (six 1.16.0 for py<3.12, 1.17.0 for py>=3.12)	hosted refuses (redirect_poetry_lock_unsupported, documented); vendored refuses with "forked resolution" before any write
2.5.1	Hosted pin on a package in an optional group that isn't installed	vex attests from the lock pin. Documented (CLI_CONTRACT "with nothing installed, attests a discovered lockfile reference").
2.5.1	Agent, virtualenvs.options.system-site-packages = true, six in Debian dist-packages	fail, 2/2. Poetry 2.5.1 doesn't install six into .venv (the system copy satisfies it). Agent scan says package_not_installed, exits 0, and the imported copy stays unpatched. Already covered by #409 (pip), so I commented there.
1.8.5	Same, agent	pass (Poetry 1.8 installs into .venv anyway)
1.8.5, 2.5.1	Same, hosted, then poetry install, then vex	pass (Poetry reinstalls because the source changed; 1.8.5 also warns redirect_pypi_stale_install)
1.8.5, 2.5.1	Hosted, then install with POETRY_INSTALLER_NO_BINARY=six / :all:	pass (installs the hosted wheel)
1.8.5, 2.5.1	Hosted rollback (via the forwarder): lock restored to both PyPI files, check --lock ok, reinstall unpatched	pass. A re-run on the now-clean project gives "Manifest not found", exit 1, which is documented (truly-empty project).
macOS / Windows	anything	blocked. git push origin --delete and git push origin :refs/heads/… both still fail ("unexpected disconnect while reading sideband packet").

Issues

• Commented on In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 (Poetry's system-site-packages trigger, agent miss, hosted fine): In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 (comment)
• Filed nothing new.

Leads I couldn't prove on Linux (not filed)

1. macOS + XDG. Since platformdirs 4.6.0 (2026-02-12), platformdirs.MacOS honours XDG_CACHE_HOME and XDG_CONFIG_HOME (XDGMixin). Poetry 1.2–2.x take platformdirs>=3,<5, so a fresh install gets 4.12.x. With XDG_CACHE_HOME set on macOS, Poetry puts venvs in $XDG_CACHE_HOME/pypoetry/virtualenvs and reads $XDG_CONFIG_HOME/pypoetry/config.toml. python_crawler.rs poetry_default_cache_dir / poetry_user_config_path ignore XDG on macOS and only look in ~/Library/Caches and ~/Library/Application Support. The expected result is a missed venv, falling back to the global interpreter (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 family). This needs a macOS probe.
2. Windows + Poetry < 1.2. Poetry 1.0/1.1 generate_env_name hashes cwd as-is, with no normcase or realpath. socket-patch always lowercases on Windows (windows_normcase), so the hash can't match for any path with an uppercase letter (C:\…). This needs a Windows probe.

False positives ruled out

• uv failed to install from the exported requirements because my mock doesn't answer HEAD. pip installs fine. Mock artifact.
• rollback --json reports rolledBack: 0 on a hosted-only project even though it did restore the lock. It's probably counting manifest entries only. Cosmetic, not filed.

Next

1. macOS: the XDG lead above, plus Fix Poetry venv discovery to match Poetry (#327, #329) #330 verification and global mode (needs probe branches; a maintainer has to delete the two stale bughunt/poetry/20260930-* branches first).
2. Windows: the Poetry 1.1 env-name hash lead above.
3. Conda CONDA_PREFIX as Poetry's env (needs micromamba).
4. virtualenvs.use-poetry-python / prefer-active-python with no envs.toml entry (a With several Poetry envs for one project (poetry env use on two Python minors), agent mode patches the alphabetically first env instead of the one Poetry activated, and VEX attests not_affected #526 follow-on).
5. Hosted socket.yml policy on Poetry (the mock now has a grant route).