[Mikola Lysenko (mikolalysenko)]

LLM Description written by Claude Code:claude-opus-5-5

Fixes #842

Summary

Some projects commit [pipenv] venv_in_project = true in the Pipfile
and have no ./.venv. On Pipenv 2018.11 through 2026.1, socket-patch
missed the venv Pipenv really uses ($WORKON_HOME/<name>-<hash>).
Agent scan then skipped the installed package as "not installed",
exited 0 and left the venv unpatched. Hosted scan lost its
stale-install warning for the warm venv. Both modes now find that venv.

Root cause

pipenv_settings_site_packages (crates/socket-patch-core/src/crawlers/python_crawler.rs)
read any explicit "in project" choice plus a missing ./.venv as
"Pipenv has no venv yet" and returned nothing. Only Pipenv 2026.2+ reads
the Pipfile key, so older releases still use WORKON_HOME. Both agent and
hosted discovery go through find_local_venv_site_packages, so one fix
covers both shapes reported in the issue.

Fix

"No venv yet" now applies only when every Pipenv agrees the venv is
./.venv: a truthy PIPENV_VENV_IN_PROJECT (2018-2020 read it as
bool(value), later releases parse it). If the choice comes only from
the Pipfile key, or from PIPENV_NO_VENV_IN_PROJECT (which old releases
also ignore), Pipenv's own placement is looked up. That lookup returns
the WORKON_HOME venv only if it exists. docs/testing/pipenv-compatibility.md
is updated to match.

Test evidence

Issue	Test	Without fix	With fix
#842 (discovery, agent + hosted)	python_crawler::tests::pipenv_pipfile_in_project_without_dot_venv_finds_workon_venv	FAIL: left: [], right: [<wh>/proj-<hash>/lib/python3.12/site-packages]	pass
#842 (agent scan end to end, in-process)	in_process_python_envs::pipenv_pipfile_in_project_without_dot_venv_scans_workon_venv	FAIL: pipenv-pkg not discovered	pass

Commands run locally on the final head:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --all-features: 6726 passed. The
  4 failures are permission-denial tests that can't fail when run as
  root in this sandbox (copy_tree relax loop, vlt_heal unremovable
  lock, pypi_poetry / pypi_requirements wire-write failure). They
  are unrelated to this change, and CI runs them as non-root.
• cargo test -p socket-patch-cli --all-features --lib --test in_process_python_envs --test in_process_redirect_pipenv --test in_process_scan --test in_process_rollback_all_ecosystems: all pass
• A full cargo test --workspace ran out of this sandbox's disk
  allowance twice (30 GB of test binaries), so CI's run is the full
  check. I didn't run the real-Pipenv e2e_vex_build pipenv:: suite
  locally because it pins PIPENV_VENV_IN_PROJECT=1, and that path
  doesn't change here. CI runs it.

Review notes (/code-review high)

• Fixed: old Pipenv also ignores PIPENV_NO_VENV_IN_PROJECT; the guard
  is simplified; the test now combines each variable with the Pipfile key.
• Not changed, by design: on Pipenv 2026.2+ with the key set, no
  ./.venv yet, and a leftover WORKON_HOME venv from before, that
  leftover venv is now scanned. The crawler can't tell the Pipenv
  version without running it. This matches the existing policy for
  ./.venv + WORKON_HOME (return both and patch whichever is used).
  Missing the venv older releases really use was the worse failure.
• Not changed, pre-existing and out of scope: Pipenv 2018-2020 read
  PIPENV_VENV_IN_PROJECT=0 as truthy.

https://claude.ai/code/session_01S1uW4TCxr9hChxXPPiYCCb

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

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

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

[Mikola Lysenko (mikolalysenko)]

Burn-down agent: labeled Ready for review.

• Head: 41362706a1
• CI: 38/38 checks green on this head (50 more skipped); no merge conflict with main (3db3cdf65c)
• Bugbot: reviewed 4136270, no findings; there are no open review threads
• Reviewer focus: python_crawler.rs now treats Pipfile venv_in_project as meaningful only for Pipenv 2026.2+, so check the version gate and the new in-process env test.

Slack announcement not sent this run (no Slack send tool available); the next run will retry.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does: If a Pipfile sets [pipenv] venv_in_project = true and there is no ./.venv, venv discovery used to give up ("no venv yet"). Only Pipenv 2026.2+ reads that key, though; older Pipenv keeps the venv in $WORKON_HOME, so agent scan skipped installed packages and hosted scan lost its stale-install warning. Now only a truthy PIPENV_VENV_IN_PROJECT (read the same way by every Pipenv) means "no venv yet". Otherwise the WORKON_HOME venv is looked up (#842).

Risk: low. It is a one-condition change in Python venv discovery. The worst case is on Pipenv 2026.2+ with the key set, no ./.venv and a leftover WORKON_HOME venv: that extra venv is scanned too. This matches the existing "return both" policy for ./.venv plus WORKON_HOME.

Look here:

• python_crawler.rs:1133:`` new pipenv_in_project_for_every_version (truthy-value parsing)
• python_crawler.rs:1645:``` the changed "no venv yet" guard
• python_crawler.rs:5596:```` unit test matrix (env var × Pipfile key)
• in_process_python_envs.rs:671:````` end-to-end agent scan test

Verified:

• Read the full diff (3 files, +97/−4). CHANGELOG.md is untouched and the compatibility doc matches the code.
• Ran the pipenv_ unit tests on this head locally: 62 passed.
• Put the old guard back and the new unit test failed (left: []), so the test does catch the bug.
• CI is green on this head (ci-ok, clippy), with no unresolved threads. Bugbot reviewed this head with no findings.

Changes I made: none.

Open questions: none.

Auto-merge (squash) is armed, so approving sends this straight to the merge queue.

---

Generated by Claude Code