Can A Crash-Report View Hierarchy Expose An AI Prompt Even When The Screenshot Is Masked?

August 25, 2026

Usually not through standard fields. Learn why a masked crash screenshot does not prove view-hierarchy JSON is safe, and how to test every artifact.

Usually not through Sentry's standard view-hierarchy fields—but a masked crash screenshot does not prove the sibling view-hierarchy attachment is safe. Sentry's current mobile schema records UI structure, element type, identifiers, tags, geometry, visibility, alpha, and child nodes. It does not define a general field for the visible text inside every control.

An AI prompt can still leak if an app places user text in an accessibility identifier, resource identifier, tag, custom-exporter field, or other diagnostic metadata. The prompt can also survive in a separate event field, breadcrumb, log, replay, screenshot, or custom attachment.

The practical rule is simple: inspect every crash artifact separately. A blacked-out screenshot proves only that the pixels you inspected were masked. It is not a deletion certificate for view-hierarchy.json or the rest of the event.

What Is Confirmed

Sentry's current event-attachments API documentation shows screenshot.png and view-hierarchy.json as two distinct attachments on the same event. The screenshot is typed as an ordinary event attachment, while the JSON file is typed as event.view_hierarchy.

That separation matters. Screenshot masking changes an image representation. A view hierarchy is a structured representation of the interface. One can be clean while the other contains sensitive metadata.

The standard Android data model is narrower than the phrase "view hierarchy" may suggest. Sentry's current open-source ViewHierarchyNode schema defines these fields:

• rendering_system
• type
• identifier
• tag
• width and height
• x and y
• visibility
• alpha
• children

There is no standard text, value, prompt, or content field in that node schema.

Sentry's Android ViewHierarchyEventProcessor shows the default collection path. It records the view's class name as its type, obtains a resource identifier when one exists, and adds dimensions, position, alpha, visibility, and child nodes. It does not read the visible text of an Android text control in that default path.

The Apple implementation reaches a similar boundary. Sentry's current SentryViewHierarchyProvider exposes an option to report accessibilityIdentifier values in the hierarchy. An accessibility identifier is meant to identify a UI element for code or testing; it should not contain a user's prompt. But if an app dynamically copies personal content into that property, the identifier becomes a data-leak path.

Sentry's Dart schema also includes an extra map, and Sentry's Java model preserves unknown fields. Custom exporters or framework integrations can therefore add fields beyond the minimum schema. The exact JSON generated by a particular SDK version and app matters more than a generic promise about "the view hierarchy."

Sentry's Issue Details documentation likewise treats screenshots, attachments, replays, breadcrumbs, tags, and contexts as separate debugging surfaces. A privacy review has to follow the same separation.

What Is Still Unclear

Public documentation cannot establish what one AI app sends. The answer still depends on details that only the app owner or a controlled capture test can verify:

• Which Sentry SDK, framework integration, and version are installed?
• Are screenshots and view hierarchies enabled in production?
• Does the app use Sentry's default exporter or a custom one?
• Are accessibility identifiers, resource IDs, tags, or test IDs derived from user content?
• Does a framework plugin add extra or unknown properties?
• Is prompt text copied into the event, breadcrumbs, logs, feedback, replay, or another attachment?
• Which crash and handled-error types generate the hierarchy?
• Is the attachment queued locally and uploaded after restart?
• Who can download attachments, and are they copied into tickets or alerts?
• Does deleting the AI chat delete the separate diagnostic event?

This article does not claim that Sentry exposed a particular user's AI prompt. It explains why a clean screenshot alone cannot answer that question—and why the standard hierarchy schema is less text-heavy than some security summaries imply.

Why "Masked Screenshot" Is The Wrong Unit Of Proof

Suppose a user types this fictional prompt:

Summarize the acquisition memo for Project Cedar and keep the board's walk-away price confidential.

The crash screenshot may show black rectangles over the composer and conversation. That is useful evidence that screenshot masking worked for those views at that moment.

Meanwhile, the hierarchy might contain only structural entries such as:

{
  "type": "android.widget.EditText",
  "identifier": "id/prompt_input",
  "width": 912,
  "height": 180,
  "visibility": "visible",
  "children": []
}

That sample reveals that a visible prompt field existed and where it was located, but it does not reveal the prompt text.

Now consider an unsafe implementation:

{
  "type": "android.widget.EditText",
  "identifier": "Project Cedar walk-away price prompt",
  "visibility": "visible"
}

