Developer data protection
Claude
Review Claude Code support uploads
A Claude Code feedback submission can disclose conversation history and source code beyond the text of a bug description. Review the selected sharing path, included material, recipient and retention before sending. Current documentation distinguishes /feedback-style reports, simple session ratings, optional transcript sharing and automatic error reporting; their data and retention are not interchangeable.
For Developer-platform and privacy teams
A short bug description can accompany a much larger disclosure.
Synthetic payload illustration, not a real export or submitted report. No network action is included.01
Identify the exact sharing action
A developer reporting a failure may choose a feedback command, a rating prompt or a later transcript-sharing option. Start by naming that action and the current client/provider route. Do not apply the ordinary chat-retention setting to an exceptional support upload without checking the documented policy.
Anthropic currently documents /feedback, /bug and /share as using the same feedback-reporting path. The documentation states that shared transcripts on that path are retained for five years and that feedback may be used to improve products and services. Review that disclosure separately from the team’s normal coding permission.
Source context: Claude Code: Data usage
02
Keep ratings, transcripts and diagnostics separate
The session-quality rating prompt is documented as collecting the rating rather than the conversation transcript. A separate follow-up can ask to share session data. The current documentation describes explicit consent for that follow-up, source code and conversation content included as-is, and retention up to six months for shared transcripts on that path.
Some provider or authentication arrangements create a local archive for the optional follow-up instead of uploading it immediately. Forwarding that archive later is another disclosure decision. Automatic error reporting is also a separate flow with its own eligibility, redaction and opt-out behaviour. Verify the flow actually presented to the user.
| Action | Documented distinction | Review before acting |
|---|---|---|
| /feedback, /bug or /share | Feedback transcript path; five-year retention | Included history and code |
| Session rating | Rating alone, not a transcript | The specific prompt being answered |
| Optional transcript follow-up | Separate explicit sharing; up to six months | Payload, eligibility and provider route |
| Local diagnostic archive | May remain local until forwarded | Archive contents and intended recipient |
Source context: Claude Code: Data usage
03
Inspect what accompanies the report
Look for source files, conversation excerpts, command output, paths and comments that reveal more than the error. A value being redacted does not mean proprietary code or business context has been removed. Separate “known secret pattern removed” from “owner has approved this disclosure.”
The synthetic bundle in the download contains a fake project path, a fictional feature name, a harmless code excerpt and an already removed credential marker. Its purpose is to show how a bundle can still contain company-style context after a token is absent. It is not a real Claude Code export or a promise about every field in one.
04
Prefer the smallest useful support example
Where possible, reproduce the issue in a clean project with synthetic data and prepare the report from that context. Preserve the version, relevant operation and error needed for diagnosis, while leaving unrelated repository content out. Do not edit evidence in a way that changes the failure being described without explaining the difference.
Use the review worksheet before an authorised person sends the material. Record the exact route, included history, recipient, documented retention and owner decision. Keep observed contents separate from assumptions about automatic redaction. If the bundle cannot be inspected or reduced sufficiently, use the organisation’s approved support and escalation process.
05
Make feedback sharing part of developer practice
Tell developers who can approve support disclosures and which routine feedback choices are permitted. A useful rule covers both a convenient in-product button and a file later forwarded to support. It should explain how to obtain help without putting real credentials or customer data into a diagnostic reproduction.
Recheck the policy when the client changes its feedback interface, provider route or account agreement. Keep normal prompt inspection, support uploads and telemetry as separate coverage questions. A browser or native DLP result for ordinary chat does not establish that an exceptional support bundle was evaluated.
Source context: Claude Code: Data usage · Aona: AI security coverage
Put it into practice
Claude Code support-upload review pack
Inspect a fictional bundle and document the selected sharing route before an authorised disclosure.
Synthetic payload illustration, not a real export or submitted report. No network action is included.
| Bundle element | Illustrative content | Decision needed |
|---|---|---|
| Error | Synthetic parser failure | Enough detail to reproduce? |
| Conversation | Fictional feature discussion | Necessary and approved? |
| Code | Harmless toy function | Owner permits the disclosure? |
| Credential field | Removed fake marker | Other sensitive context still present? |
Work through your review
Use the checks to organise the evidence you need. Save your selections in Word, then add your notes and evidence. Your selections stay in this tab until you download them.
0 of 3 reviewed
Examples and review material
Read the detail here, or keep the PDF, editable Word document and spreadsheets together.
Support-upload review exerciseRead
This is a fictional payload, not a Claude Code export. It contains no customer data, working credentials or instructions to send a report. No file invokes feedback commands or makes API calls.
Read synthetic-support-bundle.json. Notice that removing the fake credential does not remove the fictional feature name or code context. Use bundle-review.csv to decide what is necessary, and complete the “Support disclosure decision” section with the intended route and current retention source. Do not put a real support bundle into this training pack.
Worked example: the toy sum function and feature discussion do not reproduce the named parser error. They illustrate unnecessary context and should be omitted from this fictional parser report. A real minimal parser reproduction and current version would need separate evidence. This is a teaching disposition, not an authorised support submission.
Guide and source references
Canonical guide: https://aona.ai/resources/guides/ai-coding-assistant-support-uploads/ Source review: 2026-09-21
- Claude Code: Data usage: https://code.claude.com/docs/en/data-usage
- Aona: AI security coverage: https://aona.ai/resources/ai-security-coverage/
Synthetic support bundleRead
Notice: SYNTHETIC EXERCISE ONLY; NOT AN ACTUAL EXPORT
Route: TO_BE_SELECTED_AND_APPROVED
Client version: RECORD_CURRENT_VERSION
Error: SYNTHETIC_PARSE_ERROR: quantity missing
Project path: /synthetic-review/example-project
Conversation excerpt: Review the fictional INTERNAL_DEMO_FEATURE calculation.
Code excerpt: def synthetic_total(values): return sum(values)
Credential field: [FAKE_CREDENTIAL_REMOVED]
Submission status: NOT_SUBMITTED
Bundle reviewRead
| Element | Observed synthetic content | Needed for diagnosis | Owner decision | Change or reason | Illustrative disposition |
|---|---|---|---|---|---|
| error | SYNTHETIC_PARSE_ERROR | REVIEW | UNDECIDED | Retain only with the actual minimal reproduction and version | |
| project_path | fictional local path | REVIEW | UNDECIDED | Omit unless necessary for the specific diagnosis | |
| conversation_excerpt | fictional internal feature | REVIEW | UNDECIDED | Omit unrelated feature discussion | |
| code_excerpt | toy sum function | REVIEW | UNDECIDED | Omit unrelated toy sum function | |
| credential_field | removed fake marker | REVIEW | UNDECIDED | Keep credentials out; a removed marker does not approve the remaining context |
Support disclosure decisionRead
Client/version, provider and account: ____________________ Exact action: rating / feedback report / optional transcript / forwarded archive / other Files and history selected: ____________________ Recipient: ____________________ Documented retention for this route and source date: ____________________ Owner approval for code and other context: ____________________ Minimal reproduction available: ____________________ Decision: NOT YET REVIEWED Submission status: NOT SUBMITTED
A local draft or archive is not proof that nothing will leave if it is later forwarded. Review that later action separately.
Before you proceed
Keep these distinctions clear
- Using the normal retention setting for every upload
- Identify the exceptional feedback route and its own documented handling.
- Equating redaction with disclosure approval
- Code, comments and conversation context may remain even when a credential pattern is removed.
Apply it to employee AI use
Bring your actual data path.
Aona secures employees’ AI use on supported, installed endpoint paths.
This guide does not claim coverage of every feedback command, diagnostic archive, telemetry flow or third-party support upload.
Bring an inert synthetic bundle and the actual intended sharing route to a scoped coverage discussion.
Review your use caseFAQ
Questions for this decision
Does answering the session rating prompt send the transcript?
Are /feedback transcripts retained like normal coding sessions?
Is the sample JSON the exact Claude Code export format?
If a diagnostic archive remains local, is it automatically safe to email?
Evidence behind the guide
Sources and scope
Prepared by Aona. Sources checked 2026-09-21. The cited material supports the specific points below; it does not certify a product or your use case.
- Claude Code: Data usage
Documents feedback-report retention, session ratings, optional transcript sharing, local archives and error-reporting distinctions.
vendor · checked 2026-09-21 - Aona: AI security coverage
Requires verification of the exact supported input route rather than assuming universal interception.
vendor · checked 2026-09-21