terminal: Remove SHLVL from terminal environment to fix incorrect shell level - #44835
Merged
Conversation
Fixes #33958 When opening a terminal in Zed, SHLVL incorrectly starts at 2 instead of 1. This happens because: 1. Zed's shell_env::capture() spawns a login shell to capture environment, which increments SHLVL 2. The captured SHLVL is passed to the PTY, and the spawned shell increments it again The fix removes SHLVL from the environment before passing it to alacritty_terminal, allowing the shell to initialize SHLVL to 1 on its own. This matches the behavior of standalone terminal emulators like iTerm2, Kitty, and Alacritty.
|
We require contributors to sign our Contributor License Agreement, and we don't have @edlsh on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'. |
maxdeviant
changed the title
Contributor
Author
|
@cla-bot check |
Member
|
@cla-bot check |
cla-bot
Bot
added
the
cla-signed
|
The cla-bot has been summoned, and re-checked this pull request! |
Veykril
changed the title
CherryWorm
pushed a commit
to CherryWorm/zed
that referenced
this pull request
Dec 16, 2025
…ll level (zed-industries#44835) Fixes zed-industries#33958 ## Problem When opening a terminal in Zed, `SHLVL` incorrectly starts at 2 instead of 1. On `workspace: reload`, it increases by 2 instead of 1. ## Root Cause 1. Zed's `shell_env::capture()` spawns a login shell (`-l -i -c`) to capture the user's environment, which increments `SHLVL` 2. The captured `SHLVL` is passed through to the PTY options 3. When alacritty_terminal spawns the user's shell, it increments `SHLVL` again Result: `SHLVL` = captured value + 1 = 2 (when launched from Finder) ## Solution Remove `SHLVL` from the environment in `TerminalBuilder::new()` before passing it to alacritty_terminal. This allows the spawned shell to initialize `SHLVL` to 1 on its own, matching the behavior of standalone terminal emulators like iTerm2, Kitty, and Alacritty. ## Testing - Launch Zed from Finder → open terminal → `echo $SHLVL` → should output `1` - Launch Zed from shell → open terminal → `echo $SHLVL` → should output `1` - `workspace: reload` → open terminal → `echo $SHLVL` → should remain `1` - Tested with bash, zsh, fish Release Notes: - Fixed terminal `$SHLVL` starting at 2 instead of 1 ([zed-industries#33958](zed-industries#33958))
Contributor
Contributor
Author
|
I'm looking into it now |
Veykril
pushed a commit
that referenced
this pull request
Jan 8, 2026
Fixes #33958 ## Problem PR #44835 attempted to fix SHLVL starting at 2 by removing it from the `env` HashMap passed to alacritty. However, that HashMap is only an **overlay** — alacritty uses the parent process environment as a base and applies the overlay on top. Since alacritty never calls `env_remove("SHLVL")`, the terminal shell still inherits `SHLVL` from Zed's process environment. ## Root Cause The real issue is in `load_login_shell_environment()`: 1. `shell_env::capture()` spawns a login shell to capture environment variables 2. That login shell increments `SHLVL` (from 0→1 or n→n+1) 3. The captured env (including the incremented `SHLVL`) is written to Zed's **process environment** via `env::set_var` 4. When you open a terminal, the shell inherits Zed's `SHLVL` and increments it again → starts at 2 5. On reload, `shell_env::capture()` runs again with the already-elevated `SHLVL`, incrementing it further → +2 per reload ## Fix Skip `SHLVL` when setting Zed's process environment in `load_login_shell_environment()`. This prevents the login-shell capture from polluting Zed's env, so terminals start fresh with the correct `SHLVL`.
rtfeldman
pushed a commit
that referenced
this pull request
Jan 9, 2026
Fixes #33958 ## Problem PR #44835 attempted to fix SHLVL starting at 2 by removing it from the `env` HashMap passed to alacritty. However, that HashMap is only an **overlay** — alacritty uses the parent process environment as a base and applies the overlay on top. Since alacritty never calls `env_remove("SHLVL")`, the terminal shell still inherits `SHLVL` from Zed's process environment. ## Root Cause The real issue is in `load_login_shell_environment()`: 1. `shell_env::capture()` spawns a login shell to capture environment variables 2. That login shell increments `SHLVL` (from 0→1 or n→n+1) 3. The captured env (including the incremented `SHLVL`) is written to Zed's **process environment** via `env::set_var` 4. When you open a terminal, the shell inherits Zed's `SHLVL` and increments it again → starts at 2 5. On reload, `shell_env::capture()` runs again with the already-elevated `SHLVL`, incrementing it further → +2 per reload ## Fix Skip `SHLVL` when setting Zed's process environment in `load_login_shell_environment()`. This prevents the login-shell capture from polluting Zed's env, so terminals start fresh with the correct `SHLVL`.
Contributor
Author
|
@injust This should have resolved the issue 😁 |
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
…ll level (zed-industries#44835) Fixes zed-industries#33958 ## Problem When opening a terminal in Zed, `SHLVL` incorrectly starts at 2 instead of 1. On `workspace: reload`, it increases by 2 instead of 1. ## Root Cause 1. Zed's `shell_env::capture()` spawns a login shell (`-l -i -c`) to capture the user's environment, which increments `SHLVL` 2. The captured `SHLVL` is passed through to the PTY options 3. When alacritty_terminal spawns the user's shell, it increments `SHLVL` again Result: `SHLVL` = captured value + 1 = 2 (when launched from Finder) ## Solution Remove `SHLVL` from the environment in `TerminalBuilder::new()` before passing it to alacritty_terminal. This allows the spawned shell to initialize `SHLVL` to 1 on its own, matching the behavior of standalone terminal emulators like iTerm2, Kitty, and Alacritty. ## Testing - Launch Zed from Finder → open terminal → `echo $SHLVL` → should output `1` - Launch Zed from shell → open terminal → `echo $SHLVL` → should output `1` - `workspace: reload` → open terminal → `echo $SHLVL` → should remain `1` - Tested with bash, zsh, fish Release Notes: - Fixed terminal `$SHLVL` starting at 2 instead of 1 ([zed-industries#33958](zed-industries#33958))
jonx
pushed a commit
to jonx/zed-aros
that referenced
this pull request
Jul 17, 2026
…ries#46273) Fixes zed-industries#33958 ## Problem PR zed-industries#44835 attempted to fix SHLVL starting at 2 by removing it from the `env` HashMap passed to alacritty. However, that HashMap is only an **overlay** — alacritty uses the parent process environment as a base and applies the overlay on top. Since alacritty never calls `env_remove("SHLVL")`, the terminal shell still inherits `SHLVL` from Zed's process environment. ## Root Cause The real issue is in `load_login_shell_environment()`: 1. `shell_env::capture()` spawns a login shell to capture environment variables 2. That login shell increments `SHLVL` (from 0→1 or n→n+1) 3. The captured env (including the incremented `SHLVL`) is written to Zed's **process environment** via `env::set_var` 4. When you open a terminal, the shell inherits Zed's `SHLVL` and increments it again → starts at 2 5. On reload, `shell_env::capture()` runs again with the already-elevated `SHLVL`, incrementing it further → +2 per reload ## Fix Skip `SHLVL` when setting Zed's process environment in `load_login_shell_environment()`. This prevents the login-shell capture from polluting Zed's env, so terminals start fresh with the correct `SHLVL`.
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
…ll level (zed-industries#44835) Fixes zed-industries#33958 ## Problem When opening a terminal in Zed, `SHLVL` incorrectly starts at 2 instead of 1. On `workspace: reload`, it increases by 2 instead of 1. ## Root Cause 1. Zed's `shell_env::capture()` spawns a login shell (`-l -i -c`) to capture the user's environment, which increments `SHLVL` 2. The captured `SHLVL` is passed through to the PTY options 3. When alacritty_terminal spawns the user's shell, it increments `SHLVL` again Result: `SHLVL` = captured value + 1 = 2 (when launched from Finder) ## Solution Remove `SHLVL` from the environment in `TerminalBuilder::new()` before passing it to alacritty_terminal. This allows the spawned shell to initialize `SHLVL` to 1 on its own, matching the behavior of standalone terminal emulators like iTerm2, Kitty, and Alacritty. ## Testing - Launch Zed from Finder → open terminal → `echo $SHLVL` → should output `1` - Launch Zed from shell → open terminal → `echo $SHLVL` → should output `1` - `workspace: reload` → open terminal → `echo $SHLVL` → should remain `1` - Tested with bash, zsh, fish Release Notes: - Fixed terminal `$SHLVL` starting at 2 instead of 1 ([zed-industries#33958](zed-industries#33958))
jolutz
pushed a commit
to jolutz/zed
that referenced
this pull request
Aug 8, 2026
…ries#46273) Fixes zed-industries#33958 ## Problem PR zed-industries#44835 attempted to fix SHLVL starting at 2 by removing it from the `env` HashMap passed to alacritty. However, that HashMap is only an **overlay** — alacritty uses the parent process environment as a base and applies the overlay on top. Since alacritty never calls `env_remove("SHLVL")`, the terminal shell still inherits `SHLVL` from Zed's process environment. ## Root Cause The real issue is in `load_login_shell_environment()`: 1. `shell_env::capture()` spawns a login shell to capture environment variables 2. That login shell increments `SHLVL` (from 0→1 or n→n+1) 3. The captured env (including the incremented `SHLVL`) is written to Zed's **process environment** via `env::set_var` 4. When you open a terminal, the shell inherits Zed's `SHLVL` and increments it again → starts at 2 5. On reload, `shell_env::capture()` runs again with the already-elevated `SHLVL`, incrementing it further → +2 per reload ## Fix Skip `SHLVL` when setting Zed's process environment in `load_login_shell_environment()`. This prevents the login-shell capture from polluting Zed's env, so terminals start fresh with the correct `SHLVL`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #33958
Problem
When opening a terminal in Zed,
SHLVLincorrectly starts at 2 instead of 1. Onworkspace: reload, it increases by 2 instead of 1.Root Cause
shell_env::capture()spawns a login shell (-l -i -c) to capture the user's environment, which incrementsSHLVLSHLVLis passed through to the PTY optionsSHLVLagainResult:
SHLVL= captured value + 1 = 2 (when launched from Finder)Solution
Remove
SHLVLfrom the environment inTerminalBuilder::new()before passing it to alacritty_terminal. This allows the spawned shell to initializeSHLVLto 1 on its own, matching the behavior of standalone terminal emulators like iTerm2, Kitty, and Alacritty.Testing
echo $SHLVL→ should output1echo $SHLVL→ should output1workspace: reload→ open terminal →echo $SHLVL→ should remain1Release Notes:
$SHLVLstarting at 2 instead of 1 (#33958)