I hit this same issue after setting up a new machine last week and was able to get around it by uninstalling the Homebrew tmuxinator package and installing tmuxinator with Rubygems instead:

• Uninstall the Homebrew package: brew remove tmuxinator
• Exit out of tmux: tmux kill-server
• Start up tmux
• Install tmuxinator with Ruby: gem install tmuxinator

Everything now works for me. I'm not sure why the Homebrew package is not working correctly, but I wonder if the instructions should be removed from the readme or a warning added until this is fixed?

I'm not sure why the Homebrew package is not working correctly, but I wonder if the instructions should be removed from the readme or a warning added until this is fixed?

Please feel free to submit a PR.

Thanks, @ethagnawl. I opened #843.

I also wanted to provide some additional context:

• OS: macOS Monterey (12.0.1)
• Device: 2021 M1 Macbook Pro
• Architecture: I installed Homebrew in the normal way (non-Rosetta) and am not running my terminal with Rosetta
• Ruby: Ruby is installed with rbenv, not using system Ruby

Issue faced:

After installing tmuxinator with HomeBrew, tmuxinator itself worked fine, but gems I installed with gem install <gem_name> were not available on my path. When I ran gem env, my RubyGems "Installation Directory" was inside of /opt/homebrew/tmuxinator/.... (I can't remember the exact path and no longer have this error to check), instead of the expected path of ~/.rbenv/versions/2.7.5/....

After uninstalling tmuxinator from HomeBrew and reinstalling with RubyGems, the installation directory is correctly reported to be inside of ~/.rbenv/version/... and installing gems with gem install now works.

I faced same issue as @stevehanson - but with asdf installed Ruby.
Same fix worked 👍

The problem with Homebrew is that it doesn't link gems into /usr/local/lib/ruby/gems. Instead, all gems stay in their own /usr/local/Cellar directory and the executables in /usr/local/bin set GEM_HOME to /usr/local/Cellar/<package>/<version>/libexec so that the gems can be located. Since Homebrew packagers apparently don't care much about shared Ruby dependencies, this makes it easier to untangle dependency conflicts.

As a workaround, one can simply add unset GEM_HOME in .zshrc to avoid gem install to /usr/local/Cellar/tmuxinator (if it's an interactive shell of cos).

PS: I also use asdf and I always run GEM_HOME="$(gem env gempath | tr ':' $'\n' | rg '\.asdf')" gem/bundle install in project directories just to make sure nothing gets into user or /usr/local gem directories either. Dependency management is fun 🙄

It seems like there's some discussion around this issue in Homebrew/homebrew-core#59484.

It'd be great to see some kind of fix implemented in tmuxinator. I'm not sure what needs to be done, but it is convenient to use Homebrew to install tmuxinator because I don't need to worry about the gem disappearing when changing Ruby versions.

My current workaround is to unset the GEM_HOME env variable in my interactive shell configuration. It's a bit of a blunt solution, but my current setup works well without that variable set.

If someone wanted a different value, I suppose you could just set it in a similar way.

Examples:

~/.zshrc

# Workaround for Homebrew tmuxinator issue
# https://github.com/Homebrew/homebrew-core/issues/59484
# https://discourse.brew.sh/t/why-does-tmuxinator-sets-gem-home/7296
unset -v GEM_HOME

~/.config/fish/config.fish

if status is-interactive
  # Workaround for Homebrew tmuxinator issue
  # https://github.com/Homebrew/homebrew-core/issues/59484
  # https://discourse.brew.sh/t/why-does-tmuxinator-sets-gem-home/7296
  set -e GEM_HOME
end

Is this still an issue? I'm having trouble reproducing it. This is from within the tmuxinator session:

$ cat `which tmuxinator`
#!/bin/bash
GEM_HOME="/opt/homebrew/Cellar/tmuxinator/3.2.1/libexec" exec "/opt/homebrew/Cellar/tmuxinator/3.2.1/libexec/bin/tmuxinator"  "$@"

$ gem env home
/Users/akofink/.rbenv/versions/3.3.3/lib/ruby/gems/3.3.0