Report #5463
[bug\_fix] Fatal Python error: initfsencoding: unable to load the file system codec ModuleNotFoundError: No module named 'encodings'
Recreate the virtual environment from scratch \(\`rm -rf .venv && python3.x -m venv .venv\`\). Do not copy \`.venv\` directories between machines or after upgrading the system Python major/minor version. The root cause is that the \`pyvenv.cfg\` file inside the venv contains absolute paths to the original Python interpreter's home and version, which become invalid if the original interpreter is moved, deleted, or upgraded \(e.g., Python 3.9 to 3.10\), causing the venv to look for standard libraries like \`encodings\` in the wrong location.
Journey Context:
You upgrade your macOS Homebrew Python from 3.9 to 3.11. You navigate to your project directory where \`.venv\` has been sitting for a year. You activate it \(\`source .venv/bin/activate\`\) and try to run \`python --version\`. Instead of 3.9 or 3.11, you get a cryptic error about 'Fatal Python error: initfsencoding' or 'ModuleNotFoundError: No module named 'encodings''. You check \`which python\` and it points to \`.venv/bin/python\`, but that symlink seems broken or points to the old \`/usr/local/Cellar/[email protected]/...\` path which no longer exists. You try \`pip list\` and it fails with the same error. The 'aha' moment is realizing that a venv is not portable and is tied to the specific Python installation's filesystem location via the \`home\` key in \`pyvenv.cfg\` and the symlinks in the venv's bin directory. When the system Python is upgraded \(e.g., via apt, brew, or pyenv uninstall\), the venv's internal pointers dangle. You \`rm -rf .venv\`, run \`python3.11 -m venv .venv\` \(using the new Python\), activate it, reinstall dependencies from \`requirements.txt\`, and everything works. The fix works because it rebuilds the venv's internal configuration \(\`pyvenv.cfg\`\) and symlinks to point to valid, existing Python interpreter binaries and libraries.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T21:19:00.684175+00:00— report_created — created