Bug hunt ledger: Hatch

[Mikola Lysenko (mikolalysenko)]

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

Last run: 2026-10-01 21:53Z on main 61cfb9b. The latest tag v4.0.0 predates Hatch support (#244). Linux runs use real Hatch against a local mock patch API (six 1.16.0; v5 vendored uses --vendor-source service (local build was removed) and needs integrity.sha512 in the mock, the grant artifact kind must be tarball, and SOCKET_PATCH_SERVER_URL must point at the mock so hosted wiring is recognised). macOS and Windows use probe branches.

Coverage matrix

Hatch	hosted, existing env, pip (Linux / macOS / Windows)	hosted, existing env, uv	vendored, existing env	hosted shapes + rollback (Linux)	vendored shapes + rollback (Linux)	rollback after an unrelated edit (hosted / vendored)	mode takeover (H→V / V→H)	agent	agent re-scan after env recreate	global -g, pipx-installed (L / M / W)	global -g, uv-tool-installed (L / M / W)	global-prefix apply / vex / rollback (L / M / W)	locked env + pylock, hosted / vendored (L / M / W)
1.0 – 1.6	untested	n/a	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	n/a (no hatch lock)
1.7.0	fail #335 (all 3 OS)	n/a	untested	untested	pass (unicode/space path)	hosted untested on v5 / fail #385	untested	untested	fail #454	fail #415 (all 3)	untested	pass (all 3)	n/a (no hatch lock)
1.9.7	fail #335 (all 3 OS)	untested	untested	untested	untested	untested	untested	untested	untested	untested	pass / pass / fail #449	untested	n/a (no hatch lock)
1.14.1	blocked (virtualenv incompatibility)	blocked	blocked	untested	untested	untested	untested	untested	untested	untested	untested	untested	n/a (no hatch lock)
1.16.5	fail #335 (all 3 OS)	pass	untested	untested	untested	untested	untested	fail (see #335)	untested	fail #415 (all 3); uv-tool pass (Linux)	pass / pass / fail #449	pass (all 3)	n/a (no hatch lock)
1.17.0	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested	fail #479 (all 3, both modes)
1.18.1	fail #335 (Linux re-checked on v5)	pass	fail (#335 comment)	pass (13 shapes pre-v5; v5: template, dotted keys, matrix, features, detached, hatch.toml envs pass)	pass (12 shapes; group refused, pre-v5)	pass on v5 (bump + added dep, 61cfb9b) / fail #385	v5: pass / fail #328	fail (see #335)	fail #454	fail #415 (all 3)	pass / pass / fail #449; UV_TOOL_DIR fail #449 (Linux)	pass (all 3); read-only root-owned prefix: exits 1 (#424 JSON), re-run exits 0 (#454)	fail #479 (all 3, both modes)

Also on v5: scan -g is report-only and never touches pyproject or the Hatch env dirs; -g / --global-prefix / SOCKET_GLOBAL=1 with --mode hosted exit 2 and write nothing. Fresh-environment installs of hosted and vendored rewrites pass on 1.18.1 (and on 1.7.0 for vendored). Locked env with no committed pylock (pyproject lane) passes on 1.18.1. On main 6e7ef74: #335 and the vendored #385 cell still reproduce, and the hosted version-bump rollback passes. Workspaces (1.16.5 / 1.18.1, v5): a member-only dependency is refused from the root with a warning. Scanned from the member, hosted passes (fresh root env patched) but vendored fails #505: the root env doesn't expand {root:uri} in member deps. CRLF pyproject on v5: hosted and vendored pass, with fresh env patched and rollback byte-exact (1.18.1). On main 61cfb9b: #335 and the vendored #385 cell still reproduce; the hosted #385 cells (version bump, added dependency) pass. #454 and #415 are fixed and closed.

Backlog

0. Vendored scan in a Hatch workspace member writes {root:uri} that the workspace root env never expands, so every hatch run at the root fails to install #505 follow-ups: workspace members with features, dynamic-dep members, workspace declared in hatch.toml; probe Vendored scan in a Hatch workspace member writes {root:uri} that the workspace root env never expands, so every hatch run at the root fails to install #505 on macOS / Windows.
1. Hatch 1.17+ projects with a hatch-generated pylock.toml get only the lock rewritten, and Hatch regenerates it from pyproject, so hosted and vendored patches are silently dropped #479 follow-ups: lock-filename context formatting, global lock-envs, matrix envs sharing a lock, hatch dep sync, rollback / remove on a pylock-wired Hatch project (see Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407).
2. Maintainer request (global mode), remaining cells: UV_TOOL_DIR on macOS / Windows; a read-only, root-owned prefix on macOS (needs sudo on the runner); Windows Program Files prefix.
3. Vendored → hosted takeover (Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328) once it moves; multi-patch rollback <purl> / --preserve-state and allow-direct-references ownership (the mock needs a second package).
4. Vendored Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 / Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335 cells on Hatch 1.7.0, and with installer = "uv" envs.
5. Hatch 1.0 / 1.1 / 1.2 vendored-env boundary; 1.14.x with a pinned virtualenv.
6. Re-triage Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335, Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 (vendored only), Hatch 1.17+ projects with a hatch-generated pylock.toml get only the lock rewritten, and Hatch regenerates it from pyproject, so hosted and vendored patches are silently dropped #479, Vendored scan in a Hatch workspace member writes {root:uri} that the workspace root env never expands, so every hatch run at the root fails to install #505 when main moves.

Known non-bugs

• Locked Hatch envs with installer = "pip": Hatch's pip locker can't apply lockfiles (LockerUnsupportedError), so it's a Hatch limitation.
• Probing Hatch through uv tool run with uv 0.12 leaks UV / UV_INTERNAL__PARENT_INTERPRETER and breaks Hatch's locked sync: a harness artifact. Use installed Hatch binaries.
• Vendored PEP 735 dependency groups are refused (Hatch does not expand {root:uri} there): documented.
• Vendored with installer = "uv" / uv-path is refused: documented. Note that uv 0.12 does enforce local wheel hashes, so the documented rationale looks outdated. Hatch's internal uv envs (hatch-test etc.) aren't covered by the refusal, but the hash is still enforced (verified with a tampered wheel).
• Vendored needs hatch >= 1.2 on PATH (preflight pypi_hatch_unsupported): documented, including for pipx run / uvx users.
• Ranges, transitive-only (including workspace-member-only deps when scanned from the root), dynamic deps, sources, overrides and custom env types are refused: documented.
• Hosted project rewrites embed a direct URL in the built wheel's Requires-Dist (so the result can't be uploaded to PyPI): inherent to the design.
• rollback with nothing ever written exits 2 Manifest not found. remove after a full rollback gives manifest_not_found.
• Vendored scan against the mock fails vendor_prebuilt_required unless the grant's artifact carries integrity.sha512 (v5): a harness requirement, not a bug.
• In mock runs every purl "has" a six patch (the batch endpoint answers six for any input). Use scannedPackages and the apply results, not packages[], to judge discovery.
• scan -g, and the bare -g hosted refusal, print the usage error to stderr only, even with --json (exit 2): this matches the exit-code table.
• Hosted rollback only recognises wiring on patch.socket.dev or the --patch-server-url origin. A mock URL on another origin gives Manifest not found, which is a harness artifact.
• A "read-only" prefix the current user owns (chmod 0444 / 0555) still gets patched, because the owner can write. Only a prefix the user can't write to is a real refusal case.
• Env overrides, [tool.hatch.env] (requires / collectors), custom env type, and a non-table envs in hatch.toml are refused with nothing written: documented.
• six==1.16 (PEP 440-equal to the installed 1.16.0) is refused as not exact. It's a minor over-refusal that fails closed, logged rather than filed.
• A pyproject.toml with a UTF-8 BOM isn't loadable by Hatch (TOMLDecodeError at 1:1). Hosted strips the BOM and rollback doesn't restore it; vendored preserves it. Not filed, because the input is invalid for Hatch.
• vex from the project root in the sandbox can omit six as not_applied because of the system /usr/lib/python3/dist-packages/six.py: a sandbox artifact.

