Bug hunt ledger: Poetry

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-06 (run 14), main 9c43dfc (includes #330, #446, #452, #456, #503, #527, #538, #540, #644, #703, #708), latest release 4.0.0 (previous 3.3.0). Run 9 re-measured the cells marked "r9". Runs 10–14 have their own tables below. #327 and #329 are closed: macOS / Windows cells that still show them haven't been re-run, because probe branches are blocked.

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]); r14 pass	vendored→hosted fail #945	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); r9 envs.toml (3.10/3.11) pass	n/a	fixed by #527 (not re-run)	pass v5 (lock 1.1, extras + dev); r5 dotted name jaraco.context rewrite/install/vex/rollback	untested	pass v5 (LF + CRLF, unicode/space path)	pass r14 (both ways, LF + CRLF)	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; r9 envs.toml + custom path pass	pass r5 (fixed by #330; nameless, in-project=false, unicode path)	pass r9 (#527)	pass v5 (LF + CRLF)	pass r5 (#330)	pass v5 (LF + CRLF, unicode/space path)	pass r14 (both ways, LF + CRLF)	pass v5 (#380 fixed)
Linux	2.0.1	untested	pass	pass r5 (fixed by #330; nameless, in-project=false, unicode path, both names)	fixed by #527 (not re-run)	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	pass r11 (all 3 layouts)	untested	pass (groups, markers, path/url deps, supersede, dry-run, get)	untested	pass (path/url deps)	fixed by #503 (not re-run)	fixed (#380)
Linux	2.4.3	untested	pass	pass r11 (all 3 layouts)	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)	pass r9 (#527)	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 pass r10 (#328 fixed by #503); r14 both ways LF + CRLF pass, mixed EOL → whole-file LF (#814)	pass v5 (#380 fixed)
macOS	1.8.5	untested	pass	fail #327 (closed; not re-run)	untested	pass (LF + CRLF)	untested	pass (LF + CRLF)	untested	untested
macOS	2.0.1	untested	pass	fail #327 (closed; not re-run)	untested	untested	untested	untested	untested	untested
macOS	2.4.3	untested	pass	fail #327 (closed; not re-run)	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 (closed; not re-run)	fail #327 (closed; not re-run)	untested	pass (LF + CRLF)	untested (likely #327/#329)	pass (LF + CRLF)	untested	untested
Windows	2.0.1	untested	fail #329 (closed; not re-run)	fail #327 (closed; not re-run)	untested	untested	untested	untested	untested	untested
Windows	2.4.3	untested	fail #329 (closed; not re-run)	fail #327 (closed; not re-run)	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	fixed by #527; pass r9 (2.5.1, 1.8.5, 1.1.15)
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	fixed by #527 (unit-tested; r9 conda variants pass)
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, custom POETRY_HOME)	pass r13 (#640 fixed by #644)
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 d63ae5f, r9)
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)	fixed by #538 (not re-run)
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); in-project = true + no .venv fixed by #527 (r9 pass)
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)

Run 9 cells (Linux, main d63ae5f)

