The five features reflect your recorded choices. Each comparison retains current OpenProgram behavior and alternatives, with the selected option marked. This document covers attachment use in the existing desktop and web interfaces.
All panels illustrate behavior; they are not product screenshots. Framework labels indicate verified similarities in processing, not identical UI or retention. “Selected” marks the feature design you confirmed, not an implemented app capability.
Composer attachments: images and files in one row
Redesigning the composer shown in the supplied screenshots: images no longer occupy a separate row, and document tiles lose their empty space. All items share one height and follow insertion order, with a name, format, and size.
New visual proposal, not implemented. These HTML illustrations use example filenames and sizes; controls are not live uploads. The five selected processing rules remain unchanged.
Image, PDF, and spreadsheet together
Same height, insertion order, and information structure
▣ Local▱ fzkuji
Screenshot 2026-09-09 at 3.43.11 PM.png
PNG · 1.3 MB
×
PDF
Scholarships and Financial Aid Records.pdf
PDF · 842 KB
×
XLSX
Annual Report 2026.xlsx
XLSX · 126 KB
×
Use the screenshot and both files to list the application materials.
＋↑
Ask permissionsCurrent model · Medium
Images use a 40 × 40 thumbnail. Each item is about 248 × 60, allowing images and documents side by side. Format remains visible even when a filename is truncated.
More attachments wrap as one group
Insertion order, without type grouping
▣ Local▱ fzkuji
Screenshot 2026-09-09 at 3.43.11 PM.png
PNG · 1.3 MB
×
PDF
Scholarships and Financial Aid Records.pdf
PDF · 842 KB
×
XLSX
Annual Report 2026.xlsx
XLSX · 126 KB
×
CSV
sales.csv
CSV · 18 KB
×
FOLDER
project/
FOLDER · Folder
×
Check these materials for missing items.
＋↑
Ask permissionsCurrent model · Medium
Reading and failure states stay on the affected item
Item height stays unchanged
▣ Local▱ fzkuji
Screenshot 2026-09-09 at 3.43.11 PM.png
PNG · 1.3 MB
×
XLSX
Annual Report 2026.xlsx
XLSX · 126 KB · Reading…
×
PDF
report.pdf
PDF · 842 KB · Read failed
×
Summarize the key information in these files.
Cannot read report.pdf. Add it again or remove it.
＋↑
Ask permissionsCurrent model · Medium
Appearance and interaction
The first line shows the filename with single-line truncation. The second always shows format and size, independently of the name: PNG · 1.3 MB or PDF · 842 KB.
Images use proportional thumbnails without heavily rounded cropping. Documents, spreadsheets, and code use small format-labelled icons; color is not the only distinction.
For extensionless files, show a confirmed format or “File” when unknown. Folders show “Folder” without an invented total size.
Click the item body for a preview or details with the full name, location, size, and copy status. Keep removal visible. Implement separate keyboard-accessible actions rather than filling the composer with paths.
Images and files share a single layout region. Wrap uniformly in narrow windows; for many items cap the region at two rows and scroll it, keeping the text area available.
Preserve text and attachments while reading or after a failure. Explain why sending is unavailable; re-add or remove the failed item without selecting the others again.
Issue in the screenshots
Proposed change
Images and files occupy separate regions
One compact group in insertion order
Oversized images and mostly empty document tiles
32 px icons/thumbnails and 46 px item height
Wrapping filenames and inconsistent format labels
Single-line names, separate format and size
Image proposals assume a model that supports image input. Current OpenAI Responses handling may remove image content for a model without that capability, with no automatic tool fallback. The proposed behavior should prompt a model switch, or explicitly use a configured image tool and explain that processing.
01
Paste a screenshot
Should the model see the image immediately or ask a tool to open it?
Selected: A · See the image and save it with chat. Acceptance status is listed at the end of this page.
02
Drag in an existing image
With a vision-capable model, both options send image content; the choice is whether to copy the original.
Selected: B · Always save a chat copy. Acceptance status is listed at the end of this page.
03
Drag in text, code, or data
Pass a path by default, or include the text as soon as it is attached?
Selected: A · Reference it and read for the task. Acceptance status is listed at the end of this page.
04
Drag in PDF, Word, or Excel
Let the assistant choose a reading tool, or prepare a preview automatically?
Selected: A · Reference it, then choose how to read. Acceptance status is listed at the end of this page.
05
Drag in a folder
Provide only the folder path, or include its immediate listing?
Selected: B · Include the immediate listing. Acceptance status is listed at the end of this page.
Rules shared by all scenarios
Does the image need processing?
Process the sending version using known model requirements and preserve an available original. Use explicit rules for unknown limits; not every model exposes them.
Keep input after failure
Keep text and attachments until confirmed. Explain upload, read, or send failures; check the previous result after a disconnect to avoid duplicates.
Will the sent version remain available?
References are affected by edits, moves, and deletion. A saved copy preserves the version; listings and text excerpts are not original-file copies.
Recorded choices
The first five choices are saved in this document and persist on reload. This records design only and does not change the app.
Framework evidence and current implementation
OpenProgram file handling
When a file is added through the web interface, the backend receives and saves it for the assistant to read. The desktop interface references ordinary files at their original paths. Images retain a chat copy. Users add a file and state their task; they do not choose between upload and path handling.
Verified: ordinary file selection inserts a path, decodable images become image input, and clipboard images are written to temporary PNG files. This does not establish the desktop app’s complete long-term copying policy. Copy controls and status labels in the panels are OpenProgram proposals.
Supported text attachments include their text; directories include an immediate listing; PNG/JPEG/GIF/WebP become image media. SVG is text; PDF, audio, video, and other binary attachments currently do not directly enter model requests. Server-accessible files can be referenced. Configurable resizing does not guarantee compliance with every model.
Channel media is downloaded to the runtime. Vision-capable primary models can receive images; other configurations can generate descriptions. Documents can yield text, with configured page-image fallback for scanned PDFs. Tool handoff requires an accessible saved path. Channel reception is not treated as equivalent to local desktop drag-and-drop.
The current upload flow saves ordinary files too; path-only reference is not the current default. Image thumbnails do not resize outgoing images. Full image encoding counts toward the execution-input limit and can be rejected before the user message is saved. The composer clears before durable confirmation, which can leave a chat with only a title.
The target chat log records oversized input. The full original request is unavailable, so the responsible field is not established. A minimal local request reproduced image encoding exceeding the execution-input limit without a model call.
Handle chat persistence, image delivery, and file reading separately. Shrinking every image to fit the execution-input limit is insufficient; copying every local file should not become the default fix. Treat attachment text as supplied material, not automatically as new user instructions.
Public Codex code supports several image-processing modes selected by capabilities and configuration. A utility’s default dimension is not every model’s limit. OpenCode’s configurable resizing does not guarantee compliance with every model. OpenClaw channel reception limits are not universal model limits.
Temporary storage, upload to a runtime, and long-term chat retention are different promises. Retention periods not established by the sources are not inferred here. Image copies are selected for OpenProgram; implementation must specify copy handling for chat deletion, export, and migration in development notes.
Messages waiting for the current turn are grouped immediately above the composer, outside the scrolling transcript. Each message keeps its own compact bubble, previewable attachments, delivery status, Edit and Remove actions. The group has a bounded height and can collapse to a message count. It does not merge message identity or order.
Queue submission captures text, expanded paste content, attachment bytes or original paths, and send settings. Attachments can be queued without starting another execution. A queue editor holds that message until Save or Cancel; it supports text, file picking, file drop, previews and individual attachment removal. Save retains the queue position and original settings; Cancel keeps the previous payload. In-flight or receipt-pending steering commands cannot be edited or removed. Attachment messages wait for a normal turn because the steer API accepts text only.
Draining uses the ordinary chat sender and attachment envelope. Transport failure or rejection keeps the complete queued message; acceptance releases it. Queue content remains local to this open App window and is not promised to survive a reload. Unsent previews use captured local content, including native paths outside the session workdir: images and text render directly, and bounded PDF files use a local Blob URL. Native documents remain path references when sent; preview bytes do not widen backend file access. Persisted attachments retain the existing read-only document viewer. Missing or unsupported previews report their limitation without discarding the attachment.
User messages in the transcript retain individual identity, controls and bubbles with reduced vertical spacing. History editing retains its existing fork-and-resend semantics. This change does not delete persisted history, change model behavior, combine separate instructions, or modify approval decisions.
Reference and choices
The user's Codex interaction description is the layout reference: retained messages near the input with a small footprint. Existing OpenProgram queue, composer attachment processing and DocumentWindow are the implementation reference. No undocumented Codex storage or editing behavior is assumed. A bounded group is adopted; merging instructions and transferring queued files through text-only steering are rejected.
Acceptance and implementation status
Verify through composer submission that mixed attachments remain previewable in the queue, editing and removal affect only the chosen message, editing blocks drain, send failure retains bytes, and ordered draining uses the exact edited payload. Verify native App queue positioning, compact spacing, preview dismissal and session isolation. The implementation uses QueuedMessages in the composer, attachment snapshots in the existing send queue, a transient instance of the shared attachment editor, and local attachment previews. Release requires independent specification and quality review, the full verification manifest, and installed-App acceptance; evidence is recorded separately.