SSH subshell Warpification hangs or breaks connection with fish shell on remote machine

[hussainweb]

Summary

SSH connection hangs or breaks when attempting to Warpify via the subshell workaround (command ssh added to subshell-compatible commands) with fish shell on both local and remote machines.

Problem

Warpify SSH (tmux-based) does not support fish on remote machines (tracked in #871). The documented workaround is to add command ssh to Settings > Warpify > Subshells > Added commands and use the subshell Warpification path instead. However, when using this workaround to SSH into an Ubuntu 26.04 machine running fish 4.x, the SSH connection itself hangs or breaks rather than successfully Warpifying.

Since the subshell feature explicitly supports fish 3.6+, this workaround should work but does not.

Expected behavior

After adding command ssh to subshell-compatible commands and running command ssh user@host, Warp should detect the fish subshell on the remote machine and successfully Warpify the session, providing Blocks, completions, and the input editor.

Actual behavior

The SSH connection hangs or breaks entirely. The session becomes unusable.

Reproduction steps

1. Ensure the local machine runs fish shell in Warp.
2. Go to Settings > Warpify > Subshells and add command ssh to "Added commands."
3. Run command ssh user@host to connect to a remote Ubuntu 26.04 machine running fish 4.x.
4. Observe that the connection hangs or breaks.

Artifacts

None attached.

Warp version

v0.2026.05.06.15.42.stable_03

Operating system

• Local: macOS 26.4.1 (build 25E253)
• Remote: Ubuntu 26.04, fish 4.x

Possible source references

• SSH - Support Fish for remote machines #871: existing open feature request for fish support in Warpify SSH (tmux-based). This bug affects the subshell workaround that is recommended as an alternative while SSH - Support Fish for remote machines #871 is unresolved.

[oz-for-oss]

@hussainweb

Here's what I found while triaging this issue:

• This looks distinct from SSH - Support Fish for remote machines #871 because it affects the documented command ssh subshell workaround, not only tmux-based SSH Warpification.
• I found related fish SSH-wrapper reports (SSH integration bombs out with fish remote #6233, SSH Warpify Failed #6859), but not two open exact duplicates for this specific workaround path.

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

1. Can you attach the exact redacted terminal output from WARP_DEBUG_MODE=1 command ssh user@host up to the hang or disconnect?
2. Does the remote machine's config.fish already include any Warp auto-Warpify snippet from the fish-over-SSH workaround in SSH - Support Fish for remote machines #871?

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 SSH subshell Warpification with command ssh appears to hang or break for fish remotes, likely in the remote fish subshell bootstrap path, but exact failing output is still needed..

Initial triage

This appears to be a distinct SSH Warpification bug in the subshell-workaround path for fish remotes. The report is related to the known fish-over-SSH gap in #871 and to earlier fish SSH wrapper failures such as #6233 and #6859, but the key difference here is that the documented command ssh subshell workaround is reported to hang or break instead of bypassing the tmux/SSH-wrapper path.

Reproducibility

Medium. The report includes a concrete workflow, Warp version, local shell/OS, and remote OS/shell, and the behavior is plausible from the current Warpification control flow. However, the actual failure mode is still underspecified: there is no terminal output, debug output, or indication of whether the session fails before login, after the remote prompt appears, or after accepting the subshell Warpification prompt.

Likely area

command ssh becomes eligible for subshell Warpification through AddedSubshellCommands matching in app/src/terminal/warpify/settings.rs. When the command starts, app/src/terminal/view.rs treats the long-running command as a subshell candidate and, on Warpification, writes app/assets/bundled/bootstrap/unknown_init_subshell.sh into the active PTY. If that detector reports fish, the client then writes the fish-specific bootstrap generated via app/src/terminal/bootstrap.rs from app/assets/bundled/bootstrap/fish_init_subshell.sh.

The most likely failure is in this remote fish bootstrap sequence or in interaction with an existing remote config.fish Warp auto-Warpify snippet. If the remote rc file emits SourcedRcFileForWarp without disabling tmux, app/src/terminal/view.rs can route an SSH block into continue_warpify_ssh_session, which would re-enter the tmux-oriented SSH Warpification path rather than staying on the pure subshell workaround.

Follow-up needed

The next useful evidence is exact redacted output from the failing command ssh session, preferably with Warp debug mode enabled, and whether the remote fish config already contains a manual Warpification snippet from the #871 workaround.

Question reasoning

1. Can you attach the exact redacted terminal output from WARP_DEBUG_MODE=1 command ssh user@host up to the hang or disconnect? — The output should show whether the failure occurs during SSH login, the unknown-shell detector, the fish-specific subshell bootstrap, or a timeout after bootstrap starts.
2. Does the remote machine's config.fish already include any Warp auto-Warpify snippet from the fish-over-SSH workaround in SSH - Support Fish for remote machines #871? — An existing SourcedRcFileForWarp snippet could cause Warp to route the SSH session into the tmux-oriented Warpification path instead of the intended command ssh subshell path.

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

Powered by Oz