Can A Crash-Report Screenshot Capture A Redacted AI Prompt?
Yes. Redacting an AI prompt in a request or error event does not remove text that is still visible in the app when a crash-report screenshot is taken.
Yes. A crash-report screenshot can capture an AI prompt even when the prompt was successfully redacted from the model request, error event, logs, or breadcrumbs. Text redaction and screenshot masking protect different representations of the same information.
If the original prompt is still rendered in the chat box or conversation when diagnostic code captures the app window, the screenshot can preserve those pixels. Cleaning a JSON field does not repaint the interface, and a server-side text scrubber cannot reliably remove words already baked into a PNG.
That does not mean every AI app takes crash screenshots. Sentry documents the feature as opt-in and best effort, and its masking defaults vary by SDK. The only dependable answer for a particular app is to inspect its configuration and test the actual attachment received by the crash-reporting system.
The Short Answer By Redaction Point
| What was redacted? | Can the screenshot still show the original prompt? | Why? |
|---|---|---|
| The request sent to the AI provider | Yes | The prompt may still be visible in the app even though the outbound request contains placeholders. |
| Structured crash-event fields | Yes | A screenshot is a separate attachment, not merely another field in the event JSON. |
| Logs and breadcrumbs | Yes | Removing text copies does not change the pixels already on screen. |
| The visible chat interface itself | Usually no for that visible text | If the UI displays a placeholder or masked block before capture, the screenshot records that rendered state. Other visible details can still remain. |
| The screenshot through tested masking rules | It depends | Coverage varies by platform, SDK version, view type, custom code, and capture timing. |
| A server-side attachment rule after upload | Do not rely on it | Image content is already encoded as pixels, and attachment scrubbing has important limits. Mask or prevent capture on the device first. |
The key distinction is simple: prompt redaction protects text in a data path; screenshot masking protects pixels in an image path. A privacy review has to test both.
What Is Confirmed
Sentry's current Issue Details documentation says supported UI SDKs can take a screenshot when a user experiences an error, exception, or crash and include it as an attachment. The supported list includes Android, iOS, React Native, Electron, Flutter, .NET MAUI and Xamarin, Unity, Unreal, Native, Godot, and other UI environments.
Sentry's platform pages repeatedly say screenshots may contain personally identifiable information and therefore require opt-in. They also describe screenshot capture as a best-effort feature: the UI thread may be unavailable during a native iOS crash, the screen may not have loaded yet, and Apple app-hang events cannot capture a screenshot when the main thread is blocked. A configured screenshot is therefore a possible artifact, not a guaranteed one.
The masking behavior is not uniform:
- Android: Sentry's Android screenshot guide says screenshot masking is disabled by default. Developers can mask all text and images, classes, individual view instances, XML-tagged views, and Jetpack Compose elements. It warns teams to verify masking before production.
- Apple: Sentry's Apple screenshot guide says screenshots aggressively mask text and non-bundled images by default. It also documents class, instance, and SwiftUI controls plus a masking-preview tool. The guide warns that framework or SDK changes require renewed testing.
- React Native: Sentry's React Native screenshot guide documents default masking for text and images and allows native view classes to be masked or unmasked.
- Electron: Sentry's Electron screenshot guide documents opt-in screenshot capture. Its current page does not describe the Android-, Apple-, or React Native-style masking controls, which makes an implementation-specific capture test especially important.
Sentry's attachment-scrubbing documentation also confirms that attachments are a distinct boundary. It says support for scrubbing non-minidump attachments is limited and that an ordinary attachment is only scrubbed when an advanced rule explicitly selects a non-wildcard filename. A broad wildcard rule is not sufficient under the documented limitation.
These facts do not prove that a specific AI product uses Sentry, enables screenshots, or exposes prompt text. They show why a statement such as “we redact prompts from telemetry” is incomplete unless it also covers screenshot creation, masking, attachment handling, access, retention, and deletion.
What Is Still Unclear
Public SDK documentation cannot tell you what a particular AI app captured. You still need to determine:
- whether crash screenshots are enabled at all;
- which SDK and version the app ships;
- whether the event was a handled error, fatal crash, app hang, or startup failure;
- which window, activity, scene, or view was visible at capture time;
- whether the prompt remained in the composer, conversation, draft preview, or selected-text overlay;
- whether default masking was changed;
- whether custom views, WebViews, video surfaces, native modules, or third-party controls follow the expected rules;
- whether a screenshot was added by the SDK or by the app's own diagnostic code;
- whether the image was transformed, queued offline, retried after restart, or uploaded through another telemetry path;
- who can view or download the stored attachment and for how long;
- whether deleting the AI conversation has any effect on a separately stored crash attachment.
A clean error-event JSON proves only that the inspected JSON is clean. It does not prove that the sibling screenshot, view hierarchy, replay, minidump, or custom diagnostic file is clean.
Why A Redacted Prompt Can Remain Visible
Consider a user typing this fictional prompt:
Compare the acquisition offer for Project Cedar with our board's confidential walk-away price.
The app might replace Project Cedar and the price with placeholders before sending the request to an AI provider. It might also remove both details from logs and error fields. Those are useful controls.
But the original draft may still appear in the chat composer so the user can review or edit it. If a handled exception occurs while that composer is visible, an opt-in crash screenshot can capture the rendered sentence. The structured event can be perfectly redacted while the attached PNG contains the raw words.
There are now at least four copies with different controls:
- the live text in application memory;
- the visible pixels rendered by the interface;
- the redacted text in the model-request and telemetry objects;
- the screenshot image attached to the diagnostic event.
Treating all four as “the prompt” hides the exact failure. A sound privacy design follows each representation from creation through transmission, storage, access, and deletion.
Screenshot Masking Is Not The Same As Session-Replay Masking
The two features may share APIs, but teams should not assume one configuration automatically proves the other.
Sentry's Apple documentation says screenshot masking shares runtime APIs with Session Replay while using separate options.screenshot.* settings. The Android guide similarly describes screenshot-specific masking settings and explains that the replay module must be available at runtime for masking; if masking is configured but the module is missing, the SDK skips the screenshot rather than risking an unmasked capture.
That is a useful fail-safe, but it does not replace testing. Platform integrations evolve. A view that was masked last release may be rebuilt in a new framework, moved inside a WebView, rendered through a custom canvas, or deliberately unmasked for debugging. A privacy check tied only to the old source code can pass while the production pixels change.
Use The PIXEL Test Before Enabling Crash Screenshots
Use this five-part review for every AI surface that can contain sensitive text.
P — Prompt State
List every place the raw prompt can still appear when an error fires:
- an unsent composer;
- the submitted conversation bubble;
- a draft autosave indicator;
- selected or copied text;
- an upload preview or filename;
- a search-query preview;
- a voice-transcription preview;
- an image-edit instruction;
- a persona or system-instruction editor.
Do not stop at the primary chat screen. Diagnostic screenshots are most valuable precisely when an unusual error leaves the interface in an unusual state.
I — Instrumentation
Inventory every mechanism that can create an image:
- automatic SDK crash screenshots;
- custom
beforeSendattachment code; - user-feedback screenshots;
- session replay frames;
- native crash handlers;
- support widgets;
- QA or beta-build diagnostics;
- operating-system or device-management capture tools.
An application can disable one SDK setting and still attach a screenshot through another integration.
X — eXclusions And Masking
Define the intended result for every sensitive view. Prefer a deny-first policy: mask all text and images, then unmask only elements that have a documented debugging need and contain no user data.
Pay special attention to:
- custom text editors and rich-text controls;
- WebViews and embedded browser surfaces;
- Jetpack Compose and SwiftUI wrappers;
- native payment, health, identity, and file-picker components;
- images that contain text;
- canvases, maps, video, and camera previews;
- third-party UI packages;
- child views inside masked or unmasked containers.
The goal is not to prove that the common screen looks safe. It is to find the one view type your rule does not understand.
E — Event Timing
Test several capture moments:
- before the prompt is sent;
- immediately after submission;
- while the response streams;
- after a prompt is visually replaced or cleared;
- during an upload or voice transcription;
- after the app moves to the background;
- during a handled exception;
- during a fatal crash;
- after restart when an offline report is transmitted.
Sentry's own documentation says some crash types cannot produce a screenshot. That means a missing image in one test is not proof that another event type will also omit it.
L — Lifecycle And Least Access
Trace the image after capture:
- Is it modified on the device?
- Is it queued locally?
- Which endpoint receives it?
- Is it stored as an attachment?
- Which roles can download it?
- Does it appear in notifications, tickets, or connected tools?
- What is its retention period?
- Can an administrator delete it?
- Does conversation deletion leave it untouched?
Sentry's JavaScript attachment documentation says attachments can be added, removed, or modified through beforeSend or an event processor, are shown in Issue Details, have configurable access, and persist for a documented attachment-retention period. Your own provider, plan, and integration chain may differ.
How To Run A Safe Capture Test
Use synthetic canaries, not real secrets.
- Create a non-production account and a unique string such as
OV-SHOT-CANARY-9F3K. - Put the canary in each sensitive UI surface one at a time.
- Trigger a controlled handled error and inspect the received event and every attachment.
- Repeat with a fatal crash where the platform permits it.
- Repeat after the app restarts to test offline queues.
- Search the downstream crash system for the canary in event JSON, logs, breadcrumbs, replays, screenshots, view hierarchies, and exported files.
- Open the actual PNG at full resolution. Do not rely on a thumbnail.
- Verify access controls with a low-privilege project member.
- Delete the event or attachment and confirm the downstream state.
- Re-run the test after SDK, framework, renderer, privacy-rule, or UI changes.
Record both positive and negative controls. A positive control confirms that your test can detect an intentionally unmasked safe label. A negative control confirms that the canary is absent from every expected artifact. Without both, a blank screenshot or broken capture path can masquerade as successful masking.
Common Privacy Mistakes
“The request was redacted, so the screen is safe”
Request redaction changes the network payload sent to the model or application backend. It does not necessarily change what remains visible to the user.
“The error event contains no prompt field”
A screenshot is an attachment. It can carry information that never appears as a searchable event property.
“The provider scrubs PII after ingestion”
Post-ingestion scrubbing means the provider received the artifact. Image pixels also require image-aware handling, and Sentry documents limits for non-minidump attachment scrubbing. Prevent or mask capture before upload when the threat model requires that raw text never reach the telemetry provider.
“Masking is enabled by default everywhere”
It is not. Sentry's current Android guide says screenshot masking is disabled by default, while its Apple and React Native guides describe aggressive or default masking. SDK, version, and platform matter.
“One successful test proves the feature”
A passing test covers only the views, event type, timing, device, and SDK build you exercised. Add screenshot privacy tests to release acceptance, not just initial setup.
“Deleting the chat deletes the crash attachment”
The chat store and telemetry store are separate systems unless the application has explicitly connected their deletion workflows. Ask for evidence rather than inferring one deletion from the other.
What AI Users Can Ask A Vendor
Most users cannot inspect an app's crash SDK configuration. They can still ask precise questions:
- Do production builds attach screenshots to crashes or handled errors?
- Is screenshot capture opt-in, and is it enabled for my platform?
- Are chat composers, conversation messages, uploads, filenames, voice transcripts, and image prompts masked?
- Does masking happen before the screenshot leaves the device?
- Are screenshot attachments covered by the same deletion request as chat content?
- Who can access screenshots, and how long are they kept?
- Are screenshots copied into support tickets or third-party integrations?
- Has the vendor tested custom views, WebViews, Compose, SwiftUI, and Electron surfaces?
A strong answer names the platform, capture trigger, masking boundary, retention period, access policy, and last verified test. “We take privacy seriously” is not a data-flow description.
Where OpenVeil Fits — And Where It Does Not
OpenVeil is a hosted privacy-focused AI workspace for adults. Normal chat history is kept in the user's browser, and OpenVeil does not maintain a normal server-side chat-history record. OpenVeil also does not use prompts, uploaded files, images, audio, selected local-history context, or AI outputs to train foundation models.
Those boundaries can reduce the long-lived server-side chat archive associated with normal conversations. They do not make OpenVeil fully offline, eliminate all operational data, or guarantee that unrelated software on a device cannot take screenshots. Active requests still have to be processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers.
OpenVeil is not a crash-reporting security product and does not claim protection from operating-system capture, browser extensions, enterprise monitoring, malware, or another application's telemetry. If fully local processing and device-level control are mandatory, a carefully isolated local AI stack may be the better fit.
The practical OpenVeil path is narrower: use a privacy-focused workspace with browser-local normal chat history when you want hosted convenience, and still minimize or replace sensitive identifiers before any AI request. No privacy feature makes unnecessary disclosure risk-free.
Related Guides
- Can A Crash-Reporting SDK Capture An AI Prompt Before It Is Sent?
- Can Client-Side Redaction Stop AI Prompts From Reaching Crash Reports?
- Can A Crash-Report Attachment Bypass Client-Side Prompt Redaction?
- Can AI Error Logs Accidentally Capture Prompt Content?
Frequently Asked Questions
Can Sentry automatically take a screenshot when an app crashes?
Sentry documents opt-in crash and error screenshots for supported UI SDKs. Capture is best effort, so some fatal crashes, startup errors, and app hangs may not produce an image.
Does beforeSend redaction remove words from a screenshot?
Not automatically. A beforeSend hook can modify event data and, in some SDKs, inspect attachments, but text already rendered into screenshot pixels needs screenshot-specific masking or attachment removal.
Are screenshots masked by default in Sentry?
It depends on the platform. Current Sentry documentation says Android screenshot masking is disabled by default, while Apple and React Native use default masking for sensitive text and images. Verify the exact SDK version and configuration.
Can a screenshot reveal a prompt that was never sent to the AI model?
Yes. If the unsent draft is visible when a handled error or crash screenshot is taken, the image can preserve it even though no model request occurred.
Does deleting an AI chat delete its crash screenshot?
Not necessarily. Chat history and crash attachments are normally separate data stores with separate identifiers, retention, access, and deletion workflows.
Is a masked thumbnail enough to prove the stored screenshot is safe?
No. Inspect the original attachment at full resolution and search all related artifacts with a synthetic canary. A thumbnail can hide readable detail or represent a transformed derivative rather than the stored source image.
Should an AI app disable crash screenshots completely?
That depends on its debugging needs and threat model. For high-risk health, legal, financial, identity, or confidential-work surfaces, disabling capture may be safer than trying to enumerate every sensitive view. If screenshots are enabled, use deny-first masking, narrow triggers, least-privilege access, short retention, and release-level tests.
Bottom Line
Yes: a crash-report screenshot can capture a redacted AI prompt when the redaction protects text fields but the original prompt remains visible in the interface. Screenshot capture is a separate telemetry path with platform-specific masking, timing, storage, and access rules.
Do not ask only whether the prompt was redacted. Ask whether the pixels were captured, masked on the device, attached to the event, stored downstream, and deleted on schedule. Then prove the answer with the actual image—not the clean JSON beside it.