[teamleaderleo]

The app's native side streams a file's raw bytes to the daemon as WebSocket binary frames: no base64, no size cap, a few frames of memory whatever the file's size. Stacked on #25793 (base is its branch). Contract: #25774, sections 1 and 1b.

Leo: "why the FUCK SHOULD THERE BE A FUCKING SIZE CAP ANYWAYS JUST FUCKING / I ALREADY SAID WE NEED ARBITARRILY LARGE FILES OF ANY TYPE". The spec: files of any type and size stream to disk in chunks, resumable, with progress; bytes never cross the page binding as base64; the peer hop is uncapped and resumable.

Change

src/server/upload_frames.rs, wired into the WebSocket reader in server/mod.rs:

• One binary frame is one _acpmux/file_put_data request: "AMUP", a u32 big-endian header length, the JSON-RPC header {"id", "method": "_acpmux/file_put_data", "params": {sessionId, uploadId, offset}}, then the raw bytes. The answer is an ordinary text response with the same id: {offset} once the bytes are on disk (file_uploads::append, shared with file_put_chunk), or the upload.* reasons from acpmux: resumable uploads report where they stand, check their bytes, and fail on size only when the disk is full #25793.
• One worker per connection writes frames in order from a queue of 4 (WINDOW). A sender may keep 4 in flight; past that the socket slows it. Stop condition: the worker ends when the connection's reader ends (its sender drops) or the writer closes.
• Only the local app's connection (Origin::LocalApp) may send frames. Any other gets filePut.remote as its answer, never silence (the original bug was an app bridge that dropped oversize calls unanswered).
• A text message on the same connection is read only after every frame before it is written and answered (InFlight: a count and a Notify; the worker releases what it holds when it ends). So a finish, status or prompt sent right behind the last frames sees all their bytes. A connection that sends no frames never waits.
• A chat on a peer: the bytes go to the peer that owns it as file_put_chunk requests of at most 512 KiB over the peer link, so the peer hop has no cap and resumes the same way (status and finish are forwarded). A peer that does not list filePutChunks is refused at begin and at every frame, before anything is sent.
• Feature uploadFrames; _acpmux/file_put_data is in the protocol registry.

Risk: contained to WebSocket binary frames, which the daemon dropped before. Text frames take the same path as before, except that on a connection with frames in flight they wait for those frames.

Tests

• tests/upload_frames.rs: a 6 MiB file in 1 MiB frames, 2 then 4 in flight, answered in order; the connection drops and a new one resumes from file_put_status; a stale frame is upload.offset with the resume offset; finish with sha256. A Web connection's frame is answered filePut.remote. A peer's chat gets the frames written on the peer, SHA-256 intact.
• a_finish_right_behind_its_frames_sees_every_byte: a finish sent right behind 5 unanswered frames (3 rounds) gets its answer after every frame's. Before the fix, the finish was answered ahead of 3 frames ([3, 4, 8] against [3, 4, 5, 6, 7, 8]).
• a_peer_without_chunked_uploads_is_refused_before_anything_is_sent: a peer listing filePut but not filePutChunks is refused filePut.unsupported at begin and at a frame, and gets nothing.
• tests/prompt_uploads_large.rs (Linux): a 2,000,000,000-byte file of no known type streamed the app's way (1 MiB frames, 4 in flight) to a busy chat, finished with its sha256, named in a prompt, then checked at the path the agent got.

Results (cmux-ci test, 32-vCPU Linux):

• acpmux: resumable uploads report where they stand, check their bytes, and fail on size only when the disk is full #25793's head plus these tests (run 40425675864, run 40426369589): fail: all 4 (no frame is answered: no answer to request 3 in 20 s; no uploadFrames feature).
• The two new tests on the previous head c4d9358b27b (run 40440049200): both fail, as above.
• This head 67d53596666 (rebased onto acpmux: resumable uploads report where they stand, check their bytes, and fail on size only when the disk is full #25793's 85a0b100709; run 40445691817): upload_frames 5 passed, send_attach 12, peer_integration 47, prompt_uploads_large 1, upload_resume 3, prompt_uploads 8, file_put 7, conn_auth 3, lib file_uploads/upload_frames/protocol 14, hub_integration protocol 1, cargo clippy -p acpmux --all-targets -D warnings clean.

2 GB: uploaded in 8.406496689s, accepted in 1.252289ms, sha256 7c0b933376ce085551dd57695c4a77881a2783679c5969eec9299817a02ecb41, peak RSS 62 MiB
50 screenshots: uploaded and accepted in 218.690875ms, accept 59.379628ms

Not in this PR: the native sender (its owner builds against this), and model-sized copies of large images per harness (next PR).

Agent session: agent session

🤖 Generated with Claude Code

[teamleaderleo]

Owned by an agent session · session

[blacksmith-sh]

Found 7 test failures on Blacksmith runners:

Failures

Test	View Logs
/tmp/tmpn7ehl082/summary-missing.json (live):/summary-missing.json (live):	View Logs
/tmp/tmpxacty1vc/summary-fail.json (live):/summary-fail.json (live):	View Logs
[new_workspaces] debug.new_workspace timed 0 of 50 new workspace rows/ [new_workspaces] debug.new_workspace timed 0 of 50 new workspace rows	View Logs
[new_workspaces] the window draws no frames/[new_workspaces] the window draws no frames	View Logs
[tabs] debug.tab_switch timed 0 of 40 switches/ [tabs] debug.tab_switch timed 0 of 40 switches	View Logs
[tabs] the window draws no frames/[tabs] the window draws no frames	View Logs
test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)/ test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)	View Logs

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

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

red: cmux-next checks (god files, concurrency, crash safety, l10n); no finished base run on e6adb7f to compare; do not merge until green; see lane-rules

[teamleaderleo]

Bead cx-e3m83 created for this PR by the cmux coordinator.

[github-actions]

The feat-cmux-next push run https://github.com/manaflow-ai/cmux/actions/runs/40458763715 at 9a52a3c failed: cmux-next generated files.
Those jobs last passed at 865b6c3. This pull request is one of 5 merged since: #25885, #25876, #25803, #25955, #25774.
If the failure is in your change, fix forward on feat-cmux-next. Pull requests run only the tiers their paths reach (docs/ci/cmux-next-tiers.md); label a batch PR full-ci to run them all before merging.

[github-actions]

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4048747891701 (2c7dda4036)
• cmux NEXT nightly 1.0.0-nightly.4048947256901 (273534101b)
• cmux NEXT nightly 1.0.0-nightly.4049353932801 (e7cbb89fab)