Skip to content

Bug: /paste blocks input while macOS reads a clipboard image #414

Description

@reyanshgupta

Issue details

On macOS, /paste can leave fx unresponsive for several seconds before the image placeholder appears. I hit this with fx 0.0.6 in Ghostty while pasting a 3346×2040 PNG.

Steps to reproduce:

  1. Copy a screenshot or other large image.
  2. Run /paste in an interactive fx session.
  3. Try to type while the image is being attached.

The input should stay responsive, with some indication that fx is reading the clipboard. Instead, nothing redraws and input appears frozen until the paste finishes.

The clipboard path is synchronous today. attachClipboard calls loadClipboardImageAttachment, which runs osascript with std.process.run and waits for it to exit. The snapshot copy/hash also happens before control returns to the input loop. Images above the encoded-size limit may add a synchronous sips conversion.

The image from my session ended up as a 3.16 MB snapshot, below the sips threshold, so the delay I saw was most likely macOS materializing the clipboard PNG rather than normalization.

I think the clipboard read should move off the input loop. A small in-progress notice plus cancellation or a timeout would also make this feel much less like a hang.

Source: https://github.com/vercel-labs/fx/blob/v0.0.6/src/core/images/image_attachments.zig#L1717-L1760

Trace

fx version: 0.0.6
platform: macOS arm64
terminal: Ghostty
clipboard image: PNG, 3346×2040, 3,163,273-byte stored snapshot

Sensitive information

  • I reviewed the information above and removed secrets and other sensitive data.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    type: bugFixes incorrect behavior

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions