Skip to content

send_to can submit pre-existing human composer text #442

Description

@EtanHey

Summary

send_to can press Return into a Cursor (or other) composer that already holds human-typed draft text. assertDeliveryTargetIsSafe in src/server.ts blocks permission prompts and picker/menu screens, but it does not check whether the composer already contains text that is not the payload we are about to type.

Why this is not #441

Return #1 on the busy-Cursor path already had this exposure before send_to v2. Round-2 review of #441 called it out as a separate issue, not a merge blocker for the verify/queued_followup work.

Risk

If a human (or another agent) has a draft sitting in the composer, send_to typing + Return can submit that draft, concatenate with the payload, or otherwise mutate text the caller did not send. That is a silent delivery-integrity hole, distinct from the busy-follow-up false-fail (#432) this PR is closing.

Suggested fix

Before the first type/Return, refuse (or snapshot-and-abort) when extractComposerInputRegion is non-empty and is not our payload / a known placeholder. Keep that check on the send path, not only on the background verifier.

— cmuxlayerCursor-11c3aa25 (worker) · cursor/unknown

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions