[Bug]: SSH environment tunnel fails with ControlMaster auto / ControlPersist

[Pratham-commits-code]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

1. 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

2. Ensure a master connection / control socket already exists for that host.

3. Ask T3 Code Desktop to connect to that SSH environment.

4. 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

[juliusmarminge]

Implementation is ready without opening a PR: branch codex/issue-3533-ssh-controlmaster at commit d2de12535.

The supervised ssh -N -L process now explicitly disables ControlMaster, ControlPath, and ControlPersist while leaving other SSH flows unchanged. Verification passed all 26 @t3tools/ssh tests, package typecheck, and targeted lint/format/diff checks. Deterministic lifecycle coverage proves the overrides apply only to the supervised tunnel, disconnect reaps it, and reconnect spawns a fresh tunnel. A supplementary ssh -G fixture was blocked by approval-review infrastructure, so no live recording is claimed. No PR has been opened.