#16630
Issues/warpdotdev/warp/#16630

macOS zsh commands are corrupted with ^[i^P after updating to v0.2026.10.21.08.25.stable_02

Openjohanhalebyopened 7d ago

Pre-submit Checks

Describe the bug

After Warp auto-updated to v0.2026.10.21.08.25.stable_02, submitting or editing commands intermittently inserts the literal sequence ^[i^P into the command line. Command text is also repeated and displaced across the terminal. This makes the terminal unreliable for normal use and for running scripts.

A complete quit with Command-Q and restart does not resolve it. Starting a login shell with exec zsh -l works around the corruption, but the resulting session behaves like a native zsh session and does not have the Warp editing experience I normally use.

To reproduce

  1. Start Warp v0.2026.10.21.08.25.stable_02 on macOS.
  2. Open a zsh tab.
  3. Change into a project directory and run ll. In my configuration, ll is an alias for lsd -la.
  4. Type another command, such as brew install lsd, then edit it with the Right Arrow key or submit it.
  5. Observe literal ^[i^P sequences and repeated command text in the terminal input.

The problem is intermittent, but it persists across new tabs and a complete Warp restart.

Expected behavior

Warp should submit the command exactly as typed. The Right Arrow key should move the cursor without inserting escape sequences or duplicating text.

Screenshots, videos, and logs

Example terminal output:

^[i^Pbrew install lsd
                     ^[i^Pbrew install lsd
                                          brew install lsd

Warp logs contain repeated Bootstrapping failed for shell zsh messages from the first launch of this build. I can provide the relevant logs if needed.

Operating system (OS)

macOS

Operating system and version

macOS 27.0.1 (26A434)

Shell Version

zsh 5.9 (arm64-apple-darwin26.0)

Current Warp version

v0.2026.10.21.08.25.stable_02

Regression

Yes, this bug started recently or with an X Warp version

Recent working Warp date

2026-10-22, using v0.2026.10.14.08.27.stable_02

Additional context

The same zsh startup configuration works correctly in a clean pseudo-terminal outside Warp. The zsh binding for Right Arrow is normal: ^[[C is bound to forward-char. ll resolves to the expected lsd -la alias.

The closest existing report I found is #6228, but that report is from 2025 and concerns Windows with PowerShell. This report is for the current stable Warp build on macOS with zsh. My shell configuration has not changed since September, and the previous Warp version worked yesterday.

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this an issue only in Warp?

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

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

None

Activity

3
warp-for-oss[bot]7d ago

@johanhaleby

Here's what I found while triaging this issue:

This looks like a recent Warp Stable regression in macOS zsh shell integration/input handling. The ^[i^P bytes match Warp-owned control keys that should normally be consumed by the shell integration, and the exec zsh -l workaround is useful evidence because it bypasses Warp's editing layer.

I have a few follow-up questions before I can narrow this down:

  1. Can you attach the relevant redacted Warp log lines around the repeated Bootstrapping failed for shell zsh messages from the affected launch?
  2. Can you attach a short screen recording showing the moment ^[i^P appears while editing or submitting a command?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that recent macOS zsh regression where Warp's shell-integration control bytes appear in the editable command line, corrupting terminal input after the 2026.10.21 stable update..

Triage summary

This is a high-priority macOS zsh terminal-input regression in the 2026.10.21 Stable build. The reporter provides a recent working build, exact current build, OS and shell versions, a concrete intermittent reproduction path, confirmation that the behavior is Warp-only, and a workaround using exec zsh -l.

Evidence

  • The literal ^[i^P sequence is significant: Warp's zsh integration binds ESC-i to input-buffer reporting and Ctrl-P to clearing/resetting the zsh line editor buffer. If those internal bindings are not installed or are disrupted, the internal control bytes can appear in the user's command line.
  • The report mentions repeated Bootstrapping failed for shell zsh log entries from the first launch of the affected build.
  • exec zsh -l works around the issue, which points away from native zsh input handling and toward Warp's bootstrap/shell-integration layer.
  • Duplicate search found related older zsh/bootstrap corruption reports (#8755, #4084, #1540), but fewer than two existing issues match this exact current Stable macOS zsh regression and trigger closely enough to mark as a duplicate.

Likely area

The most relevant area is zsh shell integration and terminal input handling, especially the zle bindings and bootstrap control-sequence flow in app/assets/bundled/bootstrap/zsh_body.sh, zsh session startup in app/assets/bundled/bootstrap/zsh.sh / zsh_init_shell.sh, and local shell startup in crates/warp_terminal/src/local_tty/shell.rs.

Remaining uncertainty

The report is actionable for escalation, but maintainers need the redacted zsh bootstrap failure logs and ideally a short recording to confirm whether the bindings are missing, being reset by startup files, or racing with a recent Warp change.

Question reasoning

  1. Can you attach the relevant redacted Warp log lines around the repeated Bootstrapping failed for shell zsh messages from the affected launch? — The logs should identify which zsh bootstrap step failed and materially improve confidence in whether this is a bootstrap failure, binding reset, or later input-handling regression.
  2. Can you attach a short screen recording showing the moment ^[i^P appears while editing or submitting a command? — The symptom is intermittent and input-sequence-sensitive, so a recording can confirm the exact trigger and whether the bytes appear after Right Arrow, submit, or another Warp action.

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

Powered by Oz

johanhaleby7d ago

Thanks for checking this.

I found six Bootstrapping failed for shell "zsh" on ssh false warnings at exactly 2026-10-23T08:21:09Z. Each one is immediately followed by Showing bootstrap slow toast. These are the relevant redacted lines:

2026-10-23T08:21:09Z [WARN] Bootstrapping failed for shell "zsh" on ssh false
2026-10-23T08:21:09Z [WARN] Showing bootstrap slow toast
2026-10-23T08:21:09Z [WARN] Bootstrapping failed for shell "zsh" on ssh false
2026-10-23T08:21:09Z [WARN] Showing bootstrap slow toast
2026-10-23T08:21:09Z [WARN] Bootstrapping failed for shell "zsh" on ssh false
2026-10-23T08:21:09Z [WARN] Showing bootstrap slow toast
2026-10-23T08:21:09Z [WARN] Bootstrapping failed for shell "zsh" on ssh false
2026-10-23T08:21:09Z [WARN] Showing bootstrap slow toast
2026-10-23T08:21:09Z [WARN] Bootstrapping failed for shell "zsh" on ssh false
2026-10-23T08:21:09Z [WARN] Showing bootstrap slow toast
2026-10-23T08:21:09Z [WARN] Bootstrapping failed for shell "zsh" on ssh false
2026-10-23T08:21:09Z [WARN] Showing bootstrap slow toast

I don't have a screen recording from when the corruption occurred. The problem is intermittent, and I can't currently reproduce it on demand. I'll add a recording if it happens again.

warp-for-oss[bot]7d ago

@johanhaleby

Here's what I found while triaging this issue:

The ^[i^P bytes line up with Warp's zsh input-reporting and buffer-clear keybindings, so this looks related to Warp shell integration/bootstrapping rather than zsh's normal Right Arrow binding. The exec zsh -l workaround bypassing Warp's editing experience is consistent with that.

I have a few follow-up questions before I can narrow this down:

  1. Can you attach the full redacted Warp log segment from app startup through the first corrupted command, including the lines before and after the bootstrap warnings?
  2. Does this zsh profile use any prompt framework or custom zle-line-init, precmd, preexec, or bindkey setup beyond the normal Right Arrow binding you already checked?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that recent macOS zsh regression where Warp shell-integration input-reporting and buffer-clear control bytes appear to leak into the command line after bootstrap warnings..

Triage summary

This looks like a high-priority macOS zsh regression in the terminal input / shell-integration path. The reporter observed literal ^[i^P text, repeated/displaced command text, and repeated Bootstrapping failed for shell "zsh" on ssh false warnings after updating to v0.2026.10.21.08.25.stable_02; the previous stable build reportedly worked the day before.

Evidence

  • Repro is plausible but intermittent: the report includes version, OS, shell version, concrete commands, a sample corrupted command line, and a workaround, but the reporter cannot currently reproduce on demand.
  • exec zsh -l avoids the corruption while also bypassing Warp's normal editing experience, which points toward Warp shell integration / bootstrapping rather than a generic zsh right-arrow binding.
  • Code inspection shows zsh uses ESC-i for input-buffer reporting and ^P for Warp's kill-buffer/reset binding before writing commands. The observed literal bytes match that protocol closely.

Likely area

The most relevant code paths are zsh bootstrap/ZLE bindings, input reporting/typeahead handling, and PTY command write sequencing:

  • app/assets/bundled/bootstrap/zsh_body.sh binds ESC-i to warp_report_input and ^P to warp_kill_buffer_and_reset_insert_mode.
  • crates/warp_terminal/src/shell/mod.rs defines the input-reporting and kill-buffer bytes for zsh.
  • app/src/terminal/writeable_pty/pty_controller.rs queues input-reporting when the line editor becomes active and prefixes commands with the shell kill-buffer bytes.
  • app/src/terminal/line_editor_status.rs gates when queued PTY writes can run based on zsh precmd/end-prompt events.
  • app/src/terminal/model/early_output.rs handles shell-reported typeahead.
  • app/src/terminal/view.rs emits the slow-bootstrap warning seen in the logs.

Duplicate check

I enumerated open issues and checked close candidates including #13189, #5137, #4084, #8755, #4835, and #14484, plus recent closed issues. Those are adjacent terminal/bootstrap/input reports but do not match this issue's current macOS zsh ESC-i + ^P command-corruption pattern closely enough, and there are not two likely duplicate candidates.

Remaining uncertainty

The main blocker is confirming why this user's zsh session sometimes treats Warp's expected ZLE protocol bytes as literal input. Full surrounding logs and details about prompt/ZLE/bindkey customizations would materially improve confidence.

Question reasoning

  1. Can you attach the full redacted Warp log segment from app startup through the first corrupted command, including the lines before and after the bootstrap warnings? — The current excerpt confirms repeated slow-bootstrap warnings, but the surrounding events are needed to tell whether bootstrap completed, whether line-editor activation fired, or whether another shell-integration error occurred before the bytes leaked.
  2. Does this zsh profile use any prompt framework or custom zle-line-init, precmd, preexec, or bindkey setup beyond the normal Right Arrow binding you already checked? — Warp's zsh input reporting and buffer clearing depend on ZLE widgets/bindkeys; reporter-specific prompt or keymap hooks are not externally inferable and could explain why ESC-i/^P were echoed literally.

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

Powered by Oz