Kaede AkinoandClaude Opus 5
ccd539fb33
fetch returns a page through the conversation, bounded at 256 KB. So a page larger than that could not be read at all — the tail was truncated and there was no second call that would reach it — and a page you meant to refer back to was paid for twice, once to read and again to quote into a file. scratch_pull already solved this for hosts: it lands a remote file in the workspace and returns a size and a digest, which is what lifts sftp_read's inline ceiling. The network had no equivalent. scratch_fetch is that, and its bound is the workspace's own 8 MB per-file limit rather than what fits in a reply — so a large page arrives whole and is read a window at a time with scratch_read. A separate tool rather than a scratch_path on fetch, on the same grounds scratch_pull and scratch_push were split out of sftp_read and sftp_write. The flag would decide the tool's Safety — locallyReadOnly without it, locallyContained with it — and one descriptor meaning two things is harder for a model to choose correctly and harder to audit. fetch is unchanged, byte for byte, so nothing already in a conversation's history changes meaning. locallyContained is the sum of its halves: reading a page, public or private-network, is what fetch already does un-gated and never escalates for, and the landing site is storage the app owns. It therefore needs no approval and stays available while planning, which is right — staging the documentation you are planning against is planning. The result carries the title, size and digest and no page text; the title is enough to confirm the right page arrived. Both paths are proven in preflight, so a bad URL or a destination that escapes the scope costs nothing rather than a page fetched and dropped. An empty extraction fails instead of staging a zero-byte file the model would then try to read. 851 tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>