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 09:57Z on main 2463257 (v5 workflow, #277). 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 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)
1.0 – 1.6	untested	n/a	untested	untested	untested	untested	untested	untested	untested	untested	untested	untested
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)
1.9.7	fail #335 (all 3 OS)	untested	untested	untested	untested	untested	untested	untested	untested	untested	pass / pass / fail #449	untested
1.14.1	blocked (virtualenv incompatibility)	blocked	blocked	untested	untested	untested	untested	untested	untested	untested	untested	untested
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)
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 / 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)

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). Workspaces (1.18.1, pre-v5): a member-only dependency is refused from the root with a warning, and passes when scanned from the member.

Backlog

1. 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. The uv-tool L/M/W and read-only Linux cells are done (20261001T095737Z).
2. 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).
3. 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.
4. Hatch 1.0 / 1.1 / 1.2 vendored-env boundary; 1.14.x with a pinned virtualenv.
5. Workspaces (Hatch 1.16+ workspace.members) and CRLF / BOM pyproject on v5; the vendored shapes on v5.
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, 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 draft), 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.

Known non-bugs

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

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