Files SDK 1.7 adds resumable uploads, provider sync, and read-only clients

• haydenbleasel's release post says Files SDK 1.7 centers on safer file workflows and long-running transfers, with resumable uploads, provider sync, read-only clients, directory-style list(), and MCP hardening.
• The official 1.7.0 release notes add the most important implementation detail: sync() is an incremental mirror that can compare by size plus etag, prune deleted keys, and run as a dryRun, while haydenbleasel's source link points to the underlying repo.
• Resumable uploads are not just retry logic. Per the release notes, UploadControl can pause, resume, abort, and serialize state for continuation after a crash or reload, matching the long-transfer framing in haydenbleasel's post.
• Read-only mode now exists at both the client and MCP layer: the release notes say readonly: true blocks every write surface with a normalized ReadOnly error, and haydenbleasel's feature list pairs that with security hardening for MCP and adapters.

You can jump from haydenbleasel's docs link to the API overview, where the surface is still just nine core methods, then over to the 1.7.0 release notes, which are much more revealing about what actually changed. The small weird detail is that the security work is not abstract policy language. It includes capped AI-tool downloads, path-segment rejection for local and Microsoft Graph backed adapters, and an MCP server that now starts read-only unless --allow-writes is set in the release notes.

The two headline additions are aimed at jobs that fail halfway through real transfers. In the 1.7.0 release notes, sync() is an incremental mirror between providers, with optional pruning, dryRun, and parity across the SDK, CLI, and an MCP sync tool.

Uploads get a separate control surface. The same release notes say UploadControl can pause, resume, abort, and serialize progress with toJSON(), then restore the upload later with UploadControl.from(token).

The cleaner safety story is that read-only is now a first-class mode, not just convention. The release notes say readonly: true or files.readonly() leaves reads available but fails writes immediately with FilesError { code: "ReadOnly" }, before any adapter call happens.

That same patch set tightened the agent surface. According to the release notes and the AI docs, the MCP server now starts read-only by default, mutation tools require --allow-writes, and AI-tool download overrides are capped at 10 MiB.

list() also got more opinionated. The 1.7.0 release notes add a delimiter option that collapses keys into S3-style common prefixes and returns them in ListResult.prefixes, with matching behavior in the CLI and MCP server.

The interesting part is where that support stops. Adapters without any folder concept, including UploadThing, Appwrite, PocketBase, Convex, and Bun's S3, now advertise supportsDelimiter: false and throw instead of quietly flattening the result, which makes the cross-provider abstraction stricter than before.