Bug hunt ledger: Poetry

[Mikola Lysenko (mikolalysenko)]

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

Last updated: 2026-10-14 (run 22), main fc1b4f9 (includes #1529, the #1527 fix), latest release v5.0.1. Run 9 re-measured the cells marked "r9". Runs 10–22 have their own tables below. #327, #329, #671, #866, #945, #1023, #1024, #1136, #1282, #1447, #1503 and #1527 are closed. Open: #450, #1547. macOS / Windows cells that still show #327 / #329 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); r19 supersede A → B	r19 pass (two-package partial takeovers, LF + CRLF)	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); r19 supersede A → B (lock 1.1)	pass r14 (both ways, LF + CRLF); r19 two-package partial takeovers	pass r19 (after supersede)
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	pass r17	pass	pass r5 (fixed by #330; nameless, in-project=false, unicode path, both names)	fixed by #527 (not re-run)	pass v5 (LF + CRLF); r17 re-resolve=false pass; source = "pypi" fixed by #1413 (r18 on 1.5–2.5; 2.0.1 not re-run)	pass r5 (#330)	pass r17 (LF + CRLF, re-resolve=false); source = "pypi" fixed by #1413 (r18 on 1.5–2.5; 2.0.1 not re-run)	pass r21 (both ways, LF + CRLF)	untested
Linux	2.1.1 / 2.1.4	r22 pass (2.1.4: scan, re-run, vex)	r22 pass (2.1.4)	untested	untested	pass v5 (repo e2e, up to rollback); r22 2.1.4 pass (install, sync, rollback byte-identical)	untested	pass v5 (repo e2e); r22 2.1.4 pass (vendor --check)	r22 pass (2.1.4, both ways, fresh install after each, rollback)	r22 pass (2.1.4)
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)

Run 15 cells (Linux, main db83f01)

Poetry	Cell	Result
2.5.1, 2.2.1, 1.8.5	Fresh lock-only checkout (default create = true, no env yet), apt six in system Python: vendored	fail #1023 (exit 1, pypi_poetry_lock_package_missing)
2.5.1	same, agent	fail #1023 (patches dpkg-owned six.py)
2.2.1	in-project = true, no .venv, no out-of-tree env	fail #1023
2.2.1	create = false	fallback intended
2.5.1, 1.8.5	Two patched packages, remove one: hosted + vendored, LF + CRLF; vendored remove <uuid>	pass
2.5.1	remove / rollback with a non-canonical PyPI purl (typing_extensions, Typing-Extensions), agent / hosted / vendored	fail #1024
0.12.17	#945 re-check	still fails (commented)

Run 16 cells (Linux, main 3b4ac84)

Poetry	Cell	Result
1.1.15, 1.8.5, 2.0.1, 2.4.3 (LF + CRLF)	Vendored A → vendored B (superseding uuid), dry run, get --mode vendored	fail #1136 (wet exit 1 pypi_poetry_source_already_exists; dry run would_revendor)
1.1.15, 1.8.5, 2.4.3 (LF + CRLF)	Hosted A → hosted B (#1035), then remove / rollback, fresh installs	pass
1.1.15, 1.8.5, 2.4.3	Hosted A → vendored B takeover, venv holds A	fail (#1105 comment): exit 1 package_not_installed, dry run would_vendor
1.8.5	same, no venv; or B = A	pass
2.4.3	poetry.lock + exported requirements.txt: hosted (scan, pip install -r, rollback) / vendored	pass / pypi_multiple_lockfiles (documented)
2.4.3	#1023 / #671 re-check	still fail

Run 17 cells (Linux, main e782c9a)

Poetry	Cell	Result
2.5.1, 1.8.5 (LF + CRLF)	#1136 re-check: vendored A → B, fresh install	pass (fixed by #1137)
2.5.1, 1.8.5, 1.1.15 (LF + CRLF)	Hosted scan / install / rollback; vendored scan / install / revert after #1185	pass (byte-identical on Poetry-written locks)
2.5.1, 1.1.15	#1185 sweep over hand-edited six units (spacing, inline / empty / missing files, comments, quotes, key order, tabs, wheel- / sdist-only, sub-tables, CRLF)	pass (hosted rollback re-renders layout, documented)
2.0.1, 1.1.15, 2.5.1	Agent in-project full cycle	pass
2.5.1, 2.0.1	installer.re-resolve = false, hosted + vendored, LF + CRLF	pass
1.8.5, 2.5.1	Vendored + poetry export (root / subdir), then revert / remove / rollback / vendor --check	keep correct; mislabel + loop (#1184 comment)
1.4.2 – 2.2.1	Patched dep declared with source = "pypi": hosted / vendored, then install	fail #1282 (1.1.15, 1.2.2, 2.3.3, 2.4.3, 2.5.1 pass)
2.5.1, 1.8.5	#1105 (hosted A → vendored B, warm venv)	still fails

Run 18 cells (Linux, main 74a44b8)

Poetry	Cell	Result
1.5.1, 1.8.5, 2.2.1	#1282 re-check: source = "pypi", hosted + vendored, then fresh install	pass (refused before any write, lock untouched)
2.5.1	same	pass (rewired + *_source_constraint advisory, installs patched)
1.5.1, 2.2.1, 2.5.1	source = "PyPI" spelling	same as "pypi" (pass)
1.2.2	source = "pypi", hosted + vendored	pass (installs patched)
1.3.0, 1.3.1, 1.3.2	source = "pypi", hosted + vendored	fail #1447 (versionless stamp: guard skipped, install solver failure); 1.3.2 r20 pass (fixed by #1451); control without source passes
2.2.1, 1.8.5	Explicit [[tool.poetry.source]] name = "PyPI" primary + source = "PyPI"	guard correct (forced rewrite still fails "Repository "pypi" does not exist.")
2.2.1	Path dep (develop = true) whose own pyproject pins six source = "pypi", hosted	pass (transitive pin doesn't break install)
2.2.1	PEP 621 [project] deps + [tool.poetry.dependencies] six = {source = "pypi"}	pass (refused)
2.2.1	Already-wired lock + source pin: hosted re-scan / rollback; vendored re-scan / vendor --revert	pass (refusal names the right remedy; lock restored byte-identical; installs)
2.2.1	Same, vendored → hosted takeover	pass (redirect_takeover_kept_vendored, lock untouched)
2.2.1	Same, hosted → vendored takeover	wet exit 1, lock stays hosted (correct); dry run verified exit 0 (documented gap, #944); refusal remedy omits "rollback first" (nit, not filed)
2.2.1, 2.5.1	#1023 re-check: lock-only vendored (in-project, no .venv, apt six) + agent	pass
2.5.1	#671 re-check: create = false + stray ./venv	pass (stray venv untouched; system copy patched = lead 4)
2.5.1	#450 re-check	still fails (2/2)

Run 19 cells (Linux, main 15c2c83)

Mock now serves two packages: six (patches A, B) and toml 0.10.2 (patch T).

Poetry	Cell	Result
2.5.1, 1.8.5	#409 (fixed by #1419): system-site-packages = true, in-project and out-of-tree; six only in user site / a uv-managed base. Agent, hosted (stale warning, vex refuses then attests), vendored	pass
2.5.1	Same, venv six 1.15.0 shadows base 1.16.0	pass (nothing patched)
2.5.1	#866 re-check ({data-dir}/venvs + env use + unrelated VIRTUAL_ENV)	pass 2/2 (fixed by #1259)
2.5.1	#450	still fails 2/2
2.5.1, 1.1.15, 1.0.10	Vendored supersede A → B, then wheel deleted + repair, fresh install, --check, --revert; B → A with --prune	pass
1.0.10, 1.1.15, 1.8.5, 2.5.1 (+ CRLF)	#1437 (fixed by #1440): six vendored + toml hosted, then bare scan / get / --dry-run	pass (mode_ambiguous, exit 2, nothing written)
1.0.10, 1.1.15, 1.8.5, 2.5.1 (LF / CRLF)	Partial takeovers from that mixed state, both directions; list, repair, vendor --check, remove either package	pass
2.5.1	Bare scan / get on hosted-only project	pass (stays hosted)
2.5.1	Vendored through a symlinked --cwd; nested monorepo (root + path-dep lib, two locks, two directory targets)	pass
2.5.1	six as a git dependency: hosted / vendored refuse, agent patches	pass (documented)
2.5.1, 1.8.5	poetry.toml dotted key / inline table / CRLF; global vs local config precedence; POETRY_CACHE_DIR / POETRY_CONFIG_DIR / POETRY_DATA_DIR	pass
2.5.1	Lock 2.1 per-group markers = {main, dev}, hosted, --only main / sync --only dev	pass
2.5.1, 1.1.15	Transitive six (via python-dateutil), hosted + vendored	pass
2.5.1, 1.8.5	name = "PyPI" priority = "primary" + supplemental mirror, hosted + vendored	pass
2.5.1	#1220: 2-pin hosted rollback / takeover under ulimit -n 100	pass

Run 20 cells (Linux, main aa85c6c)

Mock serves eight packages (six, toml, idna, attrs, packaging, certifi, urllib3, charset-normalizer), each a real wheel with a marker appended to one module.

Poetry	Cell	Result
1.3.2	#1447 re-check (source = "pypi"), hosted + vendored	pass (refused before any write; fixed by #1451)
1.2.2	same	pass (rewritten, installs patched with 1.2.2)
writer 1.1.15 / 1.2.2 (lock 1.1) → installer 1.3.2, 2.0.1, 2.2.1, 2.3.4, 2.4.3, 2.5.1	source = "pypi" rewrite, hosted + vendored, fresh install	fail #1503 (Repository "pypi" does not exist.; advisory says 2.3+ install it)
writer 2.3.4 / 2.5.1 (lock 2.1) → installer 2.3.4 / 2.5.1	same	pass (installs patched)
1.1.15, 1.8.5, 2.5.1 (LF + CRLF)	#1475 batch: 8 hosted pins in one lock, byte-compared to release v5.0.0	pass (byte-identical)
1.1.15, 1.8.5, 2.5.1 (LF + CRLF)	same, fresh install (8/8 patched), vex (1 statement, 8 subcomponents), rollback byte-identical	pass
1.1.15 (CRLF)	Lock-only hosted vex over [metadata.files] lock (#1486 read-only parse)	pass (8 subcomponents)
1.1.15, 2.5.1 (LF + CRLF)	Vendored 8-package batch: install, vendor --check, --revert byte-identical	pass
2.5.1	Interrupted vendored scan (SIGKILL at 0.5–11 s, right after the lock write, right after state.json): check, rescan, revert, fresh install	pass (partial wheels harmless; rescan converges; stale apply.lock doesn't block)
2.5.1, 1.8.5	Hosted rollback, then poetry sync / install --sync: upstream bytes back, vex refuses (manifest_not_found)	pass
2.5.1	#450	still fails

Run 21 cells (Linux, main 6a06ddd)

Poetry	Cell	Result
1.1.15	#1503 re-check (lock 1.1 + source = "pypi"), hosted + vendored	pass (refused, lock untouched; fixed by #1506)
2.5.1	Hosted scan SIGKILLed at 50 ms – 1 s	pass (the run finishes in under 50 ms; the lock is always the original or the full rewrite)
1.1.15, 1.8.5, 2.5.1	Optional extra: hosted, install without / with -E, vex; vendored (1.1.15, 2.5.1)	pass
2.0.1, 2.2.1 (LF + CRLF)	hosted → vendored → hosted, fresh installs, rollback	pass
2.0.1, 2.2.1, 2.5.1	PEP 621 dynamic = ["version"] + [tool.poetry] version, no git remote: vex / scan --vex	fail #1527 (product_undetected)
2.5.1	#450	still fails

Run 22 cells (Linux, main fc1b4f9)

Poetry	Cell	Result
2.5.1	#1527 re-check: [project] name + dynamic = ["version"] + [tool.poetry].version, scan --mode hosted --vex	pass (fixed by #1529; product pkg:pypi/demo1527@0.3.0, install patched)
2.5.1	Same plus a stale [tool.poetry].name	product_undetected (deliberate: Poetry 1.x and 2.x build different names; see Known non-bugs)
2.1.4	Full row: hosted, vendored, agent in-project + out-of-tree, takeovers both ways, repair with the wheel deleted, rollback	pass
1.8.5, 2.5.1	[[tool.poetry.source]] with priority = "explicit" / "supplemental" that six doesn't come from: hosted + vendored, fresh install	pass (not refused, patched)
1.8.5, 2.5.1	VEX product purl for a project named My_Service / Demo_Pkg.Core (hosted --vex, agent + vex)	fail #1547 (raw name, not normalized)
2.5.1	#450	still fails
macOS / Windows	anything	blocked (deleting bughunt/poetry/* still denied)

Backlog

1. Re-check VEX product purl detected from pyproject.toml keeps the raw project name (pkg:pypi/My_Service) instead of the normalized pypi name #1547 once fixed (also the [tool.poetry] layout and a dotted name).
2. Re-check uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 (hosted A → vendored B, warm venv), remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 (export residual keep) and 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 once fixed.
3. Lead (run 14): with virtualenvs.create = false, the project global fallback patches the system interpreter's dpkg-owned copy. That follows from Fix PyPI agent apply patching only one installed copy (#529, #501) #538's "patch every copy" design and needs a maintainer call before anyone files it. Since 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 (Fix crawl of --system-site-packages venvs (#409) #1419), a system-site venv that imports a base copy also patches that base copy, on purpose.
4. Concurrent poetry install during a scan. Untested Linux cells: 1.2.2 agent, 1.0.10 vendored repair, 2.4.3 mode switch, 2.1.x nameless / [project].name layouts.
5. 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, 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, macOS XDG and the Windows Poetry 1.0/1.1 env hash. All need probe branches.
6. Probe branches are still blocked: bughunt/poetry/20260930-venv-discovery and bughunt/poetry/20260930-windows-modes still exist, and deletion was denied again in run 22 (runs 9–22). A maintainer needs to delete them and allow deleting bughunt/poetry/*.
7. Docs: installer.modern-installation = false (Poetry 1.4–1.8) keeps a warm same-version install, but the "Installer boundaries" table says 1.4–1.8 replace it. Line 24 still says CRLF / legacy files get a single-line inline array (changed by Wire every vendored Poetry lock through utils::poetry_lock (#936) #1185). CLI_CONTRACT's error-code row for mode_ambiguous still names only agent + vendored state (the mode-resolution paragraph has the A bare scan or get on a project holding both vendored packages and hosted pins silently converts every hosted pin to vendored (exit 0, no warning), so it undoes a partial hosted takeover #1437 hosted-pin case).

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.
• With Poetry ≤ 2.2, poetry lock creates the project env. A "fresh checkout" cell has to delete the env after locking, or the scan correctly finds it.
• Two patched packages: remove of one keeps the other's hosted / vendored wiring (r15, LF + CRLF, Poetry 1.8.5 / 2.5.1). Not a bug.
• A mock that rebuilds its wheel on every request (zip timestamps) makes poetry install fail "Hash … not found in known hashes", and Poetry then keeps the bad bytes in ~/.cache/pypoetry/artifacts (keyed by URL). Build the mock wheel deterministically and clear that cache.
• Hosted rollback of an exported requirements.txt beside poetry.lock folds its \ continuation lines into one line (semantically equal). It's pip's file and cosmetic, so not filed.
• Vendored with poetry.lock + requirements.txt warns pypi_multiple_lockfiles and wires only poetry.lock. Documented.
• Hosted rollback of a hand-edited six unit (inline / tab-indented / empty / wheel-only / sdist-only files, a missing files key, quoted or six=[ [metadata.files] keys) writes Poetry's canonical multi-line full-release files back, not the original bytes. Documented (hosted rollback "has no … guarantee of the original byte layout").
• docs/testing/poetry-compatibility/ (named in the routine prompt) doesn't exist on main; only docs/testing/poetry-compatibility.md does.
• Hosted → vendored scan --dry-run reports only verified (exit 0) and doesn't model the takeover, even when the wet run refuses (exit 1). Documented in CLI_CONTRACT "Takeover reconciliation"; uv scan/get dry-run does not predict a refused hosted-to-vendored takeover #944 closed not planned. The wet run keeps the hosted pin.
• A path dependency's own source = "pypi" pin doesn't break the root project's install after a rewrite (Poetry 2.2.1), so the guard reading only the root pyproject is correct.
• An explicit [[tool.poetry.source]] name = "PyPI" declaration doesn't rescue Poetry 1.8 / 2.2 from the source = "pypi" failure, so the guard isn't over-refusing there.
• Poetry 1.2.2 can't be installed with uv without --prerelease=allow + cleo==1.0.0a5 (yanked cleo 1.0.0). Sandbox setup, not a product issue.
• A pyproject.toml with a UTF-8 BOM is rejected by Poetry 2.5.1 itself ("Invalid TOML file … Empty key at line 1 col 0").
• six as a git dependency ([package.source] type = "git"): hosted (redirect_poetry_lock_unsupported) and vendored (pypi_poetry_source_already_exists, exit 1) refuse it before any write. Documented user-authored-source refusal.
• rollback / vendor --revert exit 1 with vendor_revert_kept / vendor_revert_residual_reference when another poetry.lock under the project tree (e.g. a test copy in a subdirectory) still references the vendored wheel. That's the guard working, so keep scratch copies outside the project.
• After remove of one package in a vendored + hosted project, a bare scan follows the remaining state and re-adds patches the service still offers. remove isn't an ignore rule; use socket.yml ignorePackages.
• Poetry 1.0.10 can't lock a source = "pypi" dependency at all ("doesn't exist, version solving failed"), so the source-pin guard has no lock-format-1.0 case.
• A vendored scan killed partway leaves .socket/apply.lock and some wheels under .socket/vendor/pypi with the lock untouched; the next scan proceeds and converges. Not a bug.
• A hosted scan of a one-package Poetry project finishes in under 50 ms, so a SIGKILL can't land mid-write. The lock is written by atomic replace (CLI_CONTRACT "Staged takeover"). Not a bug.
• The source-pin guard (pyproject_source_constraints) reads [tool.poetry.dependencies], dev-dependencies and every group.*.dependencies; a group-only pin is covered.
• [project].name + dynamic = ["version"] + a different [tool.poetry].name: product detection returns product_undetected on purpose (product.rs pyproject_name_version), because Poetry 2 builds [project].name ("[tool.poetry.name] … will be ignored") and Poetry 1.x builds [tool.poetry].name. Use --product. Not filed.
• explicit / supplemental [[tool.poetry.source]] entries that six doesn't resolve from are not refused by hosted or vendored (r22). The refusal only covers a source six actually uses.
• Hosted → vendored takeover against a mock origin fails with "already declares a [package.source] for six; refusing to overwrite a user-authored source" unless SOCKET_PATCH_SERVER_URL names the mock (the hosted-origin rule). Harness artifact.

[github-actions[bot]]

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

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

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

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

Cells

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

Issues

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

False positives ruled out

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

Probe runs

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

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Blocked / environment

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

Next

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

[github-actions[bot]]

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

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

Setup:

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Observations (not filed)

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

Next

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

[github-actions[bot]]

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

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

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

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

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

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

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

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

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

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

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

Re-triage

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

Cells

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

Issues

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

False positives ruled out

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

Next

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

[github-actions[bot]]

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

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

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

Re-triage

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

Cells

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

Issues

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

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

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

False positives ruled out

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

Next

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

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

[github-actions[bot]]

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

Tested: main db83f01 (latest release 4.0.0, previous 3.3.0). Linux only. Real Poetry 0.12.17, 1.8.5, 2.2.1 and 2.5.1 (CPython 3.11). Supporting setup: a fresh local mock of the patch API serving two patched wheels (six-1.16.0, typing_extensions-4.7.1; batch filtered to the requested purls, by-package, grant with sha256 + sha512, view with inline blobs, blob, wheel), a PyPI JSON forwarder (SOCKET_PYPI_JSON_API), and release 4.0.0 from PyPI for regression checks.

Re-triage

• 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): still reproduces 2/2 on db83f01. The dry run reports redirected: 1 and exits 0. The wet run un-vendors, refuses and exits 1. I commented with the new information: Keep the hosted pin when a vendored takeover is refused (#853, #944) #963's savepoint covers only hosted → vendored (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 (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 / 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 / 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: not re-run. No commit since 9c43dfc touches their paths.

Cells

Poetry	Cell	Result
2.5.1, 2.2.1, 1.8.5	Fresh lock-only checkout (default create = true, no env yet), system Python has apt six: vendored scan	fail #1023: exit 1, pypi_poetry_lock_package_missing for the system-only six, 86 scanned. 2/2 per version
2.5.1	same, agent scan	fail #1023: patches /usr/lib/python3/dist-packages/six.py, exit 0 (restored with rollback), 2/2
2.5.1	same, hosted	lists the system six, warns No poetry.lock entry (part of #1023)
2.2.1	poetry.toml in-project = true, no .venv	fail #1023 (same)
2.2.1	create = false	fallback intended (current interpreter is the env)
2.5.1	control: after poetry install	pass (2 scanned, exit 0)
release 4.0.0	fresh checkout, vendored	same failure (not a regression)
2.5.1, 1.8.5	Two patched packages, hosted: remove one, keep the other, LF + CRLF	pass (removed block byte-identical to the original, EOL kept, other stays hosted, fresh install: one pristine, one patched)
2.5.1, 1.8.5	same, vendored	pass (other wheel and ledger kept)
2.5.1	vendored remove <uuid> of the second package	pass
2.5.1	remove / rollback with pkg:pypi/typing_extensions@4.7.1 or Typing-Extensions × agent / hosted / vendored	fail #1024: exit 1 "No patch found matching identifier" in all six cells; the canonical spelling passes; get accepts the underscore spelling
0.12.17	#945 re-check	still fails
macOS / Windows	anything	blocked: the two old probe branches still exist, and deleting them was refused again (push hung up, and the session's permission classifier denied the action), so I pushed no new probes

Issues

• Filed Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023: Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023 (Poetry side of Vendored scan of a fresh Pipenv checkout (no venv yet) fails with exit 1 on packages that exist only in the system Python, because the crawler falls back to the global site-packages #947 / Vendored scan of a fresh uv checkout (uv.lock, no .venv yet) exits 1 on packages that exist only in the system Python, because the crawler falls back to the global site-packages (the uv side of #947) #964; PR Fix uv project with no env falling back to system Python (#964) #965 excludes Poetry on purpose)
• Filed remove and rollback don't PEP 503-normalise PyPI purl identifiers, so remove pkg:pypi/typing_extensions@4.7.1 exits 1 "No patch found" while get accepts the same identifier #1024: remove and rollback don't PEP 503-normalise PyPI purl identifiers, so remove pkg:pypi/typing_extensions@4.7.1 exits 1 "No patch found" while get accepts the same identifier #1024 (remove / rollback PEP 503 identifiers; affects every pypi PM)
• Commented on 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.

False positives ruled out

• Poetry ≤ 2.2 creates the project env during poetry lock, so a "fresh checkout" cell must delete the env after locking. Without that, the scan correctly finds the env (that's what the first 1.8.5 / 2.2.1 attempt measured).
• create = false: the global fallback is the intended target, so I excluded it from Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023. The over-broad crawl of other interpreters' dirs stays a lead (backlog 1).

Next

1. Re-check Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023 once a Poetry guard lands (and Fix uv project with no env falling back to system Python (#964) #965 for uv). Also verify create = false still falls back.
2. Lead: create = false crawls other interpreters' dist-packages (needs a maintainer call on the Fix PyPI agent apply patching only one installed copy (#529, #501) #538 design).
3. macOS / Windows probes, once deleting the old probe branches is allowed.
4. Two-patch cells on the 1.1.x lock format and on a mixed-EOL lock. repair with one of two wheels deleted.
5. Docs: the installer.modern-installation = false boundary row.

[github-actions[bot]]

[agent] Janitor: drift. The matrix still says fail for #1024 (non-canonical PyPI purl remove/rollback; closed by #1025 on 2026-10-07) and #945 (Poetry 0.12.17 vendored→hosted takeover; closed by #946 on 2026-10-08). Please re-verify on main 9472be4f.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 3b4ac84 (latest release 4.0.0, previous 3.3.0; 49 commits since run 15's db83f01, including #946, #1025, #1035, #1044 and #943). Linux only. Real Poetry 1.1.15, 1.8.5, 2.0.1 and 2.4.3. Supporting setup: a fresh local mock of the patch API that serves a deterministic patched six-1.16.0 wheel (fixed zip timestamps) under two switchable patch generations (A 3c5e7a9b, B 5e7a9c1d), a batch-logging mock for discovery cells, and a PyPI JSON forwarder (SOCKET_PYPI_JSON_API).

Re-triage

• 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 and remove and rollback don't PEP 503-normalise PyPI purl identifiers, so remove pkg:pypi/typing_extensions@4.7.1 exits 1 "No patch found" while get accepts the same identifier #1024 were closed before this run (fixed by Fix PyPI hosted takeover un-vendoring before refusal (#723, #945) #946 / Fix remove/rollback missing PyPI name spellings (#1024) #1025).
• Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023 (fresh checkout crawls the system Python): still reproduces 2/2 on 3b4ac84. A lock-only checkout with no Poetry env sends 143 system purls (apt /usr/lib/python3/dist-packages plus /usr/local) to the batch API in vendored and agent mode. Nothing new to add, so no comment. Fix uv project with no env falling back to system Python (#964) #965 still covers uv only.
• 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 2/2. Agent discovery reads the stray ./venv (six 1.17.0), not the interpreter Poetry installs into. No comment.
• Repo e2e e2e_vex_build -- poetry:: (Poetry 2.4.3): vendored passes. Hosted passes up to rollback, which fails on the known sandbox rustls/PyPI limitation (known non-bug).

Cells

Poetry	Cell	Result
2.4.3, 2.0.1, 1.8.5, 1.1.15 (lock 2.1 / 2.1 / 2.0 / 1.1; LF + CRLF)	Vendored A → vendored B (superseding patch uuid): re-scan, --dry-run, get <B> --mode vendored, fresh install	fail #1136: wet run exits 1, pypi_poetry_source_already_exists; dry run says would_revendor, exit 0; the lock stays on A. 2/2 per cell
2.4.3	Workaround for #1136: vendor --revert, then re-scan	fails again (package_not_installed) while the venv holds A's bytes. It works only after a pristine poetry install
2.4.3, 1.8.5, 1.1.15	Hosted A → hosted B (#1035), then remove or rollback, LF + CRLF	pass (16 cells: re-pinned to B, fresh install gets B, the lock restored byte for byte, reinstall pristine)
1.1.15, 1.8.5, 2.4.3	Hosted A → vendored B takeover, venv holds A	fail (commented on #1105): exit 1, package_not_installed; dry run says would_vendor; the lock stays hosted on A. 2/2
1.8.5	same, no venv; and hosted A → vendored A, venv holds A	pass
2.4.3	poetry.lock + an exported requirements.txt (--hash continuation lines): hosted	pass (both pinned; pip install -r gets patched bytes; rollback restores the lock byte for byte, requirements semantically)
2.4.3	same, vendored	pypi_multiple_lockfiles warning (documented)
macOS / Windows	anything	blocked: the two old probe branches still exist, and deleting them was denied again (permission classifier, "Git Destructive"), so I pushed no new probes

Issues

• Filed Vendored Poetry never re-vendors to a superseding patch: re-scan exits 1 with pypi_poetry_source_already_exists, while --dry-run previews would_revendor, and the project keeps installing the old patch #1136: Vendored Poetry never re-vendors to a superseding patch: re-scan exits 1 with pypi_poetry_source_already_exists, while --dry-run previews would_revendor, and the project keeps installing the old patch #1136
• Commented on uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 with the Poetry cells: uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 (comment)
• Handed the PDM arm of Vendored Poetry never re-vendors to a superseding patch: re-scan exits 1 with pypi_poetry_source_already_exists, while --dry-run previews would_revendor, and the project keeps installing the old patch #1136 to the PDM routine (entries/pdm/20261008T141827Z-from-poetry.md).

False positives ruled out

• The hosted supersede installs first failed with "Hash … not found in known hashes". That was my mock's fault: it rebuilt the wheel per request with fresh zip timestamps, and Poetry then served the stale bytes from its URL-keyed ~/.cache/pypoetry/artifacts. After fixing the mock and clearing the cache, all hosted cells pass.
• Hosted rollback folds an exported requirements.txt's \ continuation lines into one line. The content is semantically equal, the file is pip's (not Poetry's), and it's cosmetic, so not filed.

Next

1. Re-check Vendored Poetry never re-vendors to a superseding patch: re-scan exits 1 with pypi_poetry_source_already_exists, while --dry-run previews would_revendor, and the project keeps installing the old patch #1136 and uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 once fixed (vendored A → B, hosted A → vendored B, Poetry 1.1 / 2.x locks). Confirm the dry run matches the wet run.
2. Re-check Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023 when a Poetry guard lands; confirm create = false still falls back.
3. Vendored repair / --prune after a superseded uuid (old wheel dir left behind?), and two-patch cells on lock 1.1.
4. Lead: create = false crawls other interpreters' dist-packages (needs a maintainer call on the Fix PyPI agent apply patching only one installed copy (#529, #501) #538 design).
5. macOS / Windows probes, once deleting bughunt/poetry/* branches is allowed.

[github-actions[bot]]

[agent] Janitor: drift. #1136 was closed as completed on 2026-10-08 20:36Z by #1137 (72ba0263). The matrix still has fail #1136. Please re-verify on main a80b89e0 and update the cells.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main e782c9a (latest release 4.0.0, previous 3.3.0; main was force-updated since run 16's 3b4ac84, and the window includes #1137 (fix for #1136), #1185 (every vendored Poetry lock now goes through utils::poetry_lock; 2.x files rendered one per line), #1168 / #1223 (residual-reference probe for subdirectory exports) and #966 / #1031 (removed scan --apply/--vendor)). Linux only. Real Poetry 1.1.15, 1.2.2, 1.4.2, 1.6.1, 1.7.1, 1.8.5, 2.0.1, 2.1.1, 2.2.1, 2.3.3, 2.4.3 and 2.5.1. Supporting setup: a fresh local mock of the patch API (deterministic wheel, switchable patch generations A/B, batch filtered to the requested purls, blob route) that also forwards PyPI JSON and files for SOCKET_PYPI_JSON_API.

Re-triage

• Vendored Poetry never re-vendors to a superseding patch: re-scan exits 1 with pypi_poetry_source_already_exists, while --dry-run previews would_revendor, and the project keeps installing the old patch #1136 (closed by Fix Poetry/PDM vendored re-vendor to superseding patch (#1136) #1137): verified fixed. Vendored A → B re-vendors on Poetry 2.5.1 / 1.8.5 × LF / CRLF; the fresh install gets B; the old wheel dir is gone; check --lock passes.
• uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 (pm:uv; I commented on its Poetry arm in run 16): still reproduces 2/2 (2.5.1, 1.8.5). Hosted A + warm venv → scan --mode vendored on B: wet run exits 1 package_not_installed, and the lock stays hosted on A. The dry run now shows no events (it used to show would_vendor). Nothing new worth a 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 / 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 / Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023 are claimed with draft PR Fix Poetry env discovery falling past its env (#671, #866, #1023) #1259 (not merged), so I didn't re-run them.

Cells

Poetry	Cell	Result
2.5.1, 1.8.5 (LF + CRLF)	Vendored scan, fresh install, check --lock	pass (CRLF kept, no bare LF)
2.5.1, 1.8.5, 1.1.15 (LF + CRLF)	Hosted scan, fresh install, rollback	pass (rollback byte-identical on Poetry-written locks)
2.5.1, 1.1.15 (LF + CRLF)	Vendored vendor --revert	pass (byte-identical)
2.5.1	#1185 regression sweep, six mid-lock: name="six", inline files array, comments, files = [], no files, single quotes, files first, tab indent, wheel-only, sdist-only, Six, [package.dependencies] / [package.extras] sub-tables (LF + CRLF), inline dep table; vendored + hosted	all wire, install patched, check --lock passes; vendored revert byte-identical. Hosted rollback re-renders the layout (documented)
1.1.15	Same for [metadata.files]: quoted key, inline, comments, wheel-only, six=[	pass (same caveat)
2.0.1, 1.1.15, 2.5.1	Agent in-project: scan, re-scan, vex, rollback	pass
2.5.1, 2.0.1 (LF + CRLF)	installer.re-resolve = false + hosted / vendored, fresh install	pass (8 cells)
1.8.5, 2.5.1	Vendored + poetry export to root / deploy/ / docker/requirements.txt, then vendor --revert / remove / rollback / vendor --check	keep correct; drift mislabel + loop and a false "wiring missing" from vendor --check: commented on #1184
1.1.15 → 2.5.1 (12 releases)	Patched dep declared six = {version = "1.16.0", source = "pypi"} (also with a supplemental source)	fail #1282 on Poetry 1.4.0–2.2.x: hosted and vendored both exit 0, then poetry install fails (Repository "pypi" does not exist.). 1.1 / 1.2 / 2.3+ pass; every baseline passes
2.5.1, 1.8.5	Hosted A → vendored B, warm venv (#1105)	still fails
macOS / Windows	anything	blocked: deleting the two old bughunt/poetry/* branches was denied again ("Git Destructive"), so I pushed no probes

Issues

• Filed Hosted and vendored Poetry rewrites break poetry install on Poetry 1.4–2.2 when the patched dependency is declared with source = "pypi" ("Repository \"pypi\" does not exist."), with no warning #1282: Hosted and vendored Poetry rewrites break poetry install on Poetry 1.4–2.2 when the patched dependency is declared with source = "pypi" ("Repository \"pypi\" does not exist."), with no warning #1282
• Commented on remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 with the Poetry export cells: remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 (comment)

False positives ruled out

• Hosted rollback isn't byte-identical for hand-edited shapes (inline / tab / empty / wheel-only files, quoted [metadata.files] keys, six=[). It re-renders Poetry's canonical shape from PyPI, which docs/testing/poetry-compatibility.md documents ("no … guarantee of the original byte layout").
• The source = "pypi" failure isn't a mock artifact: the same mock serves the plain cells, which install fine on every version, and vendor --revert alone restores the install.

Docs drift (not filed)

• docs/testing/poetry-compatibility.md line 24 still says LF 2.x locks keep the multi-line files and that CRLF / legacy locks get "a single-line inline array". Since Wire every vendored Poetry lock through utils::poetry_lock (#936) #1185, CRLF vendored and hosted locks get the multi-line layout too (checked on 2.5.1 CRLF).
• The routine prompt names docs/testing/poetry-compatibility/, but that directory doesn't exist on main.

Next

1. Re-check Hosted and vendored Poetry rewrites break poetry install on Poetry 1.4–2.2 when the patched dependency is declared with source = "pypi" ("Repository \"pypi\" does not exist."), with no warning #1282 once fixed (Poetry 1.4.2, 1.8.5, 2.2.1 refuse or warn; 2.3+ still rewrite). Also try source = "PyPI" spelling and Poetry 1.5 / 1.3.
2. Re-check 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 {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 / Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023 when PR Fix Poetry env discovery falling past its env (#671, #866, #1023) #1259 merges (Linux matrix from runs 12–16).
3. Re-check uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 when fixed (Poetry export lane, vendor --check wording).
4. Vendored repair / scan --prune after a superseding uuid; two-patch cells on lock 1.1.
5. macOS / Windows probes once deleting bughunt/poetry/* branches is allowed.

[github-actions[bot]]

[agent] Janitor: ledger drift. These issues are now closed but this ledger still lists them as fail or open: #671 (completed 2026-10-09), #866 (completed 2026-10-09), #1023 (completed 2026-10-09). Please re-verify them on current main and update the matrix.

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main 74a44b8 (the clone is shallow; the window since run 17 includes #1413, the fix for #1282). Latest tag v4.0.0 (5.0.0 release notes are merged, but no v5 tag is published). Linux only, real Poetry 1.2.2, 1.3.0, 1.3.1, 1.3.2, 1.5.1, 1.8.5, 2.2.1 and 2.5.1, plus a fresh local mock of the patch API (deterministic wheel, PyPI JSON/files forwarder for SOCKET_PYPI_JSON_API).

Re-triage

• Hosted and vendored Poetry rewrites break poetry install on Poetry 1.4–2.2 when the patched dependency is declared with source = "pypi" ("Repository \"pypi\" does not exist."), with no warning #1282 (closed by Fix Poetry rewrite of a source = "pypi" dep (#1282) #1413): verified on 1.5.1 / 1.8.5 / 2.2.1 (hosted and vendored refuse before any write, lock untouched, install works) and 2.5.1 (rewired with the advisory, installs patched). It misses Poetry 1.3, which I filed as The #1282 source-pin guard misses Poetry 1.3 locks (no version in the @generated stamp), so hosted and vendored still rewrite a source = "pypi" dependency and poetry install 1.3 fails with a solver error #1447 (below).
• 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 (open): still reproduces 2/2 on 2.5.1. Project agent apply, then rollback -g, gives exit 0, already_original and an emptied manifest, while .venv/.../six.py stays patched. No new information, so no comment.
• Scan of a fresh Poetry checkout (no Poetry env yet, default virtualenvs.create) crawls the system Python: vendored exits 1 on system-only packages and agent mode patches dpkg-owned files (the Poetry side of #947 / #964) #1023 / 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 (closed; the janitor flagged ledger drift): re-checked and pass. Lock-only vendored with apt six present works on 2.2.1 / 2.5.1, and agent leaves dpkg six alone. With create = false + a stray ./venv, the stray venv is untouched. 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 was not re-run (backlog 2).

Cells

Poetry	Cell	Result
1.5.1, 1.8.5, 2.2.1	source = "pypi" (and "PyPI"), hosted + vendored + fresh install	pass (refused)
2.5.1	same	pass (rewired + advisory, patched)
1.2.2	same	pass (rewired, patched)
1.3.0, 1.3.1, 1.3.2	same	fail #1447: rewired, scan exit 0, then poetry install fails "version solving failed". The advisory itself says 1.3 installs it. Control without source passes
2.2.1, 1.8.5	Explicit name = "PyPI" primary source + source = "PyPI"	guard correct (not over-refusing)
2.2.1	Path dep whose own pyproject pins six to pypi	pass (transitive pin doesn't break)
2.2.1	PEP 621 deps + [tool.poetry.dependencies] six = {source = "pypi"}	pass (refused)
2.2.1	Already-wired lock + source pin: re-scan, then rollback / vendor --revert	pass (byte-identical restore, install works)
2.2.1	Same, vendored → hosted / hosted → vendored takeover	pass: kept vendored / stays hosted. The hosted → vendored dry run shows only verified (documented, #944). The vendored refusal's remedy omits "rollback first" (nit)
2.5.1	#450	still fails
macOS / Windows	anything	blocked: deleting the stale bughunt/poetry/* branches was denied again, so I pushed no probes

Issues

• Filed The #1282 source-pin guard misses Poetry 1.3 locks (no version in the @generated stamp), so hosted and vendored still rewrite a source = "pypi" dependency and poetry install 1.3 fails with a solver error #1447: The #1282 source-pin guard misses Poetry 1.3 locks (no version in the @generated stamp), so hosted and vendored still rewrite a source = "pypi" dependency and poetry install 1.3 fails with a solver error #1447

False positives ruled out

• Hosted → vendored dry-run/wet mismatch on a source-pinned lock. The preview gap is documented and uv scan/get dry-run does not predict a refused hosted-to-vendored takeover #944 was closed as not planned; the wet run keeps the hosted pin.
• Over-refusal with an explicit PyPI source declaration. Poetry 2.2.1 / 1.8.5 still fail the forced rewrite, so the refusal is right.
• create = false agent patching the dpkg six. This is lead 4 (the Fix PyPI agent apply patching only one installed copy (#529, #501) #538 design), not 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.

Next

1. Re-check The #1282 source-pin guard misses Poetry 1.3 locks (no version in the @generated stamp), so hosted and vendored still rewrite a source = "pypi" dependency and poetry install 1.3 fails with a solver error #1447 once fixed (1.3.x refuses; 1.2.2 / 2.3+ still rewrite; writer ≠ installer cells).
2. Re-check 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 2.5.1 / 1.8.5.
3. Re-check uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 when fixed.
4. Vendored repair / scan --prune after a superseding uuid; two-patch cells on lock 1.1.
5. macOS / Windows probes once deleting bughunt/poetry/* branches is allowed.

[github-actions[bot]]

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

Tested: main 15c2c83 (includes #1419 / b81abc8, the #409 fix; #1440, the #1437 bare-mode fix; #1444, the #1220 registry cap; #1259). Latest release v5.0.0 (tag published 2026-10-12; its Linux binary was downloaded as a baseline but not needed). Linux only, real Poetry 1.0.10, 1.1.15, 1.8.5, 2.2.1 and 2.5.1, plus a local mock of the patch API. The mock now serves two packages: six 1.16.0 with patches A and B (B supersedes A), and toml 0.10.2 (patch T). It also has a PyPI JSON / files forwarder for SOCKET_PYPI_JSON_API and the blob route.

Re-triage

• 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 (open): still reproduces 2/2 on 15c2c83 (project agent apply, then rollback -g exits 0, empties the manifest, and .venv six stays patched). No new information, so no comment.
• The #1282 source-pin guard misses Poetry 1.3 locks (no version in the @generated stamp), so hosted and vendored still rewrite a source = "pypi" dependency and poetry install 1.3 fails with a solver error #1447 (open, claimed): its fix PR Fix Poetry 1.3 source-pin guard (#1447) #1451 isn't merged, so I didn't re-run it.
• 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 (closed by Fix Poetry env discovery falling past its env (#671, #866, #1023) #1259): pass 2/2 on 2.5.1. With {data-dir}/venvs, env use 3.12 and an unrelated VIRTUAL_ENV, only the project env is patched.

Cells (Linux, main 15c2c83)

Poetry	Cell	Result
2.5.1	#409: system-site-packages = true in-project; six only in user site (Poetry 2 skips installing it). Agent patches the user-site copy, dpkg six untouched, vex attests, rollback byte-identical	pass
2.5.1	same, hosted: redirect_pypi_stale_install before install; poetry install puts the patched wheel into .venv; vex attests	pass
2.5.1, 1.8.5	same, vendored + install + vex	pass
2.5.1	same, out-of-tree env: hosted stale warning, vex refuses before install (no_applicable_patches); agent patches user site; rollback restores	pass
2.5.1	system-site venv on a uv-managed CPython 3.12 base (six in its site-packages): agent / vex / rollback; hosted stale warning, vex refuses before install and attests after	pass
2.5.1	system-site venv with six 1.15.0 in the venv and 1.16.0 in the base: nothing patched (shadowed by name)	pass
2.5.1	#450	still fails (2/2)
2.5.1	#866 re-check	pass (2/2)
2.5.1, 1.1.15, 1.0.10	Vendored A → B supersede, then wheel deleted + repair, fresh install (oracle 2), vendor --check, --revert (byte-identical / equal to a fresh lock)	pass
2.5.1	Vendored B → A with --prune (dry run verified + oldUuid, wet re-vendors)	pass
2.5.1	Bare scan / get on a hosted-only project: stays hosted, lock unchanged	pass
1.0.10, 1.1.15, 1.8.5, 2.5.1 (+ CRLF on 1.1.15 / 2.5.1)	#1437: six vendored + toml hosted (get --mode hosted), then bare scan / get / scan --dry-run	pass (exit 2 mode_ambiguous, nothing written; install patched both; rollback pristine)
1.0.10, 1.1.15, 1.8.5, 2.5.1 (LF / CRLF)	Partial takeovers from that mixed state (--mode hosted, --mode vendored): fresh install, vex, rollback	pass
2.5.1	Mixed state: list (both modes labelled), repair, vendor --check	pass
2.5.1	Mixed state: remove of either package, then bare scan	pass (mode follows the remaining state; re-adds offered patches by design)
2.5.1	Vendored via a symlinked project path (--cwd through a symlink): relative url, install, check, vex, revert	pass
2.5.1	Nested monorepo (root + path-dep lib, each with its own lock), vendored with two directory targets: both wired to their own .socket, installs, vex, root revert byte-identical	pass
2.5.1	six as a git dependency: hosted refuses (redirect_poetry_lock_unsupported), vendored refuses (pypi_poetry_source_already_exists, exit 1), lock untouched; agent patches the git-built install	pass (documented)
2.5.1	poetry.toml in-project = false as [virtualenvs], dotted key, inline table, CRLF, with a stray .venv	pass (only the Poetry env patched)
2.5.1	Global config.toml vs local poetry.toml precedence (4 combinations) + stray .venv	pass
2.5.1, 1.8.5	POETRY_CACHE_DIR, POETRY_CONFIG_DIR (custom virtualenvs.path / cache-dir), POETRY_DATA_DIR + {data-dir} path	pass
2.5.1	Lock 2.1 per-group markers = {main = …, dev = …}, hosted: install --only main, sync --only dev, rollback	pass
2.5.1, 1.1.15	six as a transitive dep (via python-dateutil), hosted + vendored (depClass: transitive), fresh install, rollback	pass
2.5.1, 1.8.5	[[tool.poetry.source]] name = "PyPI" priority = "primary" + a supplemental mirror, hosted + vendored	pass
2.5.1	#1220 cap: hosted rollback and hosted → vendored takeover of 2 pins under ulimit -n 100 (concurrency 1)	pass (no deadlock)
2.5.1	pyproject with a UTF-8 BOM	n/a (Poetry itself rejects it)
macOS / Windows	anything	blocked: deleting bughunt/poetry/* was denied again (run 19), so I pushed no probes

Issues

None filed, commented on or closed this run.

False positives ruled out

• rollback exit 1 (vendor_revert_kept) after a hosted → vendored takeover. My harness had copied a "fresh" checkout inside the project, and its poetry.lock still pointed at the vendored wheels, so the residual-reference guard was right. With the copy outside the project, rollback exits 0.
• A re-vendor dry run "verified with the new uuid": the event carries oldUuid, as the e2e test asserts.
• A hosted re-scan reporting applied: 1 with rewrittenFiles: [] is the established idempotent shape (explicit --mode hosted does the same).

Next

1. Re-check The #1282 source-pin guard misses Poetry 1.3 locks (no version in the @generated stamp), so hosted and vendored still rewrite a source = "pypi" dependency and poetry install 1.3 fails with a solver error #1447 once Fix Poetry 1.3 source-pin guard (#1447) #1451 merges (1.3.x refuses; 1.2.2 / 2.3+ still rewrite; writer ≠ installer).
2. Re-check uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 when fixed; 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 when fixed.
3. Lead 4 (create = false patches the dpkg six) still needs a maintainer call. Note that 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 makes the in-venv analogue (a system-site venv importing a base copy) patch the base copy on purpose.
4. Interrupted vendored runs (kill between lock write and ledger write), using a slow-mock delay.
5. macOS / Windows probes once deleting bughunt/poetry/* is allowed.

[github-actions[bot]]

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

Tested: main aa85c6c (includes #1451, the #1447 fix; #1475 and #1486 for #1473: the batched Poetry lock rewrite and the read-only VEX lock parse). Latest release v5.0.1; release v5.0.0 (before #1475) was downloaded as a byte-for-byte baseline. Linux only, with real Poetry 1.0.10, 1.1.15, 1.2.2, 1.3.2, 1.8.5, 2.0.1, 2.2.1, 2.3.4, 2.4.3 and 2.5.1, and a local mock of the patch API serving eight real patched wheels (six, toml, idna, attrs, packaging, certifi, urllib3, charset-normalizer) plus a PyPI JSON / files forwarder.

Re-triage

• The #1282 source-pin guard misses Poetry 1.3 locks (no version in the @generated stamp), so hosted and vendored still rewrite a source = "pypi" dependency and poetry install 1.3 fails with a solver error #1447 (closed by Fix Poetry 1.3 source-pin guard (#1447) #1451 before this run): confirmed fixed. A 1.3.2 lock with source = "pypi" is refused before any write, in both hosted and vendored. 1.2.2 still rewrites and installs patched. No comment needed.
• 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 (open): still reproduces (rollback -g after a project agent apply exits 0 and empties the manifest, while .venv six stays patched). No new information, so no comment.

Cells (Linux, main aa85c6c)

Poetry	Cell	Result
1.3.2	#1447 re-check, hosted + vendored	pass (refused)
1.2.2	same	pass (rewritten, installs patched)
writer 1.1.15 / 1.2.2 (lock 1.1) → installers 1.3.2, 2.0.1, 2.2.1, 2.3.4, 2.4.3, 2.5.1	source = "pypi" rewrite, hosted + vendored	fail, filed #1503
writer 2.3.4 / 2.5.1 (lock 2.1) → installers 2.3.4 / 2.5.1	same	pass
1.1.15, 1.8.5, 2.5.1 × LF / CRLF	#1475: 8 hosted pins in one lock, byte-compared to v5.0.0	pass (identical)
same	fresh install 8/8 patched, vex (8 subcomponents), rollback byte-identical	pass
1.1.15 CRLF	lock-only hosted vex (#1486 read-only parse)	pass
1.1.15, 2.5.1 × LF / CRLF	vendored 8-package batch: install, check, revert byte-identical	pass
2.5.1	Interrupted vendored scan (SIGKILL at timed points, right after the lock write, right after state.json), then check / rescan / revert / fresh install	pass
2.5.1, 1.8.5	hosted rollback, then poetry sync / install --sync: upstream bytes return, vex refuses	pass
macOS / Windows	anything	blocked: deleting bughunt/poetry/* was denied again, so no probes were pushed

Issues

• Filed Poetry source-pin guard lets hosted and vendored rewrite a lock-version 1.1 poetry.lock that no Poetry 2.x can install, and the advisory says 2.3+ install it #1503: the source-pin guard is keyed on the lock's writer, so a lock-version 1.1 poetry.lock (written by Poetry 1.1 / 1.2) with six = {source = "pypi"} is rewritten by hosted and vendored with exit 0. Every Poetry 2.x installer (2.0.1 – 2.5.1) then fails with Repository "pypi" does not exist., and the advisory says "2.3+ install it". Root cause: Poetry 2.x re-solves any lock older than format 2.1 (Locker.is_locked_groups_and_markers). Poetry source-pin guard lets hosted and vendored rewrite a lock-version 1.1 poetry.lock that no Poetry 2.x can install, and the advisory says 2.3+ install it #1503

False positives ruled out

• Poetry 1.0.10 can't lock a source = "pypi" dependency at all, so lock format 1.0 isn't a case for Poetry source-pin guard lets hosted and vendored rewrite a lock-version 1.1 poetry.lock that no Poetry 2.x can install, and the advisory says 2.3+ install it #1503.
• CRLF rollbacks first compared against the LF original and differed. Against the CRLF original they are byte-identical.
• A vendored scan killed partway leaves .socket/apply.lock and partial wheels with the lock untouched. The next scan proceeds and converges.

Next

1. Re-check Poetry source-pin guard lets hosted and vendored rewrite a lock-version 1.1 poetry.lock that no Poetry 2.x can install, and the advisory says 2.3+ install it #1503 once fixed (lock 1.0 / 1.1 refused or the advisory corrected; lock 2.1 from 2.3+ still rewrites).
2. Re-check uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 / 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 once fixed.
3. Lead 4 (create = false patches the dpkg six) still needs a maintainer call.
4. Concurrent poetry install during a scan; interrupted hosted runs.
5. macOS / Windows probes once deleting bughunt/poetry/* is allowed.

[github-actions[bot]]

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

Tested: main 6a06ddd (includes #1506, the #1503 fix), latest release v5.0.1. Linux only, with real Poetry 1.1.15, 1.8.5, 2.0.1, 2.2.1 and 2.5.1 and a freshly written local mock of the patch API: one patched six-1.16.0 wheel, plus PyPI JSON / files routes for rollback.

Re-triage

• Poetry source-pin guard lets hosted and vendored rewrite a lock-version 1.1 poetry.lock that no Poetry 2.x can install, and the advisory says 2.3+ install it #1503 (closed by Fix Poetry source pin over a pre-2.1 lock (#1503) #1506): confirmed fixed. A Poetry 1.1.15 lock (lock-version 1.1) with six = {source = "pypi"} is now skipped by hosted, with a warning naming the lock format (exit 0, redirect_unconfirmed), and refused by vendored (pypi_poetry_source_constraint, exit 1). The lock is byte-identical afterwards in both cases. No comment needed.
• 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 (open): still reproduces on Poetry 2.5.1 (rollback -g after a project agent apply: exit 0, manifest emptied, .venv six still patched). No new information, so no comment.

Cells (Linux, main 6a06ddd)

Poetry	Cell	Result
1.1.15	#1503 re-check, hosted + vendored	pass (refused, lock untouched)
2.5.1	Hosted scan killed with SIGKILL at 50 ms – 1 s	pass (the run finishes in under 50 ms; the lock is always the original or the full rewrite)
1.1.15, 1.8.5, 2.5.1	Optional extra (six optional, [tool.poetry.extras]): hosted, install without and with -E s, vex	pass (absent / patched)
1.1.15, 2.5.1	Same, vendored + vendor --check	pass
2.0.1, 2.2.1 (LF + CRLF)	hosted → vendored → hosted takeovers, fresh install after each, rollback	pass (patched each time; rollback byte-identical)
2.0.1, 2.2.1, 2.5.1	PEP 621 [project] dynamic = ["version"] + [tool.poetry] version, no git remote: vex, scan --mode hosted --vex	fail, filed #1527
2.5.1	Same with a static [project].version (control)	pass
2.5.1	#450	still fails
macOS / Windows	anything	blocked: deleting bughunt/poetry/* was denied again, so no probes were pushed

Issues

• Filed VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527: vex/product.rs::parse_pyproject needs name and version from the same section. Poetry 2's documented dynamic-version layout keeps name in [project] and version in [tool.poetry], so vex exits 2 and scan --vex exits 1 with product_undetected, after writing the hosted pin. This isn't a duplicate of VEX product detection ignores PDM 0.x's [tool.pdm] name/version, so vex and scan --vex fail with product_undetected on PDM 0.12 projects (after scan has already rewritten pdm.lock) #642, which is about the missing [tool.pdm] fallback. VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527

False positives ruled out

• An early "scan patched the global six" came from a broken test pyproject.toml (invalid TOML from my harness), so the project wasn't recognised as Poetry. Not a product bug. Restored with rollback -g.
• The source-pin guard already reads dev-dependencies and every group.*.dependencies (unit-tested), so a group-only source = "pypi" pin isn't a gap.

Next

1. Re-check VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527 once fixed. Also check the variant where [project] has a name and dynamic version and [tool.poetry] also has a stale name: the current code would then pick the [tool.poetry] name.
2. Re-check uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184 / 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 once fixed.
3. Lead 3 (create = false patches the dpkg six) still needs a maintainer call.
4. Concurrent poetry install during a scan; untested Linux cells (1.2.2 agent, 2.1.x, 1.0.10 vendored repair).
5. macOS / Windows probes once deleting bughunt/poetry/* is allowed.

[github-actions[bot]]

[agent] Janitor: ledger drift for the bug-hunt routine to pick up. These issues are now closed as completed, but this ledger's body still lists them as fail:

• Poetry source-pin guard lets hosted and vendored rewrite a lock-version 1.1 poetry.lock that no Poetry 2.x can install, and the advisory says 2.3+ install it #1503 (closed 2026-10-14 00:00Z by Fix Poetry source pin over a pre-2.1 lock (#1503) #1506): source = "pypi" rewrite over a 1.1 lock row
• VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527 (closed 2026-10-14 13:00Z by Fix pyproject product detection tables (#1527, #642) #1529): PEP 621 dynamic = ["version"] VEX row

---

Generated by Claude Code

[github-actions[bot]]

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

Tested: main fc1b4f9 (includes #1529, the #1527 fix), latest release v5.0.1. Linux only, with real Poetry 1.8.5, 2.1.4, 2.2.1 and 2.5.1 and a local mock of the patch API serving one patched six-1.16.0 wheel.

Re-triage

• VEX product detection fails on Poetry 2 projects that declare dynamic = ["version"] with the version in [tool.poetry], so scan --vex exits 1 after rewriting poetry.lock #1527 (closed by Fix pyproject product detection tables (#1527, #642) #1529): confirmed fixed. A Poetry 2.5.1 project with [project].name + dynamic = ["version"] + [tool.poetry].version now gets the product pkg:pypi/demo1527@0.3.0 from scan --mode hosted --vex (exit 0), and poetry install gets the patched bytes. No comment needed.
• 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 (open): still reproduces on fc1b4f9 with Poetry 2.5.1. No new information, so no comment.

Cells (Linux, main fc1b4f9)

Poetry	Cell	Result
2.5.1	#1527 re-check	pass
2.5.1	#1527 variant with a stale [tool.poetry].name	product_undetected, deliberate (Poetry 1.x and 2.x build different names); known non-bug
2.1.4	Hosted (install, poetry sync, rollback byte-identical), vendored (vendor --check), agent in-project (scan, re-run, vex) and out-of-tree venv, hosted ⇄ vendored takeovers with a fresh install after each, vendored repair with the wheel deleted	pass
1.8.5, 2.5.1	explicit / supplemental [[tool.poetry.source]] that six doesn't come from: hosted + vendored + fresh install	pass
1.8.5, 2.5.1	VEX product purl for My_Service / Demo_Pkg.Core	fail, filed #1547
2.5.1	#450	still fails
macOS / Windows	anything	blocked: deleting bughunt/poetry/* is still denied, so no probes were pushed

Issues

• Filed VEX product purl detected from pyproject.toml keeps the raw project name (pkg:pypi/My_Service) instead of the normalized pypi name #1547: vex/product.rs::parse_pyproject puts the raw project name into the product purl (pkg:pypi/My_Service@1.2.0) instead of the normalized pypi name (my-service). Reproduces in hosted --vex (Poetry 1.8.5, [tool.poetry]) and agent + standalone vex (Poetry 2.5.1, [project]). VEX product purl detected from pyproject.toml keeps the raw project name (pkg:pypi/My_Service) instead of the normalized pypi name #1547

False positives ruled out

• The first hosted → vendored takeover on 2.1.4 failed (exit 1, "already declares a [package.source] for six") because the mock origin isn't the patch server. With SOCKET_PATCH_SERVER_URL set it passes. Harness artifact.

Next

1. Re-check VEX product purl detected from pyproject.toml keeps the raw project name (pkg:pypi/My_Service) instead of the normalized pypi name #1547 once fixed, and 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 / uv hosted → vendored takeover onto a newer patch uuid fails "no installed package found on disk" (exit 1) when the venv holds the hosted patch's bytes, while --dry-run previews success #1105 / remove and rollback call a vendored PyPI residual-reference keep "lockfile wiring drifted", and their "re-run scan --mode vendored to normalize, then remove" remedy loops (Pipenv pipenv requirements export) #1184.
2. Untested Linux cells: 1.2.2 agent, 1.0.10 vendored repair, 2.4.3 mode switch, 2.1.x nameless / [project].name layouts.
3. Concurrent poetry install during an agent scan.
4. Lead 3 (create = false patches the dpkg six) still needs a maintainer call.
5. macOS / Windows probes once deleting bughunt/poetry/* is allowed.