.zshrc overwritten by Warp without warning

[LennyHirsch]

Dupe Check

• I have searched Warp bugs and there are no duplicates

Describe the bug

Set up Warp to use zsh, and upon reloading the terminal found that none of my aliases were working. I checked my .zshrc, and it turns out Warp has completely overwritten it without warning me or backing up to a .zshrc.bak file.

What the hell guys?!

To reproduce

1. Install Warp via pacman.
2. Set up to use zsh from settings menu.
3. Get your config overwritten.

Expected behavior

Warp to use my .zshrc and not overwrite it without backing it up or warning me first.

Screenshots

No response

Operating system

Linux

Operating system and version

Arch 6.9.1

Shell Version

zsh 5.9

Current Warp version

No response

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)

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

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

None

[lucieleblanc]

Hi there, I'm really sorry to hear this – it's incredibly frustrating. Warp definitely shouldn't be overwriting your config files, and this is the first case we’ve heard of this happening.

To help us figure out what happened:

• What are the contents of the new .zshrc file? Is there anything left over from your old .zshrc file in it?
• What is the path to your .zshrc file?

[LennyHirsch]

Yes, I have to say I was pretty shocked when I found out what had happened; I was using kitty before, and had no issues with this, and I'm not using any other terminals so I can't imagine the changes were caused by anything else; Warp was the only "new thing" added to the equation.

As far as I can remember, all I did was boot up Warp for the first time, and set it up to use my existing .zshrc. I did that by following the Onboarding prompts when Warp is first opened. Everything worked at first, and then I restarted Warp to reload the terminal. Then my aliases didn't work anymore. I tried setting zsh as the default shell through the settings menu, but that didn't change anything, and I tried running chsh $which(zsh) and that did nothing either. At that point I restarted my kitty instance, found my aliases weren't working there either, and then found that my .zshrc had been overwritten.

I am wondering if the fact I was using Starship has something to do with this, as I believe Starship causes some issues with Warp; the new .zshrc includes a good bit of code for setting up Starship, but I didn't expect the whole config to be overwritten; nothing was left of my old config.

Here is the new .zshrc file:

# ZSH has a quirk where `preexec` is only run if a command is actually run (i.e
# pressing ENTER at an empty command line will not cause preexec to fire). This
# can cause timing issues, as a user who presses "ENTER" without running a command
# will see the time to the start of the last command, which may be very large.

# To fix this, we create STARSHIP_START_TIME upon preexec() firing, and destroy it
# after drawing the prompt. This ensures that the timing for one command is only
# ever drawn once (for the prompt immediately after it is run).

zmodload zsh/parameter  # Needed to access jobstates variable for STARSHIP_JOBS_COUNT

# Defines a function `__starship_get_time` that sets the time since epoch in millis in STARSHIP_CAPTURED_TIME.
if [[ $ZSH_VERSION == ([1-4]*) ]]; then
    # ZSH <= 5; Does not have a built-in variable so we will rely on Starship's inbuilt time function.
    __starship_get_time() {
        STARSHIP_CAPTURED_TIME=$(/usr/local/bin/starship time)
    }
else
    zmodload zsh/datetime
    zmodload zsh/mathfunc
    __starship_get_time() {
        (( STARSHIP_CAPTURED_TIME = int(rint(EPOCHREALTIME * 1000)) ))
    }
fi

# The two functions below follow the naming convention `prompt_<theme>_<hook>`
# for compatibility with Zsh's prompt system. See
# https://github.com/zsh-users/zsh/blob/2876c25a28b8052d6683027998cc118fc9b50157/Functions/Prompts/promptinit#L155

