set -a 在 Warp 的 zsh 中会导致命令被重复拼接（例如输入 pwd 实际执行为 pwdpwd）

[stat0s2p]

Summary

在 Warp 的 zsh 会话中，执行 set -a 后继续输入普通命令会发生命令字符串重复拼接，导致实际执行内容异常。

Problem

该问题仅在 Warp 中可复现。用户在 iTerm2（包括 iTerm2 中启动 zsh）按同样步骤不会出现异常。
触发后即使输入简单命令（如 pwd），Warp 实际执行的内容会变成重复字符串（如 pwdpwd），影响基本终端可用性。

Expected behavior

执行 set -a 后，后续命令应按原样执行；输入 pwd 应只执行 pwd 一次。

Actual behavior

执行 set -a 后，后续命令出现重复拼接；输入 pwd 时实际执行为 pwdpwd（或等价的重复输入行为）。

Reproduction steps or desired workflow

1. 在 Warp 中打开 zsh 会话。
2. 执行 set -a。
3. 输入并执行 pwd（或其他简单命令）。
4. 观察 Warp 执行的命令被重复拼接（例如 pwdpwd）。
5. 在 iTerm2（或 iTerm2 中启动 zsh）重复以上步骤，不会出现该问题。

Artifacts

None attached

Warp version

v0.2026.05.20.09.21.stable_02

Operating system

macOS 26.5 (build 25F71)

[oz-for-oss]

@stat0s2p

Here's what I found while triaging this issue:

This appears tied to Warp's zsh input handling while allexport remains enabled. As a temporary workaround, run set +a or unsetopt allexport immediately after the environment-variable assignments that need auto-exporting.

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

1. Could you attach a short screen recording showing the input box before pressing Enter and the resulting executed block after set -a?
2. What does zsh --version report in the same Warp session where this reproduces?

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 warp zsh sessions on macOS may duplicate the next command after set -a, likely through zsh shell-integration input-buffer/typeahead sync interacting with allexport..

Triage summary

This is a Warp-specific zsh input bug report: after enabling zsh allexport with set -a, the next command can be duplicated so pwd is executed as pwdpwd. The report includes clear minimal steps, Warp Stable version v0.2026.05.20.09.21.stable_02, macOS 26.5, and a comparison showing iTerm2 does not reproduce the same behavior.

Reproducibility

Medium. The steps are short and plausible, but there is no recording/log and the exact zsh version is not included. The behavior may depend on zsh/ZLE option handling or the reporter's prompt/input setup.

Likely area and cause

This should route to terminal input plus shell integration. The likely path is Warp's zsh input-buffer/typeahead synchronization: the client requests the shell line editor buffer when zsh becomes active, the zsh bootstrap widget reports $BUFFER and clears it, and the client imports non-empty reported buffers as typeahead. Because parts of the zsh bootstrap run under the user's current shell options, leaving allexport enabled with set -a may interfere with Warp's internal zsh variables or buffer-clearing path, producing stale/doubled input.

Relevant files for maintainers:

• app/assets/bundled/bootstrap/zsh_body.sh
• app/src/terminal/writeable_pty/pty_controller.rs
• crates/warp_terminal/src/shell/mod.rs
• app/src/terminal/model/early_output.rs
• app/src/terminal/line_editor_status.rs

Duplicate check

I checked all open issues and recently closed issues for exact and broad matches involving set -a, allexport, pwdpwd, zsh input duplication, and repeated command text. I did not find enough matching issues to mark this as a duplicate.

Follow-up needed

A short recording and zsh version would help confirm whether the doubled text is introduced in the Warp input editor before Enter, by zsh's line editor/typeahead bridge, or only in the executed block/history.

Question reasoning

1. Could you attach a short screen recording showing the input box before pressing Enter and the resulting executed block after set -a? — The recording would distinguish whether Warp's UI input buffer is already doubled before submission or whether duplication appears only after shell execution.
2. What does zsh --version report in the same Warp session where this reproduces? — The suspected path depends on zsh/ZLE input-buffer behavior, so the exact zsh version materially improves repro and owner confidence.

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

Powered by Oz

[stat0s2p]

@stat0s2p

Here's what I found while triaging this issue:

This appears tied to Warp's zsh input handling while allexport remains enabled. As a temporary workaround, run set +a or unsetopt allexport immediately after the environment-variable assignments that need auto-exporting.

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

1. Could you attach a short screen recording showing the input box before pressing Enter and the resulting executed block after set -a?
2. What does zsh --version report in the same Warp session where this reproduces?

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 warp zsh sessions on macOS may duplicate the next command after set -a, likely through zsh shell-integration input-buffer/typeahead sync interacting with allexport..

Triage summary

