我明白你的痛点——当程序直接调用wsl <command>而不带bash -ic参数时，非交互式的bash shell不会加载~/.bashrc，导致keychain没法自动运行。下面有几个可行的解决方案，你可以根据自己的情况选择：

方案1：修改~/.bashrc的加载条件 #

默认情况下，~/.bashrc开头会有一段判断，只在交互式shell下执行后续内容：

# 如果是交互式shell才继续
if [[ $- == *i* ]]; then
    # 这里是原来的配置内容
fi

你可以把keychain的命令移到这个判断外面，这样不管是交互式还是非交互式shell，都会执行keychain：

# 先运行keychain（放在判断外面）
keychain --agents ssh id_rsa
# 加载keychain生成的环境变量
source ~/.keychain/$HOSTNAME-sh

# 保留原有的交互式判断，其他配置仍只在交互模式下运行
if [[ $- == *i* ]]; then
    # 原有的.bashrc内容
fi

⚠️ 注意：如果你的keychain命令需要交互式输入（比如密码提示），非交互式模式下会卡住，所以确保keychain已经缓存了密钥，或者加上--quiet参数避免触发交互。

方案2：设置BASH_ENV环境变量 #

bash在非交互式模式下，会自动加载BASH_ENV环境变量指向的文件。你可以在Windows系统里设置这个变量，让WSL的bash每次非交互式启动时都加载包含keychain的脚本：

1. 打开Windows的「系统属性」→「高级」→「环境变量」
2. 在「系统变量」里新增一个变量：
   • 变量名：BASH_ENV
   • 变量值：/home/你的用户名/.bashrc（替换成你实际的WSL用户路径）
3. 重启Windows Terminal生效

这样不管是wsl git push还是其他直接调用的WSL命令，bash都会加载~/.bashrc，自然就会执行keychain了。

方案3：添加全局bash启动配置 #

如果不想修改个人的~/.bashrc，可以在WSL的全局配置里添加keychain：

1. 编辑全局bash配置文件（需要sudo权限）：

sudo nano /etc/bash.bashrc

2. 在文件末尾添加keychain的启动命令：

if [ -f /usr/bin/keychain ]; then
    keychain --agents ssh id_rsa
    source ~/.keychain/$HOSTNAME-sh
fi

这个方法会对所有WSL用户生效，适合多用户共享的WSL环境。

方案4：Windows端包装WSL命令（适配无法修改程序参数的场景） #

如果上面的方法都不适用，你可以在Windows端做一个包装脚本，让程序调用的wsl实际上先执行keychain再运行目标命令：

1. 创建一个名为wsl-wrapper.bat的脚本，内容如下：

@echo off
:: 先通过交互式shell执行keychain并加载环境变量
wsl bash -ic "keychain --agents ssh id_rsa; source ~/.keychain/$HOSTNAME-sh"
:: 再执行原命令
wsl %*

2. 把这个脚本放在Windows的PATH优先级更高的目录里（比如优先于C:\Windows\System32的自定义目录）
3. 将脚本重命名为wsl.exe（注意备份系统原有的wsl.exe，或者确保自定义目录在PATH中的顺序更靠前）

这样程序调用wsl git push时，实际上会先运行keychain，再执行目标git命令。

内容的提问来源于stack exchange，提问作者stelios