Hello. Many toolchain capabilities as driven from within Jetbrains now support WSL2 (as does VSCode etc). The intended mode of operation is to run the IDE in Windows and drive things like Git, NPM etc back through the WSL2 subsystem.
Unfortunately the AWS Explorer defaults to looking for credentials in c:\Users\userId.aws\config rather than, say, the WSL2 location \wsl$\Ubuntu-20.04\home\userId.aws\config. It's clearly using the Windows client and therefore the Windows credentials management.
There should be an option to either drive the AWS client back through WSL rather that Windows, or at least allow the Windows client to use the WSL AWS configuration. In the example of Git, when the executable path is set as \wsl$\Ubuntu-20.04\usr\bin\git, it is clearly using the Linux environment's .gitcredentials, .gitconfig etc
The reason why the use of WSL config/credentials management is preferred is that when you start using services like Code Artifact in your npm builds, there's an authorisation token going to be required in the WSL .npmrc anyway, and the only way that can be placed in there is to run aws codeartifact login ... within that WSL environment so that the WSL .npmrc is frequently updated as necessary.
Hello. Many toolchain capabilities as driven from within Jetbrains now support WSL2 (as does VSCode etc). The intended mode of operation is to run the IDE in Windows and drive things like Git, NPM etc back through the WSL2 subsystem.
Unfortunately the AWS Explorer defaults to looking for credentials in c:\Users\userId.aws\config rather than, say, the WSL2 location \wsl$\Ubuntu-20.04\home\userId.aws\config. It's clearly using the Windows client and therefore the Windows credentials management.
There should be an option to either drive the AWS client back through WSL rather that Windows, or at least allow the Windows client to use the WSL AWS configuration. In the example of Git, when the executable path is set as \wsl$\Ubuntu-20.04\usr\bin\git, it is clearly using the Linux environment's .gitcredentials, .gitconfig etc
The reason why the use of WSL config/credentials management is preferred is that when you start using services like Code Artifact in your npm builds, there's an authorisation token going to be required in the WSL .npmrc anyway, and the only way that can be placed in there is to run aws codeartifact login ... within that WSL environment so that the WSL .npmrc is frequently updated as necessary.
A similar issue has been raised in https://github.com/aws/aws-toolkit-jetbrains/issues/1893 but the required fix is surely broader than just SAM and requires overall WSL awareness.