[BUG] Screenshots are captured and saved to disk, but Claude Code then can't find/read them back in the same session

Resolved 💬 2 comments Opened Jun 24, 2026 by afram123 Closed Jun 27, 2026

What happens

During a session, Claude Code captures a screenshot and writes it to disk. Immediately afterward, when it tries to read that same image file back to actually use it, the read fails with a "file not found" / "no such file" error — even though the file was just written and exists at the reported location.

Net effect: the screenshot is taken and saved, but never usable. The capture step reports success; the follow-up read claims the file doesn't exist.

Steps to reproduce

  1. In a session, have Claude Code take a screenshot.
  2. It captures the image and reports saving it to a path on disk.
  3. Ask it to read/use that screenshot.
  4. The read fails — the file "can't be found" — despite being present at the reported path.

Expected

A screenshot just captured and saved should be immediately readable in the same session, at the path reported on save.

Actual

The save reports success and a path, but a subsequent read of that exact path fails as if the file doesn't exist. The screenshot is effectively unusable.

Impact

Screenshot capture is pointless if the file can't then be read back. Any workflow where Claude takes a screenshot and then reasons over it is broken.

Likely cause

Smells like a path-resolution mismatch — the path returned by the capture step not matching the path used by the read step (absolute vs relative, working-directory differences, or path separator/normalization). Worth checking that the exact string returned on save is the exact string used on read.

Environment

  • OS: Windows 11
  • Reproduced in a normal interactive session.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