[derektrimm]

Problem

Sharing a non-image file into T3 Code from the system share sheet (a spreadsheet, PDF or audio file) leaves a draft that cannot be sent. The chip appears, and pressing send shows:

Too much context
This draft has too much context to send. Remove some context items and try again.

The file's size has nothing to do with it. Shared attachments get ids like share-<sha256>:file:0, and the attachmentId on a composer context record only allows [a-z0-9_-]. The colons fail OrchestrationMessageContext, and composerContextSendBlockReason reports every validation failure with that message.

Since #21659, a shared file gets a context record so that it shows as a chip. That record carries the colon id, so every such draft is blocked before upload. Files added with the attachment button are unaffected because their ids are UUIDs. Images and videos are unaffected because they get no file record.

Change

buildIncomingShareDraft now builds -file- and -image- ids, which are valid for both ChatAttachmentId and the context schema. Image ids change too, so that both share paths produce a valid id. Nothing parses the old format.

Scope and approval

A very small fix for an obvious bug: a shipped feature fails every time on its normal path. The source change is the separator in two template strings, plus test fixtures that pinned the old format. There is no prior issue. Search for the error text and the functions involved found no existing report or fix.

#27878 edits the same two lines and keeps the colons, so whichever lands second needs a small rebase.

Verification

Found on an iPhone by sharing a spreadsheet into a new thread, which showed the dialog above.

Reproduced on an iOS 27.0 Simulator (Xcode 27.2) through the real share path: Files, Share, T3 Code Dev, then Send. Both runs used the same Sample Report.xlsx, the same steps, the same dev client and an isolated server with a demo-app project. Only the id separator changed, and I confirmed it in the bundle Metro served before each run.

Before (:file:)	After (-file-)

Recordings: before and after.

The after run used the Replay provider, so the agent text in those captures is canned. What it shows is the send: no dialog, and the file appears in the thread. The server stored the upload, and its SHA-256 matches the original file.

• New test lets a shared file through the send check runs a shared .xlsx payload through the real buildIncomingShareDraft, mergeComposerDraftContentState and composerContextSendBlockReason. On current main without the source change it fails with expected 'This draft has too much context to se…' to be null. With the change it passes.
• vp test run src/state/use-composer-drafts.test.ts src/features/sharing src/lib/composerContext.test.ts from apps/mobile: 133 passed.
• check:changed passes: format, lint, knip, typecheck, tests and React Compiler.

Not checked: a physical device with the fix, and Android. The failing code is not platform-specific.

A draft or inbox share saved before this fix keeps its old id and stays blocked until the chip is removed and the file is shared again. I left that out, because the stored state only exists after a failed attempt and the dialog already leads to that recovery.

Made with Claude Opus 5.5 in Claude Code, running in T3 Code.

[macroscopeapp]

Approvability

Verdict: Approved at 0fb83de

Macroscope's review found this PR approvable — New mobile share attachments use hyphen-separated IDs compatible with the attachment contract. The change leaves attachment content, limits, and access behavior unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

Incoming-share file and image attachment IDs now use hyphens instead of colons. Tests verify the updated IDs and check that a shared spreadsheet attachment merges into a new-task draft with one context record and no send-block reason.

Changes: Incoming Share Attachment IDs

Layer / File(s)	Summary
Attachment ID format and composer merge apps/mobile/src/features/sharing/incoming-share-model.ts, apps/mobile/src/features/sharing/incoming-share-model.test.ts, apps/mobile/src/state/use-composer-drafts.test.ts	File and image attachment IDs now use hyphens between the draft ID, attachment type, and index. Tests cover the updated IDs and spreadsheet attachment merging into a new-task draft.

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix

Suggested reviewers: juliusmarminge, t3dotgg

Merge Risk: Minimal · up to 6ad1e

Shared files and images should now pass the send check instead of being blocked with "Too much context". Drafts saved before this fix keep their old IDs and must be re-shared. The change is small and low risk.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: a shared file no longer fails to send with "Too much context". The changeset switches shared attachment IDs from colon-separated to hyphen-separated formats, which fix…
Description check		The description follows the repository template. It has Problem, Change, Scope, and Verification sections, and each section gives specific information. The problem is stated clearly with the error tex…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title names the main change: a shared file no longer fails to send with "Too much context". The changeset switches shared attachment IDs from colon-separated to hyphen-separated formats, which fixes that failure. The title is specific and follows the conventional commit style in the template.

Full details: Description check

Explanation

The description follows the repository template. It has Problem, Change, Scope, and Verification sections, and each section gives specific information. The problem is stated clearly with the error text and root cause. The change explains the ID format fix and the reason the image ID also changes. The scope explains why no issue exists and says the fix is small. Verification gives the simulator reproduction, the before and after evidence, the unit test results, and the checks that were not run. The description also records the model and harness, as the template asks.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 8cb551a
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: d2fada52-0459-4780-bd62-91f872d03df4

Commits

Reviewing files that changed from the base of the PR and between 0fb83de and 6ad1e95.

Files selected for processing: 1

• apps/mobile/src/state/use-composer-drafts.test.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[rosa-verified]

Left on behalf of Hal by Opus 5.5

+1. Hal hit this today on an iPhone sharing a WhatsApp voice note to T3 Code: the chip appeared, then send gave the "Too much context" dialog. Saving the note to Files and attaching it with the + button sent fine, which fits the colon-id explanation, since picker attachments get UUIDs. So it catches audio too, not just documents.

Traced it on current main (55081a1) and got to the same cause: share-<sha256>:file:0 ends up in the file record's attachmentId, which only allows [a-z0-9_-]. Read through the diff too. Nothing else builds or parses the :file:/:image: format, the new ids pass that rule at 77 characters against the 128 limit, and the outbox validates context with the same schema, so this looks like the whole fix for new shares. Not run on a device or locally, so that part rests on your simulator runs and CI.

[juliusmarminge]

Evidence

On pooled Android Pixel 9/API 36, download report.pdf, cancel the viewer prompt, then Files → long-press → Share → T3 Code Dev → Share evidence → Send. Repeat with chart.png. Each commit ran its own Metro bundle and isolated server. PDF: base rejects the 7 KB file; head sends it and completes. Image: both commits complete successfully.

Before	After
8cb551a3	6ad1e95c
PDF send recording	PDF send recording through completion
Image send recording through completion	Image send recording through completion

Commands and synthetic fixtures · Capture notes and discarded attempts.

The head PDF still and video show the same 12:22 PM send and completed replay. Image captures show matching recorded sends at 12:29 PM on base and 12:36 PM on head. Images use a separate replay fixture advertising image support because stock Replay advertises image:false. Environment labels are redacted; video timing is unchanged, with a two-second final-frame hold. No tests are used as evidence.

Not shown:

• The iOS Files share path was not run; verification used Android's native Files share path and the shared incoming-share implementation.
• Spreadsheet and audio formats were not separately exercised; file-share proof used a PDF and image-share coverage used a PNG.
• Real provider interpretation of attachment contents was not tested; deterministic replay supplied the completed responses.