Claude Code Zero Data Retention: What You Give Up

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.

What ZDR actually promises

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.

The routing gap you have to close yourself

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.

What ZDR does not cover, even when it is on

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:

The five features that stop working

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.

What is actually lost day to day

Translated out of feature names, here is what a developer on a ZDR organisation notices:

• No starting a task from a phone or browser, and no picking up a desk session elsewhere — both the web surface and Remote Control are gone.
• No publishing an artifact, so anything you would have shared as a page has to be a file or a document somewhere else.
• No feedback, bug or share commands, which also means your team cannot send Anthropic a reproduction when something misbehaves.
• Contribution metrics are unavailable in the analytics dashboard, which shows usage metrics only.

The model that is not available

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.

Getting it, and the exception that survives it

The process is short and entirely outside the product:

1. Contact sales or your Anthropic account team to confirm eligibility — ZDR is available to qualified accounts and is not part of the standard Enterprise plan.
2. Your account team submits the request internally, Anthropic reviews it, and enables it on the organisation after confirming eligibility.
3. Deploy the login-method and organisation managed settings so developers' sessions actually authenticate into the covered organisation.

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.