packages/ssh
sh is dash (for example, Ubuntu/Debian).fnm installed and available to the remote non-interactive shell.The SSH environment setup should work with the remote shell selected by the command, or fail with a clear compatibility diagnostic.
Environment setup fails with:
| 1 | Could not prepare the SSH environment: Error invoking remote method 'desktop:ensure-ssh-environment': SshCommandError: sh: 1: eval: --: not found |
| 2 | sh: 16: eval: Syntax error: "(" unexpected |
The remote account may have Bash as its login shell; the failure still occurs because the desktop SSH runner explicitly invokes:
| 1 | ssh ... sh -l -s -- ... |
packages/ssh/src/tunnel.ts sends the generated launch and pairing scripts through sh. The generated node-environment script contains Bash-specific fnm activation:
| 1 | eval "$(fnm env --shell bash)" |
When sh resolves to dash, the Bash-shaped output is evaluated by a POSIX shell. This produces the reported eval: --: not found and Syntax error: "(" unexpected messages.
Relevant code:
Keep the remote script contract internally consistent:
fnm activation path POSIX-shell-safe before evaluating it, orPlease preserve support for remote hosts that provide only a POSIX shell.
sh: dashdesktop:ensure-ssh-environmentRelated but distinct: #11001, #4761, and #11733.
I encountered this on a Windows machine while adding an SSH connection to a remote Linux machine through the T3 Code desktop client. The remote account uses Bash as its login shell,
my agent wrote this issue, idk why example of dash was chosen, most prolly the code is only written for bash / linux specific shell commands, needs a diff one for powershell.
The desktop launch really does force POSIX sh on the remote, but the stderr in this report is not coming from eval "$(fnm env --shell bash)" inside ensure_remote_node_path.
launchOrReuseRemoteServer in packages/ssh/src/tunnel.ts runs:
| 1 | remoteCommandArgs: ["sh", "-l", "-s", "--", remoteStateKey(target)] |
On Ubuntu/Debian that sh is dash, even when the account’s login shell is Bash. -l sources the login profile before the bootstrap script runs.
These two lines are dash’s eval diagnostic for a script whose first line is -- and whose line 16 uses Bash function name() syntax:
| 1 | sh: 1: eval: --: not found |
| 2 | sh: 16: eval: Syntax error: "(" unexpected |
A syntax error in eval exits dash (status 2) even with || true. That is enough to fail desktop:ensure-ssh-environment.
REMOTE_NODE_ENV_SCRIPT does contain:
| 1 | eval "$(fnm env --shell bash)" >/dev/null 2>&1 || true |
That came from #2641: fnm has no sh shell, and --use-on-cd emits Bash [[ ]], so the remote script asks for Bash syntax and then tries to ignore failure. Two facts keep it from being this report:
archiveVersion (apps/desktop/src/main.ts). The archive launch and REMOTE_RUNNER_SCRIPT do not call ensure_remote_node_path. That function runs only for the dev node-script runner.eval discards stderr. On dash, the same syntax error under >/dev/null 2>&1 is hidden, and the shell still exits. The messages here were visible, so they came from an eval that is not redirected — login startup, not this line.fnm 1.39 fnm env --shell bash (with and without --use-on-cd) is POSIX export lines plus functions dash can define. Evaluating it under dash succeeds. The stock installer block (eval "\fnm env`"in~/.bashrc`) also survives dash. So a current fnm env script is not this 16-line body.
| Issue | Why it is different |
|---|---|
| #11001 | Same ensure-SSH wrapper and sh -l -s, but the hang is bash -ilc stopped by SIGTTOU |
| #4761 / #7213 | #7213 added this login sh so per-user PATH loads. That -l is what now executes the profile under dash |
| #3709 / #3710 | Version-manager gates when a non-satisfying node is already on PATH |
| #11733 | Worktree setup color queries |
Please run these from the client and paste both stderr outputs:
| 1 | ssh user@host 'sh -c true' |
| 2 | ssh user@host 'sh -l -c true' |
If only the login command fails, this is Bash syntax in the login profile (or a file it sources), not the silenced fnm line. Please also paste any eval / fnm / starship block from ~/.profile, ~/.bashrc, and /etc/profile.
The bootstrap script should stay POSIX so a dash-only host still works. The login shell used to load PATH should not be forced to dash when the profile is Bash. Changing only fnm env --shell bash will not fix a release-client failure with this stderr. fnm env --json is still a reasonable follow-up for the dev node-script runner, separate from this report.
Follow-up from the affected Windows client and remote Linux host. I ran the requested checks with the host and username omitted:
| 1 | ssh <user>@<host> 'sh -c "printf SH_OK"' |
| 2 | exit 0 |
| 3 | stdout: SH_OK |
| 4 | |
| 5 | ssh <user>@<host> 'sh -l -c "printf LOGIN_OK"' |
| 6 | exit 2 |
| 7 | stderr: |
| 8 | <starship path omitted> sh: 1: eval: --: not found |
| 9 | sh: 16: eval: Syntax error: "(" unexpected |
This reproduces the failure only when the remote login shell is invoked with -l. The client machine is Windows; the remote machine is Linux.
| 1 | ssh <user>@<host> 'sh -c true' |
| 2 | # No output; succeeded |
| 3 | |
| 4 | ssh <user>@<host> 'sh -l -c true' |
| 5 | /usr/local/bin/starship |
| 6 | sh: 1: eval: --: not found |
| 7 | sh: 16: eval: Syntax error: "(" unexpected |
| 8 | |
| 9 | Relevant login-profile lines: |
| 10 | |
| 11 | .bashrc:34: [ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)" |
| 12 | .bashrc:80: test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval "$(dircolors -b)" |
| 13 | .bashrc:123: # Starship |
| 14 | .bashrc:124: eval "$(starship init bash)" |
| 15 | .bashrc:126: eval "$(zoxide init bash)" |