Skip to content

iris init zsh breaks shell startup in Warp terminal (raw-mode TTY conflict) #100

Description

@vptsar

Describe your issue

With IRIS enabled, Warp terminal's shell bootstrap never completes and the
session ends up in a broken state. Everything works normally in iTerm2,
Ghostty and VS Code's terminal.

What happens:

  • Banner appears: Seems like your shell is taking a while to start...
  • Warp's initialization block is printed to the terminal literally instead
    of being executed. The heredoc read -r -d '' WARP_BOOTSTRAP_VAR << 'EOM'
    never finishes reading.
  • zsh drops into a continuation prompt (then> repeated), so the input
    stream was torn mid-parse.
  • .zshrc never finishes sourcing and the prompt falls back to bare
    default zsh.
  • Sidebar error: Project explorer unavailable. The Project Explorer requires access to your local workspace, which isn't supported in remote sessions.

Quick check inside a Warp session:

echo "LOCAL=$WARP_IS_LOCAL_SHELL_SESSION BOOT=$WARP_BOOTSTRAPPED"

Broken: LOCAL= BOOT=
Working: LOCAL=1 BOOT=1

Root cause

Warp injects its bootstrap into the shell's stdin wrapped in DCS/OSC
sequences. IRIS puts the TTY into raw mode and handles keys directly.
Both compete for the same TTY and the bootstrap stream gets corrupted.
Terminals that don't inject anything into stdin are unaffected, which is
why IRIS behaves fine everywhere else.

Note on the misleading symptom

Project explorer unavailable reads like a filesystem-permissions
problem, so that is where people will look first. It is actually a
consequence: without the Bootstrapped hook, Warp never sets
WARP_IS_LOCAL_SHELL_SESSION=1 and falls back to treating the session
as remote. The error points nowhere near .zshrc.

Workaround

if [[ "$TERM_PROGRAM" != "WarpTerminal" ]]; then
  eval "$(iris init zsh)"
fi

This covers local sessions and remote hosts entered through Warp's ssh
wrapper, since the wrapper propagates TERM_PROGRAM to the remote machine.

Suggestion

Either emit this guard from iris init itself, or add a compatibility
note to the README. Warp maintains a list of incompatible

Steps to reproduce

  1. Install Warp terminal on macOS with zsh
  2. Add eval "$(iris init zsh)" to ~/.zshrc
  3. Quit Warp fully (Cmd+Q, not just closing the window) and reopen it

What was the expected result?

Shell bootstrap completes normally (LOCAL=1 BOOT=1), .zshrc sources to
the end, and IRIS either works or stays out of the way without breaking
the session.

Put here any screenshots or videos (optional)

Image Image
Warp initialization block leaking into the terminal (trimmed)

Warp's bootstrap is normally consumed silently. With IRIS enabled it gets
echoed as literal text and the parse breaks. Excerpts:

hostname%  setopt interactivecomments
 read -r -d '' WARP_BOOTSTRAP_VAR << 'EOM'; eval "$WARP_BOOTSTRAP_VAR"
...
hostname% then> then> %
hostname% "''"%

The then> continuation prompts show the heredoc was cut mid-parse.
The bare % prompt shows .zshrc never finished sourcing.
Full block omitted, it is Warp's proprietary shell integration script.

Your OS and Browser (optional)

  • OS: macOS (Apple Silicon) 15.7.7
  • Shell: zsh + oh-my-zsh, zsh 5.9 (arm64-apple-darwin24.0)
  • Terminal: Warp (latest)
  • IRIS: v0.4.14

Would you like to work on this issue?

No response

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions