Can A Crash-Reporting SDK Capture An AI Prompt Before It Is Sent?

July 23, 2026

Yes. An unsent AI prompt can reach crash telemetry when app code, breadcrumbs, logs, replay, attachments, or error context copy text from the draft.

Yes. A crash-reporting SDK can receive an AI prompt before the user sends it if the app copies draft text into logs, custom keys, breadcrumbs, attachments, replay data, error messages, or other diagnostic context. That does not mean every SDK captures prompt text by default. The deciding factors are the app's instrumentation, SDK settings, redaction rules, and when telemetry leaves the device.

Last updated: July 23, 2026

Who This Is For

This guide is for:

• people who draft sensitive questions in an AI chat box
• developers building AI chat, support, writing, or research tools
• privacy and security reviewers auditing client-side telemetry
• teams using services such as Sentry or Firebase Crashlytics
• buyers comparing private AI tools beyond their visible chat-history controls

The important question is not only, "Was the prompt sent to the AI model?" It is also: Could another component read or copy the draft before model submission?

The Short Answer: Submission Is Not The First Possible Data Boundary

Text exists in application memory as soon as the interface accepts it. Depending on the app, a draft may also be copied into state stores, browser storage, console output, analytics events, autosave records, session replay, custom error context, or a local crash-report queue.

A crash or non-fatal error can then package some of that context into telemetry. The report may leave immediately, after the app restarts, or after the user opts in, depending on the SDK and configuration.

Firebase's current Crashlytics documentation says developers can attach arbitrary custom key-value pairs and custom log messages to reports to describe the state and events leading up to a crash. It also says breadcrumb logs can show user interactions before a crash, non-fatal event, or application-not-responding event. (Firebase Crashlytics: customize crash reports)

Sentry similarly describes breadcrumbs as a trail of events before an issue. Its browser JavaScript SDK can automatically record categories such as DOM interactions, XHR or fetch requests, console calls, and location changes; developers can also add structured breadcrumbs manually. (Sentry: breadcrumbs)

Neither statement proves that a particular AI app records prompt text. They prove that the telemetry systems can carry pre-error application context. The app's code and configuration determine whether that context includes the draft.

Five Ways An Unsent Prompt Can Enter Crash Telemetry

1. Custom Logs Or Keys Copy The Draft

A developer may log the current input value while debugging a failed composer, autosave routine, keyboard shortcut, or submit button. A seemingly useful line such as draft=<text> can turn the prompt into diagnostic data before the model request exists.

Firebase documents that custom keys represent application state leading up to a crash and that custom log messages are associated with the crash data. On Android, a custom key's value at the time of a fatal, non-fatal, or ANR event is associated with that event. (FirebaseCrashlytics Android reference)

Safer telemetry records facts such as:

• composer_has_text=true
• composer_length_bucket=500_to_999
• submit_state=not_started
• attachment_count=2
• autosave_result=failed

Those fields can help reproduce a bug without copying the words a user typed.

2. Breadcrumbs Preserve Events Before The Error

Breadcrumbs are useful precisely because they preserve a sequence. That sequence can include clicks, navigation, network activity, or developer-defined state changes.

An ordinary DOM breadcrumb such as "button clicked" is not the same as the text inside a prompt. But a custom breadcrumb message, console statement, selector attribute, URL parameter, or event object can include sensitive text if the application places it there. Sentry provides a beforeBreadcrumb hook that can modify or discard an assembled breadcrumb before it is retained with an event. (Sentry: customize breadcrumbs)

The practical lesson is: do not assume a breadcrumb is harmless because it is not called a chat message. Inspect its actual fields and values.

3. Error Messages And Attached Context Include Application State

Developers often enrich errors with the state that made the problem reproducible. Sentry supports event context and attachments, including strings, logs, configuration, and other files. Its documentation says attachments on a scope can be sent with events and can be added, removed, or modified through processing before send. (Sentry: event attachments)

An AI prompt could therefore appear in:

• an exception message assembled from a failed input
• an extra, context, or custom-data object
• an attached diagnostic log
• a screenshot or screen recording
• a serialized state snapshot
• a locally captured network request body

This is not necessarily malicious behavior. It is often a debugging shortcut. The privacy risk comes from collecting more content than the diagnostic purpose requires.

4. Replay Or Screen Capture Observes The Composer

