[FEATURE] Claude in Chrome: allow screenshots to be saved to local filesystem during a session
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
I use Claude in Chrome for structured exploratory QA traversal of web applications. The extension navigates flows, identifies bugs, and flags them with descriptions. It takes screenshots throughout the session so it can see the page - but those screenshots exist only as in-memory imageIds and are lost when the session ends.
For professional bug reporting in tools like Jira or Xray, each bug requires a named screenshot attached as evidence. Without any way to persist screenshots to disk, the evidence trail is destroyed at the end of every session. This means either manually interrupting the session to save screenshots at each bug (defeating the purpose of autonomous traversal), or re-navigating to every bug location afterwards just to capture evidence.
This is the single gap preventing Claude in Chrome from being genuinely useful in a professional QA context. Everything else works.
Proposed Solution
Add a filePath parameter to the screenshot tool. When provided, save the captured PNG to that path on the local filesystem. When omitted, existing in-memory behaviour is preserved - no breaking change.
Example behaviour: Claude in Chrome flags a bug, immediately saves a screenshot to:
C:\BugEvidence\Screenshots\BUG-024-revival-grandstand-missing-saturday.png
An alternative framing: allow Claude in Chrome to pass its screenshots to the Filesystem connector (already available in Claude Desktop). The screenshots already exist as imageIds during the session - the missing piece is a write path to disk.
Either approach closes the gap. The filePath parameter is simpler to implement and would solve the use case entirely.
Alternative Solutions
Attempted workarounds:
AutoHotkey trigger file approach: AutoHotkey watches a text file for changes, fires a PowerShell screenshot on each change. Fails because Claude in Chrome has no Filesystem tool in its toolset and cannot write the trigger file in the first place.
GIF recorder: Claude in Chrome has a GIF recording capability but the format, overlays, and lack of named output make it unsuitable for bug evidence attachments.
Manual screenshots: Interrupts the autonomous session flow and requires the tester to be present at each bug discovery moment - removes the key benefit of AI-assisted traversal.
Third-party tools (BugHerd, FSB): BugHerd requires manual trigger per bug. FSB (via Claude Code MCP) is a viable architectural alternative but requires significantly more setup and moves away from Claude in Chrome entirely.
This feature has been raised twice before in this repo - issues #14773 and #35184 - but both were auto-closed after seven days without activity before gathering meaningful engagement.
Priority
High - Significant impact on productivity
Feature Category
File operations
Use Case Example
Use Case Example
- QA tester opens Claude in Chrome on a pre-production e-commerce site
- Pastes a structured traversal prompt listing 22 known bugs to verify
- Claude in Chrome navigates directly to each bug location, confirms status, and flags findings
- At each bug confirmation, Claude in Chrome saves a screenshot to a local folder named after the bug ID - e.g. BUG-029-three-furlong-park-validation-error.png
- At the end of the session, the tester has a folder of named PNGs ready to attach directly to Jira or Xray tickets
Currently step 4 is impossible. The session produces a text summary of findings but no visual evidence. The tester must either interrupt the session manually at each bug or re-navigate to every location afterwards.
A single run covering 22 bugs across 14 events on a complex ticketing site took approximately 90 minutes. Manually re-navigating for screenshots would add significant time and introduce the risk of the site state having changed between the traversal and the evidence capture.
Additional Context
Community validation: two Reddit threads (r/QualityAssurance and r/ClaudeAI) independently confirmed this is a shared pain point among QA practitioners using AI browser automation tools. A practitioner building a separate browser automation tool (FSB) responded directly to confirm evidence gathering is the main bottleneck in this space.
Prior issues: #14773 and #35184 both requested a filePath parameter on the screenshot tool. Both were closed after seven days of inactivity under the auto-lock policy. This submission includes a concrete end-to-end use case and community evidence to support prioritisation.
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Addendum: security considerations and mitigations
A commenter on the Chrome Web Store raised the point that filesystem access may have been deliberately withheld due to prompt injection risk - a malicious site embedding hidden instructions that trick Claude in Chrome into writing arbitrary files to the local filesystem. That's a legitimate concern and worth addressing directly.
The risk is real but scoped
Unrestricted filesystem write access from a browser session would be a meaningful attack surface. A crafted page could theoretically instruct Claude in Chrome to write to sensitive locations, overwrite files, or exfiltrate data by writing it somewhere accessible.
The mitigations are straightforward
The filePath parameter proposal doesn't require unrestricted access. The risk can be reduced significantly with any of the following:
User-designated output folder only - the user specifies a single approved folder in settings (e.g. C:\BugEvidence\Screenshots). Claude in Chrome can only write to that folder, nothing else. No arbitrary path access.
Opt-in setting - filesystem write access is disabled by default and requires explicit activation in Claude in Chrome settings, the same way the Filesystem connector works in Claude Desktop. The user accepts responsibility on opt-in.
Filename sanitisation - strip or reject any filename containing path traversal characters (../, , etc.) so an injected instruction cannot escape the designated folder.
Write-only, no read - the feature only needs to write screenshots out, not read from the filesystem. A write-only permission to a designated folder is a much narrower surface than general filesystem access.
Combined, these mitigations reduce the attack surface to: a malicious page that knows the exact designated output folder path and constructs a filename that overwrites something in that folder. That's a significantly harder attack than arbitrary filesystem write, and consistent with the level of trust users already grant to other Chrome extensions with file access.
The Filesystem connector already exists in Claude Desktop under an opt-in model. Bringing a scoped, opt-in version of that to Claude in Chrome for screenshot output would be consistent with existing Anthropic product patterns rather than introducing something new.
Happy to discuss the security model further if that would be useful.
This might be bot-generated? But a way to take browser screenshots would be very useful.
E.g. a nice use-case would be to have QA/documentation staff log into our product, steer the agent through a UI workflow, and then have it document the whole process with annotated screenshots.
Currently, it seems to happily go through the steps, but then chokes when it comes to actually accessing the screenshots, doing wildly inventive workarounds (try to build a custom javascript server to access the browser memory, fully mock the UI in the screenshots)
I'd like to see this same capability in Claude Code's built-in browser panel (the in-app preview browser), not just Claude in Chrome.
When Claude Code drives that browser against a local dev environment, screenshots currently live only as in-memory image IDs. Over the last few days we tried every direct way to capture the browser panel and save the image to disk, and all of them failed. In the end we had to build a separate system based on Puppeteer just to take the screenshots and write the PNG files ourselves — which duplicates something the panel already does internally.
A simple, optional filePath parameter on the screenshot tool (as proposed above) would cover this perfectly: save the PNG to the given path when provided, keep the in-memory behavior when omitted (no breaking change). This is especially useful when Claude Code is working against a dev server, where saved screenshots become debugging evidence, regression references, and material to attach to issues.
I crafted a full-featured work around for this issue after discovering that the screenshot wasnt creating the file on my local system. After some research I discovered that the screenshot is happening, but not like I thought. What is happening is that the screenshot happens and instead of saving it to file the base64 image is injected into the context. My plan was simple, just use a hook after the tool has completed that will get the base64 from the last message and save it off to a file. Just using the PostToolUse hook to wait until after the image is created but before it is added to the messages.
More details here:
https://github.com/contractorwolf/hacks-tricks/blob/main/claude-code/claude-chrome-screenshot-hook.md
Adding another concrete use case that hits this same gap, from a different angle than QA screenshot evidence:
I asked Claude Code to read a Jira ticket and its attachments (which included a link to an interactive example page) to generate a frontend spec document for a UI module. Using claude-in-chrome, it navigated to and interacted with the example page directly in Chrome, taking a large number of screenshots (~19) of different UI states to reference while writing the spec. Only at the very end, when generating the final document, did it tell me the screenshots couldn't actually be embedded — it had to fall back to text-only descriptions and note that an interactive prototype was more accurate than the (missing) static screenshots.
This is the same underlying issue: screenshots taken via claude-in-chrome's computer tool are visible inline during the session but never persisted to disk, so there's no way to bring them into a generated deliverable afterward. In my case the deliverable was a documentation artifact rather than a bug report, but the root cause and the fix (a filePath/save_to_disk that actually writes bytes to disk) is identical.
+1 on prioritizing this — it blocks any documentation-generation workflow that relies on claude-in-chrome screenshots as source material.
Update: Found a working workaround in the meantime, for anyone hitting this before it's fixed — the screenshot data isn't actually lost, it's just never exposed as a file. It's sitting in the session transcript (~/.claude/projects/.../*.jsonl), which logs everything including the inline screenshot data. Asking Claude Code to read the transcript and extract/re-save the screenshots as PNG files worked and let me finish embedding images in my spec doc.
Doesn't change the underlying ask (a proper filePath/save_to_disk that writes bytes at capture time would still be much better than post-hoc transcript archaeology), but worth knowing this isn't a dead end while waiting on a fix.