Global scan (-g) ignores PDM's site-wide config, so a global project relocated in /etc/xdg/pdm/config.toml is never crawled and get -g reports "applied" while the copy PDM runs stays unpatched

[mikolalysenko]

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

Summary

#522 (fixing #451) taught -g discovery to read PDM's global_project.path, venv.location and python.install_root settings. It reads them only from $PDM_CONFIG_FILE and the user config (<user config dir>/pdm/config.toml). PDM also reads a site config, platformdirs.site_config_path("pdm") / "config.toml", and uses it as the defaults layer under the user config (Config.get_defaults() in pdm/project/config.py, present since PDM 2.0). On Linux that file is /etc/xdg/pdm/config.toml (first entry of $XDG_CONFIG_DIRS). On macOS it's /Library/Application Support/pdm/config.toml, and on Windows C:\ProgramData\pdm\pdm\config.toml.

If an image or a managed machine sets [global_project] path in the site config, pdm add -g installs into <that path>/.venv, and pdm run -g python uses that venv. socket-patch never looks there.

Impact

• scan -g exits 0 with packagesWithPatches: 0 while a patchable pdm add -g package is installed.
• When the same release is also somewhere -g does crawl (the system interpreter, for example), get -g / apply -g print 1 of 1 targeted patch applied and patch that copy. The copy PDM's global project actually imports stays unpatched, and nothing warns about it. vex -g has the same blind spot.
• With the identical setting in the user config, everything works (control below), so the defect is the missing config layer, not the relocation.

Repro (Linux, real PDM 2.29.2 or 2.12.4, local mock patch API serving a patched urllib3 1.26.18)

export HOME=$(mktemp -d)
mkdir -p /etc/xdg/pdm
printf '[global_project]\npath = "/opt/bh/global"\n' > /etc/xdg/pdm/config.toml
pdm config global_project.path           # -> /opt/bh/global (PDM honours the site config)
mkdir -p /opt/bh/global && uv venv -p 3.11 /opt/bh/global/.venv
pdm use -g -f /opt/bh/global/.venv/bin/python
pdm add -g urllib3==1.26.18              # installs into /opt/bh/global/.venv
pdm run -g python -c 'import sys;print(sys.prefix)'   # -> /opt/bh/global/.venv
socket-patch scan -g --json              # status success, packagesWithPatches 0
socket-patch get -g pkg:pypi/urllib3@1.26.18 --yes
tail -1 /opt/bh/global/.venv/lib/python3.11/site-packages/urllib3/_version.py   # still upstream
# control: move the same two lines to $HOME/.config/pdm/config.toml and remove /etc/xdg/pdm.
# scan -g finds it, get -g patches the global-project copy, rollback -g restores it.

Expected vs actual

• Expected: per Fix global Python scan missing uv and PDM installs (#449, #451) #522's commit message, global discovery "follows each tool's own path rules: … PDM's platformdirs config/data dirs plus the global_project.path, python.install_root and venv.location settings". --global is documented as "Operate on globally-installed packages" (CLI_CONTRACT.md, global flags table). PDM resolves those settings through the site config too, so the global project PDM uses should be crawled.
• Actual: the site config is never read. The relocated global project is invisible, and get -g can report success after patching a different copy.

Matrix (main d63ae5f)

OS	PDM	setting in site config	result
Linux	2.29.2	global_project.path	fail (scan -g: 0; get -g patches the system copy, global-project copy unpatched)
Linux	2.12.4	global_project.path	fail (scan -g: 0)
Linux	2.29.2	same setting in the user config (control)	pass (found, patched, rollback restores)
macOS / Windows	—	—	untested (same code path, so likely to fail)

Reproduced 3/3 on Linux. PDM 2.0.3's config.py already has the site layer, so every 2.x release is in scope. venv.location and python.install_root set in the site config are missed for the same reason (same code path). I didn't isolate those in this run, because a stray system-interpreter copy masked the scan count.

Suspect code

crates/socket-patch-core/src/crawlers/python_crawler.rs:1772-1777 (pdm_global_site_packages): config_files holds only $PDM_CONFIG_FILE plus pdm_dir_candidates(.., "XDG_CONFIG_HOME", ..). It's missing the site config dirs: $XDG_CONFIG_DIRS entries (default /etc/xdg) on Linux, /Library/Application Support on macOS, and %PROGRAMDATA%\pdm\pdm on Windows. They need to be read as a lower-precedence layer than the user file.

No probe runs (Linux only).

[mikolalysenko]

[agent] Triage: priority:p1 (PDM). Confirmed on main: the -g PDM settings reader in crawlers/python_crawler.rs (~L1750-1810) consults only $PDM_CONFIG_FILE and the user config; nothing reads the platformdirs site config (/etc/xdg/pdm/config.toml etc.). Distinct root cause from open #540 (project env discovery); no open PR covers it.

---

Generated by Claude Code

[mikolalysenko]

[agent] Shares root cause with #609: PDM settings are read from one file at a time, not through PDM's layered config (env > project > $PDM_CONFIG_FILE/user > site, with ensure_boolean-style coercion). Will be fixed together.

---

Generated by Claude Code

[mikolalysenko]

[agent] Claiming this issue (with #609; shared root cause: PDM settings aren't resolved through PDM's layered config). Branch: agent/fix-pdm-layered-config. Claim-ID: 2026-10-02T21:20:53Z-8748ca

---

Generated by Claude Code

[mikolalysenko]

[agent] Draft PR: #611

---

Generated by Claude Code