SSH sessions spawn Warp-owned ControlMaster + agent-protocol channels even with Agent and "Warpify SSH" disabled, flooding channel N: open failed: administratively prohibited

[andreibadescu]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

When connecting to an SSH host through Warp, the session is continuously spammed with:
channel N: open failed: administratively prohibited: open failed
repeating indefinitely with climbing/resetting channel numbers.
Root cause from ps aux: Warp launches ssh as
ssh -o ControlMaster=yes -o ControlPath=~/.ssh/ -t ... export WARP_CLI_AGENT_PROTOCOL_VERSION='1' ... "external_control_master": false ...
Warp creates its own ControlMaster (external_control_master: false) and uses it to open agent-protocol channels. The remote has AllowAgentForwarding no, so every channel Warp opens is refused by sshd, producing the flood.
The problem: this happens even though:

Settings → Agents: agent features disabled
Settings → Warpify → "Warpify SSH Sessions": OFF
Settings → Warpify → "Reuse existing SSH ControlMaster": OFF (Warp still spawns its own master and ignores a user-configured one)

The WARP_CLI_AGENT_PROTOCOL_VERSION=1 injection and ControlMaster=yes fire regardless of these toggles. There appears to be no user-facing way to stop Warp from opening these channels.

To reproduce

Have an SSH host with AllowAgentForwarding no (and/or AllowTcpForwarding no).
Disable Agent features and "Warpify SSH Sessions" in Warp.
ssh from Warp.
Observe continuous channel N: open failed: administratively prohibited.

Expected behavior

With Warpify SSH and Agent disabled, Warp should not open agent-protocol channels, and/or should respect a server that refuses forwarding without retrying endlessly.

Screenshots, videos, and logs

Claude conversation:

The ps aux output showing the spawned ssh command. This is your strongest evidence: it proves ControlMaster=yes, external_control_master: false, and WARP_CLI_AGENT_PROTOCOL_VERSION='1' are injected regardless of your toggles. Paste it as a code block rather than a screenshot so it's searchable/copyable for the maintainer. You can trim the giant bootstrap blob; the diagnostic part is just:

ssh -o ControlMaster=yes -o ControlPath=~/.ssh/1687006307445662789 -t support
export TERM_PROGRAM='WarpTerminal'
export WARP_IS_SSH='1'
export WARP_CLIENT_VERSION='v0.2026.06.17.09.49.stable_02'
export WARP_CLI_AGENT_PROTOCOL_VERSION='1'
hook=... "external_control_master": false ...
[zsh/bash bootstrap truncated for brevity]
Add a line: "(bootstrap body truncated; the relevant flags are ControlMaster=yes, external_control_master: false, WARP_CLI_AGENT_PROTOCOL_VERSION=1)".

A screenshot of the terminal block showing the repeating channel N: open failed: administratively prohibited. The two you already captured are perfect, the first one is ideal because it shows the kubecolor wget succeeding (proving the connection works) immediately above the spam (proving it's cosmetic noise, not a broken session).
The two Warpify settings screenshots proving "Warpify SSH Sessions" is OFF and "Reuse existing ControlMaster" is OFF. These are what make the bug compelling: the toggles say off, the behavior says on.
Server-side confirmation, as a small code block:

$ grep AllowAgentForwarding /etc/ssh/sshd_config
AllowAgentForwarding no
plus the contrast test proving it's Warp-specific:

Clean, no spam:

ssh -o ControlMaster=no -o ControlPath=none oysta@support # silent

macOS Terminal.app: silent

Warp: floods channel-open failures

Operating system (OS)

macOS

Operating system and version

26.5.1 (25F80)

Shell Version

zsh 5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.06.17.09.49.stable_02

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

19th June 2026

Additional context

Only happens in warp

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

Ignore

[oz-for-oss]

@andreibadescu

Here's what I found while triaging this issue:

This appears to be the SSH wrapper / SSH extension path rather than Agent mode itself. Disabling Warpify SSH Sessions may not currently prevent Warp from creating a ControlMaster and attempting SSH-extension setup, which can be noisy on servers that reject extra multiplexed channels.

Maintainer details

I concluded that warp's SSH wrapper/remote-server path appears to keep creating a ControlMaster and opening multiplexed SSH-extension channels even when the visible Warpify SSH setting is off, which can flood sessions on servers that reject those extra channels..

Triage summary

This looks like an SSH wrapper / SSH extension gating bug rather than a general Agent-mode issue. The report is credible because it includes a Warp-only repro, a recent stable build, the local OS/shell, and a remote-host policy that can plausibly reject additional multiplexed SSH channels.

Observed behavior

• Interactive ssh <host> from Warp creates a ControlMaster-backed session and then repeatedly prints channel N: open failed: administratively prohibited: open failed.
• The reporter says the same host is quiet from another terminal and with ssh -o ControlMaster=no -o ControlPath=none.
• The report claims this still happens with Agent features and Warpify SSH Sessions disabled.

Code-supported findings

• app/src/settings/ssh.rs defines enable_ssh_wrapper separately from WarpifySettings::enable_ssh_warpification; the wrapper default is true.
• app/src/terminal/local_tty/terminal_manager.rs passes SshSettings::enable_ssh_wrapper into PTY startup, and app/src/terminal/local_tty/unix.rs exports WARP_USE_SSH_WRAPPER plus WARP_SSH_REUSE_CONTROL_MASTER.
• The bundled bootstrap scripts (app/assets/bundled/bootstrap/bash_body.sh, zsh_body.sh, and fish.sh) intercept interactive ssh, create a ControlMaster=yes / ControlPath=... command unless an external master is explicitly reused, emit the SSH hook, and forward WARP_CLI_AGENT_PROTOCOL_VERSION when present.
• app/src/settings_view/warpify_page.rs toggles WarpifySettings::enable_ssh_warpification and disables the SSH extension install-mode dropdown in the UI, but the remote-server controller path does not appear to gate on that setting.
• app/src/terminal/writeable_pty/remote_server_controller.rs responds to SSH-wrapper sessions by checking/installing/connecting the SSH extension over SshTransport, which uses the same ControlPath via crates/remote_server/src/ssh.rs. If the remote rejects extra multiplexed channels, those background checks/proxy attempts are a likely source of the repeated OpenSSH channel errors.
• WARP_CLI_AGENT_PROTOCOL_VERSION appears to be controlled by the HOA notifications feature flag in the local PTY environment, not by the user-facing Agent setting, so it should be treated as supporting evidence of bootstrap injection rather than proof that Agent mode is enabled.

Duplicate search

I checked all open non-PR issues plus recent closed SSH-related issues. There are older open reports with generic channel ... open failed: connect failed output (#1957, #2311, #4671, #6552) and a ControlMaster-related issue (#5242), but I did not find two likely duplicates with this combination of administratively prohibited, Warpify-disabled behavior, and the current SSH extension / ControlMaster path.

Suggested routing

Route to SSH/Warpify owners. The likely fix area is to make Warpify SSH Sessions (or a separate user-facing SSH extension setting) actually gate the wrapper/remote-server setup path, and to avoid retrying noisy SSH-extension channel attempts when the remote refuses them.

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

Powered by Oz

[andreibadescu]

This only happens in Warp

[zachbai]

@kevinyang372 is this related to the remove env extension?