Before submitting
Area
apps/desktop
Steps to reproduce
-
Configure an SSH host entry that uses OpenSSH connection multiplexing:
Host <ssh-alias>
HostName <host>
User <user>
IdentityFile ~/.ssh/<key>
IdentitiesOnly yes
AddKeysToAgent yes
ConnectTimeout 5
ConnectionAttempts 2
ServerAliveInterval 15
ServerAliveCountMax 2
ControlMaster auto
ControlPath ~/.ssh/cm-%C
ControlPersist 10m
-
Ensure a master connection / control socket already exists for that host.
-
Ask T3 Code Desktop to connect to that SSH environment.
-
T3 Code launches the remote server successfully, then the supervised local tunnel process exits 0 and the app surfaces a failure.
Manual validation of the underlying behavior:
# With ControlMaster auto in the host config:
ssh -o BatchMode=yes -o ConnectTimeout=10 -p 22 \
-o ExitOnForwardFailure=yes \
-o ServerAliveInterval=15 \
-o ServerAliveCountMax=3 \
-n -N -L 52620:127.0.0.1:3773 <user>@<ssh-alias>
# Returns immediately with exit code 0 in the failing setup.
After disabling multiplexing for the alias (ControlMaster no, ControlPath none, ControlPersist no), the same tunnel command stays alive and curl -I http://127.0.0.1:<local-port>/ returns HTTP/1.1 200 OK.
Expected behavior
T3 Code should support common SSH config variants that use multiplexing — or force the supervised tunnel command to opt out of it. Possible fixes:
- Add
-o ControlMaster=no -o ControlPath=none to the supervised ssh -N -L tunnel command so the process lifetime reflects the tunnel lifetime.
- Alternatively, if multiplexing is allowed, treat
exitCode: 0 plus localPortListening: true as a possibly-successful delegated tunnel rather than an immediate failure.
- Provide a clearer diagnostic when the SSH child exits
0 under a ControlMaster auto config.
Actual behavior
With ControlMaster auto, OpenSSH delegates the local forward to the existing master connection and the supervised child process exits successfully (0). T3 Code treats that exit as a tunnel failure, even though the forwarded port is actually listening, and connecting fails.
Impact
Major degradation or frequent failure (SSH environments with multiplexing configs cannot connect; a workaround exists).
Version or commit
T3 Code Alpha 0.0.27; remote package launched by T3 t3@0.0.27.
Environment
- Local OS: macOS, OpenSSH_10.2p1
- Remote OS: macOS, OpenSSH_10.0
- T3 Code Alpha 0.0.27 / remote
t3@0.0.27
Logs or stack traces
Error invoking remote method 'desktop:ensure-ssh-environment': SshCommandError: SSH tunnel exited unexpectedly for <ssh-alias> (exit 0).
ssh.tunnel.process.exited
exitCode: 0
stderr: ""
localPort: 52609
remotePort: 3773
httpBaseUrl: http://127.0.0.1:52609/
# Readiness then failed despite:
processRunning: false
localPortListening: true
# Final error:
SshCommandError: SSH tunnel exited unexpectedly for <ssh-alias> (exit 0).
Workaround
Disable SSH multiplexing for the affected alias:
Host <ssh-alias>
ControlMaster no
ControlPath none
ControlPersist no
Before submitting
Area
apps/desktop
Steps to reproduce
Configure an SSH host entry that uses OpenSSH connection multiplexing:
Ensure a master connection / control socket already exists for that host.
Ask T3 Code Desktop to connect to that SSH environment.
T3 Code launches the remote server successfully, then the supervised local tunnel process exits
0and the app surfaces a failure.Manual validation of the underlying behavior:
After disabling multiplexing for the alias (
ControlMaster no,ControlPath none,ControlPersist no), the same tunnel command stays alive andcurl -I http://127.0.0.1:<local-port>/returnsHTTP/1.1 200 OK.Expected behavior
T3 Code should support common SSH config variants that use multiplexing — or force the supervised tunnel command to opt out of it. Possible fixes:
-o ControlMaster=no -o ControlPath=noneto the supervisedssh -N -Ltunnel command so the process lifetime reflects the tunnel lifetime.exitCode: 0pluslocalPortListening: trueas a possibly-successful delegated tunnel rather than an immediate failure.0under aControlMaster autoconfig.Actual behavior
With
ControlMaster auto, OpenSSH delegates the local forward to the existing master connection and the supervised child process exits successfully (0). T3 Code treats that exit as a tunnel failure, even though the forwarded port is actually listening, and connecting fails.Impact
Major degradation or frequent failure (SSH environments with multiplexing configs cannot connect; a workaround exists).
Version or commit
T3 Code Alpha
0.0.27; remote package launched by T3t3@0.0.27.Environment
t3@0.0.27Logs or stack traces
Workaround
Disable SSH multiplexing for the affected alias: