test(copilot): pin the read caps, and correct what the limits actually claim

Audit follow-up. No behaviour change; the code was right and the comments
explaining it were not.

Measured the bomb through this exact pipeline rather than reasoning about it
(100MP/256MP/576MP/1024MP): libvips decodes sequentially, so peak RSS stays
flat in the tens of MB no matter what the header declares. What scales is CPU,
roughly linearly — ~240ms at 100MP, ~1.35s at 1024MP, once per resize rung. The
pixel budget is a CPU bound, not the memory bound the comment described, and the
"~400MB raster" arithmetic was wrong by an order of magnitude.

- say that, with the measurements, so the next reader tunes against the real cost
- stop claiming the source byte cap covers everything a user can upload: presigned
  and multipart accept gigabytes, so an image above it is stored fine and simply
  cannot be read inline. Deliberate trade, now stated as one
- correct the resize-ladder comment, which asserted the failure is always a decode
  when the try also wraps the encoder
- correct two claims in read-placeholders: the handler does pull the VFS, and the
  oversized set excludes an image size refusal it said it included

Tests: cover the document and compiled-artifact size refusals (the document one
was the newest behaviour change and had no coverage at all), the text and
document download caps, and that the cap is handed to the download rather than
merely producing the right message. Placeholder cases are built from the
producers instead of hand-copied — a literal only proves the matcher agrees with
the test, which is the drift this module exists to prevent.

Author: waleedlatif1

apps/sim/lib/copilot/tools/handlers/vfs.test.ts

@@ -51,6 +51,7 @@ vi.mock('./upload-file-reader', () => ({
 }))
 
 import { WorkspaceFileGrepError } from '@/lib/copilot/vfs/operations'
+import { readPlaceholder } from '@/lib/copilot/vfs/read-placeholders'
 import { executeVfsGlob, executeVfsGrep, executeVfsRead } from './vfs'
 
 const OVERSIZED_INLINE_CONTENT = 'x'.repeat(TOOL_RESULT_MAX_INLINE_CHARS + 1)
@@ -179,31 +180,41 @@ describe('vfs handlers oversize policy', () => {
     expect((result.output as { attachment?: { type: string } })?.attachment?.type).toBe('file')
   })
 
