SSH session hangs when remote CLI tool (e.g. gh auth login) attempts to open a browser

[brujack]

Describe the bug

When SSH'd into a remote machine from a Warp terminal session, running a CLI tool that triggers browser-based authentication (e.g. gh auth login, gcloud auth login) causes the terminal session to hang indefinitely. The tool attempts to open a browser on the remote machine
rather than passing the auth URL back to the local machine where a browser is available. The terminal never recovers and the only recourse is to
force-close the session from within Warp.

To reproduce

1. Open a Warp terminal on your local machine.
2. SSH into a remote machine: ssh user@remote-host
3. Run a CLI tool that requires browser-based OAuth, e.g.: gh auth login
4. The tool attempts to open a browser on the remote machine (where no browser/display is available).
5. The terminal session hangs — keyboard input including Ctrl+C is unresponsive.
6. The only way to recover is to hard-close the terminal session within Warp.

Expected behavior

The terminal session should remain responsive. Ideally Warp would detect that the process is attempting to open a browser on a remote host and
either:

• Surface the auth URL in the local terminal so the user can open it manually, or
• Forward the browser open request to the local machine.

At minimum, Ctrl+C and other interrupt signals should remain functional so the user can abort the hanging process without closing the entire
session.

Additional context

This is reproducible with any CLI tool that calls xdg-open, open, or equivalent to launch a browser for OAuth flows (e.g. gh auth login, gcloud auth login, az login). The hang appears to be related to the remote process blocking on a browser that never opens,
combined with Warp not propagating interrupt signals through the SSH connection in a way that unblocks the process.

Other terminals (e.g. iTerm2, Terminal.app) exhibit the same browser-launch failure on the remote side, but Ctrl+C reliably interrupts the
process and returns the prompt — the hard-hang requiring a force-close appears to be Warp-specific.

Operating system

macOS

Does this block you from using Warp daily?

Yes — any SSH workflow that involves remote auth (CI tokens, cloud CLI setup, GitHub CLI) requires switching to another terminal or
pre-authenticating before the SSH session.

Is this an issue only in Warp?

Partially — the browser-launch failure is inherent to SSH (no display on remote), but the unrecoverable hang requiring a force-close is specific
to Warp. Other terminals allow Ctrl+C to abort the process.

[oz-for-oss]

@brujack

You can view the triage session on Warp.

Here's what I found while triaging this issue:

The remote browser launch is expected for a plain SSH session without display/browser forwarding; the Warp-specific bug to investigate is that Ctrl+C/input does not interrupt the remote foreground process.

I have a few follow-up questions before I can narrow this down:

1. What Warp version/channel were you using when this happened?
2. Was the SSH session Warpified (tmux/SSH Warpification enabled), or was it a plain SSH session?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that OAuth browser-login CLIs run inside an SSH session reportedly leave Warp unable to interrupt the remote foreground process with Ctrl+C..

Initial triage

This appears to be a bug in SSH terminal input/interrupt handling rather than a Warp authentication issue. The remote OAuth browser launch itself is expected for a plain SSH session without display/browser forwarding, but Warp should still keep the terminal responsive and send Ctrl+C to the remote foreground process.

Evidence from the report

• Repro path: start an SSH session from Warp on macOS, then run an OAuth CLI such as gh auth login, gcloud auth login, or az login on the remote host.
• Actual behavior: the CLI attempts to open a browser on the remote machine and the Warp terminal becomes unrecoverable; Ctrl+C and other keyboard input reportedly do not respond.
• Comparison: other terminals still fail to open the browser remotely, but Ctrl+C returns control to the prompt.

Reproducibility

Estimated medium. The report has clear steps and multiple example CLIs, but the exact Warp version/channel and SSH mode are missing. Those details determine whether input is routed through plain/legacy SSH, tmux SSH Warpification, or remote-server-related code paths.

Likely code area

• Ctrl+C binding and dispatch: app/src/terminal/view/init.rs, app/src/terminal/view.rs
• PTY write forwarding: app/src/terminal/writeable_pty/pty_controller.rs, app/src/terminal/writeable_pty/terminal_manager_util.rs
• SSH detection/session handling: app/src/terminal/ssh/util.rs, app/src/terminal/ssh/ssh_detection.rs
• SSH Warpification state: app/src/terminal/warpify/trigger_state.rs
• Local PTY setup on Unix/macOS: app/src/terminal/local_tty/unix.rs

Root-cause hypothesis

Warp normally routes Ctrl+C to an active long-running block by emitting ETX bytes to the PTY. If this SSH session is in a state where the active block is not considered user-controllable/long-running, or if an SSH warpification/remote-server state intercepts or prevents input, Ctrl+C may not reach the remote foreground process. Confidence is low until the reporter confirms the Warp build and SSH mode.

Follow-up needed

Two details would materially improve routing and repro confidence:

1. What Warp version/channel was running when this occurred?
2. Was the SSH session Warpified (tmux/SSH Warpification enabled), or was it a plain SSH session?

Question reasoning

1. What Warp version/channel were you using when this happened? — The report gives macOS as the platform but not the Warp build, which is needed to determine whether this matches current SSH/input behavior or a recently changed path.
2. Was the SSH session Warpified (tmux/SSH Warpification enabled), or was it a plain SSH session? — Plain/legacy SSH and tmux Warpification use different session and input-routing paths, and the report does not identify which one was active.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz