CUA save_to_disk screenshots not accessible from filesystem
Status Closed — not planned
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 6 comments · opened Mar 28, 2026 · closed May 31, 2026
Problem
When using the mcp__computer-use__screenshot or mcp__computer-use__zoom tools with save_to_disk: true, the documentation states it "Returns the saved path in the tool result." However:
- No file path is returned in the tool result — only the inline image is shown
- The saved file cannot be found on the filesystem via
find, even searching/tmp,~/Library,/var, and all user directories - The sandbox blocks alternative screen capture methods (
screencapture,CGDisplayCreateImage,Quartz.CGWindowListCreateImage), making CUA the only tool that can see granted applications
Impact
This blocks any workflow that needs to:
- Save in-game screenshots from native apps (e.g., Roblox Studio play mode) to disk
- Commit viewport captures to git repositories
- Pass captured images between agents or tools (e.g., CUA → Chrome MCP upload)
- Build automated QA/preview pipelines for 3D asset generation
Expected Behavior
save_to_disk: true should:
- Save the screenshot/zoom image to a known, accessible file path (e.g.,
/tmp/claude-screenshots/) - Return the file path in the tool result text (not just the inline image)
- The file should be readable by the sandboxed process (Bash, Python, etc.)
Reproduction
# Take a CUA screenshot with save_to_disk
mcp__computer-use__screenshot(save_to_disk=true)
# Search everywhere for the saved file
find / -name "*.png" -mmin -1 2>/dev/null
# Returns nothing accessible
# The inline image IS visible in the conversation but cannot be
# extracted, saved, or passed to other tools
Environment
- Claude Code CLI on macOS (Darwin 25.1.0)
- Computer-use MCP with
screenshotFiltering: native - Granted app: RobloxStudio (full tier)
Workaround Attempted
Tried: screencapture, AppleScript, CoreGraphics ctypes, Quartz pyobjc, Roblox CaptureService, Chrome MCP upload_image cross-reference — all blocked by sandbox or incompatible imageId namespaces.
The only viable workaround currently is asking the user to manually take screenshots with Cmd+Shift+4, which defeats the purpose of automation.
6 Comments
Yes, having the same issue. Example response from my claude session:
The save_to_disk screenshots aren't landing in a findable location. However, the images from this conversation are already cached at.claude/image-cache/0dabbda1-f28a-4186-a770-xxxxxxxxxxx/. Let me check what's there and copy the relevant ones.
Couldn't find the images in the cache directory either
the part that breaks down with CUA save_to_disk isn't the path return, it's that the sandbox sits on a different filesystem view than Bash. even when CUA writes the PNG, the file lands inside a container the agent's shell can't reach, so
find /comes up empty regardless of where you point it. the fix that actually works for me is going around CUA entirely: a small AX-based MCP that calls CGWindowListCreateImage on a granted bundle id and writes to a path you pass in. you keep granted-app capture, the path is real, and downstream tools can read it. CUA is fine for in-loop reasoning, bad for handoff.Closing for now — inactive for too long. Please open a new issue if this is still relevant.
https://github.com/BobMakhlin/claude-in-chrome-save-screenshot
I've created a claude code skill to persist the screenshot in the project. Claude Code's harness persists all conversation content - including mcp__Claude_in_Chrome__computer tool results with their inline base64 images - to a JSONL transcript file. The skill reads that transcript, extracts the base64, and decodes it to an image file in your project.
This is still relevant and multiple duplicates exist because of how useful it would be.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.