I assume JetBrains has a legitimate reason for setting the LC_CTYPE environment variable to “UTF-8” in the JetBrains 2025.x terminal. Whatever that reason is, it makes remote SSH servers very upset:

  
    ssh remote-debian-server.pizza
Linux ned 6.12.48+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.48-1 (2025-09-20) x86_64
...
Last login: Wed Dec 17 10:53:09 2025 from 10.0.73.10
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory
-bash: warning: setlocale: LC_CTYPE: cannot change locale (UTF-8): No such file or directory


  

The ssh binary from OpenSSH shipped with macOS dutifully reads /etc/ssh/sshconfig.d/100-macos.conf and does what it is instructed, shipping all environment variables matching LC_* to the remote host.

The issue is that my Debian servers do not appreciate the goofball locale string of “UTF-8” and complain loudly. The correct string would have been "en_US.UTF-8" or another appropriate value.

I spent more time than warranted trying to find a configuration setting to prevent JetBrains from clobbering my environment. In the end, I just needed to get on with my day. I added the following to my ~/.bash_profile:

  
    if [[ "${TERMINAL_EMULATOR:-}" == JetBrains* ]]; then
  unset LC_CTYPE
fi