Applying the project config will always be a onedirectional operation, it applies the state of your config/ folder to your database. Applying the project config through the control panel is the same as the project-config/apply command. To apply changes in the opposite direction (database -> config/ folder), there are the project-config/write and project-config/rebuild command, see this answer for details.
That said, it's not guaranteed that applying the project config will never perform any file system operation. Every system component and plugin can listen to project config changes and do whatever they want in reaction to those. For example, a project config change to a file system's base path may create that directory on the filesystem (not sure if that actually happens at that point, it's just an example). Other plugins may create files or move folders around as a reaction to project config changes.
That said, those changes mostly happen in folders that usually aren't tracked in git (storage, web, etc) and applying the project config should never change the contents of the config/ folder. I would ditch a plugin that does this immediately.
Working with Windows WSL2 is really a pain regarding file permissions, sometimes I find myself with modified project files that I don't want to commit and my only option is to do a git reset, because reverting them is problematic with WSL2.
This is your real problem. You can never work productively with a system you don't have full control over. Instead of trying to contain the fallout, invest the time to get your development environment under control. For example, you could:
- Use Docker to set up a predictable, reproducible environment.
- Install a dedicated Ubuntu installation on your Windows PC with a dual boot setup.
- Buy a dedicated machine for development with Linux or macOS.