Some observability products can connect an error to session replay or screenshots. Sentry's issue documentation lists replays, attachments, screenshots, HTTP information, breadcrumbs, and console or DOM events among the forms of context that may appear around an issue. (Sentry: issue details)

Whether a prompt is visible depends on masking, blocked elements, replay configuration, the type of UI control, and any later unmasking rule. A privacy review should test the real production configuration rather than relying on the product category or a default-setting assumption.

The strongest design is to treat the AI composer as sensitive at the source:

• block or mask the entire prompt input
• avoid descriptive DOM attributes containing prompt text
• disable replay where masking cannot be guaranteed
• verify screenshots do not include the composer
• retest after SDK and UI upgrades

5. A Local Queue Sends The Report Later

"Nothing was transmitted before I closed the app" does not prove that no report was created. Some SDKs can hold reports or non-fatal events locally and transmit them later.

Firebase says certain non-fatal events are logged on-device and sent with a later fatal report or when the user restarts the app. Its documentation also lets developers disable automatic collection and choose when to send reports. (Firebase Crashlytics: reporting controls)

This creates two separate audit questions:

1. Did the application capture the prompt into a report?
2. When, and under what control, did that report leave the device?

Testing only live network traffic while typing can miss a report that is queued and uploaded during the next launch.

The Capture-Before-Submit Audit

Use this five-stage audit to trace a draft from the chat box to every diagnostic destination.

This audit is more reliable than checking whether the AI request endpoint was called. The crash-reporting path may be separate from the model path.

Why Server-Side Scrubbing Alone Is Not The Best First Control

Server-side scrubbing can reduce what is stored, but the sensitive value has already crossed the network boundary by the time a remote service receives and removes it.

OWASP's Logging Cheat Sheet says extended diagnostic details can include HTTP request and response bodies, while sensitive personal data, secrets, commercially sensitive information, and data outside the logging system's classification should usually be removed, masked, sanitized, hashed, or encrypted. OWASP also recommends sanitizing event data and performing due diligence before sending it to third parties. (OWASP Logging Cheat Sheet)

For AI prompts, use a defense-in-depth order:

1. Do not collect raw prompt text when metadata can diagnose the issue.
2. Redact on the client before an event enters an offline queue or network request.
3. Scrub again at ingestion in case a new field bypasses the client filter.
4. Restrict access and exports because telemetry can spread to alerts, tickets, data warehouses, and backups.
5. Set a retention limit appropriate to the diagnostic purpose.

Hashing a full prompt is usually not a substitute for minimization. Prompt text is high-entropy and often unique, so the hash may still become a persistent correlation identifier even when the original words are not recoverable.

A Safer Telemetry Pattern For AI Chat

The goal is not to remove all observability. It is to preserve enough structure to debug the product without turning diagnostics into a second conversation archive.

Prefer:

• event names such as composer_submit_failed
• coarse prompt-length buckets instead of raw character counts when exact length is unnecessary
• schema and validation error codes instead of invalid input values
• attachment count, type category, and size bucket instead of filenames or content
• request and trace identifiers that do not encode user content
• model or feature identifiers that are already approved for telemetry
• explicit allowlists of fields permitted to leave the client

Avoid:

• raw prompt or transcript text
• prompt fragments in error messages
• full application-state dumps
• complete request or response bodies
• filenames that reveal people, clients, diagnoses, or projects
• screenshots or replay of an unmasked composer
• console calls that interpolate the current draft

An allowlist is safer than trying to enumerate every sensitive term. Prompts can contain names, health details, legal strategy, credentials, unpublished work, personal conflicts, or other information that a generic pattern-based scrubber will not recognize.

How To Test Whether An AI App Leaks Drafts Into Crash Reports

Use synthetic marker text, not a real secret.

1. Enter a unique string such as TELEMETRY-AUDIT-7F3K into the prompt box without submitting it.
2. Trigger controlled failures at several points: while typing, during autosave, when adding an attachment, and immediately before the submit handler.
3. Keep the model endpoint blocked so the prompt cannot leave through the intended AI request.
4. Inspect browser or mobile network traffic for observability endpoints.
5. Restart the app and inspect traffic again for delayed uploads.
6. Review the exact event in the crash vendor, including breadcrumbs, custom fields, attachments, replay, screenshots, and linked logs.
7. Search downstream alerts, tickets, exports, and data warehouses for the marker.
8. Repeat with automatic reporting disabled and with consent denied, if those controls exist.
9. Repeat after clearing the visible chat or draft to see whether a queued report still contains the marker.

