Warpify on non-warp terminal caused verbose log

[syscl]

Subject area or topic

doc

Page or pages affected

The warpify command will run unconditionally on every terminal in the system

Last login: Sun May 31 01:02:11 on ttys005
$f{"hook": "SourcedRcFileForWarp", "value": { "shell": "zsh"}}?% 

The proper fix is to just run this command when the terminal is WarpTerminal

What is incorrect, outdated, missing, or unclear?

Check the log above

Suggested update

No response

[warp-for-oss]

@syscl

Here's what I found while triaging this issue:

The current auto-Warpify docs can cause Warp’s marker text to appear in other terminals if the snippet is copied into a shared shell rc file. A docs update should guard the snippet so it only runs inside Warp, or clearly warn users to do so.

Maintainer details

I concluded that the docs' auto-Warpify instructions can cause Warp's shell marker to be printed in non-Warp terminals when copied into a shared rc file..

Triage summary

This is a documentation bug in the auto-Warpify guidance. The reported visible output matches the zsh SourcedRcFileForWarp marker shown in the docs, and the current bash/zsh examples are unconditional when pasted into shared rc files.

Reproducibility

High. The issue should reproduce when a user adds the documented zsh or bash auto-Warpify snippet to an rc file that is also loaded by a non-Warp terminal.

Likely root cause

src/content/docs/terminal/warpify/subshells.mdx documents the auto-Warpify bash/zsh snippets as bare printf commands. Those commands emit a Warp-specific DCS sequence intended for Warp to consume, but the docs do not guard them behind a Warp-terminal check such as TERM_PROGRAM=WarpTerminal or otherwise warn users that shared rc files will affect other terminals.

Suggested resolution

Update the auto-Warpify snippets to run only when the shell is inside Warp, and add a short note explaining that users who share rc files across terminals should guard the snippet to avoid visible escape-sequence text elsewhere.

Duplicate check

I found no open non-PR issues and no recently closed issues in warpdotdev/docs that match this report.

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

Powered by Oz

[dannyneira]

closing as this is being tracked here: #162