Claude Code ZDR: What Zero Data Retention Covers

Claude Code ZDR, or zero data retention, is a specific arrangement for eligible use, not a privacy switch that every Claude Code account includes. It addresses covered provider processing; it does not mean your computer, connected tools, and every Claude product keep no records.

Before using sensitive code, confirm the account, organization, deployment route, and features covered by your agreement. fenbs can keep that approved workflow in Decisions and rules for the team, but fenbs does not provide zero retention or extend Anthropic’s agreement to another service.

What does zero data retention mean for a coding session?

Anthropic’s Claude Code ZDR documentation↗ (opens in a new tab) describes separate enablement for qualified Enterprise organizations. Covered prompts and model responses are processed without storage after the response, subject to legal and misuse exceptions. Standard Enterprise access alone does not establish eligibility or enablement.

Think of the question as a boundary around a particular service interaction. A developer sends a request through an approved route, the model produces a response, and an agreement governs what the provider keeps. That says nothing by itself about a source repository, a local session file, or an issue tracker the assistant updates afterward.

For example, a team may permit analysis of a private module only through its approved organization. The authorization should name the permitted workflow, not simply say “Claude Code is private.” The next developer needs to know which sign-in to use and which related features require a different decision.

How is retention different from model training?

Training is using information to improve a model. Retention is keeping information after processing it. A service can promise not to train on your code while retaining it under its normal operating policy. Avoid replacing a retention requirement with a training statement just because both appear on a privacy page.

The Claude Code data-usage guide↗ (opens in a new tab) distinguishes consumer training choices, commercial policies, and retention. It also describes local plaintext session transcripts and separate feedback handling. Read the relevant section for the actual account rather than applying a commercial statement to a personal sign-in.

Ask the owner of the requirement to say what must be avoided: model improvement, provider storage, local storage, outside disclosure, or all of those. A contractual requirement might name only one. A company policy may name several. Clear wording prevents a well-intentioned teammate from solving the wrong problem.

Keep the provider’s current policy linked beside the team’s interpretation. The Claude Code documentation guide helps locate the right reference. A link plus a dated approval is more useful than copying a long policy paragraph into a project and forgetting to revisit it.

Which account and deployment route are covered?

Coverage follows requests authenticated into the enabled organization. A personal sign-in or another organization’s key does not inherit it. Anthropic also directs teams using third-party platforms to those platforms’ retention policies. Ask your account team to confirm the applicable arrangement before making the first sensitive request.

Do the first verification with harmless sample code. Have the administrator check the organization and managed configuration while the developer demonstrates the workflow. Do not paste real credentials into a test request, a support ticket, or a screenshot of settings. The evidence should establish the configuration without disclosing the information it is meant to protect.

Record the verified route as a rule in the shared work record. Include the owner to contact when the sign-in looks different. A policy that only one administrator remembers will not reliably guide a teammate starting a new machine or joining a new project.

What remains outside the provider’s retention boundary?

Anthropic’s scope excludes chat, Cowork, administrative records, and data processed by third-party integrations. Some features that require transcript storage are disabled under ZDR. Consult the current scope and feature list rather than assuming a newly visible button is covered.

Local files need a separate plan. Session transcripts, copied output, terminal logs, backups, and source changes can each persist for a different reason. Deciding what the model provider retains does not decide whether your laptop backup should keep yesterday’s transcript. Inventory those copies before making a claim about the entire workflow.

External tools introduce their own boundary. A code review posted to another service becomes a record in that service. A connected assistant that reads project notes receives the approved context needed for its work. Review the information crossing that connection and the destination’s policies instead of assuming a ZDR label follows the data.

Keep environment isolation separate too. The Claude Code sandbox guide covers restrictions on what execution can reach. A sandbox can limit actions; retention concerns copies of information. You may need both controls, but they answer different questions and should have separate checks.

How should a team verify and maintain the workflow?

1. Name the requirement and who owns it. State whether it applies to source code, customer records, prompts, outputs, or a narrower category.
2. Confirm provider enablement and scope in writing through the appropriate account contact. Resolve third-party platform questions with that platform.
3. Review sign-in and managed configuration. Anthropic’s settings documentation↗ (opens in a new tab) explains configuration scopes and organization management.
4. Test with nonsensitive material, then check local records, connected destinations, and the team’s handling procedure.
5. Revisit the approval when the account, route, feature, machine setup, or data category changes. Keep unresolved checks visible.

The result should be a reproducible workflow, not a screenshot someone cannot interpret later. Say what was checked, who checked it, and what remains outside approval. If a required control cannot be verified, leave that part of the work waiting on a person instead of inferring that a familiar account must be covered.

How to record the approved workflow with fenbs

1. Create a free account, add the project, and use a team kanban board when colleagues need shared access.
2. Record the human-approved retention rule in Decisions and rules. Include the permitted route, scope, owner, and conditions without including keys, tokens, or sensitive source content.
3. Add tasks for outstanding verification and write the checks in their plans. Record test results honestly, including anything the account team still needs to confirm.
4. Ask connected assistants to read the project’s Rules before working and save progress before stopping, including any blocked verification.

fenbs is useful for keeping the approval and follow-up work consistent across sessions. It does not inspect your Claude configuration or make records stored in fenbs subject to Claude Code ZDR. If your requirement forbids storing the project information in another service, keep that information out of fenbs.

For basic setup, use the Claude Code installation guide. For related policy questions, start with the AI governance hub. The useful final answer is precise: this organization, this route, this information, these permitted features, and these remaining records to manage.