CSO: 64 MiB snapshot cap blocks full-repository audits; manifest and reader caps also limit coverage #2993

Summary

A full-repository static audit stops during snapshot admission, before a run ID or assessment is returned, because the repository exceeds the fixed 64 MiB source limit. Two additional fixed 1 MiB limits would need to be accounted for in a supported larger-repository path.

This is a capacity/prerequisite report, not a claim of a security vulnerability or a request to bypass the trusted launcher.

Version and observation boundary

• Current installed gstack and upstream main, checked 2026-09-29: v1.91.6.0, commit 65bfb0ce49da807698359ca033a05709e342c684 (package version 1.91.6); CSO skill version 3.0.0.
• The actual failed launcher invocation was recorded on 2026-09-28, before that upgrade. No identical audit was restarted afterward. Inspection of the current installed and upstream source confirms that the limits below remain unchanged.
• The relevant installed helper source files are unmodified. No source pruning, helper patch, or alternate-launcher workaround was used.

Observed behavior

On a clean Git working tree, the trusted launcher's static/offline start was invoked with this shape (paths replaced):

<trusted-install>/bin/gstack-cso-launcher start --repo <repository> --offline --budget 600

It exited 1 before returning a run ID:

{"ok":false,"error":{"code":"MISSING_INPUT","message":"Source exceeds the 64 MiB snapshot admission limit"}}

Sanitized aggregate metadata for that frozen repository snapshot:

The manifest size is an independent metadata estimate, not an observed second launcher failure. The original run stopped at the aggregate limit. Likewise, the large-file count is not a claim that all those files are executable source; their handling and any coverage gaps still need explicit accounting.

Current-source constraints

Pinned to the version above:

1. snapshot.ts fixes the source limit at 64 MiB; aggregate bytes are checked during capture at lines 194–196.
2. The same file withholds payloads over 1 MiB and rejects serialized manifests over 1 MiB. Raising only the aggregate cap would not address these separate limits.
3. parseStart and start provide no source-byte override; capture precedes scope/diff assessment, so those flags do not reduce aggregate admission in this implementation.
4. doctor's static-snapshot readiness checks Git-working-tree availability, not whether the full snapshot fits. A ready result therefore does not establish admission.

Request

Is there a supported trusted path for complete larger-repository audits? If not, please consider a bounded upstream implementation that:

• Admits larger aggregates and manifests without silently shrinking the source inventory.
• Provides safe, reviewable redacted handling for larger files, or explicitly reports remaining unread coverage.
• Preserves path/hash identity, race checks, redaction, private state and resource limits; does not turn partial coverage into a complete result.
• Exposes these admission prerequisites in doctor/preflight or documents clearly that static readiness is not an admission check.

The 64 MiB limitation is also mentioned under “Related limits” in #2912; this report isolates the capacity issue from that issue's redaction defect. Qualified scanner/runtime availability is a separate prerequisite, including #2940, and is not claimed to be solved by larger snapshots.

No application source, repository name or path, private commit, raw manifest, candidate data, credentials or raw private logs are attached.