Pass criteria should be strict: the marker never appears outside the component that needed the draft, and diagnostic events remain useful through content-free metadata.

What This Does Not Mean

This article does not mean:

• every crash-reporting SDK automatically reads text fields
• every breadcrumb contains typed content
• every network breadcrumb records a request body
• disabling AI model submission automatically disables telemetry
• deleting a visible chat necessarily deletes a queued or stored crash event
• encryption in transit prevents an authorized telemetry service from processing the event
• a privacy-focused AI service performs no operational logging or provider processing

The accurate conclusion is conditional: an unsent prompt can be captured when the application's diagnostic path is allowed to read or copy it.

What To Check Before Choosing An AI Tool

For sensitive AI work, ask:

• Does the privacy policy distinguish chat history from diagnostics and telemetry?
• Can crash or analytics reporting be turned off or made opt-in?
• Are prompt fields blocked from replay and screenshots?
• Does client-side redaction run before offline queueing and transmission?
• Are request bodies excluded from logs, traces, and crash attachments?
• Can users delete diagnostic records, and does deletion cover exports or backups?
• How long are crash reports and attachments retained?
• Which employees, vendors, and subprocessors can access them?
• Are telemetry controls tested after SDK updates?

An answer such as "we do not save chat history" does not, by itself, answer these questions. Chat history and crash telemetry are different data systems.

Where OpenVeil Fits

OpenVeil is a paid, privacy-focused AI chat workspace with browser-local chat history and no server-side chat-history record for normal private chat sessions. It supports private chat, web search, uploads, voice, and image tools without positioning itself as a fully offline product.

That boundary matters here. Browser-local history reduces the ordinary server-stored conversation archive, but active requests may still be processed by OpenVeil and necessary AI, search, upload-processing, hosting, routing, security, billing, and infrastructure providers. Account and billing records also remain necessary to operate the service.

When evaluating OpenVeil or any other AI product, separate these questions:

1. Where is visible chat history stored?
2. What processes an active request?
3. What operational telemetry exists?
4. What is retained, for how long, and for what purpose?

Read the OpenVeil privacy policy, review what no server-side chat history does and does not mean, and use the AI privacy-claim checklist before deciding what information belongs in any hosted AI tool.

FAQ

Can a crash SDK read a prompt that was never submitted?

It can if the application exposes or copies the draft through instrumentation, custom context, logs, replay, screenshots, attachments, or an exception. The SDK's presence alone does not prove that this occurs.

Does a keyboard breadcrumb contain everything I typed?

Not necessarily. A keyboard or DOM breadcrumb may record an interaction without recording the field's value. Custom code, console output, replay settings, or element attributes can still add content, so inspect the actual payload.

Can a prompt be sent after I close and reopen the app?

Potentially. Some crash systems can queue reports or non-fatal events locally and upload them after restart or when collection is later enabled. Test delayed transmission rather than watching only the typing session.

Is beforeSend enough to protect AI prompts?

It is a useful client-side control when it reliably removes sensitive fields, but it should be backed by collection minimization, breadcrumb filtering, replay masking, ingestion scrubbing, access controls, and regression tests.

Does deleting the chat delete its crash report?

Do not assume so. A crash event is usually a separate record with its own retention and deletion controls. Verify both systems.

Should developers log a redacted part of the prompt?

Usually no. Fixed metadata such as an error code, feature state, attachment count, or prompt-length bucket is less likely to preserve identifying content. If any content sample is truly necessary, document the purpose, consent, access, and retention, and test the redaction before release.

Bottom Line

An AI prompt does not need to reach the model to leave the device. Client-side crash reporting can create an earlier route through logs, keys, breadcrumbs, replay, attachments, error context, or delayed report queues.

The safest pattern is simple: do not put prompt content into telemetry, redact before queueing or transmission, scrub again at ingestion, and verify the real payload with a synthetic marker.

OpenVeil's browser-local history model addresses the ordinary chat-history record, while its documented product boundaries remain clear that hosted AI requests and necessary providers still process data. That kind of separation is what every AI privacy review should demand.