Poetry	Cell	Result
2.5.1, 1.8.5, 1.1.15	poetry env use on two minors (envs.toml): only the active env is patched, poetry run imports the patched copy	pass (#526 fixed)
2.5.1, 1.8.5	envs.toml under a custom virtualenvs.path, Demo_App.Core name, path with a space and é	pass
2.5.1, 1.8.5	CONDA_PREFIX + CONDA_DEFAULT_ENV = work / base; VIRTUAL_ENV under conda base; empty CONDA_PREFIX / VIRTUAL_ENV	pass
2.5.1	#538: two envs, no envs.toml; drift in one copy: vex refuses, apply re-run fixes it, rollback restores both	pass
2.5.1	Project apply with the same release in user site	pass (user site untouched)
2.5.1, 1.8.5	Hosted + envs.toml envs: vex follows the active env (refuses for the stale env)	pass
2.5.1	Hosted socket.yml: minSeverity, ignorePackages, ecosystems + --prune, enabled: false, maxNewPatches, ignorePaths, includePaths	pass (needs SOCKET_PATCH_SERVER_URL for retained)

Run 10 cells (Linux, main 045d7ec)

Poetry	Cell	Result
2.5.1, 1.8.5, 1.1.15	Vendored → hosted takeover, then fresh install	pass (#328 fixed)
2.5.1, 1.8.5	Vendored + poetry add sibling edit, re-run, rollback; relock drops the wiring, then vendor_artifact_reused	pass
2.5.1	Agent scan (API path) after the env set changes (env use + env remove)	pass
2.5.1, 1.8.5	Agent apply with an uninstalled optional group (#555)	pass
2.5.1	Hosted with path-prefixed --patch-server-url (scan, re-scan, list, vex, rollback)	pass
2.5.1, 1.8.5	Vendored install via poetry -C / --directory / from a subdir	pass
2.5.1, 1.8.5	Hosted virtualenvs.create = false into an activated env	pass
1.1.15, 2.5.1	Jinja2 / typing_extensions name normalization × hosted / vendored / agent	pass
1.1.15 → 1.8.5 / 2.5.1	Lock 1.1 rewrite consumed by newer Poetry, tampered hash refused	pass
1.8.5	installer.modern-installation = false, warm venv	Poetry keeps the upstream bytes; CLI fail-closed (stale warning, vex refuses); docs table is inaccurate
1.1.15, 1.8.5, 2.5.1	virtualenvs.path = "{project-dir}/.envs"	fail #608

Run 11 cells (Linux, main 045d7ec)

Poetry	Cell	Result
2.3.3, 2.4.3	#327 layouts (nameless package-mode=false, [project].name override, in-project=false + stray .venv), agent scan finds the out-of-tree env	pass
2.2.1 (official installer), 1.8.5 (POETRY_HOME)	scan -g crawls $POETRY_HOME/venv / ~/.local/share/pypoetry/venv	fail #640 (pipx-layout control passes)
2.5.1	virtualenvs.path = "{data-dir}/venvs"; cache-dir = "{data-dir}/cache"	fail (commented on #608; data-dir key exists from Poetry 2.1)
1.8.5	same ({data-dir} stays literal in Poetry < 2.1)	pass
1.8.5, 2.5.1	path = "{cache-dir}/venvs" control	pass

Run 12 cells (Linux, main 045d7ec)

Poetry	Cell	Result
1.3.2 → 1.8.5 (every minor)	Hosted, warm venv: the 1.3 / 1.4 boundary (version stamp, advisory, byte replacement), then vex	pass (matches the docs)
1.3.2, 1.4.0, 1.5.1, 1.7.1, 2.0.1, 2.1.1	Vendored scan, install, vex (1.3.2 warns vendored_tree_out_of_sync)	pass
1.2.2 – 1.7.1, 2.1.1	Agent, out-of-tree env, Demo_App.Core / My Proj é names	pass
2.1.1	Agent list / rollback / apply / repair / remove	pass
2.5.1	Agent, dev-group-only patch, sync --without dev, then vex omits it	pass
2.5.1	Hosted / vendored with six as a path-wheel or URL dependency	refused before any write (documented)
1.0.10, 1.1.15	Hosted on a CRLF lock + fresh install + idempotent re-scan	pass
1.0.10, 1.1.15, 1.3.2	Hosted rollback (via the forwarder): byte-identical lock	pass
1.8.5, 2.5.1	virtualenvs.create = false + stray ./venv, or ./.venv with in-project = false	fail #671 (also release 4.0.0 and the PR #644 head)
2.5.1	create = false controls (no stray tree; .venv with in-project unset)	pass

Run 13 cells (Linux, main 99f61d2)

Poetry	Cell	Result
2.5.1, 1.8.5	#608 re-check: {data-dir}/venvs (2.5.1), {project-dir}/.envs literal (1.8.5) + vex	pass (fixed by #644)
any	#640 re-check: scan -g / rollback -g on $POETRY_HOME/venv and ~/.local/share/pypoetry/venv	pass (fixed by #644)
2.5.1, 1.8.5	{data-dir}/venvs + env use + unrelated VIRTUAL_ENV / conda env	fail #866 (agent over-patches; hosted vex refuses)
2.5.1	default path + env use + unrelated VIRTUAL_ENV	pass (control)
2.5.1, 1.8.5	Hosted forward splice on a mixed CRLF/LF lock (#703)	pass
1.2.2	Hosted on a mixed lock 1.1 ([metadata.files] LF), then install	pass
2.5.1, 1.8.5	Hosted rollback / remove on a mixed lock	whole file goes LF (see #814, comment)
2.5.1	#671, #450	still fail

Run 14 cells (Linux, main 9c43dfc)

Poetry	Cell	Result
2.5.1, 1.8.5, 1.1.15	hosted → vendored → hosted takeovers + fresh installs + rollback, LF and CRLF locks	pass (EOL kept, rollback byte-identical)
2.5.1	same on a mixed CRLF/LF lock	takeover revert writes the lock all-LF (#814 child 2)
2.5.1	symlinked poetry.lock: hosted / vendored takeover	pass (both refuse before writing)
0.12.17	vendored → hosted takeover	fail #945 (dry run promises redirected: 1; wet run un-vendors, then refuses)
2.5.1	#866, #671	still fail
2.5.1, create = false (uv CPython)	hosted vex / agent with an apt python3-six in /usr/lib/python3/dist-packages	vex refuses (not_applied); agent also patches the dpkg-owned copy. Lead (backlog 1)

Backlog

1. Lead (run 14): with virtualenvs.create = false, the project global fallback (get_global_python_site_packages) crawls every well-known dir, including other interpreters' /usr/lib/python3/dist-packages and /usr/local/lib/python3.X. Hosted vex then refuses a correct install because of an unrelated apt copy, and agent mode patches dpkg-owned files. That follows from Fix PyPI agent apply patching only one installed copy (#529, #501) #538's "patch every copy" design, so it needs a maintainer call before anyone files it. A realistic trigger: a python:3.x image plus apt python3-six.
2. macOS / Windows re-checks for closed 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 Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 default paths (~/Library/Application Support/pypoetry/venv, %APPDATA%\pypoetry\venv), and With {data-dir} in Poetry's virtualenvs.path, agent mode also patches an unrelated activated VIRTUAL_ENV / conda env, even though poetry env use pins the project's env, and hosted VEX then refuses a correctly installed patch #866 on macOS (where poetry_default_data_dirs can return two data dirs). All need probe branches.
3. macOS XDG (run 8 lead): with XDG_CACHE_HOME / XDG_CONFIG_HOME set and platformdirs ≥ 4.6.0, Poetry uses the XDG dirs, but poetry_default_cache_dir / poetry_user_config_path only look in ~/Library/.... Needs a macOS probe.
4. Windows Poetry 1.0/1.1 env hash (run 8 lead): Poetry < 1.2 hashes the raw cwd, while socket-patch lowercases it. Needs a Windows probe.
5. Probe branches are still blocked: bughunt/poetry/20260930-venv-discovery and bughunt/poetry/20260930-windows-modes still exist (run 14), and deletion was denied in runs 9–14. A maintainer needs to delete them and allow deleting bughunt/poetry/*.
6. Two patched packages in one lock: remove one, keep the other (hosted + vendored, LF + CRLF). Needs a two-patch mock.
7. Docs: installer.modern-installation = false (Poetry 1.4–1.8) keeps a warm same-version install, but the poetry-compatibility "Installer boundaries" table says 1.4–1.8 replace it.

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. Since Fix Python crawler missing .egg-info installs (#447) #452 the crawler sees it, so global-fallback cells pick it up (see backlog 1). Use pip install --user --ignore-installed for a controlled global copy, and rollback afterwards if agent mode patched it.
• 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.
• Poetry 1.0's EnvManager.get() uses an existing ./.venv even with an explicit virtualenvs.in-project = false; 1.1+ honour the false and socket-patch follows them. It only diverges when Poetry 1.0 also has an out-of-tree env. Theoretical, not filed.
• Hosted socket.yml narrowing lists recorded pins under policy.filtered rather than retained when the mock origin isn't the patch server. Set SOCKET_PATCH_SERVER_URL; this is the documented hosted-origin rule.
• Fix vendored rescans failing on unwired ledger entries (#541) #543's vendored "unwired ledger entry" check doesn't cover pypi (dispatch_in_use_one returns None), so Poetry vendored re-runs are unchanged by it.
• A test mock that answers every /patches/batch with the same patch makes agent scans report partial_failure for packages the project doesn't have. Filter the mock to the requested purls.
• Poetry < 2.1 has no data-dir config key, so {data-dir} in virtualenvs.path stays a literal relative directory, and socket-patch matches it.
• vex saying "No applied patches with vulnerability metadata" after a hand-staged manifest with empty vulnerabilities is a fixture artifact.
• Poetry 1.x's env-var boolean_normalizer is case-sensitive (POETRY_VIRTUALENVS_IN_PROJECT=True is false), while 2.x lowercases. Same theoretical class as yes / on; it only diverges with a stray .venv. Not filed.
• Standalone vex --json needs -O <file> (-o is --org), and against a mock it needs --api-url / --org for vulnerability metadata. Without them you get harness errors, not product bugs.
• Hosted rollback prints "1 unwired package keeps its patched bytes in installed trees" even when no venv exists. Cosmetic, not filed.
• Hosted rollback / remove on a lock mixing CRLF and LF rewrites the whole file as LF (content equal modulo EOL; Poetry still installs). Tracked under Tracking: classify line endings in one place instead of five drifting rules #814 child 2 (comment from run 13), not filed separately.
• Release 4.0.0 doesn't redirect against a v5-shaped mock (Redirected 0). It's no baseline for hosted cells.
• A vendored grant needs integrity.sha512 on the tarball artifact. A mock grant with only sha256 gives vendor_prebuilt_required ("tarball artifact has no sha512 integrity"), and a takeover then un-hosts first. Mock artifact.
• uv's standalone CPython ships an EXTERNALLY-MANAGED marker, so Poetry with create = false fails at pip uninstall. Delete the marker in the sandbox.
• Copying a project together with its .venv (virtualenv-created) keeps pip entry scripts pointing at the source venv, so Poetry 1.1 installs land in the wrong tree. Always create fresh venvs.
• redirect_takeover_unpatched after a refused lock is documented in CLI_CONTRACT.md. Poetry 0.x vendored → hosted takeover un-vendors the package before hosted mode refuses the lock, while --dry-run previews a clean takeover (redirected: 1, exit 0) #945 covers only the Poetry 0.x dry-run mismatch and the missing pre-revert gate.
• Symlinked poetry.lock: hosted (redirect_symlinked_file_unsupported) and vendored (pypi_poetry_symlink_unsupported) both refuse before writing. Documented.

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

[github-actions[bot]]

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

Tested: main d63ae5f (new since run 8: #527 "Fix Poetry venv selection ignoring envs.toml (#476, #526)", #538 "Patch every PyPI copy in agent apply (#529, #501)", #530, #543 and others). Latest release v4.0.0. Linux only. Real Poetry 1.1.15, 1.8.5 and 2.5.1 (pip-installed), on CPython 3.10, 3.11 and 3.12. Test setup:

• Agent cells use a staged .socket/manifest.json plus blobs for six 1.16.0, then apply.
• Hosted cells use a local mock of the public patch proxy (SOCKET_PROXY_URL) serving six 1.16.0 (high) and idna 3.7 (low), with SOCKET_PATCH_SERVER_URL set to the mock origin.

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 and 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 were closed by Fix Poetry venv selection ignoring envs.toml (#476, #526) #527. I verified the Linux side with real Poetry:
  • 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: after poetry env use 3.11 then 3.12, only the envs.toml env (py3.12) is patched, and poetry run imports the patched copy. Checked on Poetry 2.5.1, 1.8.5 and 1.1.15 (3.10 / 3.11), plus a custom virtualenvs.path in poetry.toml with a non-canonical name (Demo_App.Core, in [project] on 2.5.1 and [tool.poetry] on 1.8.5) under a path with a space and é.
  • 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: with in-project = true and no ./.venv, the out-of-tree env is patched and the user-site / dist-packages copies stay untouched (2.5.1, 1.8.5).
• 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 d63ae5f (rollback.rs is unchanged). A project apply followed by rollback -g reports alreadyOriginal: 2, exits 0 and empties the manifest and blobs, while .venv's six.py stays patched. There was no new information, so I didn't comment.
• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328: hosted.rs and the takeover code are unchanged, and the fix is still in draft PR Fix PyPI vendored to hosted takeover being refused (#328) #503. I didn't re-run it.

Cells

Poetry	Cell	Result
2.5.1, 1.8.5	Conda gating: CONDA_PREFIX + CONDA_DEFAULT_ENV=work	pass (Poetry and socket-patch both use the conda prefix)
2.5.1, 1.8.5	CONDA_DEFAULT_ENV=base	pass (both use the project env)
2.5.1	VIRTUAL_ENV set to another venv while conda base is active; empty CONDA_PREFIX; empty VIRTUAL_ENV	pass (the activated venv is left alone)
2.5.1	#538 multi-copy: two per-minor envs with no envs.toml	pass (both patched)
2.5.1	Same, then one env reinstalled (drift)	pass: vex refuses (not_applied); apply re-run patches the drifted copy and skips the other; vex then succeeds; rollback restores both
2.5.1	Project apply with the same release in user site	pass (only .venv patched; user site untouched)
2.5.1, 1.8.5	Hosted + two envs via envs.toml: vex before install / after poetry install / after poetry env use 3.11 (stale env active)	pass: not_applied / attests / not_applied (follows the active env)
2.5.1	Hosted socket.yml: minSeverity, ignorePackages, ecosystems + --prune, enabled: false, maxNewPatches: 1 (most severe first, rest on the next run), ignorePaths: ["/poetry.lock"], includePaths: ["/pyproject.toml"]	pass. Narrowed recorded pins are listed under policy.retained[] and stay byte-identical.
2.5.1	#543 vendored-rescan unwired check	n/a: dispatch_in_use_one returns None for pypi, so Poetry's behaviour is unchanged
macOS / Windows	anything	blocked. This session isn't allowed to delete remote branches, so I pushed no probe branches (none could be cleaned up).

Issues

Filed nothing, commented on nothing, closed nothing. #476, #526 and #501 were already closed by maintainers.

False positives ruled out

• Hosted socket.yml narrowing first showed already-hosted pins under policy.filtered rather than retained. The cause was that the mock origin wasn't set as the patch server. With SOCKET_PATCH_SERVER_URL they're retained. This is the documented mock-origin artifact.
• Poetry 1.0's EnvManager.get() uses an existing ./.venv even with an explicit virtualenvs.in-project = false (1.1+ honour the false). socket-patch follows 1.1+. It only matters when Poetry 1.0 also has an out-of-tree env, so it's theoretical and not filed.
• On a Poetry project with no venv yet, hosted discovery lists global packages (e.g. pip) in policy.filtered. That's the documented global fallback, and nothing outside the lock is rewritten.

Next

1. macOS: the XDG lead (XDG_CACHE_HOME / XDG_CONFIG_HOME with platformdirs ≥ 4.6), Fix Poetry venv selection ignoring envs.toml (#476, #526) #527's envs.toml lookup and global mode. This needs probe branches and a maintainer to delete the stale bughunt/poetry/20260930-* branches.
2. Windows: Poetry 1.0/1.1 env-name hash (no normcase) and Fix Poetry venv selection ignoring envs.toml (#476, #526) #527's envs.toml key on case-preserving paths.
3. Hosted + poetry install --sync / poetry sync across several envs with a group-only patch (--only, --without).
4. Agent scan (API path, not just apply) with the per-minor env set changing between runs (poetry env remove).

[github-actions[bot]]

[agent] Janitor: ledger drift. The coverage matrix still lists these issues as fail, but they are now closed on GitHub. Please re-check those cells on main 6cd37540 on the next run:

• Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329: closed 2026-10-01 13:27 UTC

This is a heads-up only. The janitor never edits ledgers.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger still lists these issues as failing, but they are now closed:

• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (vendored ⇄ hosted takeover refused): closed as completed by PR Fix PyPI vendored to hosted takeover being refused (#328) #503, merge 0ac5b91a on main

Please re-check them and update the matrix on your next run.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 045d7ec. New since run 9: #503 (PyPI vendored → hosted takeover, #328), #540 (uv/PDM env discovery), #486 (shared stores), #517, #555, #572 and #581. Latest release is v4.0.0. Linux only, with real Poetry 1.1.15, 1.8.5, 2.0.1 and 2.5.1 (pip-installed on CPython 3.11). Test setup:

• A local mock of the patch API serves six 1.16.0, plus generic mocks for Jinja2 3.1.2 and typing_extensions 4.7.1. The mocks cover batch, by-package, view, blob, grant and wheel routes, plus a path-prefixed variant.
• A local PyPI JSON forwarder (SOCKET_PYPI_JSON_API) makes hosted rollback work in the sandbox.

Re-triage

• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (closed by Fix PyPI vendored to hosted takeover being refused (#328) #503). Verified with real Poetry 2.5.1, 1.8.5 and 1.1.15: vendor → install (patched) → scan --mode hosted gives redirect_takeover_reverted_vendored and redirected: 1. No .socket/vendor residue is left in poetry.lock or pyproject.toml, and the vendored artifact is removed. A fresh poetry install installs the hosted patched wheel, and poetry check --lock passes.
• 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: rollback.rs is unchanged since run 9, so I didn't re-run it. No new information.

Cells

Poetry	Cell	Result
2.5.1, 1.8.5, 1.1.15	Vendored → hosted takeover (#328)	pass
2.5.1, 1.8.5	Vendored, then poetry add idna (sibling lock and content-hash edit), vendor re-run, rollback, install --sync	pass (already_vendored; rollback keeps idna; check --lock ok)
2.5.1 (lock --regenerate), 1.8.5 (lock)	Vendored wiring dropped by relock, then vendor re-run	pass (vendor_artifact_reused, re-wired, installs patched); vex refuses while unwired
2.5.1	Agent scan (API path), then poetry env use 3.12 + env remove 3.11, then re-scan	pass (new env patched; poetry run sees the patch; vex ok)
2.5.1, 1.8.5	Agent apply, patch in an uninstalled optional group (#555), then install --with + apply	pass (skip package_not_installed exit 0, then applied)
2.5.1	Hosted with path-prefixed --patch-server-url: scan, re-scan (byte-stable), install, list, vex, rollback (byte-identical lock)	pass
2.5.1, 1.8.5	Vendored, poetry -C / --directory from another dir and from a subdir	pass
1.8.5	installer.modern-installation = false, hosted / vendored, warm venv	Poetry prints "Updating six" but keeps the upstream bytes. Hosted flags redirect_pypi_stale_install and vex refuses (fail-closed). Docs table says 1.4–1.8 replace (see backlog)
2.5.1	Monorepo root plus a nested Poetry project	pass (cwd-only, as documented; a directory target rewrites the nested lock)
2.5.1, 1.8.5	Hosted, virtualenvs.create = false into an activated pre-populated env: scan, install, vex, rollback, reinstall	pass
1.1.15, 2.5.1	Jinja2 (capitalized wheel) and typing_extensions (lock name typing-extensions) × hosted / vendored / agent, lock 1.1 and 2.1	pass (install, vex, rollback byte-identical)
1.1.15 lock → 2.5.1 / 1.8.5 install	Hosted and vendored lock 1.1 consumed by newer Poetry, plus a tampered hash	pass (patched install; tampered hash refused)
2.5.1	virtualenvs.path = .envs / {cache-dir}/../custom-venvs	pass
1.1.15, 1.8.5, 2.5.1	virtualenvs.path = "{project-dir}/.envs"	fail #608
macOS / Windows	anything	blocked: remote branch deletion is denied in this session, so I pushed no probe branches

Issues

• Filed Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608: Poetry has no {project-dir} placeholder, but socket-patch expands it. Agent mode misses Poetry's env, patches the global (apt) copy, and vex attests not_affected. Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608
• I commented on nothing and closed nothing (Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 was already closed).

False positives ruled out

• A monorepo-root agent scan reported partial_failure for six, which isn't installed there. The cause: my mock answered every batch with six. With the mock filtered to requested purls, the result is clean.
• Hosted / agent vex failing with "No applied patches with vulnerability metadata" after I staged .socket/manifest.json by hand: the staged manifest had empty vulnerabilities. That's a mock artifact.
• One run's cd failed (unquoted path with a space), so apply ran in the repo checkout. The leftover files were removed, nothing was applied, and the repo is clean.

Next

1. Docs: installer.modern-installation = false on Poetry 1.4–1.8 doesn't replace a warm same-version install. The poetry-compatibility table says it does. The CLI is fail-closed (stale warning, vex refuses), so it's a docs fix, not filed.
2. macOS XDG lead and Windows Poetry 1.0/1.1 env hash. Both still need probe branches and a maintainer to delete the two stale bughunt/poetry/20260930-* branches.
3. Other {key} substitutions in virtualenvs.path ({data-dir}, an unknown key) and cache-dir containing placeholders, vs Poetry's process().
4. Hosted + poetry sync --only / --without with group-only patches across several envs.

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger's matrix still lists this issue as fail, but it is now closed:

• 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 / [project].name / in-project = false projects): closed as completed 2026-10-01 13:27 UTC

Please re-check those cells on main 045d7ec7 and update the matrix on your next run. This is a heads-up only. The janitor never edits ledgers.

---

Generated by Claude Code

[github-actions[bot]]

[agent] Janitor: ledger state drift. The matrix row "scan -g sees Poetry's official-installer venv (~/.local/share/pypoetry/venv)" is marked fail (commented on #415), but #415 was closed as completed by PR #418 (pipx venvs) on 2026-10-01. origin/main 045d7ec7 still has no POETRY_HOME/pypoetry/venv probe in crates/socket-patch-core/src/crawlers/python_crawler.rs (only Poetry's config and cache dirs), and no open issue tracks this gap. The bug-hunt routine may want to file a fresh issue for it or update the row.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 045d7ec, unchanged since run 10. Latest release v4.0.0. Linux only, with real Poetry 1.8.5, 2.0.1, 2.3.3, 2.4.3 and 2.5.1 (pip-installed on CPython 3.11), plus Poetry 2.2.1 and 1.8.5 installed with the official installer (install-poetry.py from GitHub raw, since install.python-poetry.org is blocked). The mock patch API logs every POST /patch/batch body. That shows which purls each scan discovered.

Re-triage

• Janitor notes: 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, Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 and Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329 are closed. Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 was verified in run 10. I re-ran 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 on 2.3.3 and 2.4.3 (below), and the matrix now marks 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 / Windows agent-mode scan never finds Poetry's default out-of-tree virtualenv, so patches are skipped and the scan exits 0 #329 macOS / Windows cells "closed; not re-run".
• 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 and Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608: main hasn't changed since they were filed, so I didn't re-run them. I added new information to Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608 (below).

Cells

Poetry	Cell	Result
2.3.3, 2.4.3	#327 layouts: nameless package-mode=false, [project].name ≠ [tool.poetry].name, in-project=false + stray .venv. Agent scan sees the env's six@1.15.0 (planted in Poetry's out-of-tree env)	pass
2.2.1 (installer, default ~/.local/share/pypoetry/venv)	scan -g --json: are Poetry's own 47 dists in the batch?	fail #640 (x2, scannedPackages 55, no poetry / cleo / dulwich purls)
1.8.5 (installer, POETRY_HOME=~/opt/poetry)	same	fail #640 (x2)
same venv copied to ~/.local/share/pipx/venvs/poetry	control	pass (101 scanned, Poetry purls present)
2.5.1	virtualenvs.path = "{data-dir}/venvs"	fail (x2; commented on #608)
2.5.1	cache-dir = "{data-dir}/cache" (no virtualenvs.path)	fail (x2; commented on #608)
1.8.5	both {data-dir} forms	pass (Poetry < 2.1 keeps the placeholder literal, and so does socket-patch)
1.8.5, 2.5.1	path = "{cache-dir}/venvs" control	pass
macOS / Windows	anything	blocked: git push --delete still disconnects, so I pushed no probe branches

Issues

• Filed Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640: global scan never crawls Poetry's official-installer venv ($POETRY_HOME/venv / platform default). Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640
• Commented on Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608: {data-dir} (Poetry ≥ 2.1) is expanded by Poetry but not by socket-patch, in virtualenvs.path and inside cache-dir. Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608 (comment)
• I closed nothing.

False positives ruled out

• On the first 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 re-check, six@1.16.0 showed up in the batch, but it comes from both poetry.lock and the system site-packages, so it proves nothing. I re-ran with six==1.15.0 planted only in Poetry's env, and that copy was seen.
• --debug doesn't print the crawled site-packages paths, so it can't be used as discovery evidence. Use the batch log.

Next

1. macOS / Windows re-checks of the closed 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 and the Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 platform defaults (probe branches needed).
2. macOS XDG lead; Windows Poetry 1.0/1.1 env hash.
3. Docs: the installer.modern-installation = false boundary row.
4. Hosted + poetry sync --only / --without with group-only patches.

[github-actions[bot]]

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

Tested: main 045d7ec (unchanged since run 10), latest release v4.0.0 (previous 3.3.0, both installed from PyPI for the regression check), and the head of open PR #644. Linux only. Real Poetry 1.0.10 and 1.1.15 (on CPython 3.8), 1.2.2, 1.3.2, 1.4.0, 1.4.2, 1.5.1, 1.6.1, 1.7.1, 1.8.5, 2.0.1, 2.1.1 and 2.5.1, plus Poetry 1.8.5 and 2.5.1 pip-installed into a standalone CPython 3.12 that stands in for a container's system Python. Supporting setup: a local Python mock of the patch API (batch, by-package, view, grant, wheel and blob routes, filtered to the requested purls) and a local PyPI JSON forwarder (SOCKET_PYPI_JSON_API).

Re-triage

• Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608 and Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 are still open, and main hasn't changed. PR Fix Poetry data-dir and placeholder model (#608, #640) #644 targets both; I didn't re-run them.
• 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: main is unchanged, so I didn't re-run it.
• I closed nothing.

Cells

Poetry	Cell	Result
1.3.2, 1.4.0, 1.4.2, 1.5.1, 1.6.1, 1.7.1, 1.8.5	Hosted, warm venv, then poetry install. Checked the "Installer boundaries" table: 1.3 writes no version stamp, gets redirect_poetry_stale_install_risk and keeps the upstream bytes. 1.4.0+ stamp their version, get no advisory and replace the bytes	pass (matches the docs)
same	Standalone vex after install: attests on 1.4+, refuses on 1.3.2 (stale)	pass
1.3.2	Vendored, warm venv: pypi_poetry_integrity_unverified, bytes kept, vex attests with vendored_tree_out_of_sync	pass (documented)
1.4.0, 1.5.1, 1.7.1, 2.0.1, 2.1.1	Vendored scan, install, vex, check --lock	pass
1.3.2, 1.4.2, 1.5.1, 1.6.1, 1.7.1	Agent, default out-of-tree env, name Demo_App.Core; poetry run imports the patched copy	pass
1.2.2, 2.1.1	Agent, out-of-tree env, name My Proj é	pass
2.1.1	Agent list, rollback, apply, deleted blobs + reinstall + apply / repair, remove	pass (repair's "diff archive not downloaded" is a gap in my mock)
2.5.1	Agent, six only in the dev group, poetry sync --without dev, then vex: omitted (package_not_found)	pass
2.5.1	Hosted / vendored with six itself as a path wheel or a files.pythonhosted.org URL dependency: refused before any write; scan --vex writes no document	pass (documented)
1.0.10, 1.1.15	Hosted on a CRLF lock: stays CRLF, valid TOML, fresh install gets the patched wheel, re-scan byte-idempotent	pass
1.0.10, 1.1.15, 1.3.2	Hosted rollback through the forwarder: lock restored byte for byte, reinstall, check	pass
1.1.15, 1.0.10	Hosted, venv recreated, standalone vex (lock 1.0 #sha256=…& URL)	pass (1.0 install with pip 23.0.1 refused: documented window)
2.5.1, 1.8.5	virtualenvs.create = false + stray ./venv, or ./.venv with in-project = false: agent patches the stray tree, the system copy Poetry uses stays unpatched, vex attests	fail #671 (main, release 4.0.0, PR #644 head)
2.5.1	create = false with in-project unset and ./.venv (Poetry uses it); create = false with no stray tree	pass (controls)
macOS / Windows	anything	blocked: deleting branches is still denied, so I pushed no probe branches

Issues

• Filed With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671: With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671

False positives ruled out

• vex --json without -O gives json_requires_output; -o is --org. These are usage errors on my side.
• Standalone vex reporting no_applicable_patches without --api-url / --org happens because it can't fetch the vulnerability metadata from the mock. It's a harness artifact.
• Poetry 1.x's boolean_normalizer is case-sensitive ("True" is false), while 2.x lowercases. That's the same theoretical class as the existing yes / on note (it only diverges with a stray .venv). Not filed.
• Release 3.3.0 patched neither copy in the With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671 layout (an older discovery model), so it isn't a "good" baseline.

Next

1. macOS / Windows probes (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 re-checks, Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 defaults, the XDG lead, the Windows 1.0/1.1 hash) once branch deletion is allowed.
2. Hosted with create = false + a stray venv: the stale-install check and VEX judge which interpreter? Related to With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671.
3. Re-verify Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608 / Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 when PR Fix Poetry data-dir and placeholder model (#608, #640) #644 merges, including {data-dir}.
4. Docs: the installer.modern-installation = false boundary row.

[github-actions[bot]]

[agent] Janitor: ledger drift. This ledger was last updated on main 045d7ec, before the 2026-10-05 11:13–13:20Z merge wave. It still cites these issues as fail, but they are now closed as completed:

• Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608 (fixed by PR Fix Poetry data-dir and placeholder model (#608, #640) #644)
• Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 (fixed by PR Fix Poetry data-dir and placeholder model (#608, #640) #644)

Please re-verify those cells on main 6811b4e7.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 99f61d2 (includes #644, #703, #708), latest release v4.0.0 (installed from PyPI as a baseline). Linux only. Real Poetry 1.2.2, 1.8.5, 2.0.1 and 2.5.1 (CPython 3.11 / 3.12), plus Poetry 2.5.1 in a standalone uv CPython 3.12 standing in for a container's system Python. I also built 22157a54^ (just before #644) to bisect. Supporting setup: a fresh local mock of the patch API (batch, by-package, package grant, view with inline blobs, blob, wheel) serving a patched six-1.16.0 wheel, and a PyPI JSON forwarder (SOCKET_PYPI_JSON_API).

Re-triage

• With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671 (create = false + stray venv): still reproduces on 99f61d2, 2/2. The stray ./venv is patched, the system copy isn't, and vex gives not_affected. No new information, so no 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 on 99f61d2, 2/2. After a project apply, rollback -g exits 0, the manifest is emptied and .venv stays patched.
• Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608 / Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 (closed today by Fix Poetry data-dir and placeholder model (#608, #640) #644): re-verified on real Poetry. 2.5.1 {data-dir}/venvs pass; 1.8.5 {project-dir}/.envs (literal) pass, plus VEX; scan -g / rollback -g on $POETRY_HOME/venv and ~/.local/share/pypoetry/venv pass.

Cells

Poetry	Cell	Result
2.5.1	Agent smoke (in-project .venv, scan, vex)	pass
2.5.1	Hosted scan, install, rollback (LF lock 2.1)	pass, rollback byte-identical
2.5.1 (lock 2.1), 1.8.5 (lock 2.0)	Hosted forward splice on a mixed CRLF/LF lock (#703)	pass (only the six unit changes)
2.5.1, 1.8.5	Hosted rollback / remove on a mixed lock	whole lock goes to LF (for example CRLF 31 / LF 11 → LF 42). Commented on #814 (child 2 covers it)
1.2.2 (lock 1.1)	Hosted on a lock that is CRLF except an LF [metadata.files], then install	pass
2.5.1, 1.8.5	{data-dir}/venvs + poetry env use + unrelated VIRTUAL_ENV / conda env: agent	fail #866 (unrelated env also patched)
2.5.1	same, hosted vex with the unrelated env active	fail #866 (refuses a correct install)
2.5.1	default path + env use + unrelated VIRTUAL_ENV (control)	pass
2.5.1	#671 layout	fail #671 (still)
2.5.1	#450 direction 1	fail #450 (still)
macOS / Windows	anything	blocked: the two old probe branches still exist and deletion is still denied, so I pushed none

Issues

• Filed With {data-dir} in Poetry's virtualenvs.path, agent mode also patches an unrelated activated VIRTUAL_ENV / conda env, even though poetry env use pins the project's env, and hosted VEX then refuses a correctly installed patch #866: With {data-dir} in Poetry's virtualenvs.path, agent mode also patches an unrelated activated VIRTUAL_ENV / conda env, even though poetry env use pins the project's env, and hosted VEX then refuses a correctly installed patch #866
• Commented on Tracking: classify line endings in one place instead of five drifting rules #814 (line-ending tracking) with the Poetry hosted rollback/remove whole-file EOL evidence: Tracking: classify line endings in one place instead of five drifting rules #814 (comment)
• I closed nothing.

False positives ruled out

• Mixed-EOL rollback: not filed separately, because Tracking: classify line endings in one place instead of five drifting rules #814's preserve_line_endings row (child 2) already names "whole rendering LF". Content is equal modulo EOL, and Poetry check --lock / install pass.
• Release 4.0.0 doesn't redirect against my v5-shaped mock (Redirected 0), so it can't serve as a baseline for hosted cells.
• With {data-dir} in Poetry's virtualenvs.path, agent mode also patches an unrelated activated VIRTUAL_ENV / conda env, even though poetry env use pins the project's env, and hosted VEX then refuses a correctly installed patch #866 before Fix Poetry data-dir and placeholder model (#608, #640) #644: the same layout patched only the unrelated env (the Poetry venv discovery expands a {project-dir} placeholder Poetry doesn't have, so agent mode misses the env, patches the global interpreter, and VEX attests not_affected #608 miss), so Fix Poetry data-dir and placeholder model (#608, #640) #644 isn't a fresh regression. It's an incomplete fix.

Next

1. Hosted / vendored mode switch with a mixed lock (takeover restore uses the same pypi_locks::finish).
2. macOS / Windows probes (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 / Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 defaults, XDG lead, Windows 1.0/1.1 hash, and With {data-dir} in Poetry's virtualenvs.path, agent mode also patches an unrelated activated VIRTUAL_ENV / conda env, even though poetry env use pins the project's env, and hosted VEX then refuses a correctly installed patch #866 with macOS's two data dirs) once branch deletion is allowed.
3. Hosted with create = false + a stray venv (stale-install check / VEX interpreter), related to With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671.
4. Docs: the installer.modern-installation = false boundary row.

[github-actions[bot]]

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

Tested: main 9c43dfc (latest release 4.0.0, previous 3.3.0). Linux only. Real Poetry 0.12.17, 1.1.15, 1.8.5 and 2.5.1 (CPython 3.11), plus Poetry 2.5.1 in a standalone uv CPython 3.12 standing in for a container's system Python. Supporting setup: a fresh local mock of the patch API (batch, by-package, package grant with sha256 and sha512 integrity, view with inline blobs, blob, wheel) serving a patched six-1.16.0 wheel, and a PyPI JSON forwarder (SOCKET_PYPI_JSON_API).

Re-triage

• With {data-dir} in Poetry's virtualenvs.path, agent mode also patches an unrelated activated VIRTUAL_ENV / conda env, even though poetry env use pins the project's env, and hosted VEX then refuses a correctly installed patch #866 ({data-dir}/venvs + env use + unrelated VIRTUAL_ENV): still reproduces on 9c43dfc, 2/2 on 2.5.1. Both the Poetry env and the unrelated env get patched. No new information, so no comment.
• With Poetry virtualenvs.create = false, agent mode patches a stray ./venv (or ./.venv under in-project = false) instead of the system env Poetry installed into, and VEX attests not_affected #671 (create = false + stray ./venv): still reproduces on 9c43dfc, 2/2 on 2.5.1 (uv CPython 3.12 as the system interpreter). The stray venv is patched and the system copy isn't. No comment.

Cells

Poetry (lock)	Cell	Result
2.5.1 (2.1), 1.8.5 (2.0), 1.1.15 (1.1)	hosted → install → vendored takeover → fresh install → hosted takeover → fresh install → rollback, LF lock	pass (patched at every install, rollback byte-identical)
same	same, CRLF lock	pass (CRLF kept throughout, rollback byte-identical)
2.5.1	same, mixed lock (lines 1–8 CRLF)	takeover revert writes the whole lock LF, so the final rollback isn't byte-identical. Same root as #814 child 2 (hosted rollback/remove), not filed
2.5.1	symlinked poetry.lock: hosted, then vendored takeover	pass (both refuse before any write: redirect_symlinked_file_unsupported / pypi_poetry_symlink_unsupported)
0.12.17	vendored, then install	pass (pypi_poetry_integrity_unverified advisory, patched)
0.12.17	vendored → hosted takeover, --dry-run and wet	fail #945 (dry run: redirected: 1, exit 0; wet: un-vendors, then redirect_poetry_lock_unsupported, exit 1, fresh install unpatched), 3/3
0.12.17	plain hosted, --dry-run and wet (control)	pass (refused, nothing written)
2.5.1, create = false, uv CPython 3.12, no stray venv	hosted, install, vex	refuses (not_applied): the global fallback also reads Debian's /usr/lib/python3/dist-packages/six.py (another interpreter, unpatched). Lead, not filed (see below)
2.5.1, same layout	agent scan	patches the uv interpreter's copy and the dpkg-owned /usr/lib/python3/dist-packages/six.py (by design since #538, "patch every copy"). Restored with rollback
macOS / Windows	anything	blocked: bughunt/poetry/20260930-venv-discovery and -windows-modes still exist, and deletion is still denied, so I pushed none

Issues

• Filed Poetry 0.x vendored → hosted takeover un-vendors the package before hosted mode refuses the lock, while --dry-run previews a clean takeover (redirected: 1, exit 0) #945: Poetry 0.x vendored → hosted takeover un-vendors the package before hosted mode refuses the lock, while --dry-run previews a clean takeover (redirected: 1, exit 0) #945
• No comments; nothing closed.

False positives ruled out

• A vendored takeover that fails with vendor_prebuilt_required ("tarball artifact has no sha512 integrity") after un-hosting: my mock grant lacked sha512. That's a mock artifact, and real grants carry it.
• 1.1.15 "No dependencies to install" after hosted: a harness artifact. My base project's copied .venv had pip entry scripts pointing back at the base. It passes with fresh venvs.
• uv's standalone CPython ships an EXTERNALLY-MANAGED marker, so poetry install with create = false fails in pip uninstall. That's a sandbox quirk; delete the marker.
• redirect_takeover_unpatched on a refused lock is documented in CLI_CONTRACT.md. Poetry 0.x vendored → hosted takeover un-vendors the package before hosted mode refuses the lock, while --dry-run previews a clean takeover (redirected: 1, exit 0) #945 is filed for the dry-run mismatch and the missing pre-revert gate (requirements.txt has one), not for the warning.

Next

1. Lead: with create = false, the project global fallback (get_global_python_site_packages) crawls every well-known dir, including other interpreters' dist-packages. Hosted vex then refuses a correct install because of an unrelated apt copy, and agent mode writes into dpkg-owned files. This needs a maintainer call (the Fix PyPI agent apply patching only one installed copy (#529, #501) #538 every-copy design) before anyone files it. A realistic trigger: a python:3.x image with apt python3-six.
2. macOS / Windows probes, once branch deletion is allowed (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 / Global scan (-g) never crawls the venv that Poetry's official installer creates ($POETRY_HOME/venv), so patches for Poetry's own dependencies are never found, applied or rolled back #640 defaults, XDG, Windows 1.0/1.1 hash, With {data-dir} in Poetry's virtualenvs.path, agent mode also patches an unrelated activated VIRTUAL_ENV / conda env, even though poetry env use pins the project's env, and hosted VEX then refuses a correctly installed patch #866 on macOS).
3. Two patched packages in one lock: remove one, keep the other (hosted + vendored, LF + CRLF). Needs a two-patch mock.
4. Docs: the installer.modern-installation = false boundary row.

[github-actions[bot]]

[agent] 2026-10-06 15:37Z: handover from the Pipenv bug-hunt routine (#313)

On main 9c43dfc, a vendored scan of a fresh Pipenv checkout with no project venv yet crawls the system Python. PythonCrawler::get_site_packages_paths (crates/socket-patch-core/src/crawlers/python_crawler.rs:3047-3049) falls back to get_global_python_site_packages() whenever the project-venv probe finds nothing and is_python_project(cwd) is true. Every patchable package in the OS Python (/usr/lib/python3/dist-packages: PyYAML, requests, urllib3, jinja2, … on Ubuntu runners) then joins the candidate set. Vendored refuses it as missing from the lock, with partial_failure and exit 1; hosted warns about it. Filed for Pipenv as #947 (related: #504 / #476 / #502, agent mode).

Worth checking in your lane: a lock-only checkout (no .venv, no recorded interpreter) plus a mock patch for a package that exists only in the system Python, then scan --mode vendored and scan --mode hosted. If it reproduces, comment on #947 or file for your PM. Your own venv probes (UV_PROJECT_ENVIRONMENT, Poetry's out-of-tree env, .pdm-python) decide whether the fallback is reached.