It seems like the behavior would cause problems in the following workflow:

- create first session (launch server)

- detach

- set environmental variables

- create second session

But I don't understand why you would want to follow this workflow in practice.

When using tmux, all my work on that machine is done within tmux sessions, and I expect them to be sandboxed relative to each other. If I want to set an variable that's relevant to a session, I do it from within the session, not outside.

From a user perspective, it can look like indeterminate or unexpected behavior - the set of environment variables available within the tmux session depends on the state of the world at the time the tmux server was started, as opposed to when the session was started. The tmux server may start when the session starts, or it may have started much earlier - as a user, unless you're aware of this behavior and paying attention, you won't know.

Other posters are right that the "correct" workflow is to set all your environment variables explicitly within the session before launching whatever process you're running, but on an ad-hoc basis, I've often found myself logged into a server and thinking "this may take a long time, I should run this in a tmux session," and this kind of behavior would have (and probably has) bitten me in that case.

OP here. Apologies for not providing the real world example that triggered the behavior but here's some more background: We have some make tasks that set up a local dev environment and rely on environment variables to control a few things. We ran into an issue where if someone started another tmux session and then ran the make task to start the dev environment the env vars wouldn't be set correctly causing some confusing behavior.

Ultimately we decided to use a named tmux socket to ensure the environment variables were picked up correctly when set via the make task but you can also use `set-environment` as well if the ergonomics hit of having to use the named socket each time is too much. It's nice that tmux provides a few work arounds but I thought the original behavior was not intuitive.