Description

Fixes #13408 (one verified failure mode in the #6244 family).

The SSH wrapper's zsh_env_script (written to a temp $ZDOTDIR/.zshenv on the remote host) intends to start the remote zsh with minimal startup, and let the bootstrap body re-source rc files itself — zsh_body.sh explicitly re-sources /etc/zprofile → .zprofile → /etc/zshrc → .zshrc → /etc/zlogin → .zlogin with timing brackets once it's injected.

But unset RCS; unset GLOBAL_RCS removes shell variables named RCS/GLOBAL_RCS — it does not touch the zsh options, so rc sourcing stays fully enabled:

% T=$(mktemp -d)
% echo 'unset RCS; unset GLOBAL_RCS' > $T/.zshenv
% ZDOTDIR=$T zsh -i -c 'echo rcs=$options[rcs] globalrcs=$options[globalrcs]'
rcs=on globalrcs=on        # ← options untouched; a $ZDOTDIR/.zshrc still gets sourced

Consequences on every wrapper-warpified remote zsh session:

• Global rc files execute twice — once bare before Warp's InitShell handshake, then again when the body re-sources them. (e.g. sshing into a macOS host runs path_helper twice, reshuffling PATH.)
• Anything slow, interactive, or output-producing in global rc runs before the handshake, where it can consume or garble the injected bootstrap — the failure family tracked in .bashrc addition to automatically warpify a SSH shell prints out bash code #6244.

Fix: fold RCS/GLOBAL_RCS into the existing unsetopt. The same payload string is duplicated in the bash and fish SSH wrappers; all three copies updated identically.

Scope note: this fixes the verified pre-handshake rc-suppression defect in the legacy SSH wrapper. It does not address the separate app-side issue where a failed warpification unhides the long-running block with the echoed bootstrap left in place — I have a live repro of that and will file details on #6244 for a follow-up.

Linked Issue

Closes #13408

Related to #6244 (this fixes one concrete, verified failure mode in that family — not the whole issue, so it deliberately does not close it).

• The linked issue is labeled ready-to-spec or ready-to-implement. (SSH wrapper's remote zsh env script fails to disable rc sourcing (unset vs unsetopt) #13408 is newly filed and awaiting maintainer triage; will comment /oz-review once labeled.)
• Where appropriate, screenshots or a short video of the implementation are included below (especially for user-visible or UI changes).

Testing

• zsh -n app/assets/bundled/bootstrap/zsh_body.sh

• bash -n app/assets/bundled/bootstrap/bash_body.sh

• Behavioral red/green (local zsh 5.9): with unset RCS; unset GLOBAL_RCS in a $ZDOTDIR/.zshenv, an interactive zsh reports rcs=on globalrcs=on and a planted $ZDOTDIR/.zshrc is sourced; with the new payload prefix unsetopt ZLE RCS GLOBAL_RCS, it reports rcs=off globalrcs=off and the planted rc is not sourced.

• End-to-end against a live SSH host (Ubuntu 24.04, zsh 5.9), exercising the wrapper's exact delivery mechanism — payload prefix written to a temp $ZDOTDIR/.zshenv, then an interactive zsh started against it — with a marker echo planted in the remote /etc/zsh/zshrc:

  ════ BEFORE (current payload prefix: unset = no-op) ════
  [OLD] GLOBAL-ZSHRC occurrences before handshake = 1
  [OLD]   WARP_ENV_RAN
  [OLD]   [GLOBAL-ZSHRC] executed 23:29:00.694   ← global rc ran pre-handshake
  [OLD]   SHELL_UP
  
  ════ AFTER (this PR's payload prefix) ════
  [NEW] GLOBAL-ZSHRC occurrences before handshake = 0
  [NEW]   WARP_ENV_RAN                            ← env script itself still runs
  [NEW]   SHELL_UP                                ← shell still comes up normally
  

• I have manually tested my changes locally with ./script/run (dev build used to drive the SSH sessions used for the investigation).

Screenshots / Videos

The behavior change is in a non-UI remote bootstrap payload; the terminal-text evidence above captures it end-to-end. One caveat surfaced during testing: on my test host the interactive ssh flow engages the newer remote-server extension rather than the legacy wrapper, so the payload-level test above exercises the changed path directly instead of going through the full GUI flow.

Agent Mode

• Warp Agent Mode - This PR was created via Warp's AI Agent Mode