This is a Warp-specific zsh input bug report: after enabling zsh allexport with set -a, the next command can be duplicated so pwd is executed as pwdpwd. The report includes clear minimal steps, Warp Stable version v0.2026.05.20.09.21.stable_02, macOS 26.5, and a comparison showing iTerm2 does not reproduce the same behavior.

Reproducibility

Medium. The steps are short and plausible, but there is no recording/log and the exact zsh version is not included. The behavior may depend on zsh/ZLE option handling or the reporter's prompt/input setup.

Likely area and cause

This should route to terminal input plus shell integration. The likely path is Warp's zsh input-buffer/typeahead synchronization: the client requests the shell line editor buffer when zsh becomes active, the zsh bootstrap widget reports $BUFFER and clears it, and the client imports non-empty reported buffers as typeahead. Because parts of the zsh bootstrap run under the user's current shell options, leaving allexport enabled with set -a may interfere with Warp's internal zsh variables or buffer-clearing path, producing stale/doubled input.

Relevant files for maintainers:

• app/assets/bundled/bootstrap/zsh_body.sh
• app/src/terminal/writeable_pty/pty_controller.rs
• crates/warp_terminal/src/shell/mod.rs
• app/src/terminal/model/early_output.rs
• app/src/terminal/line_editor_status.rs

Duplicate check

I checked all open issues and recently closed issues for exact and broad matches involving set -a, allexport, pwdpwd, zsh input duplication, and repeated command text. I did not find enough matching issues to mark this as a duplicate.

Follow-up needed

A short recording and zsh version would help confirm whether the doubled text is introduced in the Warp input editor before Enter, by zsh's line editor/typeahead bridge, or only in the executed block/history.

Question reasoning

1. Could you attach a short screen recording showing the input box before pressing Enter and the resulting executed block after set -a? — The recording would distinguish whether Warp's UI input buffer is already doubled before submission or whether duplication appears only after shell execution.
2. What does zsh --version report in the same Warp session where this reproduces? — The suspected path depends on zsh/ZLE input-buffer behavior, so the exact zsh version materially improves repro and owner confidence.

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

Powered by Oz

[oz-for-oss]

@stat0s2p

Here's what I found while triaging this issue:

As a temporary workaround, run set +a or unsetopt allexport after the environment-variable assignments that need auto-exporting. That should avoid leaving zsh allexport enabled while Warp's zsh input hooks continue running.

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

1. Could you attach a short screen recording showing the input box before pressing Enter and the resulting executed block after running set -a?
2. What does zsh --version report in the same Warp session where this reproduces?

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 warp-specific zsh bug where leaving set -a/allexport enabled can cause subsequent command text to be duplicated, likely through zsh input-buffer reporting/typeahead sync..

Triage summary

This is a Warp-specific zsh terminal-input bug report. After set -a enables zsh allexport, the reporter says a later simple command such as pwd is submitted/executed as duplicated text such as pwdpwd; the same sequence does not reproduce in iTerm2.

Reproducibility

Medium. The report includes concise steps, Warp version v0.2026.05.20.09.21.stable_02, macOS 26.5, and a non-Warp terminal comparison, but it does not include the zsh version or a recording that distinguishes whether the duplication is visible in the input editor before Enter or only in the executed block/history.

Likely area and cause

This should route to area:terminal-input and area:shell-terminal. The most likely implementation path is zsh shell integration input-buffer/typeahead synchronization: app/assets/bundled/bootstrap/zsh_body.sh binds ESC-i to warp_report_input, which sends $BUFFER through an InputBuffer hook and then clears BUFFER; app/src/terminal/writeable_pty/pty_controller.rs sends that input-reporting sequence when app/src/terminal/line_editor_status.rs marks the zsh line editor active; app/src/terminal/model/early_output.rs stores non-empty reported buffers as shell-reported typeahead; and app/src/terminal/view.rs inserts that typeahead into Warp's input editor. Leaving zsh allexport enabled with set -a may be interfering with this shell-side widget/hook path, but that remains a code-supported hypothesis rather than a confirmed root cause.

Duplicate check