[github-actions[bot]]

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

First run. The ledger was empty and there were no earlier pm:hatch issues, so there was nothing to re-triage.

Tested: main f6b7fb9, release build of socket-patch-cli. The latest tag is v4.0.0, which predates Hatch support (#244, 649d457), so no published release has anything to bisect. The sandbox can't reach the Socket patch hosts, so the Linux work used real Hatch releases against a local Python mock of the patch API (the same shape as tests/vex_pypi_real_common: six 1.16.0 with a SOCKET_PATCHED marker). The mock and driver are embedded in probe run 36740025279.

Filed

• Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335: a hosted rewrite leaves an existing Hatch env (pip installer) unpatched. pip keeps the same-version install on pip install "six @ url", and Hatch then records the dependency hash as synced. socket-patch never discovers Hatch's out-of-tree envs, so there's no redirect_pypi_stale_install warning, and vex attests not_affected. Reproduced on Linux, macOS and Windows × Hatch 1.7.0 / 1.9.7 / 1.16.5 / 1.18.1 (https://github.com/SocketDev/socket-patch/actions/runs/36740025279). The uv installer and fresh envs are fine. The same root cause makes agent mode apply 0 to the Hatch env (Poetry siblings: 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).

Cells covered (Linux, Hatch 1.18.1 unless noted)

Cell	Result
hosted, existing env, pip installer, 1.7.0 / 1.9.7 / 1.16.5 / 1.18.1 (Linux, macOS, Windows)	fail #335
hosted, existing env, installer = "uv", 1.16.5 / 1.18.1	pass (reinstalled on next hatch run)
hosted, 13 shapes: project deps, CRLF+BOM+comment, marker + name case, optional-deps + features, PEP 735 group + dependency-groups, env dependencies, env extra-dependencies, hatch.toml [envs], hatch.toml [metadata] permission, existing allow-direct-references = true, matrix env, project+env both, no build-backend	pass: scan, idempotent re-scan, byte-exact rollback, fresh hatch run patched
vendored (--vendor-source build), the same shapes minus the group	pass: scan, re-scan, rollback, fresh install patched
vendored PEP 735 group	refused (documented)
vendored, project dir with spaces + unicode, 1.7.0 / 1.18.1, project and env flavours	pass
vendored, tampered committed wheel: default pip env and hatch test (internal uv env, uv 0.12)	both reject with a hash mismatch (pass)
agent mode, Hatch default env	fail (same root cause as #335, noted there)
Hatch 1.14.1	blocked: env create fails against current virtualenv (propose_interpreters); pin an older virtualenv next time

Ruled out / not filed

• Vendored scan failing package_not_installed without VIRTUAL_ENV: the mock has no vendoring-service endpoints, so auto fell back to a local build. With the real service it downloads. This is a mock artifact, apart from the discovery gap already in Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335.
• Hatch's internal envs (hatch-test, hatch-build, hatch-static-analysis, hatch-uv) default to installer = "uv", and the vendored uv refusal doesn't consider them. But uv 0.12 does enforce #sha256= on local wheels, so there's no integrity gap. docs/testing/hatch.md's "uv ignores hash fragments for local wheels" looks outdated; the refusal is only over-conservative.
• rollback on a project where nothing was written exits 2 Manifest not found: benign.

Housekeeping

• Probe branch bughunt/hatch/20260930-stale-env could not be deleted: the sandbox git proxy hangs up on ref-delete pushes (the same as the PDM routine). A maintainer should delete it. It only adds .github/workflows/bughunt-hatch.yml.

Next

1. Hatch 1.0 / 1.1 / 1.2 boundary: vendored env-dependency refusal and the {root:uri} expansion, with a pinned virtualenv; also 1.14.x.
2. Workspaces (Hatch 1.16+ workspace.members) and local path deps next to a patched pin, hosted and vendored.
3. hatch.toml overriding envs with a non-table / [env] collectors / template inheritance / overrides refusal firing correctly.
4. Hosted takeover vendored→hosted and hosted→vendored on Hatch (the sibling of Poetry's Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328), and rollback --preserve-state keeping allow-direct-references ownership.
5. Windows long paths / drive-letter {root:uri} on vendored (probe).

[github-actions[bot]]

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

Tested: main f6b7fb9 (unchanged since the last run), release build. The latest tag is still v4.0.0, which predates Hatch support. Linux, real Hatch 1.18.1 and 1.7.0, using the same local mock patch API as last run (six 1.16.0).

Filed

• Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385: Hatch rollback / remove refuse ("Hatch configuration drifted" / "pyproject.toml changed since patching") after a [project].version bump, a comment on name, or an added dependency in the patched array. Hosted and vendored both fail, on Hatch 1.18.1 and 1.7.0, and a re-scan doesn't recover. The cause: vendor/pypi_lock.rs restore_document applies the lock-package same_identity (name + version) and array-length checks to pyproject tables.

Commented

• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (PyPI mode takeover): added the Hatch rows. hosted → vendored fails pypi_hatch_unsupported "existing direct source must be reverted", exit 1. vendored → hosted gives redirected: 0 with status: success. Same root cause, so no new issue.

Re-triage

• Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335: main hasn't moved (f6b7fb9), so it wasn't re-run. Still open.

Cells covered (Linux)

Cell	Result
workspace (1.16+ [tool.hatch.envs.default.workspace] members), dependency only in a member, scan from the root	refused with the redirect_hatch_unsupported "transitive-only" warning (honest; see Known non-bugs)
workspace, scan with --cwd set to the member	pass: redirected 1, fresh env patched (an existing env stays stale, which is #335)
takeover vendored → hosted, 1.18.1	fail (#328 comment)
takeover hosted → vendored, 1.18.1	fail (#328 comment)
rollback after an unrelated edit: [project].version, a dependency added to the same array, a comment on name: hosted / vendored, 1.18.1	fail #385
rollback after a [project].version bump + re-scan, hosted / vendored, 1.7.0	fail #385
rollback after an env-dependency edit or a new [tool.ruff] table, hosted 1.18.1	pass
rollback of a clean vendored project (1.18.1)	pass (byte-exact)

Ruled out / not filed

• Vendored scan without Hatch on PATH fails pypi_hatch_unsupported ("require Hatch >=1.2 on PATH"). This is the documented preflight. Note that it also fires for pipx run hatch / uvx hatch users.
• Workspace member deps refused from the root: this is the documented transitive-only refusal, with a warning.
• Hosted project rewrites put six @ https://… into the built wheel's Requires-Dist, which PyPI rejects on upload. This is inherent to the design and not filed; the docs could mention it for libraries.

Housekeeping

• Probe branch bughunt/hatch/20260930-stale-env still can't be deleted (the git proxy disconnects on ref-delete). A maintainer should delete it. No probe branch was pushed this run.

Next

1. Hatch 1.0 / 1.1 / 1.2 boundary (the vendored preflight) and 1.14.x with a pinned virtualenv.
2. Refusal correctness: overrides, template, [env] collectors, hatch-pip-compile env type, hatch.toml envs non-table.
3. Multi-patch rollback <purl> / --preserve-state and allow-direct-references ownership (the mock needs a second package).
4. Windows long paths / drive-letter {root:uri} on vendored (probe).
5. Re-check Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335 / Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 / Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 once main moves.

[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 Hatch version and on Linux, macOS and Windows.

Where Hatch puts global installs: Hatch has no global install. Check -g from inside a Hatch project scans the global interpreter, never Hatch's env dirs (hatch env find), and reports a pipx-installed Hatch 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 Hatch 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 Hatch 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 × Hatch 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: Hatch bug-hunt run

Tested: main 2463257 (#277, the v5 workflow consolidation; the binary still says 4.0.0), release build. The latest tag is still v4.0.0, which predates Hatch support. Linux with real Hatch 1.18.1 and 1.7.0, pipx 1.7.1, and uv tool, against the local mock patch API. The mock now also serves integrity.sha512, which v5 vendored mode requires (otherwise vendor_prebuilt_required). macOS and Windows via one probe branch.

Filed

• 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: scan -g / apply -g / rollback -g never crawl pipx venvs (~/.local/share/pipx/venvs, macOS ~/.local/pipx/venvs, Windows %USERPROFILE%\pipx\venvs), so a pipx-installed Hatch's dependencies are invisible. uv-tool installs work (control). Reproduces on ubuntu, macos and windows × Hatch 1.7.0 / 1.16.5 / 1.18.1. Probe: https://github.com/SocketDev/socket-patch/actions/runs/36812282643

Re-triage

• Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385: hosted half fixed on v5 (version bump, added dependency and name comment all roll back cleanly, and allow-direct-references is dropped). Vendored still fails with "pyproject.toml changed since patching" / vendor_revert_failed (3 repros). Commented: Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 (comment)
• Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335: still reproduces on v5 (hosted: success, no warning, env stays stale, vex not_affected). New: vendored mode has the same hole, and there is no stale probe even with VIRTUAL_ENV set (only Pipenv has pypi_pipenv_stale_install). It also reports an applied … six.py verified:true event while the env's six.py is untouched. Commented: Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335 (comment)

Global (-g) cells (maintainer request)

Check	Linux (sandbox + ubuntu)	macOS	Windows
scan -g report-only, inside a Hatch project; pyproject untouched, Hatch env dir not crawled	pass	pass	pass
scan -g --mode hosted / --global-prefix … --mode hosted / SOCKET_GLOBAL=1 … --mode hosted: exit 2, nothing written	pass	pass (-g)	pass (-g)
pipx-installed Hatch dependency, scan -g --mode agent	fail #415	fail #415	fail #415
uv-tool-installed Hatch dependency, -g agent apply + rollback byte-exact	pass	untested	untested
--global-prefix "<space>/ünï/site-packages" agent apply / vex not_affected / rollback byte-exact / vex after rollback refuses	pass	pass	pass
Agent scan without -g in a Hatch project: falls back to the global interpreter, applied 0, exit 1	as #335 (system copy not modified)
Read-only global prefix	blocked (sandbox runs as root)	untested	untested

Ruled out / not filed

• scan -g "finding" six in every run: an artifact of the mock, whose /patches/batch answers six for any purl. scannedPackages and the apply result are the real signal.
• Debian's apt python3-six (six-1.16.0.egg-info in /usr/lib/python3/dist-packages) is not crawled at all: egg-info-only packages are invisible. This isn't Hatch-specific, it's generic to pip/distro packages, and I didn't verify whether it's intended, so it's noted here for the pip routine rather than filed.
• apply -g printing "The targeted manifest patch matched no installed package" with exit 0: this happens after a prior agent run recorded the patch. Not investigated further.

Housekeeping

• The probe branches bughunt/hatch/20261001-global-pipx and bughunt/hatch/20260930-stale-env still can't be deleted (the git proxy hangs up on ref deletes). A maintainer should delete them.

Next

1. -g on macOS / Windows with a uv-tool Hatch, and a read-only prefix (probe, non-root runner).
2. The vendored Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 / Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335 cells on Hatch 1.7.0 and with installer = "uv" envs.
3. Refusal correctness: overrides, template, [env] collectors, hatch-pip-compile env type, hatch.toml envs non-table.
4. Multi-patch rollback <purl> / --preserve-state and allow-direct-references ownership (the mock needs a second package).
5. Hatch 1.0 / 1.1 / 1.2 vendored-env boundary; 1.14.x with a pinned virtualenv.

[github-actions[bot]]

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

Tested: main 2463257 (unchanged since the last run), release build. The latest tag is still v4.0.0; the PyPI socket-patch==4.0.0 release was installed for bisecting. Linux with real Hatch 1.18.1 (uv tool) and 1.7.0 (uvx), against a local mock patch API. The hosted wiring is only recognised as Socket's on patch.socket.dev or on --patch-server-url / SOCKET_PATCH_SERVER_URL, so the harness must set it, or rollback reports Manifest not found. macOS and Windows ran through one probe branch.

Filed

• scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454: scan --mode agent and scan --sync never re-apply a patch already recorded in .socket/manifest.json. After hatch env remove + hatch env create (or any reinstall), the re-scan gives success, skipped: 1, applied: 0, exit 0, and six imports unpatched. The --sync help promises "fully reconciled in one invocation". Reproduced on Hatch 1.7.0 and 1.18.1 and with --global-prefix; released v4.0.0 is the same. Suspect: get.rs:2438 (the nested apply only runs when downloaded > 0). PM-agnostic.

Commented

• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (takeover): on v5, Hatch hosted → vendored now works (vendor_takeover_reverted_redirect, then applied; a fresh Hatch env imports the patched six; rollback is byte-exact). Vendored → hosted is still refused (redirect_hatch_unsupported "existing direct source must be reverted", exit 0). Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 (comment)
• Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 (uv tool dirs): Windows uv-tool Hatch (%APPDATA%\uv\tools) is invisible to -g on Hatch 1.16.5 / 1.18.1 (scanned 3, applied 0, exit 1, vex package_not_found). On Linux, UV_TOOL_DIR set: scanned 42, none from the tool venv, exit 1. Global scan (-g) misses uv tool environments on Windows (looks in %LOCALAPPDATA%\uv\tools, uv uses %APPDATA%\uv\tools) and on every OS when UV_TOOL_DIR, XDG_DATA_HOME or UV_PYTHON_INSTALL_DIR is set #449 (comment)

Re-triage

• Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335, Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385, 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: main hasn't moved since the last run, so they weren't re-run. 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 has a draft fix PR, Fix global scan missing pipx venvs (#415) #418.

Global (-g) cells (maintainer request)

Check	Linux	macOS	Windows
uv-tool Hatch (1.9.7 / 1.16.5 / 1.18.1): scan -g report-only, pyproject untouched	pass	pass (job green)	pass (report)
uv-tool Hatch -g agent apply / vex / rollback byte-exact	pass	pass (job green; the log wasn't retrievable, 404)	fail #449
UV_TOOL_DIR custom tool dir	fail #449	untested	untested
Read-only prefix, root-owned, non-root user (runuser -u nobody)	scan exits 1, but the JSON has failed: 0 and no error (#424); apply exits 1 apply_failed "Permission denied"; the re-run exits 0 (#454)
Read-only prefix the user owns (chmod 0444/0555)	patched (the owner can write; not a bug)		attrib +R: exit 1, unpatched, vex omits not_applied
Read-only, then writable again: re-scan	fail #454 (exit 0, unpatched)

Probe: https://github.com/SocketDev/socket-patch/actions/runs/36845418214

Refusal / shape matrix (Linux, Hatch 1.18.1, hosted, fresh hatch env create from the rewrite)

• Pass (rewritten, and the fresh env imports the patched six): template inheritance, dotted envs.default.dependencies, matrix env (test.py3.11), features → optional-dependencies, detached env, and hatch.toml [envs] overriding pyproject envs (only hatch.toml is rewritten, matching hatchling's top-level update() merge).
• Refused with nothing written (documented): env overrides, [tool.hatch.env] requires, type = "pip-compile", hatch.toml envs = 1.
• Observation, not filed: six==1.16 (PEP 440-equal to 1.16.0) is refused with "requires an exact ==1.16.0 declaration". It's a minor over-refusal that fails closed.

Ruled out / not filed

• Hosted rollback → Manifest not found when the mock URL host isn't --patch-server-url: a harness artifact (see above).
• The ubuntu probe "read-only" prefix getting patched: the runner user owned the files, so it could restore write permission. A root-owned prefix fails as expected.

Housekeeping

• Probe branches bughunt/hatch/20260930-stale-env, bughunt/hatch/20261001-global-pipx and now bughunt/hatch/20261001-uvtool-ro still can't be deleted (the git proxy hangs up on ref deletes). A maintainer should delete them.

Next

1. Vendored → hosted takeover for Hatch, when Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328 moves; multi-patch rollback <purl> (the mock needs a second package).
2. Vendored Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 / Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335 cells on Hatch 1.7.0 and with installer = "uv" envs.
3. Hatch 1.0 / 1.1 / 1.2 vendored-env boundary; 1.14.x with a pinned virtualenv.
4. Workspaces (Hatch 1.16+ workspace.members) on v5; CRLF / BOM pyproject on v5.
5. Re-triage Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335, Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385, 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 (Fix global scan missing pipx venvs (#415) #418), scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 when main moves.

[github-actions[bot]]

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

Tested: main 6e7ef74 (it moved: #322, #337, #330 (Poetry venv discovery), #345; none of them touch the Hatch lanes), release build. The latest tag is still v4.0.0, which has no Hatch lane. Linux runs use real Hatch 1.16.5 / 1.17.0 / 1.18.1 against the local mock patch API; macOS and Windows ran through one probe branch.

Filed

• Hatch 1.17+ projects with a hatch-generated pylock.toml get only the lock rewritten, and Hatch regenerates it from pyproject, so hosted and vendored patches are silently dropped #479: Hatch 1.17+ environment locks. hatch lock (new in 1.17.0, with locked = true / lock-envs) writes a pylock.toml / pylock.<env>.toml that is derived from pyproject. When one exists, hosted and vendored scans rewrite only the pylock and report success. The existing env stays unpatched (the dependency hash is unchanged). A fresh env regenerates the lock from pyproject, which wipes the wiring and installs upstream six. hatch dep lock --check exits 1. Vendored also skips the documented uv-installer refusal. The same happens with an exported pylock on a non-locked env. Control: with no committed pylock, the pyproject rewrite passes through Hatch's re-lock (fresh env patched, --check 0). Suspect: the early return in rewrite_hatch (redirect/mod.rs:686-695). Fails on Linux, macOS and Windows × 1.17.0 / 1.18.1 × hosted and vendored. Probe: https://github.com/SocketDev/socket-patch/actions/runs/36887192239

Re-triage (main 6e7ef74, Linux, Hatch 1.18.1)

• Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335: still reproduces (hosted, existing pip env: unpatched, no stale-install warning). No comment, since there's nothing new.
• Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385: vendored rollback after a version bump still gives partial_failure "pyproject.toml changed since patching" (2×). Hosted rollback after a version bump passes (restores six==1.16.0, keeps 0.2.0). No comment.

Cells

Cell	Result
Locked env (locked = true, uv locker), hosted, 1.17.0 / 1.18.1, L/M/W	fail #479
Locked env, vendored, 1.17.0 / 1.18.1, L/M/W	fail #479
Locked named env (pylock.test.toml), hosted, 1.18.1 Linux	fail #479
hatch dep lock --export pylock.toml, non-locked env, hosted, 1.18.1 Linux	fail #479
Locked env with no committed pylock (pyproject lane), hosted, 1.18.1 Linux	pass
Locked env, installer = "pip"	n/a: Hatch's pip locker can't apply lockfiles (LockerUnsupportedError)

Ruled out / not filed

• Hatch's sync under uv tool run with uv 0.12 left six uninstalled. This is a harness artifact: uv exports UV / UV_INTERNAL__PARENT_INTERPRETER into the child, so the probe now calls installed Hatch binaries with those variables removed.
• hatch dep lock --check exits 2 on 1.17.0 (the CLI shape differs); it isn't used as evidence there.

Housekeeping

• Probe branch bughunt/hatch/20261001-pylock-relock couldn't be deleted (the git proxy hangs up on ref deletes, as before). A maintainer should delete it, along with bughunt/hatch/20260930-stale-env, bughunt/hatch/20261001-global-pipx and bughunt/hatch/20261001-uvtool-ro.

Next

1. Lock follow-ups (Hatch 1.17+ projects with a hatch-generated pylock.toml get only the lock rewritten, and Hatch regenerates it from pyproject, so hosted and vendored patches are silently dropped #479 siblings): lock-filename with context formatting, lock-envs = true globally, matrix envs sharing a lock, hatch dep sync, and rollback / remove on a pylock-wired Hatch project (also see Hosted rollback, remove and vendored takeover always refuse on a uv pip compile pylock.toml because its packages carry no index key #407).
2. Global-mode remainder: UV_TOOL_DIR on macOS / Windows; a read-only root-owned prefix on macOS; Windows Program Files.
3. Vendored → hosted takeover (Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328) once it moves; multi-patch rollback <purl> (second mock package).
4. Workspaces (1.16+ workspace.members) and CRLF / BOM pyproject on v5; Hatch 1.0–1.2 vendored boundary.
5. Re-triage Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335, Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385, 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, scan --sync / --mode agent never re-applies an already-recorded patch, so after a fresh Hatch env (or any reinstall) it exits 0 with the package unpatched #454 (Fix agent scan/get skipping apply for recorded patches (#454) #456), Hatch 1.17+ projects with a hatch-generated pylock.toml get only the lock rewritten, and Hatch regenerates it from pyproject, so hosted and vendored patches are silently dropped #479 when main moves.

[github-actions[bot]]

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

Tested: main 61cfb9b, release build. Since the last run main gained #456 (the #454 fix), #418 (the #415 fix), #446, #452 and #425; #454 and #415 are closed. The latest tag is still v4.0.0, which has no Hatch lane. Linux only, with real Hatch 1.18.1 and 1.16.5 against a local mock patch API (six 1.16.0, SOCKET_PATCH_SERVER_URL pointed at the mock, vendored via --vendor-source service). No probe branches this run: earlier probe branches still can't be deleted.

Filed

• Vendored scan in a Hatch workspace member writes {root:uri} that the workspace root env never expands, so every hatch run at the root fails to install #505: vendored scan in a Hatch workspace member. It writes six @ {root:uri}/.socket/vendor/… into the member's project.dependencies and reports success. The workspace root env reads static member dependencies raw, without context formatting, so every root hatch run (existing or fresh env) fails with pip No connection adapters were found for '{root:uri}/…'. The member's own env works, and so does hosted. Fails on 1.16.5 and 1.18.1. Suspect: utils/hatch.rs:206-210, which has no workspace-member check (compare the group refusal at :232).

Re-triage (main 61cfb9b)

• Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335: still reproduces. The existing pip env stays unpatched after two hatch runs, and scan gives warnings: [] without VIRTUAL_ENV. vex from the root now omits not_applied, but only because the sandbox's system python has an unpatched six 1.16.0, so that's not evidence of a fix. No comment.
• Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385: hosted now passes (version bump and an added dependency both roll back). Vendored still fails ("pyproject.toml changed since patching"). Commented: Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 (comment)

Cells (Linux)

Cell	Result
CRLF pyproject, hosted / vendored, 1.18.1: fresh env patched, rollback byte-exact	pass / pass
BOM pyproject (± CRLF)	n/a: Hatch's tomllib rejects a BOM (TOMLDecodeError at 1:1). Hosted strips the BOM and rollback doesn't restore it; vendored keeps it. Not filed.
Workspace (1.16+), member-only dep scanned from root, hosted	refused as documented
Workspace, scanned from member, hosted, 1.18.1	pass (fresh root env patched)
Workspace, scanned from member, vendored, 1.16.5 / 1.18.1	fail #505
#385 rollback after version bump / added dep, hosted	pass
#385 rollback after version bump, vendored	fail #385

Ruled out / not filed

• The vex not_applied on Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335 comes from the sandbox's system six (/usr/lib/python3/dist-packages), not from discovery of the Hatch env.
• BOM pyproject: Hatch itself can't load it.
• --vendor-source build was removed on v5 (use service), so it's a harness change, not a bug.

Next

1. Vendored scan in a Hatch workspace member writes {root:uri} that the workspace root env never expands, so every hatch run at the root fails to install #505 follow-ups: a workspace member with features (members = [{path=…, features=[…]}]), a member with dynamic deps, [envs.*.workspace] in hatch.toml, and probing Vendored scan in a Hatch workspace member writes {root:uri} that the workspace root env never expands, so every hatch run at the root fails to install #505 on macOS / Windows.
2. Hatch 1.17+ projects with a hatch-generated pylock.toml get only the lock rewritten, and Hatch regenerates it from pyproject, so hosted and vendored patches are silently dropped #479 follow-ups: lock-filename context formatting, global lock-envs, matrix envs sharing a lock, hatch dep sync, rollback / remove on a pylock-wired project.
3. Global-mode remainder: UV_TOOL_DIR on macOS / Windows; a read-only root-owned prefix on macOS; Windows Program Files.
4. Vendored → hosted takeover (Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328); multi-patch rollback <purl> (second mock package).
5. Hatch 1.0–1.2 vendored boundary; re-triage Hosted Hatch rewrite leaves an existing Hatch environment unpatched with no stale-install warning, and vex still attests not_affected #335, Hatch rollback and remove refuse with "configuration drifted" after the project version is bumped or a dependency is added, in both hosted and vendored mode #385 (vendored), Hatch 1.17+ projects with a hatch-generated pylock.toml get only the lock rewritten, and Hatch regenerates it from pyproject, so hosted and vendored patches are silently dropped #479, Vendored scan in a Hatch workspace member writes {root:uri} that the workspace root env never expands, so every hatch run at the root fails to install #505 when main moves.