Agent-driven zsh commands can block on spelling-correction prompts when correction is enabled

[bivo]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

When Warp Agent Mode runs commands in an interactive zsh session with spelling correction enabled, mistyped commands can trigger an interactive correction prompt like:

zsh: correct 'zef' to 'zed' [nyae]?

That prompt can block the agent flow and prevent the command from completing autonomously.

To reproduce

1. Enable zsh correction in your shell config.
   • Example: set ENABLE_CORRECTION="true" in .zshrc
2. Open Warp.
3. Start an agent task that runs a mistyped shell command in the live terminal session.
4. Have the agent execute something like:

zef file.md

Expected behavior

Agent-driven commands should not get stuck on zsh spelling-correction prompts.

The command should either:

• run as typed and fail normally, or
• be executed in a way that suppresses zsh correction only for agent-driven commands

Human-typed commands in the terminal should keep their normal shell behavior.

Screenshots, videos, and logs

Operating system (OS)

macOS

Operating system and version

26.5.2

Shell Version

5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.07.08.17.54.stable_02

Regression

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

Recent working Warp date

No response

Additional context

Why This Matters

This breaks autonomous agent workflows in otherwise normal zsh setups. Users who have shell correction enabled are likely to hit this during command execution, validation, or follow-up commands such as formatting and tests.

Notes

This appears to be a bug in how agent-driven commands are submitted into interactive zsh sessions, rather than a problem with Warp’s built-in command-correction UI.

A targeted fix would be to suppress zsh correction for agent-driven commands only, without changing behavior for human input.

I already have a candidate fix prepared and can open a PR once this issue is filed and labeled appropriately (ready-to-implement if maintainers agree).

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

[oz-for-oss]

@bivo

Here's what I found while triaging this issue:

This appears reproducible for zsh users with spelling correction enabled because Agent Mode submits visible commands through the interactive shell, where zsh can stop on its own correction prompt. A single recent exact-match issue #12592 exists; this triage does not mark it as a duplicate because no second matching existing issue was found.

Maintainer details

I concluded that agent Mode visible command execution can block in interactive zsh sessions when shell spelling correction prompts for a mistyped command..

Triage summary

This is a plausible Agent Mode / terminal-shell bug rather than a general Warp command-correction UI issue. The reporter's observed symptom is that an agent-requested visible command in an interactive zsh session can stop at zsh's own spelling-correction prompt, preventing autonomous command completion.

Reproducibility

Reproducibility looks high from the report: it includes macOS, zsh 5.9, Warp v0.2026.07.08.17.54.stable_02, screenshot evidence, and a minimal setup of zsh correction plus a mistyped command such as zef file.md.

Likely root cause

Current code supports the hypothesis that visible agent commands are executed through the normal interactive terminal path with AI metadata attached, rather than through an isolated non-interactive shell or a zsh wrapper that disables correction:

• app/src/ai/blocklist/action_model/execute/shell_command.rs emits ShellCommandExecutorEvent::ExecuteCommand for requested visible shell commands.
• app/src/terminal/view.rs handles that event by creating CommandExecutionSource::AI and emitting Event::ExecuteCommand; it special-cases PowerShell multiline commands, but not zsh correction.
• app/src/terminal/input.rs stores pending commands by inserting them into the terminal input buffer via set_pending_command.
• app/src/terminal/writeable_pty/pty_controller.rs starts the block with AI metadata and writes a normal PtyWrite::Command; bytes_to_execute_command uses kill-buffer bytes, optional bracketed paste, and the shell's execute bytes, with no zsh correction guard.
• app/assets/bundled/bootstrap/zsh_body.sh wraps in-band generator commands with warp_run_generator_command, but the reported visible Agent Mode command path does not appear to use that wrapper.

That means a zsh setup with CORRECT/oh-my-zsh ENABLE_CORRECTION="true" can still interpose its [nyae]? prompt before Warp sees ordinary command completion. Confidence is medium because the code path is clear, but I did not run a live GUI reproduction in this environment.

Duplicate check

I enumerated open issues and recently closed issues via the GitHub API. One recently closed exact-match issue was found (#12592), but no second likely duplicate candidate was found, so duplicate_of is left empty per the duplicate-detection workflow's two-candidate threshold.

Follow-up

No reporter follow-up is needed for initial triage; the report already includes the environment, visual evidence, and minimal reproduction path.

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

Powered by Oz