Summary
When an attachment pushes the model request over CAPI Responses' native size limit (5 MB), the turn fails with:
Error: The attached image or document is too large to send natively through CAPI Responses. Try a smaller attachment or fewer attachments. (9.1 MB request; 5.0 MB limit)
The CLI retries the model call 5× and then errors. The real problem is that the session never recovers: every subsequent turn fails identically, with no way to unstick it short of starting a new session.
Originally reported against the desktop client: github/app#788.
Root cause
Two issues combine into a permanently wedged session:
1. Oversized attachments poison conversation history. Once an attachment is inlined natively into a turn and the request exceeds the 5 MB limit, that attachment stays in the session's conversation history. Every later turn re-sends the full history (including the oversized blob), so the request stays over the limit and fails identically every time. The 5× model-call retry just burns time before surfacing the same error again on the next message.
2. Images have no size fallback; documents do. The session-event schema exposes nativeDocumentPathFallbackPaths and supportedNativeDocumentMimeTypes — oversized documents gracefully fall back to the path-based tagged_files flow. There is no equivalent path for images. An oversized image has nowhere to fall back to, so it just keeps failing natively.
Expected behavior
When an attachment would exceed the native request limit, the CLI should degrade gracefully instead of wedging the session. Options, roughly in order of preference:
- Down-scale / recompress oversized images before sending.
- Fall back to the path-based
tagged_files flow for oversized images, mirroring the existing document fallback.
- Evict or trim oversized inline content from history after a size failure, so the session can continue rather than re-sending the offending bytes on every subsequent turn.
Impact
A single oversized paste/drop/attachment (anything between ~5 MB and the client's upload ceiling) permanently breaks the session. Users perceive this as "the app is stuck repeating the same error and I can't recover."
Generated via Copilot (Claude Opus 4.8) on behalf of @tclem
Summary
When an attachment pushes the model request over CAPI Responses' native size limit (5 MB), the turn fails with:
The CLI retries the model call 5× and then errors. The real problem is that the session never recovers: every subsequent turn fails identically, with no way to unstick it short of starting a new session.
Originally reported against the desktop client: github/app#788.
Root cause
Two issues combine into a permanently wedged session:
1. Oversized attachments poison conversation history. Once an attachment is inlined natively into a turn and the request exceeds the 5 MB limit, that attachment stays in the session's conversation history. Every later turn re-sends the full history (including the oversized blob), so the request stays over the limit and fails identically every time. The 5× model-call retry just burns time before surfacing the same error again on the next message.
2. Images have no size fallback; documents do. The session-event schema exposes
nativeDocumentPathFallbackPathsandsupportedNativeDocumentMimeTypes— oversized documents gracefully fall back to the path-basedtagged_filesflow. There is no equivalent path for images. An oversized image has nowhere to fall back to, so it just keeps failing natively.Expected behavior
When an attachment would exceed the native request limit, the CLI should degrade gracefully instead of wedging the session. Options, roughly in order of preference:
tagged_filesflow for oversized images, mirroring the existing document fallback.Impact
A single oversized paste/drop/attachment (anything between ~5 MB and the client's upload ceiling) permanently breaks the session. Users perceive this as "the app is stuck repeating the same error and I can't recover."