feat: images upload the moment you attach them

[t3dotgg]

Attached images used to ride inside the send command as base64 data URLs. Sending a message with a 10MB screenshot meant a 14M-character string in one ws frame: send felt slow, the turn could not start until the frame landed, and the stash had to re-encode every image to squeeze it into localStorage.

Now the bytes move while you are still typing. Attaching an image mints a pending-<uuid> id plus a signed upload URL over ws (the same pattern as signed asset GETs, so it works against any environment), and the browser POSTs the compressed bytes to it with per-chip progress and cancel. The send command carries id references only, and the server renames pending files to their thread at turn start — resolving by uuid, so send retries and existing asset URLs survive the rename.

What this buys:

• Send is instant; upload overlaps with typing.
• Drafts with images now survive reloads fully (previews via signed asset URLs). The localStorage re-encode/budget machinery is deleted.
• The send button blocks while a chip is uploading or failed, so an image can never be silently dropped from a sent message.
• Never-sent uploads are deleted on chip removal, with a 30-day sweep as backstop. Uploads write .part then rename, so a partial transfer is never a valid attachment, and the route enforces the exact minted byte count.

Breaking, deliberately without a compatibility path: the dataUrl upload variant is deleted. Out-of-date clients get a loud schema error. React Native mobile compiles and degrades honestly behind IMAGE_ATTACH_ENABLED = false ("Image attach needs an app update"); the port is a fast-follow. apps/swift-ios is not on main, so the Swift mirror is untouched — a 7-edit patch list for that branch is in the plan doc.

Design doc: https://rztz3kvilrh0.postplan.dev

Verified: contracts 227, server attachment suites 66 (full suite green except 6 launcher-version failures that reproduce on untouched main), web 2201, mobile 654. Lint and format clean. Not yet done: a manual browser pass (paste several images fast, cancel mid-flight, kill the network, reload with a ready draft) — automated browsers cannot see authenticated views here.

Built by Claude Fable 5 running in Claude Code.

🤖 Generated with Claude Code

---

Note

High Risk
Breaking attachment contract (no dataUrl), new signed upload HTTP surface and turn-start claim logic, plus draft v9 migration that drops unsent inline images on upgrade.

Overview
Composer images no longer ride in thread.turn.start as base64 data URLs. Web uploads bytes as soon as a chip is added: WS mints a pending-<uuid> id and signed URL, HTTP POST stores the file, and send carries id references only. The normalizer claims pending files into thread scope at turn start (uuid-stable resolution so retries and asset URLs survive renames).