I searched all open issues and recently closed issues for set -a, allexport, pwdpwd, zsh input-buffer/typeahead, and duplicated/repeated command text. I found one broad older open issue about duplicated command block text (#4664), but it is bash-based, lacks the set -a/zsh trigger, and is not enough to meet the duplicate threshold, so I am not marking this as a duplicate.

Follow-up needed

A short recording and the exact zsh version would materially improve confidence by showing whether the text is doubled before submission, during Warp's typeahead sync, or only after shell execution.

Question reasoning

1. Could you attach a short screen recording showing the input box before pressing Enter and the resulting executed block after running set -a? — A recording would distinguish whether the command text is already doubled in Warp's input editor before submission or whether duplication appears only after zsh/Warp execution handling.
2. What does zsh --version report in the same Warp session where this reproduces? — The suspected path depends on zsh/ZLE input-buffer behavior, and the exact zsh version is not provided in the report.

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

Powered by Oz

[stat0s2p]

@oz-agent
zsh版本zsh 5.9 (arm64-apple-darwin25.0)
关于屏幕录制，是否是说我要把操作过程录制成gif视频上传？

[oz-for-oss]

@stat0s2p

已收到 zsh 版本：zsh 5.9 (arm64-apple-darwin25.0)，这正是我们需要的信息。

是的，最好上传一段很短的操作录屏；GIF、MP4 或 MOV 都可以，直接拖到 GitHub 评论框上传即可。录屏只需要展示：执行 set -a 后，在按 Enter 之前输入框里的 pwd，以及按 Enter 后实际执行块里显示的结果。

如果不方便录屏，两张截图也可以：一张是按 Enter 前输入框里的命令，另一张是执行后显示为 pwdpwd 的块。请避免录入或展示私有路径、token、主机名等敏感信息。

Reasoning

This run was triggered by a reporter follow-up on an already-triaged issue, so response mode is appropriate and labels should not be changed. The reporter answered one of the two previous follow-up questions with zsh 5.9 (arm64-apple-darwin25.0) and is asking whether a GIF/video upload is needed. The remaining high-value evidence is visual timing: whether Warp's input editor contains duplicated text before Enter, or whether duplication appears only after the zsh line-editor/typeahead bridge reports/executed block state. Code inspection supports focusing on the zsh input-buffer/typeahead path: app/assets/bundled/bootstrap/zsh_body.sh defines warp_report_input, sends an InputBuffer JSON hook with $BUFFER, then clears BUFFER; crates/warp_terminal/src/shell/mod.rs returns ESC i as zsh's input reporting sequence; app/src/terminal/writeable_pty/pty_controller.rs sends that sequence when LineEditorStatusEvent::Active fires; app/src/terminal/model/early_output.rs imports non-empty shell-reported buffers as typeahead; and app/src/terminal/input.rs / app/src/terminal/view.rs insert typeahead into the input editor. Duplicate search across all open issues found no corroborated set -a/allexport/pwdpwd duplicate; broad duplicate-text issues like #4664 and #1540 have different trigger paths and do not meet the two-candidate duplicate threshold.

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

Powered by Oz

[stat0s2p]

@oz-agent 这是完整的操作录屏

[oz-for-oss]

@stat0s2p

Here's what I found while triaging this issue:

Thanks for the zsh version and recording. This is now specific enough to triage without more information; as a temporary workaround, run set +a or unsetopt allexport after the assignments that need auto-exporting.

Maintainer details

I concluded that warp-specific zsh input duplication after leaving set -a/allexport enabled is now sufficiently evidenced by the reporter's zsh version and media attachment..

Triage update

The reporter answered the earlier follow-up with zsh 5.9 (arm64-apple-darwin25.0) and supplied the requested media attachment. The issue should no longer need needs-info: it has a minimal reproduction, exact Warp Stable/macOS/zsh versions, and a comparison showing the same steps do not reproduce in iTerm2.

Reproducibility

High. The reported path is short and specific: in a Warp zsh session, run set -a, then run pwd; the executed command becomes duplicated, e.g. pwdpwd. The remaining caveat is that this triage environment cannot run the macOS Warp UI locally.

Likely area and cause

This routes to terminal input plus zsh shell integration. The most plausible code path is Warp's shell-reported typeahead/input-buffer synchronization: after zsh prompt readiness, LineEditorStatus causes PtyController to send the zsh input-reporting sequence (ESC-i); the zsh bootstrap binds that to warp_report_input, which sends $BUFFER in an InputBuffer hook and clears BUFFER; EarlyOutput then imports non-empty reported buffers back into the Warp input editor. Leaving zsh allexport enabled may cause Warp's zsh hook functions to run under shell options they do not currently isolate from, producing stale buffer text plus the submitted command bytes.

Relevant files for maintainers:

• app/assets/bundled/bootstrap/zsh_body.sh
• app/src/terminal/writeable_pty/pty_controller.rs
• app/src/terminal/line_editor_status.rs
• app/src/terminal/model/early_output.rs
• app/src/terminal/model/blocks.rs
• crates/warp_terminal/src/shell/mod.rs

Duplicate check

I enumerated all 3,462 open issues and 81 recently closed issues. I found older command-duplication reports (#4664 and #5850), but they have different triggers/surfaces and do not match the set -a/zsh reproduction path closely enough to mark this issue as a duplicate.

Follow-up status

No more reporter follow-up is needed for initial routing. A temporary workaround remains to disable allexport after the assignments that require it, e.g. set +a or unsetopt allexport.

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

Powered by Oz