feat: make brev exec fast with SSH multiplexing

[theFong]

Summary

• Fire-first approach: brev exec now runs SSH immediately with a 5s connect timeout instead of making API calls to check instance status first. If SSH succeeds (especially via multiplexed connection), returns instantly with zero API overhead.
• SSH multiplexing: Added ControlMaster auto / ControlPath / ControlPersist 10m to all SSH config templates. First connection ~3s, subsequent connections ~0.6s (5x speedup).
• Graceful fallback: If SSH fails, checks instance status and either starts a stopped instance, waits for a booting instance, or gives a helpful error pointing to brev ls.
• Clean output: Suppressed noisy SSH messages (Agent pid, PTY warnings, known hosts warnings).

What changed

Before

Every brev exec call would:

1. API call to look up workspace by name/ID
2. Check if stopped → start it if so
3. Poll API every 5s until status is RUNNING (up to 10 min)
4. Run brev refresh to sync SSH config
5. Another API call to re-verify status is RUNNING
6. Poll SSH connection up to 40 times waiting for it to be available
7. Finally run the SSH command

Even if the instance was already running and SSH was ready, every single exec paid the cost of multiple API round-trips before doing anything.

After

1. Immediately fire SSH with a 5-second connect timeout
2. If it works → done (zero API calls)
3. If it fails → then check instance status and fall back to the old start/poll/wait behavior

With SSH multiplexing enabled, the first connection to an instance takes ~3s (normal SSH handshake). Every subsequent brev exec within 10 minutes reuses the master connection and completes in ~0.6s.

SSH multiplexing

Added to all three SSH config templates (ssh.go, sshconfigurer.go V2 and V3):

ControlMaster auto
ControlPath ~/.ssh/brev-control-%r@%h:%p
ControlPersist 10m

• ControlMaster auto — reuse an existing master connection if available, otherwise create one
• ControlPath — socket file stored per user/host/port combo
• ControlPersist 10m — master stays alive 10 minutes after last session disconnects

Suppressed noisy output

• eval $(ssh-agent -s) > /dev/null — hides "Agent pid 12345"
• ssh -T — disables PTY allocation, hides "Pseudo-terminal will not be allocated because stdin is not a terminal"
• -o LogLevel=ERROR — hides "Warning: Permanently added '1.2.3.4' (ED25519) to the list of known hosts"

Benchmark

WITHOUT multiplexing:  ~3.0s every call
WITH multiplexing:     ~3.0s first call, ~0.6s subsequent calls

Test plan

• brev exec <running-instance> "echo ok" — should succeed immediately
• Run it twice in a row — second call should be noticeably faster
• brev exec <stopped-instance> "echo ok" — should fail fast (5s), then start instance and retry
• brev exec <nonexistent-instance> "echo ok" — should fail with helpful message
• Verify no "Agent pid", "Pseudo-terminal", or "Permanently added" messages in output

[patelspratik]

3. Goroutine leak / silent failure in trackExecAnalytics

go trackExecAnalytics(sstore, workspaceNameOrID)

trackExecAnalytics makes API calls (GetUserWorkspaceByNameOrIDErr, GetCurrentUser, TrackEvent). If these block or panic, the goroutine will leak or crash silently. The
function also silently swallows all errors.

Suggestion: Consider adding a timeout context or recover() in the goroutine. The silent error swallowing is acceptable for analytics, but a panic would take down the
process.

[patelspratik]

4. ControlPath with colon may cause issues on some systems

ControlPath ~/.ssh/brev-control-%r@%h:%p

The : between %h and %p can cause issues on filesystems that don't support colons in filenames (e.g., SMB mounts, some macOS edge cases). While ~/.ssh is almost always on
a local filesystem, this is a common gotcha.

Suggestion: Use - instead of : as separator: ~/.ssh/brev-control-%r@%h-%p

[patelspratik]

not sure if this new ssh-agent behavior is on purpose, but thought I would put it here just in case

---

6. New ssh-agent spawned on every exec

cmd := fmt.Sprintf("eval $(ssh-agent -s) > /dev/null && ssh -T ...")

Every brev exec call spawns a new ssh-agent process. With the multiplexing optimization encouraging frequent rapid calls, this could lead to many orphaned ssh-agent
processes. The agent is started but never killed.

Suggestion: Check if SSH_AUTH_SOCK is already set before spawning a new agent, or use ssh-agent only when needed.