[Bug]: Antigravity reads images, PDFs, audio and video as UTF-8 text (view_file / client_view_file), so Gemini models never see media files #24969

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Put these local files in the workspace (synthetic fixtures, generated on macOS; each hides a word or number that can only be found by actually seeing or hearing the file):
   • imagem.png and imagem.jpg (800×500): a word, a number and a red triangle
   • documento.pdf: page 1 has a selectable text layer; page 2 is a raster image only
   • audio.wav and audio.mp3: a short pt-BR spoken sentence
   • video.mp4: H.264 + AAC, 6 s, two colored scenes with a word each, plus spoken audio
2. Start an Antigravity thread (tested with gemini-4-argon-medium and gemini-3.8-flash-medium).
3. Ask the agent to open each file with its native file tool, with shell/ffmpeg/OCR forbidden, and report what it perceives.

Expected behavior

Images (and ideally PDFs, audio and video, which the Gemini models support) reach the model as media, as they do for the other providers in the same T3 install. At minimum, a binary file should fail with a clear error instead of being returned as corrupted text.

Actual behavior

Both view_file and client_view_file return every file as a string like {"result": "�PNG\n\u001a\n\u0000\u0000..."}: the raw bytes decoded as UTF-8 with replacement characters. Nothing visual or audible reaches the model, and it reports "nothing perceived".

Same files, same machine and same T3 build, other providers:

The other providers either see the media or refuse it cleanly. Antigravity is the only one that silently returns corrupted text.

Root cause (read from the installed code; the fix itself is not tested)

There are two layers, and fixing only the T3 side does not restore vision.

T3 side. AntigravityAdapterV2.ts:128 enables clientFileSystem: true, and AntigravityAcpSupport.ts:60 advertises fs.readTextFile. AntigravityClientFiles.ts:55 then does:

const text = yield* input.fileSystem.readFileString(filePath);
return { content: text };

It checks workspace containment, symlinks, file type and the 8 MiB cap, but not MIME, NUL bytes or strict UTF-8. readFileString uses new TextDecoder(encoding) without fatal: true, so invalid bytes become �. fs/read_text_file is a text API (per the ACP spec), so returning binary as text is silent corruption. Note that AntigravityAcpSupport.ts:343–349 already has strict-UTF-8 and NUL checks for text attachments, which could be reused here.

Upstream (Google ACP runtime 1.3.0, agy_acp_server.par).

• server.py:3852 disables the built-in VIEW_FILE and installs tools.make_safe_view_file(...).
• That replacement opens every file with open(path, "r", encoding="utf-8", errors="replace") and returns str (tools.py:136–140), whether or not the client advertises readTextFile.
• client_view_file (tools.py:205–211) forwards every path to client.read_text_file.
• The SDK in the same package already has Image, Document, Audio and Video types, plus a supplemental_media path (event_processor.py:69–87, 965–988). The two readers never use it because they only return strings.

Suggested fix

1. T3: reject non-text content in the fs/read_text_file handler with a clear ACP error (strict UTF-8 plus a NUL check, reusing the attachment logic). This gives an honest "can't read binary" error, the same behavior as the other providers, instead of garbage that the model may hallucinate over.
2. Upstream: have the replacement view_file return Image, Document, Audio or Video objects for supported MIME types (the supplemental_media route already exists), and keep client_view_file for text only. If there's a channel to forward this to Google, it would be appreciated (similar to [Bug]: Antigravity ACP marks successful file reads as failed #20095).

Impact

Major degradation or frequent failure: the Gemini models are among the strongest multimodal models, but inside T3 they cannot look at a screenshot, PDF, audio or video file from the workspace, and they get no error that explains why.

Version or commit

T3 Code Nightly 0.1.3-nightly.20261025.3682 (commit 1eb4071a497c); managed Antigravity ACP runtime 1.3.0

Environment

macOS 27 (Apple Silicon), T3 Code Nightly desktop; Antigravity ACP provider; models gemini-4-argon-medium and gemini-3.8-flash-medium.

Workaround

For images, use another provider, or extract frames with ffmpeg and have a provider whose read tool returns images (Claude, Grok or Codex) look at them. For video, frames plus subtitles via yt-dlp work, but that loses motion and audio.

Related

• [Feature]: Native MP4 video understanding for Antigravity ACP (not file-path fallback) #17066: native MP4 understanding for Antigravity attachments (closed). This report is about the file-read tools, not prompt attachments.
• [Bug]: Antigravity ACP marks successful file reads as failed #20095: another ACP 1.3.0 runtime issue (closed, upstream).