Viewing local GIF files crashes/ruins the CLI session

[nnamuhcs]

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

1. Start a Copilot CLI session
2. Ask Copilot to view or reference a local .gif file (e.g. view tool on a GIF attachment)
3. The session becomes stuck — high CPU usage, excessive memory consumption, and no further interaction is possible

Observed Behavior

• The view tool 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 kill the 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 view on .gif files
• Use ls -lh file.gif or file file.gif to inspect GIF files safely
• Convert GIFs to single-frame PNG before viewing: ffmpeg -i file.gif -frames:v 1 frame.png