PyCharm Remote SSH Interpreter Environment Variables Missing Login Shell Inheritance

Answer

No. There is no documented, supported configuration in PyCharm that makes a Remote SSH interpreter automatically source a remote user’s login profile such as ~/.bashrc, ~/.bash_profile or ~/.zshrc. The supported boundary for environment inheritance is limited to variables you explicitly set in the Run/Debug configuration Environment variables field and the minimal environment exported by PyCharm’s IDE-managed wrapper.

The "Shell path" option in the interpreter settings is not a supported mechanism for production parity. It is an undocumented workaround that can invoke a login shell for the wrapper. That behavior is not part of the public API, is not guaranteed across releases, and can introduce unrelated profile side effects and startup delays.

Confirmed facts

• The Remote SSH interpreter launches Python through an IDE-managed wrapper, pycharm-ssh-wrapper. The wrapper runs a non-interactive, non-login shell.
• Because the shell is non-login and non-interactive, login profile files are not sourced automatically. Variables exported only in those files do not reach the interpreter process.
• The only documented way to bring remote shell state into a run is to duplicate the needed variables in the Run/Debug configuration Environment variables field.
• The wrapper’s environment is not part of the public API. Changes to its startup logic can alter inheritance behavior.

Likely explanation

Local interpreters inherit the developer host environment, so code can succeed locally while failing remotely when PATH, PYTHONPATH or custom secrets are missing. The mismatch is expected with the current wrapper design, not a misconfiguration.

Steps for production parity in this case

1. Audit the required environment. In a remote Python run print a subset of os.environ and compare it to a login shell on the same host.
2. Set required variables explicitly. Use Run > Edit Configurations > Environment variables for the specific run/debug configuration, or set them at the interpreter level if they are universal.
3. For a deterministic alternative to manual duplication, create a small wrapper script on the remote host that sources the desired profile and then execs the Python interpreter, and point the Remote SSH interpreter path to that script. This is more stable than relying on Shell path.
4. Verify. Start a run and check that the variables are present. On the remote host, inspect the running command with ps to confirm how the interpreter was invoked.

To give a precise recommendation for your setup, it helps to know which shell is the remote user’s default login shell and whether the needed variables live in a login-only file such as ~/.bash_profile versus an interactive-only file such as ~/.bashrc. That determines whether a wrapper script sourcing the correct file is sufficient.