Server additions: AttachmentUpload (token mint/validate, .part then rename, size enforcement), POST /api/attachments/upload/*, RPC attachments.createUploadUrl / attachments.delete, pending attachment sweep on startup, and planAttachmentClaim in the attachment store.

Web composer/drafts: Upload queue with progress, cancel, retry, and environment mismatch handling; send is blocked while uploads are unsettled; draft persistence bumps to v9 (server id + environmentId only—legacy inline dataUrl attachments are dropped on rehydrate). Stash and sidebar discard release pending server bytes.

Mobile: Image attach is disabled behind IMAGE_ATTACH_ENABLED = false; picks/pastes surface “needs an app update,” legacy draft/outbox images are not sent (warnings via droppedAttachmentsWarning), and buildProjectThreadStartTurnInput always sends attachments: [].

^{Reviewed by Cursor Bugbot for commit 36f6d76. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Upload composer image attachments immediately on attach instead of at send time

• Images are now uploaded to the server as soon as they are added to the composer, using a background queue (attachmentUploadQueue.ts) with progress reporting, abort capability, and XHR-based upload to signed URLs.
• Two new WebSocket RPCs (attachments.createUploadUrl and attachments.delete) mint signed upload URLs and delete pending attachments; the server validates tokens, enforces exact size, and persists bytes via a new POST endpoint.
• ClientThreadTurnStartCommand payloads no longer inline base64 image data URLs; they carry ChatAttachment id references to pre-uploaded blobs. The composer send button is blocked while uploads are pending, failed, or belong to a different environment.
• Switching environments triggers automatic re-upload of any images that still have a local File; discarding or removing an image aborts in-flight uploads and releases server-side bytes.
• Composer draft persistence is bumped to v9: only ready (fully uploaded) attachments are persisted as environment-scoped id references; in-flight and failed uploads are not saved. Legacy v8 inline dataUrl entries are dropped on rehydration.
• Mobile image attach is explicitly disabled via IMAGE_ATTACH_ENABLED = false in composerImages.ts; callers receive a structured error and a warning banner when legacy attachments are dropped.
• Risk: any clients with persisted v8 composer drafts containing inline image data will silently lose those attachments on rehydration.

^{Macroscope summarized 36f6d76.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: bf950256-a9a4-410e-98ba-2154f6f01183

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Effect service conventions review of the changed server/contracts code. Two findings on error modeling; the new AttachmentUpload module itself follows the repo's service/DI conventions (namespace subpath imports, dependencies acquired via yield* Foo.Foo, no hidden runtimes).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

🟡 Medium

t3code/apps/web/src/composerDraftStore.ts

Line 3253 in 1331956

removePreviewAnnotation: (threadRef, annotationId) => {

removePreviewAnnotation filters the annotation's image out of images but never calls releaseComposerAttachment or cancelAttachmentUpload. Removing a preview annotation while its image is still uploading leaves the upload job running, and removing one after upload completes leaves the server-side pending attachment allocated until the 30-day backstop sweep. The image disappears from the draft's images array, so the upload queue never sees it again to release or cancel it.

Also found in 1 other location(s)

apps/web/src/components/chat/ChatComposer.tsx:1510

The environment-retargeting path calls retryAttachmentUpload for an already-ready image but never releases its existing server attachment. retryAttachmentUpload only cancels an active job (there is none after readiness) and starts a new upload, whereas releaseComposerAttachment is the function that deletes a ready attachment. Switching a draft between environments therefore leaves one orphaned pending upload behind on each retarget until the 30-day sweep.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/composerDraftStore.ts around line 3253:

`removePreviewAnnotation` filters the annotation's image out of `images` but never calls `releaseComposerAttachment` or `cancelAttachmentUpload`. Removing a preview annotation while its image is still uploading leaves the upload job running, and removing one after upload completes leaves the server-side pending attachment allocated until the 30-day backstop sweep. The image disappears from the draft's `images` array, so the upload queue never sees it again to release or cancel it.

Also found in 1 other location(s):
- apps/web/src/components/chat/ChatComposer.tsx:1510 -- The environment-retargeting path calls `retryAttachmentUpload` for an already-`ready` image but never releases its existing server attachment. `retryAttachmentUpload` only cancels an active job (there is none after readiness) and starts a new upload, whereas `releaseComposerAttachment` is the function that deletes a ready attachment. Switching a draft between environments therefore leaves one orphaned pending upload behind on each retarget until the 30-day sweep.

[macroscopeapp]

Approvability

Verdict: Needs human review

2 blocking correctness issues found. This PR introduces substantial new capability (upload-on-attach for images) with new server endpoints, client upload queue, contract changes, and storage schema migrations. The scope exceeds what can be auto-approved, and there is an unresolved High-severity finding about stalled uploads potentially blocking sends indefinitely.

^{You can customize Macroscope's approvability policy. Learn more.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	11.3 KiB	11.3 KiB	−1 B (−0.0%)	15.1 KiB	✅
Codex	Thread snapshot wire	5.5 KiB	5.5 KiB	+1 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	5.9 KiB	5.9 KiB	−2 B (−0.0%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	49.7 KiB	49.7 KiB	0 B (0.0%)	66.4 KiB	✅
Codex	Live turn messages	16	16	0 (0.0%)	21	✅
Claude	Total thread wire	11.3 KiB	11.3 KiB	0 B (0.0%)	15.1 KiB	✅
Claude	Thread snapshot wire	5.5 KiB	5.5 KiB	+5 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	5.9 KiB	5.9 KiB	−5 B (−0.1%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	50.6 KiB	50.6 KiB	0 B (0.0%)	66.4 KiB	✅
Claude	Live turn messages	16	16	0 (0.0%)	21	✅

Baseline: 5304f3e · PR result: 36f6d76 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 94.6 KiB
• Claude decoded thread snapshot: 95.4 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

🟠 High components/ChatView.tsx:5207

A stalled preview upload leaves the send operation pending indefinitely, so sendInFlightRef stays true and the message is neither sent nor restored. awaitAttachmentUploads waits on an XMLHttpRequest with the default timeout of 0, which never expires when the connection remains open; add an upload timeout or cancellation path before awaiting it.

🚀 Reply "fix it for me" or copy this AI Prompt for your agent:

In file @apps/web/src/components/ChatView.tsx around line 5207:

A stalled preview upload leaves the send operation pending indefinitely, so `sendInFlightRef` stays `true` and the message is neither sent nor restored. `awaitAttachmentUploads` waits on an `XMLHttpRequest` with the default `timeout` of `0`, which never expires when the connection remains open; add an upload timeout or cancellation path before awaiting it.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 3 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 03196ef. Configure here.}

[ElliotDrel]

Non-blocking architecture follow-up for Prompt Stash: this PR solves the hard attachment half by moving image bytes onto the target T3 environment, but apps/web/src/promptStashStore.ts still makes browser localStorage the authoritative stash store. That means stash metadata still cannot follow the same environment across desktop/web/mobile or another controlling machine, even though the attachment bytes now can.

I think the clean follow-up is to make the target ExecutionEnvironment/server authoritative for stash state, rather than putting canonical stash state in T3 Connect or a thread snapshot:

• add server-side durable stash metadata keyed to the environment;
• expose idempotent mutations such as prompt-stash.create, atomic prompt-stash.take, and prompt-stash.delete (plus attachment finalization only if still needed);
• expose a separate environment-level stash subscription/snapshot, e.g. orchestration.subscribePromptStash, rather than piggybacking on subscribeThread because the stash is intentionally thread/provider agnostic;
• put the replicated client state in packages/client-runtime so web and mobile consume the same source;
• reuse the server attachment IDs introduced by this PR, so stash synchronization moves references rather than base64/blob payloads;
• keep client storage only as an optional pending outbox for offline writes. A normal stash should clear the composer only after the target server acknowledges the durable write.

T3 Connect then remains transport to the execution environment instead of becoming a second state authority.

I would keep this out of this PR because #6276 is already a large/high-risk attachment-contract change. The server-owned stash is a cleaner follow-up PR once this attachment model is stable.

[ElliotDrel]

Follow-up tracked in #7626. That issue is intentionally sequenced after this PR and should build on this PR's server-side attachment ID model rather than expand #6276 further.

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

Closing in favor of #8048. Image attachments now upload before sending, with compatibility preserved for existing mobile clients and older servers.