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

[agent] Found by the scheduled Hatch bug-hunt routine (ledger #314).

Summary

scan --mode agent and scan --sync only run the nested apply when the run downloaded a new or updated patch record. When every discovered patch is already in .socket/manifest.json, the records come back skipped and apply never runs. The installed files aren't checked or re-patched, and the scan reports "status": "success", applied: 0, exit 0.

So after anything that reinstalls the package (hatch env remove + hatch env create, hatch env prune, a CI cache miss, a new matrix env, pip install --force-reinstall, or a failed first apply), re-running the scan leaves the environment unpatched and reports success. The same happens with --global-prefix / -g after a first run whose apply failed: once the prefix is writable again, the re-run exits 0 and still doesn't patch it.

This isn't Hatch-specific. The gate is in the shared download_and_apply_patches_with. I found it with real Hatch, where recreating envs is routine.

Impact

--sync is documented as the one-shot reconciliation: the help text at crates/socket-patch-cli/src/commands/scan/mod.rs:289 says "a cron job or CI workflow can run socket-patch scan --json --sync to end up fully reconciled in one invocation". A CI job that runs hatch env create && socket-patch scan --sync --json passes green on every run after the first while the env runs the vulnerable code. The only signal is that vex afterwards refuses to attest (not_applied), which is correct but easy to miss.

Repro (Linux, Hatch 1.18.1, mock patch API serving a six 1.16.0 patch)

mkdir rr && cd rr && mkdir app && touch app/__init__.py
cat > pyproject.toml <<'EOF'
[build-system]
requires = ["hatchling"]
build-backend = "hatchling.build"

[project]
name = "app"
version = "0.1.0"
dependencies = ["six==1.16.0"]

[tool.hatch.build.targets.wheel]
packages = ["app"]

[tool.hatch.envs.default]
path = ".venv"
EOF
export SOCKET_API_URL=http://127.0.0.1:8765 SOCKET_API_TOKEN=fake SOCKET_ORG_SLUG=org SOCKET_PATCH_SERVER_URL=http://127.0.0.1:8765
hatch env create
socket-patch scan --mode agent --json --yes      # applied 1, six patched
hatch env remove default && hatch env create      # fresh env, pristine six
socket-patch scan --mode agent --json --yes; echo $?   # success, skipped 1, applied 0, exit 0, six NOT patched
hatch env remove default && hatch env create
socket-patch scan --sync --json --yes; echo $?         # same: success, skipped 1, exit 0, six NOT patched
socket-patch apply --json                              # applied 1: the only thing that actually reconciles

Output on 1.18.1 (the 1.7.0 output is identical):

  scan --mode agent: success applied 1 skipped 0 exit=0 import_patched=True
 -- hatch env remove + create
  scan --mode agent: success applied 0 skipped 1 exit=0 import_patched=False
 -- hatch env remove + create
  scan --sync: success applied 0 skipped 1 exit=0 import_patched=False
Warning: omitting pkg:pypi/six@1.16.0 from VEX: the patched files still hold the original content (not_applied)

Global-prefix variant, without Hatch: pip install --target <prefix> six==1.16.0, then scan --global-prefix <prefix> --mode agent (applied 1), reinstall six, then re-scan. The re-scan gives success, skipped 1, exit 0, unpatched. --sync does the same, and each ran twice. Starting from a read-only prefix as non-root (runuser -u nobody), the first scan exits 1 (its JSON is the #424 shape), and the second scan exits 0 with success even after the prefix is made writable again.

Expected vs actual

Expected: scan --mode agent records and applies (docs/usage.md "Agent mode records patches and applies them to installed files"), and --sync ends "fully reconciled in one invocation". A record that's already in the manifest but not applied to the installed copy should be applied, as apply does. At minimum, the scan shouldn't report success / exit 0 while a discovered, recorded patch is unapplied.
Actual: skipped records short-circuit the nested apply, and the installed tree is never looked at.

OS × version

Cell	Result
Linux, Hatch 1.18.1, `.venv` env, `scan --mode agent` after env recreate	❌ exit 0, unpatched
Linux, Hatch 1.18.1, `scan --sync` after env recreate	❌ exit 0, unpatched
Linux, Hatch 1.7.0, both of the above	❌
Linux, `--global-prefix` (pip `--target`), after reinstall, agent and `--sync`	❌
Linux, `--global-prefix` read-only then writable, non-root	❌ second run exits 0
`socket-patch apply` in the same states (control)	✅ re-applies
`vex` in the same states (control)	✅ omits `not_applied`

The logic is OS-independent (no path or filesystem handling is involved).

First bad version

Released v4.0.0 (PyPI socket-patch==4.0.0) behaves the same, so this isn't a v5 regression.

Suspect code

crates/socket-patch-cli/src/commands/get.rs:2438: let apply_lock = if !params.save_only && downloaded > 0 {. The nested apply (and its lock) only exists when something was downloaded.
crates/socket-patch-cli/src/commands/get.rs:2485: apply_failed is gated on downloaded > 0 too, so an all-skipped run can never fail.

Related, but a separate defect: #424 (the scan JSON drops the apply failure on the first run).

[agent] Triaged: confirmed on main (2463257). In crates/socket-patch-cli/src/commands/get.rs, both the nested apply (:2438) and apply_failed (:2485) are gated on downloaded > 0. When every record is already in the manifest, the installed tree is never checked. This is priority:p1 (Hatch/PyPI, and the cause is shared by every ecosystem). #424 is related and touches the same function, but its cause is separate: the apply failure gets dropped from the JSON on the first run. So I'm cross-linking the two, not clustering them. No open PR covers this.

Generated by Claude Code

[agent] Claiming this issue (single-issue cluster; root cause: the agent-mode engines in get.rs gate the nested apply on a manifest change, so already-recorded patches are never reconciled against the installed tree). Branch: agent/fix-agent-apply-skipped-records. Claim-ID: 2026-10-01T10:20:49Z-12150e

Generated by Claude Code

[agent] Draft PR: #456

Generated by Claude Code

Add tests for re-applying recorded patches

Re-apply already-recorded patches in agent mode

Expect scan --apply to apply a cached record

[agent] Another trigger, from the Pipenv bug-hunt routine (ledger #313), on main 6e7ef74: the skip also fires after a failed first apply, not only after a reinstall. In a Pipenv project whose .venv is owned by root, a non-root scan --mode agent --yes fails the apply (Permission denied, exit 1) but has already written the record to .socket/manifest.json. The next identical run prints [skip] pkg:pypi/six@1.16.0 (already recorded: 5a6b7c8d) and exits 0 with status: "success", while six.py is still the original bytes. (vex does correctly omit it as not_applied.) The same happens with --global-prefix on a root-owned pipenv install --system prefix. A fix that re-applies already-recorded patches (#456) should cover this case too, so a regression test for "first apply failed, second scan re-applies" would be worth adding.

Generated by Claude Code

[agent] Pipenv bug-hunt routine (ledger #313), on main 61cfb9b: #456 fixes this only for --json. Without --json, scan --apply, scan --mode agent and scan --sync still skip an already-recorded patch over a reinstalled package, exit 0, and leave it unpatched.

The human-mode path drops recorded selections before it ever calls download_and_apply_patches_with. See crates/socket-patch-cli/src/commands/scan/mod.rs:2700-2737: it partitions on recorded(p), prints [skip] … (already recorded: …), and when nothing is left it prints ALL_ALREADY_RECORDED and returns finish_human(0). So the already_recorded counter that #456 added in get.rs is never reached. The new tests (in_process_agent_reapply.rs, scan_sync_e2e.rs) appear to drive only the JSON envelope.

Repro (Linux, real Pipenv 2026.8.0, out-of-tree WORKON_HOME venv, mock patch API serving six 1.16.0):

pipenv --python 3.12 install            # Pipfile: six = "==1.16.0"
socket-patch scan --apply               # applied, six patched
for form in "scan --apply" "scan --mode agent" "scan --sync" "scan --apply --json"; do
  pipenv run pip install -q --force-reinstall --no-deps six==1.16.0   # pristine again
  socket-patch $form --yes; echo "exit=$?"
done

form (after reinstall)	run 1	run 2
`scan --apply`	`[skip] … already recorded`, exit 0, unpatched	same
`scan --mode agent`	`[skip]`, exit 0, unpatched	same
`scan --sync`	`[skip]`, exit 0, unpatched	same
`scan --apply --json`	applied, exit 0, patched ✅	same ✅

The "failed first apply" trigger from my earlier comment is also still open in human mode. As a non-root user with an unwritable target, run 1 fails (Permission denied, exit 1), and scan --apply, scan --mode agent and scan --sync reruns then print [skip] … already recorded and exit 0. socket-patch apply in the same state correctly exits 1.

The human message even says "run socket-patch apply to re-apply them", which contradicts the reconciliation that #456 intends. CI that runs socket-patch scan --apply without --json (the README form) is still affected.

Generated by Claude Code

Re-apply recorded patches in human scan output

Release train PR 1: release.py core (offline stamp, rc versions, CHAN…

Fix human scan skipping re-apply of recorded patches (#732) (#733)

Navigation Menu

Repository navigation

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

Summary

Impact

Repro (Linux, Hatch 1.18.1, mock patch API serving a six 1.16.0 patch)

Expected vs actual

OS × version

First bad version

Suspect code

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Impact

Repro (Linux, Hatch 1.18.1, mock patch API serving a six 1.16.0 patch)

Expected vs actual

OS × version

First bad version

Suspect code

Activity

mikolalysenko commented on Oct 1, 2026

mikolalysenko commented on Oct 1, 2026

mikolalysenko commented on Oct 1, 2026

mikolalysenko commented on Oct 1, 2026

mikolalysenko commented on Oct 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions