Does Turning Off Sentry Accessibility Identifier Reporting Remove Old Crash Data?

September 9, 2026

No. Sentry's accessibility-identifier switch changes future Apple view hierarchies; existing immutable events require separate issue-level remediation.

No. Turning off Sentry accessibility-identifier reporting prevents that field from being added to new Apple view-hierarchy attachments; it does not remove identifiers from crash data Sentry already received. Existing Sentry events are immutable, and Sentry's current API documentation says they can be removed only by deleting the whole issue that contains them.

That distinction creates two separate jobs. First, ship a corrected SDK configuration so future view hierarchies omit accessibilityIdentifier. Second, inventory and remediate existing Sentry issues, attachments, exports, alerts, and downstream copies under an authorized deletion plan.

Do not use a clean new event as proof that old data disappeared. It proves only that the new capture path changed.

Research cutoff: September 8, 2026 (America/Chicago).

What Is Confirmed

Sentry's current open-source Apple SDK defines reportAccessibilityIdentifier as a separate option. The source says the view-hierarchy attachment contains accessibility identifiers when the option is enabled, recommends setting it to false when a project uses those identifiers for personal information, and sets the default to true.

The relevant production configuration is narrow:

import Sentry

SentrySDK.start { options in
    options.attachViewHierarchy = true
    options.reportAccessibilityIdentifier = false
}

This keeps view-hierarchy capture available while omitting the identifier field from future captures made by that configured SDK path. Setting attachViewHierarchy to false is a broader choice that disables the whole automatic attachment instead.

The setting is not a retroactive deletion command. It runs in the application and changes what a future SDK capture serializes. It does not reach into an event already stored by Sentry and rewrite its attachment.

Sentry's current API permissions documentation is explicit about the stored-data boundary: events are immutable and can be deleted only by deleting the whole issue. Deletion uses the event:admin scope. Sentry's Remove an Issue endpoint queues an individual issue for deletion asynchronously and returns an accepted response rather than proving immediate completion.

Sentry also documents bulk issue deletion. That is an issue-level operation, not a field-level edit. Its behavior and filters need careful verification: a successful response can occur even when requested issue IDs are out of scope, and an unqualified request can affect a set of issues rather than one event.

The answer is therefore:

What Is Still Unclear

Public documentation cannot tell you which existing events in one organization's Sentry account contain a sensitive accessibility identifier. That requires the organization's own telemetry inventory.

Questions that remain implementation-specific include:

• Which app versions enabled view-hierarchy capture?
• Which Sentry Cocoa versions were deployed in those releases?
• Was reportAccessibilityIdentifier left at its default, explicitly enabled, or already disabled?
• Which screens and error types produced view-hierarchy attachments?
• Did the application put prompt text, filenames, chat titles, email addresses, or other personal data in an identifier?
• Did a custom exporter or framework bridge add the same value elsewhere?
• Which Sentry issues grouped the affected events?
• Did alerts, support tickets, chat integrations, exports, or data warehouses copy the value?
• Are local offline envelopes still waiting on user devices?
• What contractual, legal, preservation, or incident-response requirements apply before deletion?

The option also does not prove that screenshots, session replay, breadcrumbs, logs, error messages, custom context, user feedback, or arbitrary attachments are clean. Each is a separate data path.

Why A Configuration Change Cannot Be A Deletion

The difference becomes clearer when the data flow is drawn as a timeline:

1. An app assigns a value to a UI element's accessibilityIdentifier.
2. A handled error or crash causes the SDK to capture a view hierarchy.
3. The SDK serializes the identifier into an attachment.
4. The event and attachment are transmitted to Sentry.
5. Sentry groups the event into an issue.
6. Integrations or people may copy information into another system.
7. A later app release sets reportAccessibilityIdentifier = false.

Step 7 changes what can happen on the next capture. It does not reverse steps 3 through 6.

This is the same reason deleting an AI conversation does not automatically delete a crash report. The conversation record and diagnostic record have different identifiers, storage systems, access controls, retention rules, and deletion mechanisms. A product must explicitly connect those lifecycles before one action can control both.

The Three Records You Need To Separate

A reliable remediation plan distinguishes capture, storage, and copies.

1. Future Capture

This is the app-side path controlled by the SDK configuration. The goal is to prevent new events from containing accessibility identifiers that may be sensitive.

The strongest fix is not only disabling reporting. Accessibility identifiers should be static, content-free names such as prompt_composer or send_button. They should never be built from prompt text, a customer's name, a document title, an email address, or a file path.

If a later developer re-enables reporting, static identifiers remain low-risk. If the app continues storing personal content in identifiers, the privacy defect still exists even when one exporter currently suppresses it.

2. Existing Sentry Records

These are events and attachments already ingested. Sentry's API does not offer a normal field-level mutation that replaces one identifier inside one immutable event.

If deletion is necessary, the practical unit is usually the issue. That matters because an issue can group many events sharing a fingerprint. Deleting the issue to remove one bad event may also remove useful, non-sensitive events in the same group.

Before deleting, record the issue ID, project, event count, first and last seen times, environments, releases, owners, linked incidents, and the reason deletion is authorized. Preserve only the minimum evidence your policy requires, and do not copy the sensitive value into the remediation ticket.

3. Downstream And Local Copies

Sentry deletion cannot automatically retract data already copied into:

• Jira, GitHub, Linear, or another issue tracker;
• Slack, Teams, email, or paging notifications;
• exported JSON or CSV files;
• log archives or data warehouses;
• screenshots in documentation;
• downloaded event attachments;
• support tickets; or
• locally queued SDK envelopes on a device.

Each copy needs an owner, a lookup method, and an independent disposition. Closing the source issue is not proof that every copy was removed.

Use The STOP Audit

The STOP audit turns the configuration change into a verifiable remediation process.

S — Ship The Future-Capture Fix

Apply the option in the real Sentry initialization path used by production. Confirm that another initializer, build flavor, framework wrapper, or remote configuration does not overwrite it.

Review both controls:

options.attachViewHierarchy = true
options.reportAccessibilityIdentifier = false

This combination keeps the hierarchy while omitting accessibility identifiers. If the hierarchy has no justified diagnostic purpose on sensitive screens, consider disabling attachViewHierarchy instead.

Also replace dynamic identifiers in application code. Search assignments and framework equivalents for interpolation, concatenation, prompt variables, filenames, titles, route parameters, account data, and model output.

Record the release version, commit, SDK version, build configuration, and rollout time. Without those boundaries, investigators cannot tell which events occurred before or after the fix.

T — Trace Existing Exposure

Start with a unique non-secret pattern or a known affected identifier. Do not paste a real prompt into more systems while investigating it.

Use Sentry's issue and event interfaces to identify:

• affected projects and environments;
• releases that could have reported the field;
• issues with view-hierarchy attachments;
• oldest and newest affected events;
• grouping that mixes affected and unaffected events; and
• integrations that may have exported event content.

Sentry's List an Issue's Events endpoint can enumerate events within a known issue and optionally return full event bodies in smaller pages. Attachment contents may require separate inspection. A search that returns no result is not enough when the field lives inside a JSON attachment the search index does not expose.

Create a positive control for the inventory method. If you know one synthetic event contains a harmless identifier, your process should find it. If it cannot, the inventory method is incomplete.

O — Obtain Authorization And Remove The Right Unit

Deletion can be irreversible and broader than the triggering value. Use an explicit approval gate that names the exact organization, project, issue IDs, environments, and expected collateral loss.

For each issue, decide whether to:

• retain it under an approved exception;
• delete the issue;
• delete and discard future recurrences when that behavior is appropriate; or
• schedule project or organization remediation under a separate change plan.

Do not confuse Resolved, Archived, and Deleted. Sentry's Issue Status documentation says archiving changes triage behavior while events continue to be recorded. Ordinary deletion removes an issue, but the issue can reappear if the error recurs. Delete and Discard Forever additionally discards matching future events and is limited to Error Issues.

If you automate deletion, use least-privileged credentials with event:admin, explicit IDs, strict organization and project checks, dry-run inventory, small batches, request logs that exclude sensitive content, and post-action verification. A 202 Accepted or 204 No Content response is not the same as observing that the intended issue is gone.

P — Prove Both Past And Future Results

Run two different tests.

Future-capture test: install the corrected production-equivalent build in a non-production environment. Put a synthetic marker such as OV-A11Y-FUTURE-9Q7K in an intentionally unsafe test identifier, trigger a handled event with view-hierarchy capture, and verify that a harmless positive-control hierarchy exists while the identifier field is absent.

Past-record test: after approved deletion completes, query the exact issue IDs and event URLs that were targeted. Confirm the records are unavailable, then check every downstream destination on the copy inventory.

Keep the conclusions separate:

• “The new release no longer sends accessibility identifiers.”
• “The approved historical Sentry issues were deleted.”
• “The named downstream copies were removed or retained under policy.”

None of those statements proves the other two.

A Safe Verification Matrix

Use a matrix instead of a single pass/fail checkbox. On a narrow screen, the same release gate is easier to use as six compact checks:

• App configuration: Inspect production-equivalent initialization. Use expected DSN and environment values as positive controls. Pass only when reportAccessibilityIdentifier is false in the shipped path.
• New hierarchy: Trigger a handled synthetic event. Confirm a harmless known hierarchy node appears. Pass only when the hierarchy exists and contains no identifier field or sensitive canary.
• Other event fields: Search event JSON, logs, breadcrumbs, and contexts. Confirm a harmless diagnostic marker appears where expected. Pass only when the sensitive canary is absent from every reviewed field.
• Historical issues: Query exact issue and event IDs captured in the pre-deletion inventory. Pass only when the targeted records are unavailable after asynchronous deletion completes.
• Downstream copies: Check each integration and export destination using its own record IDs. Pass only when every named copy has a documented result.
• Delayed upload: Test offline capture, upgrade, reconnect, and restart with a non-sensitive queued-event marker. Pass only when old queued envelopes do not reintroduce the identifier.

The delayed-upload test is easy to miss. A fixed app binary cannot edit an event already queued by an older build unless the SDK and migration path explicitly do so. Test the real upgrade sequence rather than assuming it.

Common Mistakes

Mistake: “The Toggle Is Off, So We Are Done”

The toggle answers a future serialization question. Historical events and copies remain a separate incident-response task.

Mistake: “The New Canary Is Clean, So Old Data Was Scrubbed”

A new clean event validates the new configuration. It says nothing about old immutable events.

Mistake: “We Can Delete Just The One Bad Event”

Sentry's current permissions documentation says events are immutable and deletion operates on issues. Check how many events the issue groups before authorizing removal.

Mistake: “Archive Means Delete”

Archiving is triage state. Sentry says archived issues can continue receiving recorded events.

Mistake: “The API Returned Success, Therefore The Data Is Gone”

Deletion is asynchronous in the individual-issue endpoint, and bulk operations can return success without mutating an out-of-scope ID. Verify the resulting state.

Mistake: “Sentry Was The Only Copy”

Alerts, downloads, tickets, emails, and warehouses can outlive the source issue. Maintain a copy inventory.

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 reduce the ordinary long-lived account-side chat-history layer. They do not make OpenVeil fully offline, anonymous, zero-log, or free of provider processing. Active requests still require processing by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. Separate operational, security, account, billing, and abuse-prevention records can exist.

OpenVeil is not a Sentry configuration tool, crash-report scrubber, deletion service, mobile endpoint defense, or substitute for an incident-response plan. It cannot remove a prompt that another application already copied into telemetry.

For the field-level risk, read Can An Accessibility Identifier Leak An AI Prompt Into Crash Telemetry?. For sibling artifacts, see Can A Crash-Report View Hierarchy Expose An AI Prompt Even When The Screenshot Is Masked? and Can A Crash-Report Attachment Bypass Client-Side Prompt Redaction?.

Frequently Asked Questions

Does reportAccessibilityIdentifier = false delete old Sentry events?

No. It changes future Apple SDK view-hierarchy capture. It does not edit or delete data already stored.

Can Sentry remove one accessibility identifier from one event?

Not through the normal event API. Sentry documents events as immutable and says they can be deleted only by deleting the whole issue.

What permission is required to delete an issue through the API?

Sentry documents the event:admin scope for issue deletion. Use it only through an authorized, narrowly scoped remediation workflow.

Does resolving or archiving an issue remove its data?

No. Those are issue-management states. They are not equivalent to deletion.

Does deleting an issue stop the same event from returning?

Ordinary deletion does not necessarily prevent recurrence. Sentry separately documents Delete and Discard Forever for supported Error Issues, which discards matching future events.

Will deleting the issue remove copies in Slack, Jira, email, or exports?

No automatic cross-system deletion should be assumed. Inspect and remediate each destination separately.

How can I prove the fix works?

Use a production-equivalent build, a synthetic canary, and a harmless positive control. Confirm that a new view hierarchy is captured while accessibility identifiers are absent, then separately verify each historical deletion target.

Should accessibility identifiers ever contain prompt text?

No. Use stable content-free identifiers. Disabling one exporter is defense in depth, not permission to keep personal data in test IDs.

Bottom Line

Turning off Sentry accessibility-identifier reporting is prevention for future captures, not cleanup for past crash data. The historical event remains governed by Sentry's issue-level deletion model, applicable retention and preservation rules, and every downstream system that received a copy.

Ship the capture fix, remove dynamic content from identifiers, inventory the actual historical exposure, obtain approval for the correct deletion unit, and verify past and future results independently.

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.

Sources

• Sentry Cocoa Options.swift: view-hierarchy and accessibility-identifier controls
• Sentry API permissions and immutable-event note
• Sentry API: Remove an Issue
• Sentry API: Bulk Remove an Organization's Issues
• Sentry API: List an Issue's Events
• Sentry Issue Status documentation