[ilyt]

I wouldn't rely on env variables. I'd make a script that goes somewhat like

    script envname command

then just loads .env.envname before executing.

For k8s work I just put some relevant variables in PS1 so it is always visible "where I am", with prompt looking like this for say "dev" env:

    [08:15:57] ^ [~] 
    k8s:dev -> ᛯ 

As for tmux behaviour, it's honestly entirely understandable. tmux have no way of knowing the intent of the user; some people might want "clean" session with defaults of what server is running, other might want some env variables copied.

I don't have that problem because I just have session being created in my WM autostart, and I just use that one session 99.99% of the time. And creating new ones usually is from tmux, not from some random shell window elsewhere

[ajorgensen]

Yeah that makes sense. To me it felt unintuitive that environment was global and only copied on server start, with a few exceptions, and not session start but that was likely just a failure in my mental model of how tmux worked.

[ilyt]

I think it's about the stuff that needs to be shared. Like variables for X11 or ssh agent.

If you start server off your graphic session then any new tmux session will get those variables and your ssh agent or graphical app will "just work".

Reading from current one by default might fuck something up if you say have some automation that starts stuff in tmux

There isn't really good way to handle it by default that would make everyone happy, screen had similar "problems".

I just have

    tmux new-session -d -s main

in my .Xsessionrc so the main session gets both SSH_AGENT stuff (I use gnupg as agent, for smartcard support) and proper DISPLAY, then just use alias to use that main session