Generator-produced suggestions are not shell-escaped before insertion

[nickeddy]

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

Related: warpdotdev/command-signatures#271. That fix corrects how git add <tab> collects filenames containing spaces in the command-signatures repo. Once it lands and the warp pin is bumped, this warp-side bug becomes user-visible: the popup shows the correct filename, but selecting it inserts an unescaped string into the buffer that the shell parses as multiple tokens.

Suggestions produced by a Rust generator (Generator::script registered through the command-signatures crate) are converted to the in-app Suggestion type via two From implementations that copy the generator's exact_string straight into replacement with no shell-escaping. As a result, any suggestion whose value contains shell metacharacters (spaces, $, *, \, quotes, etc.) is inserted into the input buffer in a form the shell will mis-tokenize.

The fix in command-signatures#272 is necessary but not sufficient: it makes generators return the correct filenames; this issue is about warp making sure those filenames are inserted in a form the shell will accept.

To reproduce

Requires command-signatures#272 (or any local pin where files_for_staging's post-processor returns the raw filename) — without it, the bug is masked by the upstream truncation. With the upstream fix in place:

mkdir /tmp/repro && cd /tmp/repro
git init -q
touch "new file test.csv"

In Warp:

1. Type git add and press Tab.
2. The popup correctly shows new file test.csv (no truncation, no leading quote). Note: without command-signatures#272 this will show "new incorrectly, which is what command-signatures#272 fixes.
3. Arrow-select that suggestion and press Enter.
4. The buffer becomes git add new file test.csv — three space-separated tokens.
5. Press Enter to run. git add reports that none of new, file, test.csv are valid pathspecs.

Expected behavior

After step 3, the buffer should contain a form the shell parses as the single argument new file test.csv — for POSIX shells, e.g. git add new\ file\ test.csv or git add "new file test.csv". The path completer (engine/path.rs:347) already does this for filesystem-backed completions; generator-backed completions should match.

Screenshots, videos, and logs

Operating system (OS)

Linux

Operating system and version

Mint 22.2

Shell Version

zsh 5.9 (x86_64-ubuntu-linux-gnu)

Current Warp version

v0.2026.05.13.09.15.stable_01

Regression

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

Recent working Warp date

No response

Additional context

Old issue command-signatures#272 is fixing - note `"new ` is cut off and the subsequent selection into shell produces `git add "new `.

Does this block you from using Warp daily?

No

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]

@nickeddy

Here's what I found while triaging this issue:

This looks actionable from the report as filed. The command-signatures fix appears necessary but not sufficient; this should also be tracked on Warp's completion insertion side.

Maintainer details

I concluded that generator-backed command completions can insert raw filenames containing shell metacharacters, causing the shell to parse one suggested argument as multiple or expanded tokens..

Initial triage

This looks like an actionable completions bug with high reproducibility. The provided repro is specific and the reported behavior is consistent with the current generator-backed argument completion conversion path.

Likely root cause: generator results from command-signatures are converted into Warp completer suggestions with their raw exact_string/value copied into the internal replacement field. Filesystem path completions already shell-escape replacement strings before insertion, but the legacy and v2 generator conversion paths do not apply equivalent escaping. That means a generator suggestion such as new file test.csv can display correctly while still being inserted as an unescaped shell word.

Relevant code paths inspected:

• crates/warp_completer/src/completer/engine/argument/legacy.rs
• crates/warp_completer/src/completer/engine/argument/v2.rs
• crates/warp_completer/src/completer/engine/path.rs
• crates/warp_util/src/path.rs

Duplicate check: I found related open autocomplete/path escaping reports such as #3976 and #2470, but they do not provide two existing issues matching this specific generator-backed insertion path, so I am not marking this as a duplicate.

No follow-up questions are needed from the reporter for initial routing.

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

Powered by Oz

[nickeddy]

Validated fix at 8713a42 combined with the command-signature#272 PR fixes this: