Short answers to what readers ask most about this topic.
ZDR is not a switch in your admin settings, and it is not free. Five features are disabled at the backend, one model class becomes unavailable, and one gap is yours to close.
Matthews Wong
Software Engineer
Key Takeaway
Zero Data Retention for Claude Code is available to qualified Claude for Enterprise accounts and must be enabled by Anthropic rather than from admin settings. With it on, prompts and model responses are processed in real time and not stored, and five features that depend on stored conversation data are disabled at the backend along with one model class.
The first thing worth knowing about ZDR is that it is not a toggle you will find. It is not part of the standard Claude for Enterprise plan and cannot be enabled from your admin settings — it requires separate enablement by Anthropic after an eligibility review, and every enablement action is audit-logged. If you are planning a rollout around it, that procurement step is the long pole, not the configuration.
The second thing worth knowing is that it costs you a specific, enumerable set of features rather than a vague amount of convenience. This post covers exactly what is covered and what is not, the routing gap that quietly leaves sessions uncovered, the five features that stop working, the model that becomes unavailable, and the retention exception that survives ZDR entirely.
With ZDR enabled, prompts and model responses generated during Claude Code sessions are processed in real time and not stored by Anthropic after the response is returned, except where needed to comply with law or combat misuse. It covers model inference calls made through Claude Code on Claude for Enterprise, and it applies to every model available to ZDR organisations.
It is also, importantly, scoped to Anthropic's direct platform. For Claude deployments on Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry, those platforms' own data-retention policies govern instead, and your ZDR arrangement with Anthropic says nothing about them. That is the first thing to check if your architecture already routes through a cloud provider, because it may mean the ZDR conversation belongs with a different vendor.
This is the part that would fail an audit if nobody thought about it. ZDR applies to requests that authenticate into a ZDR-enabled organisation. A developer who signs in to Claude Code with a personal account, or with an API key belonging to a different organisation, is not covered — and their session gives no indication of that. The coverage is a property of the credential, not of the tool.
// ZDR applies to requests that authenticate INTO a
// ZDR-enabled organization. A developer signed in with a
// personal account, or an API key from a different org, is
// NOT covered — and nothing in their session says so.
//
// Deploy these managed settings to close that gap:
{
"forceLoginMethod": "claudeai",
"forceLoginOrgUUID": "<your ZDR organization UUID>"
}
// Without them, ZDR is a property of your organization that
// some of your developers' sessions happen not to have.ZDR is also enabled per organisation, and it does not automatically apply to new organisations created under the same account. Each new organisation requires separate enablement by your account team. An organisation spun up for a new business unit or an acquisition therefore starts without ZDR while everyone assumes the account-level arrangement covers it.
Four areas follow standard data-retention policies regardless. None of them are surprising once stated, and all of them are worth stating explicitly in whatever document your compliance team is going to read.
Outside the ZDR boundary:
| Area | What still applies |
|---|---|
| Chat on the Enterprise web interface | Not covered by ZDR at all |
| Claude Code Analytics | Stores no prompts or responses, but does collect productivity metadata such as account emails and usage statistics |
| User and seat management | Administrative data is retained under standard policies |
| Third-party integrations and MCP servers | Whatever those services do with the data, reviewed independently by you |
These are disabled at the backend level when ZDR is on, which is the right design: the block does not depend on the client behaving. If a disabled feature still appears in the terminal at startup, attempting to use it returns an error saying the organisation's policies do not allow the action.
# Disabled at the BACKEND when ZDR is on, regardless of what
# the client displays. Attempting one returns an error saying
# the organization's policies do not allow the action.
Claude Code on the Web needs server-side conversation history
Cloud sessions from Desktop needs persistent session data
Artifacts needs published content stored by Anthropic
/feedback, /bug, /share sending feedback sends conversation data
Remote Control stores the transcript to sync devices
# And one model:
Claude Fable 5 this model class REQUIRES data retention.
Absent from the /model picker, or shown
disabled. The server rejects requests for
it whatever the client is configured to do.
The "best" alias resolves to Opus instead.The list has an internal logic worth noticing — every one of them is a feature whose value comes from storing the conversation somewhere Anthropic controls. Web sessions need server-side history to exist at all, Remote Control stores the transcript specifically to keep devices in sync, Artifacts publishes page content to Anthropic-operated infrastructure, and feedback submission is by definition sending your conversation to Anthropic. None of them can be made ZDR-compatible by configuration, and future features that need stored prompts will join the list.
Translated out of feature names, here is what a developer on a ZDR organisation notices:
That third one has a real operational cost that is easy to underestimate. When a ZDR organisation hits a genuine Claude Code bug, the normal path of sending a transcript is closed, so the report has to be reconstructed by hand from what people can describe. Budget for that in your support expectations, and consider keeping one non-ZDR sandbox organisation where a reproduction can legitimately be captured.
Claude Fable 5 is unavailable to ZDR organisations, because that model class requires data retention. It is either absent from the model picker or shown disabled with a notice, and the server rejects requests for it regardless of what the client is configured to do — so pinning it in settings does not work around the restriction.
The practical consequence is small and worth knowing anyway: Fable 5 is not the default model, and the alias that normally resolves to it falls back to Opus for organisations where it is unavailable, including ZDR ones. So a configuration that names that alias keeps working rather than failing, on a different model than the person who wrote it expected.
The process is short and entirely outside the product:
Read the retention exception before you present ZDR internally as absolute, because someone will eventually ask. Even with ZDR enabled, Anthropic may retain data where required by law or to address Usage Policy violations, and a session flagged for a violation may have its inputs and outputs retained for up to two years. That is consistent with the standard ZDR policy and it is not a loophole, but it is a sentence your compliance team should read rather than hear second-hand.
ZDR is the right answer for organisations whose constraints genuinely require it, and the wrong first move for organisations that have not checked whether they do. It costs five features, one model, and a procurement cycle, and it leaves you responsible for the routing that makes it real. If you are going to adopt it, deploy the login enforcement in the same change as the enablement — an organisation with ZDR and no forced login has bought a guarantee that some of its sessions quietly do not have.
Sources & further reading