-  it('fails oversized image placeholder when image exceeds size limit', async () => {
+  /**
+   * Every size refusal is a failed read, whichever path produced it. Built from the
+   * producers so a prefix leaving `OVERSIZED_PREFIXES` fails here rather than
+   * silently downgrading a refusal to a one-line "successful" read.
+   */
+  it.each([
+    ['image', readPlaceholder.imageTooLarge('huge.png', 99, 5)],
+    ['file', readPlaceholder.fileTooLarge('huge.txt', 99, 5)],
+    ['document', readPlaceholder.documentTooLarge('huge.pdf', 99, 5)],
+    ['compiled artifact', readPlaceholder.compiledArtifactTooLarge('app.js', 99, 5)],
+  ])('fails the read when a %s exceeds its size limit', async (_kind, content) => {
     const vfs = makeVfs()
-    vfs.readFileContent.mockResolvedValue({
-      content: '[Image too large to read inline: huge.png (26214401 bytes, limit 26214400)]',
-      totalLines: 1,
-    })
+    vfs.readFileContent.mockResolvedValue({ content, totalLines: 1 })
     getOrMaterializeVFS.mockResolvedValue(vfs)
 
     const result = await executeVfsRead(
-      { path: 'files/huge.png/content' },
+      { path: 'files/huge/content' },
       { userId: 'user-1', workflowId: 'wf-1', workspaceId: 'ws-1' }
     )
 
     expect(result.success).toBe(false)
-    expect(result.error).toContain('too large')
+    // The placeholder verbatim, not the generic "grep this instead" fallback.
+    expect(result.error).toBe(content)
   })
 
   it('returns an undecodable image placeholder as content, not as a size failure', async () => {
     const vfs = makeVfs()
     // Not a size problem — the bytes were read fine and the reason is already in the
     // message, so the model should see it rather than a "too large, use grep" error.
-    vfs.readFileContent.mockResolvedValue({
-      content: '[Image unavailable: bomb.png (90 Bytes). It is too large to decode safely.]',
-      totalLines: 1,
-    })
+    const content = readPlaceholder.imageUnavailable(
+      'bomb.png',
+      90,
+      'It is too large to decode safely.'
+    )
+    vfs.readFileContent.mockResolvedValue({ content, totalLines: 1 })
     getOrMaterializeVFS.mockResolvedValue(vfs)
 
     const result = await executeVfsRead(
@@ -212,6 +223,7 @@ describe('vfs handlers oversize policy', () => {
     )
 
     expect(result.success).toBe(true)
+    expect((result.output as { content?: string })?.content).toBe(content)
   })
 
   it('reads canonical file leaf metadata without fetching dynamic content', async () => {

apps/sim/lib/copilot/vfs/file-reader.test.ts

@@ -17,6 +17,8 @@ vi.mock('@/lib/uploads/contexts/workspace/workspace-file-manager', () => ({
 import {
   MAX_IMAGE_READ_BYTES,
   MAX_IMAGE_SOURCE_BYTES,
+  MAX_PARSEABLE_READ_BYTES,
+  MAX_TEXT_READ_BYTES,
   readFileRecord,
 } from '@/lib/copilot/vfs/file-reader'
 import { PayloadSizeLimitError } from '@/lib/core/utils/stream-limits'
@@ -108,8 +110,41 @@ describe('readFileRecord', () => {
     expect(result?.content).toContain('Image too large to read inline')
     // The observed size, not the understated 1024 the cap exists to distrust.
     expect(result?.content).toContain(`${MAX_IMAGE_SOURCE_BYTES + 5_000} bytes`)
+    // And the cap was actually handed to the download — the placeholder alone would
+    // still appear if the argument were dropped, since the mock rejects regardless.
+    expect(fetchWorkspaceFileBuffer).toHaveBeenCalledWith(expect.anything(), {
+      maxBytes: MAX_IMAGE_SOURCE_BYTES,
+    })
   })
 
+  it.each([
+    ['text', 'notes.txt', 'text/plain', MAX_TEXT_READ_BYTES, 'File too large to display inline'],
+    [
+      'document',
+      'report.pdf',
+      'application/pdf',
+      MAX_PARSEABLE_READ_BYTES,
+      'Document too large to parse inline',
+    ],
+  ])(
+    'caps the %s download and reports the observed size when it breaches',
+    async (_kind, name, type, cap, expected) => {
+      fetchWorkspaceFileBuffer.mockRejectedValue(
+        new PayloadSizeLimitError({
+          label: 'workspace file',
+          maxBytes: cap,
+          observedBytes: cap + 7_000,
+        })
+      )
+
+      const result = await readFileRecord(imageRecord(name, 1024, type))
+
+      expect(result?.content).toContain(expected)
+      expect(result?.content).toContain(`${cap + 7_000} bytes`)
+      expect(fetchWorkspaceFileBuffer).toHaveBeenCalledWith(expect.anything(), { maxBytes: cap })
+    }
+  )
+
   it('reports an oversized HEIF as a size refusal, not as a corrupt file', async () => {
     // `ftyp`+`heic` brand, past the WebAssembly transcoder's own tighter ceiling.
     const heif = Buffer.alloc(MAX_TRANSCODE_INPUT_BYTES + 1)

apps/sim/lib/copilot/vfs/file-reader.ts

@@ -47,25 +47,33 @@ export const MAX_IMAGE_READ_BYTES = 5 * 1024 * 1024 // 5 MB
 // Parseable-document byte cap. Large office/PDF files can still
 // produce huge extracted text; reject up front to avoid wasting a
 // download + parse only to blow past the tool-result budget.
-const MAX_PARSEABLE_READ_BYTES = 5 * 1024 * 1024 // 5 MB
+export const MAX_PARSEABLE_READ_BYTES = 5 * 1024 * 1024 // 5 MB
 /**
- * Source-image byte ceiling, checked before the download and enforced by it. A
- * workspace file may be up to {@link MAX_WORKSPACE_FILE_SIZE}, and buffering one of
- * those whole would exhaust memory on its own — the pixel budget below bounds the
- * decode, not the transfer.
+ * Source-image byte ceiling, checked before the download and enforced by it. This
+ * route holds the whole file in worker memory, so it reuses the ceiling the FormData
+ * upload route set for that same failure mode rather than inventing a number.
  *
- * Deliberately the FormData upload ceiling rather than a number of its own: that cap
- * exists for exactly this failure mode (a route holding an entire file in worker
- * memory), so anything a user could upload through it stays readable here. Picking
- * something tighter would refuse images that read fine today for no security gain —
- * a decompression bomb is small, and it is the pixel budget that stops it.
+ * It does NOT cover everything a user can store: presigned and multipart uploads
+ * accept up to `MAX_WORKSPACE_FILE_SIZE` (gigabytes), so an image above this ceiling
+ * is stored fine and simply cannot be read inline. That is a deliberate trade — the
+ * alternative is buffering a multi-gigabyte file to answer one read — and it is a
+ * memory budget, not part of the decompression-bomb defence, which is the pixel
+ * budget below. A bomb is small; no byte cap would catch it.
  */
 export const MAX_IMAGE_SOURCE_BYTES = MAX_WORKSPACE_FORMDATA_FILE_SIZE
 /**
- * Pixel ceiling on the decoded raster. libvips materialises the whole raster, and
- * an allocation this large OOM-kills the process rather than throwing, so it has to
- * be refused up front. 100MP caps the decode near 400MB while clearing every real
- * camera — a 48MP iPhone still is 8064x6048.
+ * Pixel ceiling on the decoded image, and the actual decompression-bomb defence: a
+ * few hundred KB of PNG can declare an arbitrarily large raster.
+ *
+ * The cost it bounds is CPU, not memory. libvips decodes this pipeline sequentially,
+ * so peak RSS stays flat (tens of MB) no matter what the header declares — measured
+ * on this exact pipeline, 100MP..1024MP all sat under ~120MB. What scales is time,
+ * roughly linearly: ~240ms at 100MP, ~1.35s at 1024MP, once per resize rung. So the
+ * budget caps what one read can burn, and the `break` below caps how many rungs a
+ * failing image gets.
+ *
+ * 100MP clears every single-shot camera (a 48MP iPhone still is 8064x6048) but will
+ * refuse a stitched gigapixel panorama, which is the known cost of the ceiling.
  */
 const MAX_IMAGE_INPUT_PIXELS = 100_000_000
 const MAX_IMAGE_DIMENSION = 1568
@@ -381,9 +389,13 @@ async function prepareImageForVision(
                 }
               }
             } catch (err) {
-              // Next dimension, not next quality: the quality rungs re-decode the
-              // identical source, so repeating a failed decode there is pure waste.
-              // A smaller dimension is worth trying — libvips shrinks JPEG on load.
+              // Next dimension, not next quality: every quality rung re-decodes the
+              // same source and only varies the encoder, so a failure here almost
+              // always repeats. Dropping a dimension is the one thing that can change
+              // the outcome (JPEG shrinks on load), and it bounds a bomb at 4 decodes
+              // instead of 16. A genuinely encoder-only failure would lose its lower
+              // quality rungs at that dimension — no such failure mode is known, and
+              // 4 attempts is the deliberate ceiling.
               logger.warn('Failed image resize attempt for VFS read', {
                 mediaType,
                 dimension,

apps/sim/lib/copilot/vfs/operations.test.ts

@@ -3,6 +3,7 @@
  */
 import { describe, expect, it } from 'vitest'
 import { glob, grep, grepReadResult, WorkspaceFileGrepError } from '@/lib/copilot/vfs/operations'
+import { readPlaceholder } from '@/lib/copilot/vfs/read-placeholders'
 
 function vfsFromEntries(entries: [string, string][]): Map<string, string> {
   return new Map(entries)
@@ -200,21 +201,42 @@ describe('grepReadResult placeholders', () => {
     grepReadResult('files/x.png/content', { content, totalLines: 1 }, 'x', 'files/x.png/content')
 
   /**
-   * Every `readFileRecord` placeholder carries no searchable text, so grep must
-   * report the placeholder rather than matching against its own prose.
+   * Built from the producers rather than hand-copied: a literal here would only
+   * prove the matcher agrees with this file, which is exactly the drift that let a
+   * gate test for a prefix no producer emitted. Covers every builder, so dropping
+   * one from the shared table fails here.
    */
-  it.each([
-    '[Image unavailable: bomb.png (90 Bytes). It is too large to decode safely.]',
-    '[Image too large to read inline: huge.png (26214401 bytes, limit 26214400)]',
-    '[File too large to display inline: big.txt (99 bytes, limit 5)]',
-    '[Document too large to parse inline: big.pdf (99 bytes, limit 5)]',
-    '[Binary file: app.bin (application/octet-stream, 10 bytes). Cannot display as text.]',
-  ])('reports %s instead of grepping it', (content) => {
-    expect(() => grepPlaceholder(content)).toThrow(WorkspaceFileGrepError)
-    expect(() => grepPlaceholder(content)).toThrow(content)
-  })
+  const everyPlaceholder = Object.entries({
+    fileTooLarge: readPlaceholder.fileTooLarge('big.txt', 99, 5),
+    imageTooLarge: readPlaceholder.imageTooLarge('huge.png', 99, 5),
+    imageUnavailable: readPlaceholder.imageUnavailable('bomb.png', 90, 'It could not be decoded.'),
+    documentTooLarge: readPlaceholder.documentTooLarge('big.pdf', 99, 5),
+    compiledArtifactTooLarge: readPlaceholder.compiledArtifactTooLarge('app.js', 99, 5),
+    couldNotParse: readPlaceholder.couldNotParse('x.pdf', 'application/pdf', 10),
+    binaryFile: readPlaceholder.binaryFile('app.bin', 'application/octet-stream', 10),
+  })
+
+  it.each(everyPlaceholder)(
+    'reports the %s placeholder instead of grepping it',
+    (_name, content) => {
+      expect(() => grepPlaceholder(content)).toThrow(WorkspaceFileGrepError)
+      expect(() => grepPlaceholder(content)).toThrow(content)
+    }
+  )
 
   it('still greps ordinary single-line content', () => {
     expect(grepPlaceholder('x marks the spot')).toHaveLength(1)
   })
+
+  it('greps a real multi-line file that merely opens like a placeholder', () => {
+    // The single-line guard is what keeps this file searchable rather than swallowed.
+    const content = `${readPlaceholder.binaryFile('app.bin', 'text/plain', 10)}\nx marks the spot`
+    const matches = grepReadResult(
+      'files/notes.txt/content',
+      { content, totalLines: 2 },
+      'x',
+      'files/notes.txt/content'
+    )
+    expect(matches.length).toBeGreaterThan(0)
+  })
 })

apps/sim/lib/copilot/vfs/read-placeholders.ts

@@ -3,8 +3,6 @@
  * predicates that classify them. Producers and matchers live in different modules;
  * hand-written copies of the same prefix are how an oversized image once slipped past
  * the read-size gate, which tested for a prefix no producer emitted.
- *
- * Keep free of heavy imports — the tool handlers pull it in without wanting the VFS.
  */
 
 import { formatFileSize } from '@/lib/uploads/utils/file-utils'
@@ -39,16 +37,15 @@ export const readPlaceholder = {
 } as const
 
 /**
- * Placeholders standing in for content that exists but exceeded a read cap; the read
- * handler turns these into a tool error.
+ * Placeholders meaning "the file is there, but reading it was refused on size"; the
+ * read handler turns these into a tool error rather than a one-line success.
  *
- * Every size refusal belongs here — a document that breaches its cap is the same
- * kind of answer as a file or an image that does, and reporting one of the three as
- * a successful read was an inconsistency, not a distinction.
+ * File, image, document and compiled artifact all belong here — reporting one of
+ * the four as a successful read was an inconsistency, not a distinction.
  *
- * Deliberately narrower than {@link isNonGreppablePlaceholder}: a parse failure or
- * a binary file is not a size problem, and `[Image unavailable:` covers undecodable
- * images as well as oversized ones, so neither belongs on the size path.
+ * `[Image unavailable:` is excluded even though one of its reasons is a size, because
+ * its other reasons are not: it also covers an undecodable or unsupported image, and
+ * those are answers rather than refusals. Callers get it as content.
  */
 const OVERSIZED_PREFIXES = [
   PREFIX.fileTooLarge,