The screenshot can be perfectly masked while the identifier exposes the sensitive phrase. The problem is not that every hierarchy automatically reads text. The problem is that the app put user content into a field the hierarchy legitimately exports.

The same risk applies to resource tags, accessibility identifiers, analytics labels, automation test IDs, route names, error context, and custom extra properties. Metadata becomes content when developers build it from content.

View Hierarchy Is Not The Same As The Browser DOM

Web developers often hear "view hierarchy" and imagine a browser DOM containing text nodes, input values, labels, attributes, and page structure. Sentry's native mobile hierarchy is not automatically a serialized copy of every DOM node or every text value.

For a native Android or iOS screen, the default hierarchy focuses on structural and visual properties. A React Native or Flutter application may bridge through native SDKs and framework-specific exporters. A WebView, Electron window, custom canvas, game engine, or app-defined diagnostic collector may behave differently.

This is why platform names are not enough. The audit must identify the actual renderer and exporter used for the sensitive screen.

Questions to ask include:

• Is the chat composer a native control, Compose or SwiftUI component, WebView, or custom renderer?
• Does the framework map test IDs to native accessibility identifiers?
• Can a developer-defined tag contain a filename, email address, prompt fragment, or conversation ID?
• Does an exporter serialize semantic labels that the base SDK does not?
• Are hidden, offscreen, or transparent child views included?

The correct answer comes from the received JSON, not from the marketing name of the framework.

Use The VIEW Audit

Use this four-part test before accepting crash-report masking as proof.

V — Verify The Attachment Inventory

Trigger a controlled error in a non-production account and list every attachment for that event. Sentry's attachment API supports filtering by name or kind, but do not filter only for screenshots during a privacy audit. A screenshot-only query can hide the very sibling artifact you need to inspect.

Check for:

• screenshot.png
• view-hierarchy.json
• native crash reports or minidumps
• logs and configuration files
• user-feedback files
• app-defined attachments

Also inspect the event JSON, breadcrumbs, contexts, replay, and linked feedback. They are not all members of the same attachment list.

I — Inspect Identifiers And Extra Fields

Open the actual view-hierarchy.json file and enumerate every key. Do not assume the schema you expected is the schema the app shipped.

Pay special attention to:

• identifier
• tag
• framework-specific semantic or accessibility fields
• unknown properties
• extra maps
• route, screen, component, and test names
• child nodes from embedded or third-party UI controls

Search for emails, phone numbers, filenames, project codenames, conversation IDs, prompt canaries, and other synthetic sensitive patterns. Review values as well as keys.

E — Exercise A Synthetic Canary

Use a fake value such as OV-VIEW-CANARY-7K2M, never a real secret.

1. Put the canary in the prompt composer.
2. Trigger a handled error while the composer is visible.
3. Repeat immediately after submission.
4. Repeat with the prompt hidden, cleared, or visually masked.
5. Inspect the full-resolution screenshot and the complete hierarchy JSON.
6. Search the event, breadcrumbs, contexts, logs, replay, and every attachment.
7. Restart the app and inspect any delayed upload from an offline queue.

Add a positive control: place a different harmless canary in an identifier that you expect the hierarchy to export. If the positive control is absent, the test may have failed to capture a hierarchy at all. A missing attachment is not the same as a clean attachment.

W — Who Can Access It, And For How Long?

Sentry's attachment documentation says attachments can be viewed in Issue Details, persist for 30 days, and can have role-based download access. It also says an attachment can be modified or removed in a beforeSend hook or event processor before transmission.

Your implementation may add more copies through ticketing, chat alerts, email, exports, support tools, backups, or a self-hosted deployment. Verify:

• which roles can see that an attachment exists;
• which roles can download it;
• whether integrations copy it elsewhere;
• whether deleting an attachment or event reaches those copies;
• whether deleting the AI conversation affects diagnostic data;
• whether local offline envelopes remain on the device.

Retention is a property of each system and copy, not of the screenshot-masking switch.

What Developers Should Change

Keep content out of identifiers

Resource IDs, accessibility identifiers, test IDs, component names, and tags should be stable labels such as prompt_input or send_button. They should not be generated from prompt text, email addresses, filenames, customer names, or conversation titles.

Treat custom exporters as data collectors

