Zed editor: ERROR [crates/project/src/environment.rs:227] capturing shell environment with “/opt/homebrew/bin/bash”

In case this helps anyone else… not saying what follows below is the solution for such errors.

Started to use Zed again earlier this week, and one one of my machines it showsa warning that the environment variables failed to load.

Clicking on it opens up the logs, which has a bunch of entries like these:

Caused by:
    login shell exited with exit status: 1. stdout: "\u{1b}(B\u{1b}[m", stderr: "bash: cannot set terminal process group (-1): Inappropriate ioctl for device\nbash: no job control in this shell\nopen terminal failed: not a terminal\n"
2025-12-13T10:09:19+00:00 ERROR [project::git_store] failed to get working directory environment for repository "/Users/rakhesh/xxx"
2025-12-13T10:09:19+00:00 ERROR [crates/project/src/environment.rs:227] capturing shell environment with "/opt/homebrew/bin/bash"

Caused by:

login shell exited with exit status: 1. stdout: "\u{1b}(B\u{1b}[m", stderr: "bash: cannot set terminal process group (-1): Inappropriate ioctl for device\nbash: no job control in this shell\nopen terminal failed: not a terminal\n"

2025-12-13T10:09:19+00:00 ERROR [project::git_store] failed to get working directory environment for repository "/Users/rakhesh/xxx"

2025-12-13T10:09:19+00:00 ERROR [crates/project/src/environment.rs:227] capturing shell environment with "/opt/homebrew/bin/bash"

(It seems to be for each of the folders that are git submodules).

Trying to get to the bottom of this reminded me that I had encountered a similar issue with VS Code in the past. What happens is that on the problem machine, I have set it to launch tmux whenever a new login shell is spawned. And that was causing an issue with Zed.

In VS Code the VSCODE_RESOLVING_ENVIRONMENT variable is set to 1 when VS Code is resolving the environment variables, so I was using that to not launch tmux in such cases. Something along the lines of:

# Only if $VSCODE_RESOLVING_ENVIRONMENT is empty, launch tmux
if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]]); then
    # launch tmux
fi

# Only if $VSCODE_RESOLVING_ENVIRONMENT is empty, launch tmux

if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]]); then

# launch tmux

There doesn’t seem to be the equivalent of that for Zed, though someone’s asked for it recently.

I added the following line to the top of my .bash_profile file.

env > ~/Downloads/blah.txt

1	env > ~/Downloads/blah.txt

This showed me that a variable called ZED_TERM is set to true. So I thought I’d use that in the same place I check for VSCODE_RESOLVING_ENVIRONMENT but it didn’t work.

# Only if $VSCODE_RESOLVING_ENVIRONMENT and $ZED_TERM are empty, launch tmux
if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]] && [[ -z "$ZED_TERM" ]]); then
    # launch tmux
fi

# Only if $VSCODE_RESOLVING_ENVIRONMENT and $ZED_TERM are empty, launch tmux

if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]] && [[ -z "$ZED_TERM" ]]); then

# launch tmux

Adding the same env line at this point of the code, before launching tmux, showed me that ZED_TERM isn’t available anymore. Weird.

Not a problem, I added this at the very top of .bash_profile where ZED_TERM was visible.

# Create a variable of my own
if [[ "$ZED_TERM" == true ]]; then ; 
    ZED_RESOLVING_ENV="1"
fi

# Create a variable of my own

if [[ "$ZED_TERM" == true ]]; then ;

ZED_RESOLVING_ENV="1"

Then I can do:

# Only if $VSCODE_RESOLVING_ENVIRONMENT and $ZED_RESOLVING_ENV are empty, launch tmux
if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]] && [[ -z "$ZED_RESOLVING_ENV" ]]); then
    # launch tmux
fi

# Only if $VSCODE_RESOLVING_ENVIRONMENT and $ZED_RESOLVING_ENV are empty, launch tmux

if ([[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]] && [[ -z "$ZED_RESOLVING_ENV" ]]); then

# launch tmux

And problem solved! No more errors in Zed as tmux isn’t launched when it tries to resolve the environment variables.

ps. For those who know and loved the Atom editor, Zed is Atom reborn (well, more like rewritten to be super fast and very minimal).