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
- Install Warp terminal on macOS with zsh
- Add
eval "$(iris init zsh)" to ~/.zshrc
- 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)
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
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:
Seems like your shell is taking a while to start...of being executed. The heredoc
read -r -d '' WARP_BOOTSTRAP_VAR << 'EOM'never finishes reading.
then>repeated), so the inputstream was torn mid-parse.
.zshrcnever finishes sourcing and the prompt falls back to baredefault zsh.
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:
Broken:
LOCAL= BOOT=Working:
LOCAL=1 BOOT=1Root 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 unavailablereads like a filesystem-permissionsproblem, so that is where people will look first. It is actually a
consequence: without the
Bootstrappedhook, Warp never setsWARP_IS_LOCAL_SHELL_SESSION=1and falls back to treating the sessionas remote. The error points nowhere near
.zshrc.Workaround
This covers local sessions and remote hosts entered through Warp's ssh
wrapper, since the wrapper propagates
TERM_PROGRAMto the remote machine.Suggestion
Either emit this guard from
iris inititself, or add a compatibilitynote to the README. Warp maintains a list of incompatible
Steps to reproduce
eval "$(iris init zsh)"to~/.zshrcWhat was the expected result?
Shell bootstrap completes normally (
LOCAL=1 BOOT=1),.zshrcsources tothe end, and IRIS either works or stays out of the way without breaking
the session.
Put here any screenshots or videos (optional)
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:
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)
Would you like to work on this issue?
No response