SSH integration takes over `ssh` shell aliases, silently breaking wrapper tools like trzsz

Open

I use trzsz (github.com/trzsz/trzsz) to get rz/sz-style file transfer over SSH, with alias ssh="trzsz -d ssh" in my ~/.bashrc so it applies to every session. In other terminals this just works. In Warp, typing ssh user@host gets intercepted by the SSH integration: Warp spawns /usr/bin/ssh directly with its own flags (ControlMaster, remote-server-proxy, etc.), so the alias never runs and the wrapper is silently out of the picture.

The visible symptom: dragging a file into the terminal during an SSH session should upload it to the remote host (what trzsz -d does). Instead the file's local path gets pasted as plain text.

To reproduce

Add alias ssh="trzsz -d ssh" to ~/.bashrc (trzsz is a standard wrapper around ssh, works in gnome-terminal, kitty, etc.)
Open a new Warp tab, verify with type ssh that the alias is active
Run ssh user@host
Drag any local file into the window
The absolute path of the file is typed into the prompt instead of triggering an upload

Expected behavior

The SSH integration should not silently discard the user's shell environment. Two outcomes would both be fine:

Warp detects the wrapper and stays out of the way (runs the aliased command as-is, without the SSH session takeover), or
the integration works on top of the wrapper.

Right now there is no indication that the alias was bypassed at all — type ssh says the alias exists, but the process that ends up running is Warp's own /usr/bin/ssh invocation.

Screenshots, videos, and logs

Process list while connected (host redacted):

ssh -o ControlMaster=yes -o ControlPath=~/.ssh/9370937070338089112 -t user@host \
  export TERM_PROGRAM='WarpTerminal' export WARP_IS_SSH='1' \
  ... hook=$(printf "{\"hook\": \"SSH\", ...
ssh -q ... placeholder@placeholder ~/.warp/remote-server/oz-v0.2026.09.16.08.27.stable_02 \
  remote-server-proxy --identity-key ...

No trzsz process anywhere. The wrapper was never started.

Additional context

Workaround: run trzsz -d ssh user@host directly — since the command doesn't start with ssh, Warp doesn't intercept it and everything works. But that defeats the point of having the alias, and it's easy to forget until you wonder why drag-and-drop pasted a path.

Possibly related: #6195 (drag & drop SSH upload), #1179 / #988 (rz/sz support). Those ask for native zmodem; this report is narrower — the integration silently breaks existing wrapper-based setups that work in every other terminal.

Activity

warp-for-oss[bot]7d ago

@CuriousTank

Here's what I found while triaging this issue:

This looks like a Warp SSH integration bug: the report shows the SSH takeover path bypassing an ssh alias/wrapper, so trzsz -d ssh never starts. The direct trzsz -d ssh user@host workaround is consistent with the current behavior while this is investigated.

Maintainer details

I concluded that warp's SSH integration appears to bypass an aliased ssh wrapper, so tools like trzsz -d ssh never start and drag-and-drop upload falls back to plain path insertion..

Triage summary

This looks like an SSH integration bug rather than a native zmodem feature request. The reporter's observed behavior is that an ssh alias wrapping OpenSSH with trzsz -d is active in the shell, but when they run ssh user@host, Warp's SSH integration starts its own ControlMaster/remote-server SSH flow and no trzsz process appears. The visible user impact is that drag-and-drop during the remote session pastes the local path instead of invoking the wrapper's upload behavior.

Evidence

The report includes a minimal repro: define alias ssh="trzsz -d ssh", verify type ssh, run ssh user@host, then drag a file into the session.
The process list shows Warp-managed ssh -o ControlMaster=yes -o ControlPath=... and remote-server-proxy processes, with no trzsz wrapper process.
Running trzsz -d ssh user@host directly works because the command no longer starts with plain ssh, so Warp does not take over the session.

Likely implementation area

Warp's shell bootstrap installs an ssh function for local sessions and the helper invokes command ssh with Warp's ControlMaster/ControlPath and remote bootstrap. The Rust side also parses interactive SSH commands for warpification and the remote-server transport launches ssh directly over the ControlMaster. These paths are likely bypassing a user-provided ssh alias/wrapper once Warp decides to handle the session.

Duplicate check

I found related open requests for SSH drag-and-drop upload (#6195, #6804) and rz/sz/zmodem support (#1179, #1205, #1502), plus a separate SSH-wrapper request (#2100). Those are related but do not match this narrower alias/wrapper-bypass behavior closely enough to mark this as a duplicate under the repository's duplicate policy.

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

Powered by Oz

CuriousTank7d ago

Follow-up with more data points after digging further, in case it helps triage.

1. The takeover also depends on shell rcfile layout — worth knowing for repro.

Warp's bash bootstrap (per the comments embedded in the warp binary: "we use the --rcfile option so no startup files are evaluated ... it runs ~/.bashrc") starts bash with a custom rcfile, then sources /etc/profile → ~/.bash_profile (or ~/.bash_login/~/.profile). It never reads ~/.bashrc directly.

On Ubuntu, an interactive non-login shell reads ~/.bashrc, and a login shell reads ~/.bash_profile. If the user has a ~/.bash_profile that doesn't source ~/.bashrc (which is my case — mine only sets up pyenv), aliases defined in ~/.bashrc simply don't exist inside Warp, while they work fine in gnome-terminal/kitty. So on my machine the alias never had a chance to interfere until I added the standard .bashrc re-source snippet to .bash_profile.

2. With the alias actually active, typing ssh no longer triggers warpification at all.

After the rcfile fix, alias ssh="trzsz -d ssh" is live in Warp, and now ssh user@host connects without the SSH integration — no ControlMaster, no remote-server-proxy, no WARP_IS_SSH. Running \ssh user@host (bypassing the alias) brings warpification back.

So the interception happens late enough that an alias-expanded wrapper hides the command from the SSH detection entirely. That makes the two features mutually exclusive in practice:

alias active → warpification never triggers, drag-and-drop upload works (trzsz handles it)
alias absent → warpification takes over, trzsz is bypassed, drag-and-drop pastes a local path

3. Where this leaves users.

The workaround set is workable but fiddly:

rename the alias (alias tssh="trzsz -d ssh") so plain ssh still gets warpified and tssh is reserved for file-transfer sessions, or
drop the alias and type trzsz -d ssh user@host manually when uploading.

Either way, the original problem stands: the SSH integration silently wins over user shell config, and there's no detection or warning for wrapper tools in between.