WSL Python interpreter hangs on "Loading environments…": shell startup output breaks detection

Symptoms

Adding a Python interpreter on a WSL (or other remote) target never completes: the environment dropdown stays on Loading environments… indefinitely and the spinner never stops. The Add Python Interpreter dialog cannot proceed because no environments are ever listed.

A pre-existing in-project virtual environment (.venv) may also be marked as Invalid Python SDK with the type shown as Unknown, even though the same environment works correctly when activated in the WSL terminal.

The IDE log (Help | Collect Logs and Diagnostic Data) contains entries similar to:

WARN - #c.j.p.s.a.v.c.CondaViewModelKt - No <number> found in
/bin/bash: -c: line 1: unexpected EOF while looking for matching `"'

SEVERE - com.jetbrains.python.sdk.PyInvalidSdk mismatch for SDK:
Unknown \\wsl.localhost\<distro>\...\.venv; type: Python SDK

Environment

• Customer type: Personal and commercial customers
• Region affected: All regions
• Product affected: PyCharm (and other IntelliJ-based IDEs that add interpreters on WSL or SSH targets)

Cause

To list the available environments on a remote target, the IDE runs a short command through a login shell on that target and reads the result back from standard output. When a shell startup file (~/.profile, ~/.bash_profile, or ~/.bashrc) prints anything to standard output on every shell start (for example, a system-info banner from screenfetch, neofetch, fortune, or a plain echo), that text is mixed into the same stream the IDE parses.

The injected banner corrupts the expected output: the IDE can no longer find its result marker, and the shell itself can fail to parse the command (unexpected EOF while looking for matching quote). Detection never returns a clean result, so Loading environments… spins forever, and the existing environment is left registered as an invalid ("Unknown") SDK.

The virtual environment itself is valid, which is why it still works in the terminal. The trigger is the startup-file output, not the environment or the IDE command.

Resolution

1. Confirm that a startup file prints to standard output. In the WSL (or remote) terminal, run:

   bash -lc 'echo ===START===; echo ===END==='
   

   The output must be exactly two lines, ===START=== and ===END===, with nothing before, between, or after them. Any extra text (a banner, a warning) means a startup file is writing to standard output on shell start.

2. Check the startup files for syntax errors (an unmatched quote produces the same unexpected EOF error):

   bash -n ~/.bashrc
   bash -n ~/.bash_profile
   bash -n ~/.profile
   

   Files that do not exist can be skipped.

3. In the offending startup file, locate the line that prints output (commonly a call to screenfetch, neofetch, fortune, or echo) and guard it so it runs only in an interactive terminal. Either form works:

   # Run only when standard output is a real terminal
   if [ -t 1 ] && command -v screenfetch >/dev/null 2>&1; then
       screenfetch -p
   fi
   

   # Run only for interactive shells
   case $- in
       *i*) command -v screenfetch >/dev/null 2>&1 && screenfetch -p ;;
   esac
   

   The banner still appears in a normal terminal session but stays silent when the IDE reads the shell programmatically.

4. Re-open the Add Python Interpreter dialog and add the WSL/remote interpreter again. The environment list loads, and the existing environment is recognized as valid.

Keep anything that writes to standard output out of ~/.profile and ~/.bashrc, or guard it as shown above. Startup-file output also breaks other tools that read a shell programmatically, such as SSH-based tooling and file synchronization.