Installing requirements via "python -m pip install" randomly throws WinError5 exception

OS:     Windows 10, 64-bit
Python: 3.9.1
Pip:    21.0.1
Editor: JetBrains Pycharm 2020.3.3

I have cloned a private GitHub repository via Pycharm and created the project's venv as usual after selecting my project interpreter. Ran python -m pip install -U --force-reinstall pip setuptools wheel after. Versions of all modules are up-to-date.

Pycharm automatically activates the created venv, so there is no need to manually activate it.

When running python -m pip install -r requirements.txt, this error (seemingly) randomly occurs:

ERROR: Could not install packages due to an OSError: [WinError 5] Access is denied: {file_path within venv}
Consider using the `--user` option or check the permissions.

I have checked for this error, and all sources seem to imply a permission mismatch, but I cannot figure out why there would be any.

So, I opened cmd as admin, navigated to my project folder and activated the venv through .\venv\Scripts\activate. There was no issue here.

Naturally, I ran python -m pip install -U --force-reinstall -r requirements.txt and the same error still occurred - even with admin permissions. (pip seems to fail randomly - sometimes e.g. numpy is able to be installed, sometimes not)

What could I try next in order to make it work? Have I made any mistakes so far? How could I proceed?

EDIT:

Using the --user flag does not work. ERROR: Can not perform a '--user' install. User site-packages are not visible in this virtualenv.

EDIT 2:

Deleting the venv directory, and reinstalling it with the following commands seems to have fixed the issue when installing the project requirements for the first time:

python -m venv .\venv
.\venv\Scripts\activate
python -m pip install -U --force-reinstall pip setuptools wheel
python -m pip install -r requirements.txt

The project is able to be run now, but out of curiosity, I tried running this command again: python -m pip install -U --force-reinstall -r requirements.txt

The error still occurs, so it doesn't seem like the issue is fixed by recreating the venv, but at least the project can be run now. Not closing the question myself, as the "actual problem" does not seem to be fixed.