feat(mobile): pick, share, and receive files in threads

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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

[rynfar]

Third of the mobile batch. Adopted from upstream pingdotgg/t3code#8237 (86c9a9288). Follows #223 and #224.

Mobile gains file attachments: the composer's + offers Files when the server supports uploads, the system share sheet can send a file into Pylon, and received files can be saved or opened elsewhere. Brings a new features/sharing surface, upload/download helpers, and outbox support.

Port fidelity

41 of the 43 changed source files apply upstream's diff line-for-line. The two that differ are the two resolved by hand, and I diffed the diffs to confirm the deltas are only what was intended.

7 files conflicted. The shape is not obvious, so it's worth recording:

Upstream landed this at 13:35 the same day it landed #8793 at 12:22, so #8237's tree already contains #8793's composer restructure. Every ThreadComposer conflict here was that restructure re-arriving as context, not the attachment feature. Pylon declined it in #223 to keep ComposerToolbarScroller and the thirteen toolbar controls that need it, so it is declined again — useLayoutEffect (used only by the ComposerSurface radius animation) and the collapsed-row wrapper are not taken.

Upstream's conflict side also carried copies of Pylon's attachment strip and stop/send blocks. Pylon's own copies sit below the conflict as context and include ContextWindowIndicator, which upstream has no equivalent of — taking that side would have duplicated all three. The file-glyph rendering is ported into Pylon's block instead.

Review confirmed no Pylon features were lost: occurrence counts match origin/pylon exactly for ComposerToolbarScroller (10), ContextWindowIndicator (3), QuickQuestionTrigger (6), sessionGoal (14), renderCodexDirectivesForCopy (2), and all 12 ComposerToolbarButton instances. No duplication. Pylon identity intact across all three app variants.

A real bug this PR introduced and then fixed

Worth calling out because the first commit got it wrong.

onQueueFollowUp originally filtered files out, described as a queue limitation. It isn't one: Pylon's follow-up command already takes the same attachment union as thread.turn.start, its own contract comment says the server normalizer branches on "dataUrl" in attachment for both, and web passes identical attachments to followUpInputQueue and startTurn. The filter was a fix for a type error dressed as a design decision.

The consequence was silent data loss on an ordinary path — the composer's send button routes to handleQueueFollowUp whenever a session is running. Attaching a file mid-turn and pressing send filtered it from the payload, and because clearComposerDraftContent ran without deferAttachmentCleanup, the sweep then deleted the local copy. Composer cleared, message queued without the file, no warning, bytes gone.

Now mirrors onSendMessage: enforce the cap, validate against the server's advertised limits, upload via prepareTurnAttachments, defer cleanup until the queue call succeeds, release minted uploads and restore with allowOverflow on failure. This also makes the docs sentence "queued messages keep their files until they deliver" true, which it wasn't.

Pylon-first details

The four file glyphs use tintColorClassName="accent-icon-subtle" rather than upstream's hardcoded #a3a3a3. A first attempt subscribed to the theme directly and tripped no-mobile-uniwind-theme-escape-hatches — AppSymbol exists precisely so callers don't do that.

docs/user/composer.md was hand-merged to keep Pylon's voice and branding; upstream's text said "T3 Code".

Verification

@t3tools/mobile typecheck clean, lint clean, 1021 tests passing across 141 files (including 15 new test files this brings).

Not yet run on a simulator. The share-sheet path in particular wants a device pass.

Filed, not fixed

Three upstream design issues found in review, filed rather than folded in to keep this to one concern: #228 (share inbox has no cap, expiry, or way out), #229 (mixed image+file share skips the image size gate), #230 (one corrupt share file permanently disables attachment cleanup).

Reviewed and integrated with Claude Opus 5 in Claude Code.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[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	13.5 KiB	13.6 KiB	+45 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+41 B (+0.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.1 KiB	57.2 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+36 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	7.0 KiB	6.9 KiB	−10 B (−0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+46 B (+0.7%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 9d82e68 · PR result: 8221250 · 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: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

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