fix(cli): handle multi-line paste on Windows & fix command approval chaining

[YuriNachos]

Summary

Fixes two separate issues:

1. Copy/paste multilines does not pass instructions as a block #4773 - Multi-line paste on Windows terminals submits each line individually
2. command-approval-patterns allow piping to totally different command #4812 - Command chaining operators bypass approval patterns (security fix)

Fix #4773: Multi-line Paste on Windows

Root Cause

On Windows terminals (especially those without proper bracketed paste mode support), pasting multi-line text causes each line to be submitted immediately because newlines are sent as Enter key presses.

Changes

• keyboard.ts: Added paste detection system with atoms:

  • lastCharTimestampAtom: Tracks when last character was received
  • charCountInWindowAtom: Counts characters in rapid input window
  • hasSuppressedEnterAtom: Tracks if we've suppressed an Enter (active paste mode)
  • resetPasteDetectionAtom: Resets paste detection state
  • checkPasteDetectionAtom: Checks if we should suppress Enter
  • updatePasteDetectionAtom: Updates paste detection on character input
  • schedulePasteSubmitAtom: Schedules auto-submit after paste timeout

• Enter handling: Modified to detect paste by:

  1. Checking if already in paste mode (hasSuppressedEnterAtom)
  2. Checking if buffer has newlines AND recent rapid input (indicating active paste)
  3. Suppressing Enter submission during paste, inserting newline instead
  4. Auto-submitting after 60ms timeout

Testing

• All 1521 CLI tests pass
• Paste detection only triggers when:
  • Already in paste mode (have suppressed previous Enter), OR
  • Buffer contains newlines AND characters arrived very recently (<5ms)
• Prevents false positives on normal fast typing or test loops

Fix #4812: Command Approval Chaining Bypass (Security)

Problem

The matchesCommandPattern function used startsWith with word boundary checking, but didn't account for command chaining operators. This allowed commands like git status; rm -rf /tmp to match the pattern git status because the semicolon was treated as a word boundary.

Solution

• Import parseCommand from shared utilities
• Split commands into sub-commands before pattern matching
• Only auto-approve if ALL sub-commands match the allowlist
• Auto-deny if ANY sub-command matches the denylist

Testing

Added comprehensive tests for:

• Semicolon chaining (;)
• AND chaining (&&)
• OR chaining (||)
• Pipe chaining (|)
• Ampersand chaining (&)
• Newline-separated commands
• Multi-line quoted strings (should remain as single command)

All existing tests continue to pass.

---

@kilocode/cli

[changeset-bot]

⚠️ No Changeset found

Latest commit: 2b08d48

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[marius-kilocode]

@YuriNachos just saw this, thanks for contributing. Abbreviated paste will come with #4916. Will we still need your fix with it for Windows?

[sanderma]

Solution

Import parseCommand from shared utilities
Split commands into sub-commands before pattern matching
Only auto-approve if ALL sub-commands match the allowlist
Auto-deny if ANY sub-command matches the denylist

Very smart! Better than my regex proposal.