A custom hierarchy exporter is telemetry code. Give it the same privacy review as logs, analytics, crash contexts, and feedback attachments. Document every added field and prohibit raw user content by default.

Make capture deny-first

If a hierarchy is not needed to diagnose production failures, do not enable it. If it is needed, minimize fields, test sensitive screens, limit access, and prevent downstream copies.

Test each representation

Do not accept one screenshot as the test result. Release acceptance should examine the screenshot, hierarchy, event, breadcrumbs, replay, logs, and attachments using the same canary.

Re-run after UI and SDK changes

A safe native text field can later become a WebView, custom renderer, or framework component with a different exporter. Repeat the VIEW audit after SDK upgrades, renderer migrations, new support tools, or changes to accessibility and testing labels.

What AI Users Can Ask A Vendor

Most users cannot inspect an app's crash configuration, but they can ask questions that distinguish evidence from reassurance:

• Do production builds attach screenshots or view hierarchies to errors?
• Which SDKs, platforms, and event types can create them?
• Does the hierarchy include accessibility identifiers, test IDs, tags, semantic labels, or custom fields?
• Are any identifiers derived from user prompts, filenames, chat titles, or account data?
• Are screenshots and hierarchies tested with the same synthetic canary?
• Who can download attachments, and how long are they retained?
• Are attachments copied to support or incident-management systems?
• Does deleting a chat delete the related diagnostic event and downstream copies?

A useful answer names the collected fields, platform, capture trigger, access policy, retention period, and last test date. "Screenshots are masked" answers only one part of the question.

Where OpenVeil Fits — And Where It Does Not

OpenVeil is a hosted privacy-focused AI workspace for adults. Normal chat history is stored in the user's browser, and OpenVeil does not maintain a normal server-side chat-history record for those sessions. 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 normal long-lived account-side chat-history layer. They do not make OpenVeil fully offline, eliminate operational data, sanitize another application's crash reports, or guarantee that device software cannot capture the screen or UI metadata. 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-report security product, screenshot blocker, telemetry auditor, or device-compromise defense. Users should still minimize sensitive identifiers before sending them and protect the browser profile where local history is stored.

For the adjacent pixel risk, read Can A Crash-Report Screenshot Capture A Redacted AI Prompt?. The broader attachment boundary is covered in Can A Crash-Report Attachment Bypass Client-Side Prompt Redaction?, and Can AI Error Logs Accidentally Capture Prompt Content? explains the log path.

Frequently Asked Questions

Does Sentry's standard view hierarchy include text from every input?

No. Sentry's current standard mobile hierarchy schema does not define a general text-content field. It focuses on type, identifiers, tags, geometry, visibility, alpha, and children. Framework integrations and custom exporters can add other fields.

Can a view hierarchy expose an AI prompt?

Yes, if the app copies prompt content into an exported identifier, tag, accessibility field, custom property, or extra map. The prompt may also appear in another crash artifact even when the standard hierarchy does not contain it.

Does masking a screenshot mask view-hierarchy.json?

No. They are separate attachments with different representations and controls. Inspect both.

Is an accessibility identifier supposed to contain user text?

No. It should be a stable programmatic identifier. Putting dynamic personal or prompt content in it creates an avoidable diagnostic-data leak.

Does deleting an AI chat delete its crash attachments?

Not automatically. Chat storage and crash telemetry are separate systems unless the app explicitly connects their deletion workflows.

Are view hierarchies always enabled in Sentry?

No. Availability and defaults vary by SDK and integration. Check the production configuration and the actual received event.

Can server-side PII scrubbing replace client-side minimization?

Do not assume it can. The provider has already received the artifact by that point, attachments can have special scrubbing limits, and custom JSON may not match the rules you expected. Keep sensitive content out before upload.

Does browser-local chat history prevent crash-report collection?

No. Browser-local history describes where normal chat history is stored. It does not control screenshots, telemetry, extensions, operating-system tools, or other software on the device.

Bottom Line

A masked screenshot does not prove a crash event's view hierarchy is clean. But Sentry's standard hierarchy is not a transcript of every visible string: by default, it records structure and identifiers rather than a general prompt-text field.

The real risk is implementation-specific. Inspect the JSON, keep user content out of identifiers and custom fields, test every sibling artifact with a synthetic canary, and verify access and retention separately.

If you want a hosted AI workspace with browser-local normal chat history and no normal server-side chat-history record, try OpenVeil after reviewing its documented boundaries and privacy policy.