Repository navigation
Viewing local GIF files crashes/ruins the CLI session #2468
Description
Bug Description
Viewing (or referencing) a local GIF file in a Copilot CLI session causes the session to become unresponsive or enter an unrecoverable error state.
Steps to Reproduce
- Start a Copilot CLI session
- Ask Copilot to view or reference a local
.giffile (e.g.viewtool on a GIF attachment) - The session becomes stuck — high CPU usage, excessive memory consumption, and no further interaction is possible
Observed Behavior
- The
viewtool attempts to base64-encode the entire GIF file (including all animation frames) and inject it into the conversation context - For animated GIFs, this produces a massive base64 payload that either:
- Floods the context window, leaving no room for model reasoning
- Triggers an error loop that the session cannot recover from
- The stuck process consumes ~36% CPU and ~957 MB RAM indefinitely
- The only recovery is to
killthe process manually
Expected Behavior
- The CLI should detect animated GIF files and either:
- Extract and display only the first frame
- Return file metadata (size, dimensions, frame count) without dumping the full base64 payload
- Reject the file with a helpful message (e.g. "Animated GIFs are not supported, use a static image format")
- Large image files in general should have a size guard to prevent context flooding
Environment
- Copilot CLI version: 1.0.10 (confirmed), likely also affects 1.0.15
- OS: macOS (Darwin, Apple Silicon)
- GIF file sizes tested: ~240 KB and larger (wiki attachments)
Workarounds
- Avoid using
viewon.giffiles - Use
ls -lh file.giforfile file.gifto inspect GIF files safely - Convert GIFs to single-frame PNG before viewing:
ffmpeg -i file.gif -frames:v 1 frame.png
Activity
EdwinGarcia commentedon May 15, 2026
Here's my +1 to this issue.
gradual multi-turn image accumulation triggers the same failure mode
This isn't limited to single large files, my sessions crash and get corrupted where I can't resume them and reach the same unrecoverable state when many normal-sized images (screenshots, PNGs) accumulate across a long session.
I had a 78-turn session doing screenshot-based reference work. Each turn included a pasted screenshot (~copilot-image temp PNGs), some turns also referenced art files in a local directory. Everything worked fine through ~turn 76. By turn 77, the session started showing (repeated once per prior image in the conversation history)
! Images and/or native document attachments were removed from the request due to size constraints.Followed by:Request failed due to a transient API error. Retrying...By turns 77-78, assistant responses were completely empty (NULL) -- the session was permanently dead. No recovery possible without starting a new session.
Root cause is the same: inline base64 image payloads accumulate in the conversation history sent with each API request for some reason. Unlike text, which compacts relatively well, images are enormous and grow linearly with turn count. There's no eviction or out-of-line storage for old image payloads.
Can we get something that
Related issues: #965 (single large PNG → 413), microsoft/vscode#295334 (long session + PNG → renderer crash), microsoft/copilot-intellij-feedback#1242 (multi-turn image → permanent 413)
Environment: Copilot CLI 1.0.49, Windows
copilot-cli-bot commentedon Oct 26, 2026
This appears to be resolved as of GitHub Copilot CLI v1.0.103. Please update to that release or a newer stable version. We're closing this as completed. If it still happens, please comment with your version and reproduction steps.