Record image-attachment CSP fix (blob scheme) and build-provenance guarantees

[gennadiryan]

Important

Problem

Image attachments were unusable inside the Amicode webview: a pasted screenshot staged a broken thumbnail, sending with a staged image failed ("Failed to send prompt / failed to fetch"), and the chat stalled until the staged image was removed. The failure was independent of the separately fixed copy/paste duplication defect — it reproduced identically for screenshots, for images copied as files, and for the attachment picker, and predated the paste work.

Approach

Record the defect and its resolution as the regression playbook for future triage, and record the build-provenance guarantees that made the verification attributable. Root cause: the app server's Content-Security-Policy allowed network schemes and the data scheme but omitted the blob scheme from its image, connection, and media source lists — while the whole attachment pipeline stages thumbnails and sends payloads through object URLs. Resolution: allow the blob scheme in those three source lists, shipped in the vendored fork as PR #140 (branch fix/image-attachments). Companion guarantee: build provenance stamping embeds branch, commit, and dirty-state in every shipped binary, so a verified build can be attributed to exactly the code that was reviewed.

Approaches Considered

• Allow the blob scheme in the app policy (chosen) — one policy change restores thumbnails and sending together, for every attachment source.
• Eliminate object URLs from the pipeline (render and send via data URLs) — larger change, and it would still leave the image policy hostile to future blob use; retained as a second pass if the first ever proves insufficient.
• Relax the policy wholesale — rejected: only one scheme was missing, and it is same-origin and page-created.

Scope

• In: this record — symptom, diagnosis, fix reference, regression-triage guidance, and the provenance guarantees; linkage to the fork fix PR and the addendum issue.
• Out: new product behavior. The fix itself lives in the fork PR; nothing in this repo changes behavior.

Assumptions / Open Qs

• The fix is assumed stable as verified; this record's value is triage speed and attribution, not code. If a recurrence appears with console policy refusals absent, the diagnosis branch is the pipeline, not the policy.

---

Acceptance Criteria

1. A future triager reading this issue alone can reproduce the symptom class, confirm the policy diagnosis from console refusals, and locate the fix PR.
2. The issue's Source links the fork fix PR (branch fix/image-attachments), the addendum Addendum to #261: image-paste failure was a distinct defect from the copy/paste duplication opencode#141 (to BUG: paste duplicates input — clipboard content inserted twice #261), and this repo's provenance commit.
3. The provenance guarantees are stated: stamped branch, commit, and dirty-state, with the verified build's stamp recorded.
4. The record explicitly separates this defect from the copy/paste duplication defect (different mechanism, fix, and verification).
5. The issue notes the deferred considerations (data-URL pipeline as second pass; MIME/size policy for attachments).

Key Decisions

• The record lives in this repo (the product repo), because the symptom is user-visible product behavior and the fork is an upstream dependency; the addendum issue records the correction on the fork side where BUG: paste duplicates input — clipboard content inserted twice #261 lives.
• The fix's decision surface is preserved here (blob allowance vs. data-URL pipeline vs. wholesale relaxation) so the second pass can be picked up without re-deriving it.
• Provenance stamping is treated as a guarantee, not a diagnostic tool: the stamp is embedded at build time and is the only way to answer "which binary was actually verified".

Constraints & Invariants

• No product behavior changes as a result of this issue.
• The host webview's own policy is untouched by the fix; the blob allowance is scoped to the framed app document and to the three source lists named in the fork PR.
• The clipboard bridge protocol and paste ownership are unaffected by the fix and out of scope for any follow-up here.

Prior Art / Patterns

• The app server's shared Content-Security-Policy (the site of the omission and the fix): one template string covering all directives; non-network schemes must be listed explicitly because the wildcard covers network schemes only.
• The attachment pipeline: staging with byte-hash duplicate detection, a format gate (image MIME allowlist), thumbnail rendering from object URLs, and send-time payload encoding by fetching the object URL.
• The clipboard seam: a single-slot media hook on the window-level paste fallback, registered by the composer controller; image hand-off happens only when the clipboard carries no text.
• Provenance stamping: build-time embedding of branch, commit hash, and dirty-state into the binary, exposed in the shipped artifact's metadata.
• Related seam records: the copy/paste duplication fix (single-value paste) and the zoom chord record; both arose from the same seam sweep and follow the same two-reader format.

Source

• Fix: harmoniqs/opencode PR feat(brand): light-mode yellow as a bordered fill, not a dimmed line #140 from branch fix/image-attachments (commit 42a2c2a82).
• Correction record: Addendum to #261: image-paste failure was a distinct defect from the copy/paste duplication opencode#141 (addendum to BUG: paste duplicates input — clipboard content inserted twice #261).
• Provenance: this repo's commit 98b7cff on dev/gennadiryan/provenance-fix (build provenance stamping).
• Related seam work: Harness-swappable: the vendored-opencode seam becomes an adapter boundary #243; the copy/paste duplication record (single-value paste); BUG: Cmd/Ctrl +/- zoom keybindings do not work in Amicode #266 (zoom record).

Notes

The defect's diagnosis was pinned by source-independence: identical symptoms for screenshots, copied files, and picker attachments meant the fault sat in the shared pipeline or its policy, not in any paste path — the console's two policy refusals (image and connection) were the one-step confirmation. The provenance stamp is what made the remote verification trustworthy: the retested binary is attributable to the fork commit that carried the fix, dirty-state at build time recorded.