[richiemcilroy]

A transcript created from a URL that does not point to an audio or video file now fails as soon as its first bytes arrive. Before, Cap downloaded and stored the whole file, up to 2 GB, before failing it. The failure code and message are unchanged, and it is still never charged.

What changed

After the credit hold and before anything is stored, the download reads the first 4 KB of the response. It runs the same check that extraction already runs on the stored file (sniffMedia). If those bytes are not a self-contained audio or video file, such as an HTML page, a playlist or anything else, the download is cancelled and the transcript ends with unsupported_format and "The file is not a supported audio or video format". Otherwise the bytes that were read are passed back in front of the rest of the stream, so the stored file is identical.

• An empty response still ends with source_unreachable, as before.
• Upload sources are unchanged. They are still checked when extraction starts.
• The check after storing stays, so a file is never extracted unless it passed.

Measured

Each failing source was run through the real download step, with a local origin that sends the file as fast as it is read:

Source	Main: read from origin	Main: stored	This change: read	This change: stored
2 GB declared, not media	2,147,483,648 bytes	2,147,483,648 bytes	48,825 bytes	0
100 MB declared, not media	104,857,600 bytes	104,857,600 bytes	65,366 bytes	0
40 KB HTML page	40,000 bytes	40,000 bytes	40,000 bytes	0
2 GB video with no audio track	2,147,483,648 bytes	2,147,483,648 bytes	unchanged	unchanged

The check needs 4 KB. The tens of kilobytes read are the first network chunks the HTTP client delivers before the connection is cancelled. On main the 2 GB case took 0.58 s locally to fail; with this change it fails in 0.01 s.

Proof

What	Result
New download tests run against main's workflow	3 fail (HTML page, playlist, random bytes are stored before failing)
The same on this branch	12 of 12 pass, including a media file stored byte for byte, one shorter than 4 KB, and an empty response
Developer, infra and agent unit suites	2,108 pass
Real MySQL scratch database	transcripts and holds suites 32 of 32
Typecheck and Biome	clean, apart from one known unrelated typecheck error

The download tests' fake origin now starts its file with an MP3 tag so that it counts as media, and the test mocks of the media check keep the real sniffMedia.

Not covered

• A video with no audio track is a real file the customer chose to send, so it is still downloaded in full before it fails. Its cost is bounded by the 2 GB source limit. A per-app daily cap on failed source bytes is a possible follow-up if usage ever shows abuse. It is not built here.
• This changes the same workflow file as feat(infra): transcribe a stored video by id and write its captions #4134, fix(infra): charge transcripts deleted during speech and cap running transcripts per app #4143 and perf(infra): finish a short transcript in one workflow step #4147. Whichever lands later merges it.

Confidence Score: 5/5

The PR appears safe to merge.

Summary

URL transcripts now check their first 4 KB before storing the download.

• URL transcript downloads reject non-media sources before storing them.

No actionable issues were found. This review checked source code; it did not run tests.

_{Reviews (1) · Last reviewed commit: "test(infra): cover URL sources refused f..." · Reviewed by Greptile}

[capy-ai]

Capy found no issues.

View 1 other finding in Capy.

[sandchest-com]

Sandchest reviewed 64dcef3: nothing exploitable found in this change.

_{Sandchest reviews every change for vulnerabilities an attacker could use · 6 credits · Review details}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
cap-status	Skipped		Nov 13, 2026 4:31am UTC

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found no issues.

[capy-ai]

Capy found no issues.