[Mikola Lysenko (mikolalysenko)]

A project could already have a pnpm, Yarn or patch-package fix and still receive a Socket patch without specific consent. Native npm/Bun had backend-specific refusals, but there was no shared package-ownership check. Agent apply also overwrote unknown installed file contents with the verified Socket blob by default, potentially discarding a local fix.

This change protects project patches before patch selection or mutation, even when the two fixes touch different files or the user diff has not been installed yet.

• Add a read-only detector for pnpm declarations and lock markers; Yarn user and plugin patch locators; patch-package filenames and literal custom directories; native npm/Bun declarations; Composer patch definitions and locks; Cargo overrides; and Go replacements. Inspect declared npm workspace members and ancestor workspace settings. Preserve Socket-owned wiring and distinguish Yarn's builtin compatibility patches from user patches.
• Skip protected scan candidates with user_patch_conflict warnings in every mode. apply (including nested apply) leaves protected manifest entries out with the same warning and applies the rest, so a postinstall apply never fails an install over them. Explicit get and vendor refuse conflicts with exit 1; vendor reverts dropped entries first. Recheck ownership before hosted/vendored writes, including hosted-to-vendored eject, and retain the full crawl for pruning.
• Add invocation-only --allow-user-patches, forwarded through nested apply and reported as user_patch_override. General --yes, UUID selection, policy settings, and --force do not approve declared patch composition. Existing backend safety refusals remain in force.
• Reject unknown installed-file drift by default, except content an earlier Socket patch wrote (its hash names a stored .socket/blobs/ blob, as after a patch update), which is overwritten with the usual warning. Explicit consent restores the previous hash-verified overwrite behavior; --strict keeps rejecting drift even with consent. Existing apply --force remains an explicit override for file drift only. Consent is an attempt to combine changes, not an automatic merge.

The CLI contract and usage docs specify diagnostics, read-only/reversal exemptions, version matching, workspace behavior, and detection limits. The ecosystem documentation links the primary package-manager documentation and source used for the research. Regression coverage includes pnpm wildcard prereleases, nested Yarn patch locators in both directions, scoped/nested/sequenced patch-package names, malformed metadata, all CLI modes, nested opt-in forwarding, and preservation of user files.

Breaking change / release coordination: the stricter mismatch default and package eligibility belong in the next major release under the CLI semver policy. Version stamps and release notes remain the release train's responsibility.

Detection is conservative where metadata is unreadable or cannot be resolved without executing scripts. Arbitrary build hooks, external patch pipelines, global-install declarations, and unrecorded edits to files a Socket patch does not touch cannot be detected reliably. These limits are explicit in the contract. Scan exits 0 when a package is protected only because metadata could not be inspected; the warning names the file.

Validation passed locally:

• cargo check --locked -p socket-patch-cli --tests
• Core detector tests: 12 passed; CLI unit tests: 925 passed.
• Full apply, get, scan, vendor, hosted eject, in-process vendor, user-patch, and affected global/parser integration suites.
• cargo clippy --locked --workspace --all-features -- -D warnings
• cargo fmt --all -- --check and git diff --check
• A real pnpm 7.28.0 patch / patch-commit workflow with a local Socket test record targeting a different file: default apply and --force refused; --allow-user-patches applied the Socket fix while preserving the native diff and user-modified file.

/code-review high ran on 4b3d620; all 10 findings were fixed (the drift-default, apply-scope and scan-exit questions were decided with the maintainer as described above). A second /code-review high pass on e48ded2 found 10 more candidates; 7 are fixed in 6cb2793 and one is documented. The other three:

• Unreadable metadata protects the whole ecosystem and scan/apply exit 0. This is the fail-safe direction and was decided with the maintainer (exit 0 with a warning naming the file). The false positives behind it (stub locks, cd in scripts, ** globs, big lockfiles) are fixed.
• Discovery runs more than once per command (vendor, eject, hosted). The second read under the apply lock is the intended TOCTOU recheck; sharing one index across the rest is a perf follow-up, not a correctness issue.
• Earlier Socket output needs its blob to be recognized. Documented in the contract: once the blob is pruned or not shared, apply --force replaces it.

---

Note

High Risk
Major behavior change to default apply/scan eligibility and file-overwrite policy on dependency trees, with new consent gates across mutating commands that can block or alter installs in projects using native patching workflows.

Overview
Breaking (major): Socket Patch now treats declared project patches as protected ownership and tightens in-place apply safety unless the user opts in per invocation.

