feat(server): accept PDF, ZIP, and other file uploads up to 50MB by rynfar · Pull Request #140 · pylon-code/pylon

rynfar · 2026-08-28T20:50:17Z

Adds the server contract, streaming upload, storage, and download support for
generic files up to 50 MiB. Pylon previously accepted images only.

Every attachment's absolute path goes into the turn text, and every attachment
now reaches the provider adapter, which decides what its provider ingests
natively. OpenCode sends images, text files, and PDFs up to 20 MB as native file
parts; the other adapters send images only and rely on the path line.

Adopted from T3 Code 8f49132214a40c85cf46bf5e3d8ea11c04a9610a
(pingdotgg/t3code#8235). 40 files.

Adaptation — Pylon has a sixth adapter

PrimeAgentAdapter needed the image-only guard the other five received. Upstream
has no Prime adapter, and Pylon's pushed every attachment into an ACP image
content block unconditionally. Once ProviderService started forwarding generic
files, a PDF would have been base64'd and sent as an image with
application/pdf as its mime type.

Prime runs models on Anthropic and OpenAI Codex, so images-only matches those
providers' own adapters, with generic files reaching the agent via the path line.

Unlike upstream, that guard ships with a test. Upstream added no coverage for
any of the five adapter guards it introduced — I checked. Pylon's uses the mock
ACP agent's existing T3_ACP_REQUEST_LOG_PATH hook to assert the prompt Prime
actually sends. Mutation-probed: removing the guard yields
expected [ 'image', 'image' ] to deeply equal [ 'image' ] — the PDF becoming a
second image block is exactly the bug.

Also: the cherry-pick dropped ProviderService.test.ts's EnvironmentId import,
which upstream no longer needs but Pylon's browser-credential test still uses.
That surfaced as a typecheck error, not a test failure.

docs/internals/providers.md keeps Pylon's Subscription capacity section and
gains upstream's Attachment access section, with Prime Agent listed among the
image-only providers.

Verification

vp test run across ProviderService.test.ts, AttachmentUpload.test.ts,
attachmentStore.test.ts, http.test.ts, assets.test.ts,
orchestration.test.ts, Normalizer.attachments.test.ts — 138 passed
vp test run apps/server/src/provider/Layers/PrimeAgentAdapter.test.ts — 5 passed
vp run -F t3 typecheck, -F @t3tools/contracts, -F @t3tools/web,
-F @t3tools/mobile — all clean
vp lint on every file I hand-resolved — clean

Risks you should weigh before merging

I flagged these when recommending deferral; you chose to adopt, so here they are
on the record rather than dropped:

No client can attach a file yet. The web and mobile file pickers are
upstream #8236 and #8237, and both are still OPEN. This ships server
support with no UI to exercise it.
Wire compatibility is one-way. Upstream's own PR warns that older clients
cannot decode file-bearing messages, and that an older server can fail
startup for a whole environment when replay reaches one — not just for the
affected thread. Pylon's mobile app ships independently through EAS, so an
updated server against an older installed Pylon mobile build is a realistic
break, and rollback is not per-thread.

Neither is a reason not to merge, but #2 in particular argues for landing this
before any Pylon mobile release rather than after.

Claude Opus 5 via Claude Code.

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

github-actions · 2026-08-28T20:55:37Z

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.3 KiB	13.3 KiB	+35 B (+0.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+1 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.4 KiB	6.4 KiB	+34 B (+0.5%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	55.5 KiB	55.6 KiB	+44 B (+0.1%)	66.4 KiB	✅
Codex	Live turn messages	9	10	+1 (+11.1%)	21	✅
Claude	Total thread wire	13.3 KiB	13.3 KiB	−26 B (−0.2%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+12 B (+0.2%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.5 KiB	6.4 KiB	−38 B (−0.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	56.4 KiB	56.4 KiB	−44 B (−0.1%)	66.4 KiB	✅
Claude	Live turn messages	11	10	−1 (−9.1%)	21	✅

Baseline: 3d6035f · PR result: a570ecc · 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.4 KiB
Claude decoded thread snapshot: 110.1 KiB

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

rynfar · 2026-08-28T23:03:40Z

Independent review pass found two real defects. One fixed, one documented.

Fixed in 70d4fb32c — the guard was on the wrong Prime adapter.

Pylon has two: PrimeAgentAdapter and PrimeAgentDaemonAdapter, and
PrimeAgentDriver.ts:286 selects the daemon one whenever Prime Agent runs its
daemon backend. I had guarded only the first, so the exact bug this PR claims to
fix was still live on the path most Prime users take — at both of the daemon
adapter's attachment loops, sendTurn and followUp.

Now guarded at both sites, with a test on the sendTurn path: the fake runtime
already records prompt images, so it pins the mime types actually sent. Removing
the guard fails it with ['image/png', 'application/pdf'] against
['image/png'].

I also audited every adapter that resolves attachment paths rather than assuming
the set was complete. Cursor, Claude, and both Prime adapters use the negative
guard; Codex and Grok use a positive attachment.type === "image" filter,
which my first grep missed. OpenCode is intentionally unfiltered because it
ingests files natively.

Documented, not fixed — generic files are silently lost on the follow-up path.

ProviderService.followUp does not build the [Attached … is saved at: …] path
lines that sendTurn builds. With the adapter guard in place, a generic file
attached to a queued follow-up is therefore dropped entirely: not ingested
natively, and not surfaced as a path either. The agent never learns it exists.

This is inherited, not introduced — upstream's ProviderService has
attachmentPathLines only in sendTurn too. It is also not yet reachable in
practice, since no client can attach a generic file until upstream #8236/#8237
ship. But it becomes a real data-loss path the moment they do, so it should be
closed before the file pickers land rather than after.

Adds the server contract, streaming upload, storage, and download support for generic files up to 50 MiB. Previously only images were accepted. Every attachment's absolute path goes into the turn text, and every attachment now reaches the provider adapter, which decides what its provider ingests natively. OpenCode sends images, text files, and PDFs up to 20 MB as native file parts; the other adapters send images only and rely on the path line. Adopted from T3 Code 8f49132214a40c85cf46bf5e3d8ea11c04a9610a (pingdotgg/t3code#8235). Adaptation: PrimeAgentAdapter needed the image-only guard the other five adapters received. Upstream has no Prime adapter, and Pylon's pushed every attachment into an ACP image content block unconditionally - so once ProviderService started forwarding generic files, a PDF would have been base64'd and sent as an image with application/pdf as its mime type. Prime runs models on Anthropic and OpenAI Codex, so images-only matches those providers' own adapters. Unlike upstream, that guard ships with a test. The mock ACP agent's existing request log is used to assert the prompt Prime actually sends. The cherry-pick also dropped ProviderService.test.ts's EnvironmentId import, which upstream no longer needs but Pylon's browser-credential test still uses. docs/internals/providers.md keeps Pylon's Subscription capacity section and gains upstream's Attachment access section, with Prime Agent listed among the image-only providers.

Review follow-up. The image-only guard was added to PrimeAgentAdapter but not to PrimeAgentDaemonAdapter, which PrimeAgentDriver selects whenever Prime Agent runs its daemon backend. Both of its attachment loops - sendTurn and followUp - read any attachment into memory and pushed it as an ACP image block, so a PDF would have been base64'd and sent with application/pdf as its mime type. That is the exact bug the original guard was for, still live on the path most Prime users take. Guards both sites and asserts the sendTurn one: the fake runtime already records prompt images, so the test pins the mime types actually sent. Removing the guard fails it with ['image/png', 'application/pdf'] against ['image/png']. Audited the remaining adapters rather than assuming: Cursor, Claude, Codex, Grok, and both Prime adapters now filter, Codex and Grok through a positive attachment.type === "image" filter rather than the negative guard. OpenCode is intentionally unfiltered because it ingests files natively.

rynfar · 2026-08-28T20:50:17Z