On the macOS host, VS Code fails to open a terminal on startup with:
Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 1, signal null)
macOS GUI apps don't inherit a shell environment, so VS Code resolves it at
startup by spawning an interactive login shell to harvest env vars. That
probe runs with stdout piped and no controlling terminal.
The order-200 auto-tmux block in home/shell.nix treated the probe as a normal
interactive shell and ran exec tmux new-session -A -s main. Without a tty,
tmux exits with open terminal failed: not a terminal (non-zero), so VS Code
reports the error above. Linux/WSL is unaffected because VS Code Remote inherits
its environment and skips the probe.
Fix
Add two guards to the tmux exec:
[[ -t 1 ]] — only exec when stdout is a real terminal (the probe's stdout is
a pipe, so it is skipped).
[[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]] — skip VS Code's env-resolution
probe explicitly, covering the case where a future version hands it a pty.
Real terminals still land in tmux; the integrated terminal was already exempt
via the existing TERM_PROGRAM != vscode check.
Verification
Reproduced the probe locally: piped, no-tty interactive login zsh printed open terminal failed: not a terminal and swallowed the env output.
Confirmed [[ -t 1 ]] is false in that probe and true in a real terminal.
## Problem
On the macOS host, VS Code fails to open a terminal on startup with:
> Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 1, signal null)
macOS GUI apps don't inherit a shell environment, so VS Code resolves it at
startup by spawning an **interactive login shell** to harvest env vars. That
probe runs with stdout piped and **no controlling terminal**.
The order-200 auto-tmux block in `home/shell.nix` treated the probe as a normal
interactive shell and ran `exec tmux new-session -A -s main`. Without a tty,
tmux exits with `open terminal failed: not a terminal` (non-zero), so VS Code
reports the error above. Linux/WSL is unaffected because VS Code Remote inherits
its environment and skips the probe.
## Fix
Add two guards to the tmux exec:
- `[[ -t 1 ]]` — only exec when stdout is a real terminal (the probe's stdout is
a pipe, so it is skipped).
- `[[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]]` — skip VS Code's env-resolution
probe explicitly, covering the case where a future version hands it a pty.
Real terminals still land in tmux; the integrated terminal was already exempt
via the existing `TERM_PROGRAM != vscode` check.
## Verification
- Reproduced the probe locally: piped, no-tty interactive login zsh printed
`open terminal failed: not a terminal` and swallowed the env output.
- Confirmed `[[ -t 1 ]]` is false in that probe and true in a real terminal.
- `nix fmt` clean; `darwinConfigurations.lyrathorpe-mac` evaluates.
VS Code on macOS resolves the shell environment at startup by running an
interactive login shell with stdout piped and no controlling terminal.
The order-200 auto-tmux block treated that probe as a normal interactive
shell and ran `exec tmux new-session`, which fails without a tty ("open
terminal failed: not a terminal") and exits non-zero. VS Code then reports
"Unable to resolve your shell environment: Unexpected exit code from
spawned shell (code 1)".
Gate the exec on a real terminal (-t 1) and skip it when
VSCODE_RESOLVING_ENVIRONMENT is set. Real terminals still land in tmux;
the integrated terminal was already exempt via TERM_PROGRAM.
lyrathorpe
scheduled this pull request to auto merge when all checks succeed 2026-07-14 16:44:36 +01:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
On the macOS host, VS Code fails to open a terminal on startup with:
macOS GUI apps don't inherit a shell environment, so VS Code resolves it at
startup by spawning an interactive login shell to harvest env vars. That
probe runs with stdout piped and no controlling terminal.
The order-200 auto-tmux block in
home/shell.nixtreated the probe as a normalinteractive shell and ran
exec tmux new-session -A -s main. Without a tty,tmux exits with
open terminal failed: not a terminal(non-zero), so VS Codereports the error above. Linux/WSL is unaffected because VS Code Remote inherits
its environment and skips the probe.
Fix
Add two guards to the tmux exec:
[[ -t 1 ]]— only exec when stdout is a real terminal (the probe's stdout isa pipe, so it is skipped).
[[ -z "$VSCODE_RESOLVING_ENVIRONMENT" ]]— skip VS Code's env-resolutionprobe explicitly, covering the case where a future version hands it a pty.
Real terminals still land in tmux; the integrated terminal was already exempt
via the existing
TERM_PROGRAM != vscodecheck.Verification
open terminal failed: not a terminaland swallowed the env output.[[ -t 1 ]]is false in that probe and true in a real terminal.nix fmtclean;darwinConfigurations.lyrathorpe-macevaluates.VS Code on macOS resolves the shell environment at startup by running an interactive login shell with stdout piped and no controlling terminal. The order-200 auto-tmux block treated that probe as a normal interactive shell and ran `exec tmux new-session`, which fails without a tty ("open terminal failed: not a terminal") and exits non-zero. VS Code then reports "Unable to resolve your shell environment: Unexpected exit code from spawned shell (code 1)". Gate the exec on a real terminal (-t 1) and skip it when VSCODE_RESOLVING_ENVIRONMENT is set. Real terminals still land in tmux; the integrated terminal was already exempt via TERM_PROGRAM.