Adds global --allow-user-patches (not env-bound; --yes, --force, and UUID selection do not substitute). A new detector scans manifests/locks for pnpm, Yarn, patch-package, npm/Bun, Composer, Cargo, and Go patch/replace evidence. scan withholds protected packages in every mode with user_patch_conflict warnings; apply skips those manifest entries but still patches others (postinstall-friendly exit 0); get / vendor / hosted & vendored writers refuse with user_patch_conflict before mutation (with a lock-time recheck on hosted writes). Consent emits user_patch_override and is forwarded through nested apply.

File mismatch policy flips: unknown local drift on apply paths fails by default instead of warn-and-overwrite. The exception is content whose hash matches a stored .socket/blobs/ entry (prior Socket patch output on update), which can still be overwritten with content_mismatch_overwritten. --allow-user-patches restores hash-verified overwrite for other drift; --strict rejects drift even with consent; apply --force still overrides file-content checks but not declared project patches. Core adds MismatchPolicy::SocketContent to implement this.

Docs (CLI_CONTRACT, usage, ecosystems) and broad CLI/core tests cover the new gates, diagnostics, and policy behavior.

^{Reviewed by Cursor Bugbot for commit 6cb2793. Configure here.}

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: CI on 98d2edd had two separate failures.

Fixed (29dd054): e2e_vendor_cargo_build cargo_url_spelled_crates_io_patch_table_is_refused and cargo_ancestor_config_patch_cannot_silently_shadow_the_vendored_copy. The new UserPatchIndex now refuses these fixtures with user_patch_conflict before the cargo-specific guards run. The tests now pass --allow-user-patches, so they still exercise cargo_manifest_patch_source_alias / user_authored_patch_entry. Both pass locally.

Needs a decision (coverage job): 5 tests in tests/in_process_redirect_pnpm.rs fail: hosted_scan_from_package_json_workspace_member_refuses, hosted_scan_from_npm_member_with_stray_lock_refuses, hosted_scan_from_bun_or_vlt_member_with_stray_lock_refuses, hosted_scan_from_brace_or_class_glob_workspace_member_refuses, and hosted_run_from_berry_picomatch_workspace_member_refuses. No user patch is declared in any of these fixtures. The detector fails closed anyway:

• package-lock.json / bun.lock (cannot inspect patch metadata: expected value at line 1 column 1): the fixture lock is a non-JSON placeholder.
• (workspace outside the inspection root): the berry packages/b/../a glob.

scan --mode hosted then drops the package with a user_patch_conflict warning and exits 0 / status success. Before this PR it exited 1 / status error, and the tests assert exactly that ("a found-but-unpinnable patch is not success").

Question: when the protection comes only from an inspection failure (unparseable lockfile, workspace glob outside the root) and not from real patch evidence, should scan still exit 0 and report success? Or should that case stay an error (exit 1)? If exit 0 is intended, the five tests need new expectations. If not, scan (or UserPatchIndex) needs to tell inspection failures apart from declared patches. I didn't pick one, because either choice changes the PR's breaking-change contract.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON, but none of the reported issues met your autofix severity threshold.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 6cb2793. Configure here.}

[cursor]

Skipped apply still reported applied

Medium Severity

Nested apply now drops a protected manifest entry and still exits 0. Agent scan/get then record every saved selection as applied. Hosted rechecks under the write lock for this window; agent no longer fails the run, and scan also suppresses the skip warning, so a package added to project patch metadata after selection can be saved and reported patched without a write.

Additional Locations (2)

• crates/socket-patch-cli/src/commands/apply.rs#L1148-L1156
• crates/socket-patch-cli/src/commands/scan/mod.rs#L891-L892

 

^{Reviewed by Cursor Bugbot for commit 6cb2793. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Traced it. In get/scan, the selection already runs the same user-patch detector (with the same allow_user_patches) before anything is recorded. So a recorded purl is skipped by the nested apply's skip_protected only if the project's patch metadata (a pnpm/Yarn/patch-package/Composer/Cargo patch entry) is added between selection and the nested apply in the same run. In that window, record_apply_outcome sees code == 0 and records applied for a package that was left unwritten. The race is real but narrow. Fixing it means adding a user_patched list to ApplyRunReport and mapping covered purls to skipped in record_apply_outcome, about 20 lines plus a test. I'm leaving this thread open for the maintainer to decide whether that's worth adding to this PR.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: CI is green on 6cb2793 (34/34, 19 skipped) and it merges cleanly with main. Bugbot reviewed this head and left one Medium finding: Skipped apply still reported applied (agent_download.rs:1449). I checked it, and it only happens if a project patch entry is added between selection and the nested apply in the same run. I replied on the thread with the traced path and the fix (~20 lines).

Question for a human: should this PR fix that race now, by mapping purls that apply skipped as user-patched to skipped events instead of applied, or accept it as is? Reply here and I'll implement or resolve it, then label this PR Ready for review.

---

Generated by Claude Code