# Runs before each new command line.
prompt_starship_precmd() {
    # Save the status, because subsequent commands in this function will change $?
    STARSHIP_CMD_STATUS=$? STARSHIP_PIPE_STATUS=(${pipestatus[@]})

    # Calculate duration if a command was executed
    if (( ${+STARSHIP_START_TIME} )); then
        __starship_get_time && (( STARSHIP_DURATION = STARSHIP_CAPTURED_TIME - STARSHIP_START_TIME ))
        unset STARSHIP_START_TIME
    # Drop status and duration otherwise
    else
        unset STARSHIP_DURATION STARSHIP_CMD_STATUS STARSHIP_PIPE_STATUS
    fi

    # Use length of jobstates array as number of jobs. Expansion fails inside
    # quotes so we set it here and then use the value later on.
    STARSHIP_JOBS_COUNT=${#jobstates}
}

# Runs after the user submits the command line, but before it is executed and
# only if there's an actual command to run
prompt_starship_preexec() {
    __starship_get_time && STARSHIP_START_TIME=$STARSHIP_CAPTURED_TIME
}

# Add hook functions
autoload -Uz add-zsh-hook
add-zsh-hook precmd prompt_starship_precmd
add-zsh-hook preexec prompt_starship_preexec

# Set up a function to redraw the prompt if the user switches vi modes
starship_zle-keymap-select() {
    zle reset-prompt
}

## Check for existing keymap-select widget.
# zle-keymap-select is a special widget so it'll be "user:fnName" or nothing. Let's get fnName only.
__starship_preserved_zle_keymap_select=${widgets[zle-keymap-select]#user:}
if [[ -z $__starship_preserved_zle_keymap_select ]]; then
    zle -N zle-keymap-select starship_zle-keymap-select;
else
    # Define a wrapper fn to call the original widget fn and then Starship's.
    starship_zle-keymap-select-wrapped() {
        $__starship_preserved_zle_keymap_select "$@";
        starship_zle-keymap-select "$@";
    }
    zle -N zle-keymap-select starship_zle-keymap-select-wrapped;
fi

export STARSHIP_SHELL="zsh"

# Set up the session key that will be used to store logs
STARSHIP_SESSION_KEY="$RANDOM$RANDOM$RANDOM$RANDOM$RANDOM"; # Random generates a number b/w 0 - 32767
STARSHIP_SESSION_KEY="${STARSHIP_SESSION_KEY}0000000000000000" # Pad it to 16+ chars.
export STARSHIP_SESSION_KEY=${STARSHIP_SESSION_KEY:0:16}; # Trim to 16-digits if excess.

VIRTUAL_ENV_DISABLE_PROMPT=1

setopt promptsubst

PROMPT='$('/usr/local/bin/starship' prompt --terminal-width="$COLUMNS" --keymap="${KEYMAP:-}" --status="$STARSHIP_CMD_STATUS" --pipestatus="${STARSHIP_PIPE_STATUS[*]}" --cmd-duration="${STARSHIP_DURATION:-}" --jobs="$STARSHIP_JOBS_COUNT")'
RPROMPT='$('/usr/local/bin/starship' prompt --right --terminal-width="$COLUMNS" --keymap="${KEYMAP:-}" --status="$STARSHIP_CMD_STATUS" --pipestatus="${STARSHIP_PIPE_STATUS[*]}" --cmd-duration="${STARSHIP_DURATION:-}" --jobs="$STARSHIP_JOBS_COUNT")'
PROMPT2="$(/usr/local/bin/starship prompt --continuation)"

The .zshrc was in my home directory, at ~/.zshrc.

edit:

seems like the new .zshrc matches this, so it does look like the issue is Starship. Not sure what caused this to trigger upon running Warp though. Seems like the overwrite might've been caused by Starship, but what is odd is that this hasn't happened before; I had been running it in kitty for a good while with no issues. So perhaps something in Warp triggered this init script from Starship?

[lucieleblanc]

Interesting -- I'm not sure how Warp would have performed this replacement, since the Warp bootstrap scripts don't directly interact with prompt customization tools.

From a cursory search through Starship's repo, I don't see any open issues about overwriting configs on their side either. Is there anything zsh- or Starship-related in your .zsh_history?

[warp-factories]

We need a bit more information before we can continue triaging this issue.

If you're still hitting this, could you try reproducing it on the latest version of Warp and share logs along with a screenshot or short video if possible?

If there's no activity after 3 business days, we'll close this out to help keep the tracker tidy.

---

This is part of an automated backlog review and may be inaccurate. If you believe this assessment is wrong, please let us know.

[github-actions]

This issue has been automatically closed because it was labeled needs-info and received no response for 3 business days. If you have the requested information, please reply and we will reopen.