I am dealing with a severe package manager execution block on a Windows work machine. Immediately following a recent Windows Update, all Python package managers (pip, uv, conda, pip3) have started failing silently or aggressively bypassing active virtual environments.
I have local write privileges on the C: drive, but the machine runs Zscaler and Xcitium Antivirus. I suspect Xcitium's Auto-Containment or a new Windows kernel-level security policy is sandboxing the processes, but I cannot capture any error logs to prove it.
The Symptoms
Universal Silent Failures: Running any installation command (e.g., pip install requests, uv pip install requests) results in a completely silent failure. The process drops immediately back to the shell prompt with no output, no stack trace, and no exit code.
Static Commands Work: Purely informational commands that do not write to disk or spawn subprocesses, such as pip --version, execute perfectly and point to the correct venv binary.
Forced Roaming Profile Routing: If I try to force execution by calling the module directly (python -m pip install ), it completely ignores the active venv. Instead of targeting venv\Lib\site-packages, Python forcibly routes the installation to the user site-packages: C:\Users\AppData\Roaming\Python\Python314\site-packages.
Environment & Context
OS: Windows (Corporate environment, but with C: drive write privileges).
Python Version: 3.14
Security Stack: Zscaler, Xcitium Antivirus.
Trigger Event: This behavior began exactly after the latest Windows Update. Prior to the update, venv isolation and pip worked flawlessly.
Troubleshooting Already Attempted
Switched Package Managers: I completely abandoned pip and tried uv (Rust-based) and conda. Both exhibit the exact same silent termination and path-bypassing behavior, ruling out a corrupted pip installation.
Reinstallation: Completely reinstalled pip and Python.
Path & Config Overrides: Attempted to force the target using --target, --no-user, and environment variables like PIP_REQUIRE_VIRTUALENV=true. The silent failure persists.
The Theory & Core Questions Given that Xcitium relies heavily on Auto-Containment (sandboxing unknown executables and virtualizing their file system writes), and this broke exactly after a Windows Update, I suspect Python's subprocesses or temporary directory writes are being silently hooked and terminated, causing Python's site.py to panic and fallback to the roaming profile.
Has anyone experienced the latest Windows Update breaking Xcitium/Zscaler's interaction with Python subprocesses?
How can I trace or bypass a silent executable kill when -vvv verbosity yields absolutely no output because the process is terminated at the OS/EDR level?
Is there a known workaround to force Python to respect sys.prefix when an EDR or AppLocker policy is intentionally redirecting file system writes to virtualized AppData directories?