Report files dropped from /exec files[] by output limits (count, depth, size, path)

[danny-avila]

Problem

/exec can drop generated files from files[] with no marker in the response. The client can't tell "not generated" from "generated but dropped". artifact_delivery covers upload failures only (api/v2.ts, delivery.ts). These limits in api/src/job.ts skip files without it:

• Output file count: SANDBOX_MAX_OUTPUT_FILES (default 50) stops the scan once it's reached. Inherited refs only fill the slots left over.
• Nesting depth: directories at max_nesting_depth (default 10) or deeper are skipped.
• Path shape / length: paths failing isValidPathShape (max_path_length 256) are skipped.
• File size: files over SANDBOX_MAX_FILE_SIZE (default 10 MB) are skipped.
• Unreadable files: a failed stat skips the file.

An internal truncated status exists, but it never reaches the response.

Impact

LibreChat's create_file and the other sandbox authoring writes report success unless artifact_delivery is set (LibreChat-AI/LibreChat#15920, LibreChat-AI/LibreChat#15671). A file dropped by one of these limits is reported as written, but it isn't persisted for later calls or downloads.

Proposal

When the scan skips a file that would otherwise be returned, say so in the response. Either extend artifact_delivery, or add a sibling marker such as { code: 'artifact_truncated', reasons: { max_files, depth, size, path, unreadable }, skipped }. Ideally include the skipped relative paths, capped, so a client can match its own write against them.

Out of scope, since these are intentional and not failures:

• unsupported extensions
• hidden directories
• unchanged files that session-mode content-hash dedup leaves out

[Odrec]

We run this stack self-hosted (KVM/libkrun sandbox, http backend) behind LibreChat, and don't set SANDBOX_MAX_OUTPUT_FILES, so the default of 50 applies for us. Happy to help test a fix on a real deployment.

For what it's worth on prioritisation: I checked 30 days of logs on our busiest instance and found no evidence we've hit any of these limits, so I can't claim it bites us today — only that if it did, it would be indistinguishable from the failure mode in LibreChat-AI/LibreChat#15920. That's the part that makes it worth a marker rather than the frequency.

The reason it matters downstream: when a file goes missing from files[] without a marker, the model has no way to tell "not written" from "written but not returned", and it tends to invent an explanation. In an unrelated incident on our production host — the in-guest API couldn't reach egress_gateway, so every file was pruned — the model told the user /mnt/data was out of disk space, which was false; the host had ~100 GB free. A marker the model can see avoids that class of confabulation entirely.