It's quite an indictment of the current state of our tooling (not just tmux) that such an application as this is necessary. Why isn't it easy to configure this in tmux itself, and persist the resulting configuration?

This doesn't let you persist ad hoc setups, but I have a `~/lib/tmux-code` file that I source from `~/.bash_profile` with entries like this:

    function ins-code {

      env_name=code
      long_name=insurance
      short_name=ins
      tmux_session=${short_name}-${env_name}

      if tmux list-sessions | grep ${tmux_session}; then
        tmux attach-session -t ${tmux_session}

      else
        cd ~/src/${long_name}/backend/app/models && \
        tmux new-session -d -s ${tmux_session} && \
        tmux rename-window -t ${tmux_session}:1 models

        cd ~/src/${long_name}/backend/app/controllers && \
        tmux new-window -t ${tmux_session}:2 -n controllers

        cd ~/src/${long_name}/backend/app/views && \
        tmux new-window -t ${tmux_session}:3 -n views

        cd ~/src/${long_name}/backend/app/assets/stylesheets && \
        tmux new-window -t ${tmux_session}:4 -n css

        tmux select-window -t ${tmux_session}:1 && \
        tmux -2 attach-session -t ${tmux_session}
      fi
    }
Then I can just say `ins-code` and it will either launch a new session or attach if it already exists.
I highly recommend https://github.com/tmuxinator/tmuxinator if you haven't tried it, I've actually used it to run whole microservice environments locally and works without a hitch