How can I maintain environment variables in a tab that is launched by a script that is launched by a keymap?

[mwpardue]

I have a bash script that launches a list of SSH hosts in fzf. From that list I select the host and then the script connects to the host in a new tab using a kitty launch command. I also have ssh-agent running on my machine, so the SSH_AGENT_PID and SSH_AUTH_SOCK ENV variables need to be passed to the new tab to prevent ssh asking for my passphrase every time.

Here is the relevant line in the script:

      kitten @ launch --type=tab --copy-env --tab-title "${hostname}" ssh $hostname

If I run the script directly at the command line then the variables are passed to the final new tab. However, when I call the script via a launch mapping I lose the environment variables.

Here is the relevant keymap in the kitty.conf:

 map cmd+x launch --type=window --location=hsplit --copy-env /usr/local/bin/xxh.sh

I'm not sure what to do to pass these variables through to the final tab. I've tried using --copy-env on the mapping as well as explicitly passing them via --env but the variables don't get sent to the final tab when launched via a keymap.

Thanks for any advice or assistance!!

[kovidgoyal]

As the docs for --copy-env note it only works for env vars that the child process was started with not current env vars. This is a kernel limitation. I suggest you set your SSH env vars in whatever environment you are running kitty itself from, then kitty and thus all tabs/windows/etc. in kitty will inherit those env vars. You can also set them in kitty.conf using geninclude and running ssh-agent in a script that outputs the appropriate env directives for kitty.conf, but this is unnecessary complexity, IMO.

[mwpardue]

Thank you, I assumed it was something like that but I'm not familiar enough with the details of how inheritance and shell spawning works to say for sure just on my own. I appreciate the explanation and advice!

[mwpardue]

Just wanted to add the solution, just in case somebody is searching for this in the future. You can configure Mac OS to use the keychain for ssh passphrases rather than ssh-agent, and the keychain is globally accessible. This fixed my particular issue.

Host *
  UseKeychain yes

In my research I found that you can run ssh-agent as a system service on Linux, which would achieve the same global availability as using keychain on Mac OS.