[Bug]: Long pastes flagged as application/x-mach-binary get hard-rejected with no recovery path

[KooshaPari]

Summary

When a user pastes content into the prompt that the input transport (terminal paste / clipboard) fingerprints as a Mach-O binary (application/x-mach-binary), forge rejects the entire paste with a hard error and does not surface any way to recover or override. This blocks any paste of a long captured log, terminal scrollback, or session transcript that happens to contain even a few bytes of binary, even when the pasted content is overwhelmingly textual.

Repro

1. Run forge in a session (observed on v2.13.13, model MiniMax-M3, host macos-arm64).

2. Capture a long session scrollback (e.g. script -q output, or tail -f of a build log) to a file, or paste a long terminal capture that includes ANSI escapes, NUL bytes, or fragments of binary blobs inlined by accident.

3. Paste the content into the prompt.

4. Observe the error:

   ● [17:46:25] ERROR: Binary files are not supported. File detected as application/x-mach-binary
   

5. The paste is fully discarded. The prompt is left empty. There is no warning, no preview, and no paste as text anyway affordance.

Expected

At least one of:

• Detect-and-warn: show a non-fatal warning that the content was fingerprinted as binary, sanitize (strip NULs / strip ANSI), and accept the cleaned text.
• Override flag: forge --force-prompt-text or an env var (FORGE_PASTE_FORCE_TEXT=1) to force text-mode paste and run a sanitizer (e.g. strings-like extraction) before submission.
• Preview-then-confirm: render the first N bytes as a hex/text preview and ask the user Treat as text? [y/N].
• Pipe-friendly bypass: when stdin is non-TTY, skip the binary heuristic and submit as text (current behavior of many CLIs).

Actual

Hard rejection. Single error line. No recovery. The user has to manually edit the captured content (e.g. cat | tr -d '\0' | col -b) before retrying, which is impractical for the very large dumps that triggered the heuristic in the first place.

Context

• Observed in session captured at log.md:1039 of the user's local scratch repo.
• Triggered by pasting the output of a forge session itself (self-referential capture), so any long-running session that wants to be reviewed produces a paste that its own input layer rejects.
• Related but distinct: [Bug]: Paste of terminal with p10k configured rejected in the prompt #3240 reports a p10k / OSC 133 specific paste rejection — this is the broader binary-fingerprint failure mode that p10k happens to hit too.
• Reproduces reliably on every long paste in every session, per user: "every forge session has this issue".

Proposed fix sketch

1. Move the binary-fingerprint check out of the input transport and into a paste::classify() step that runs before submit.
2. If classify returns binary but the candidate is >80% printable text and contains no NULs in the first 4 KB, demote to text-with-binary-fragments and pass through a sanitizer (strip_nuls, strip_ansi).
3. If still binary, render the first 256 bytes as a hex dump preview and ask the user.
4. Always log a paste.classify event via pheno-tracing (or whatever the forge OTEL pipeline is) so the failure mode is visible in the trace.

Labels

type: bug, help (extra attention)