[Bug]: hardcoded timeouts for SSH environment lead to hard-to-recover-from "did not respond during connection setup" error. #32572

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. work with a SSH environment
2. the remote host is not the most powerful machine, codex started a couple of subagents scanning various folders
3. remote server took couple secs
   End result:
   T3 Code connection to xxx: T3 Code on xxx did not answer
   The host is fine, possibly slow.

Expected behavior

Ideally, I can configure the timeout per environment. Setting timeouts to 10 min would solve the issue with the particular slow host.

I don't need to see the output during the job, provided that: (1) the job gets done on the remote, and (2) the response arrives at some point for me to check.

Actual behavior

T3 Code connection to xxx: T3 Code on xxx did not answer

This device: not checked
T3 Code on xxx: FAILED

Cause: timeout
Attempts: 2
Route: Direct
App version: 0.1.7
Host version: 0.1.7
Error: xxx did not respond during connection setup.

Subsequent manual reconnects end the same way. To reconnect, remove the env, but without proper cleanup, it fails to re-add the env and gets stuck on "adding".

Impact

Major degradation or frequent failure

Version or commit

0.1.7

Environment

macOS 27.0.1 (26A434) -> debian stable, VM

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

The only functional workaround in T3 code seems to be removing and re-adding the environment, often paired with rm -rf ~/.t3 on the remote host.