Your Local Claude Code Sessions Are Now Retrievable by Your Organization

What Actually Shipped

The relevant line in Anthropic's August 11 release notes runs to two sentences. It says the Compliance API now returns transcripts of Cowork and Claude Code sessions that run on your users' machines, in beta for Claude Enterprise organizations, through three endpoints:

• GET /v1/compliance/apps/sessions/local — lists sessions across the organization.
• GET /v1/compliance/apps/sessions/local/{session_id} — retrieves one session's metadata.
• GET /v1/compliance/apps/sessions/local/{session_id}/messages — returns its transcript.

All three work with an existing Compliance Access Key carrying the read:compliance_user_data scope. The reference page is explicit that "no new key, scope, setting, or client update is required" — the same key that already reads claude.ai chats, files, and projects reads these.

A related detail is easy to miss. The list endpoint is built from session activity metadata, not from transcripts, so it can return sessions whose content was never captured — including sessions that ran before capture began for the organization, as far back as the retention period allows. Such a session still appears in the list, still carries its user ID and email address, and then returns messages marked unavailable. An export can therefore establish that a session happened and who ran it, even where it cannot show what was said.

The endpoints are read-only. Anthropic's documentation states plainly that local and remote sessions "cannot be deleted through the Compliance API." A Compliance Access Key is created in claude.ai by the primary owner of the parent organization, or by an organization owner for a key limited to their own organization. An Admin API key created in Claude Console cannot reach these endpoints at all; such calls return 403 Forbidden. All /v1/compliance/* calls share a limit of 600 requests per minute per parent organization, and the local session endpoints count against that limit only.

Does It Apply to Your Organization?

Capture is tied to the Compliance API being enabled for the organization, and it applies while users are signed in with their Claude Enterprise account. Enablement is done by the primary owner in claude.ai under Organization settings, and it cascades from the parent organization to every linked organization. It is an organization-level switch, not a per-team, per-repository, or per-project one.

The documentation lists four cases the local session endpoints do not return, and they are more useful than the inclusion rule because each one names a real configuration:

• Claude Code authenticated with a Claude Console API key, or run through Amazon Bedrock, Google Cloud, or Microsoft Foundry. Same binary, same machine, different credential — not returned.
• Claude Code on the web. It runs in Anthropic-managed environments, but it is not a "remote session" either; the remote endpoints return Cowork sessions only.
• Organizations with HIPAA readiness enabled. No local session data is captured, so the endpoints return no sessions for them.
• Sessions under zero data retention. Excluded from list results; retrieve and messages return 404.

One more case sits between yes and no: organizations using customer-managed encryption keys get local sessions listed and retrievable, but no transcript content — every message comes back marked unavailable. That is worth knowing before a legal team assumes an export will contain text.

So the boundary that decides whether a session is retrievable is which credential the client authenticated with, not whose hardware it ran on. The intuition to correct is the one that treats the laptop as the private space and the cloud as the monitored one. Here the laptop is not the boundary; the sign-in is.

What Is Actually in the Transcript

The mechanism matters for reasoning about the blast radius. Anthropic records each conversation server-side as its requests reach the Claude API. Nothing is installed on the device, and nothing is collected beyond the requests the client already sends. The consequence, stated in the docs: transcripts show "what Claude was asked to do and what it returned, not what happened on the device." File and network activity is visible only through tool calls and tool results, so a local file the session never sent is not captured.

Within that boundary, the transcript is close to verbatim. It carries user prompts, assistant text, tool calls, and the text portions of tool results, "all returned as they were sent apart from size truncation." And then the sentence that should drive every habit change below:

Two specifics deserve naming because developers do not expect them. First, project instruction files such as CLAUDE.md appear as ordinary user-role content — indistinguishable from something the developer typed. Second, skill content appears when the client sends it as message content, also undifferentiated from user text. Anything you wrote once into a repo's instruction file is therefore in the transcript of every session that repo produces.

Several things are not returned, and the omissions are as informative as the inclusions:

Size caps are the detail most likely to give false comfort. Each tool_use input and each text entry in a tool_result is truncated to 10,000 bytes by default — but the caller can pass tool_result_max_bytes=-1 to raise it to the server maximum of roughly 1 MiB per string. The default is a convenience for the exporter, not a privacy control. Assume the reviewer raises it.

Retention is six years from capture by default. If the organization has set a finite custom conversation retention period, that period applies instead — shorter or longer — and where several are configured, the shortest wins. Lengthening the period later does not resurrect content that already expired, because each message is stored under the period in force when it was captured.

This Is Not the Same Problem as Sanitizing Your Input

Our guide on what to remove from code and data before sending it to an AI service answers a question about the outbound direction: what leaves your environment, and what the provider could see. This release is the return path. The provider already had the requests; the change is that your own organization can now enumerate them, attribute each one to a user ID and email address, and read the text back on demand.

That distinction changes who the risk is about. Outbound sanitization protects the company from leaking to a vendor. Retrieval does the opposite job: it exposes the individual developer's session to their own employer's security, legal, and HR processes. That is a legitimate governance capability and a genuinely new exposure for the person typing. Both are true at once.

It is also not observability. The telemetry you build for debugging a failed agent run answers "why did this go wrong" and carries the token counts, latencies, and host metadata that transcripts deliberately omit. Compliance retrieval answers "what did this person ask for, and what came back." And unlike a decision log you choose to write, a transcript is a record nobody opted into composing.

Three Habits Worth Changing Now

1. Stop the secret from entering the context, not just the prompt. The common advice — "don't paste your API key into the chat" — is now half a rule. The capture boundary is the API request, so a key that arrives via a tool result is in the transcript exactly like a pasted one. Asking the agent to cat .env, dumping a connection string into a debugging prompt, or pasting a production log full of customer records all land in the same place, unmasked and retained. The workable version: let commands consume secrets from the environment or a secret manager without the agent reading the values back, and refer to secrets by name.
The test: if you hold a Compliance Access Key with read:compliance_user_data, pull one of your own sessions with tool_result_max_bytes=-1 and search the response for a known token prefix or a customer name. If you do not, use your terminal scrollback as the proxy — whatever the agent read is a candidate for the transcript.

2. Treat CLAUDE.md and skill files as compliance-visible text. They read as ordinary user content, they are re-sent constantly, and they are retained for six years by default. An internal hostname, a customer name in an example, a ticket link, or a helpful note about where a staging credential lives is not written once — it is written into every session the repo produces. Audit those files the way you would audit a file you knew was going to be exported.
The test: grep your instruction and skill files for hostnames, internal URLs, customer or client names, and any sentence that tells a reader where a credential is kept. Anything that would be awkward in an eDiscovery export belongs in a secret store or a private note instead.

3. Know which credential you are signed in with before you start. Because capture follows the Claude Enterprise sign-in rather than the machine, "work laptop" and "work session" are no longer the same thing. Personal exploration on a work account is captured; work done under a Claude Console API key or through a third-party cloud platform is not returned by these endpoints. This is not an argument for evading governance — work should be done on the work profile, where the audit trail belongs. It is an argument for knowing which profile you are in, deliberately, before you type.
The test: check the authentication method your client is currently using before starting anything you would not want listed under your email address, and keep personal projects on a separate profile rather than a separate directory.

One correction belongs with all three, because it is routinely misread: /clear scopes, it does not erase. Starting a new conversation or clearing context begins a new session record with a new clls_ ID. The previous record still exists, still lists, and still cannot be deleted through this API.

What to Check This Week

• Establish whether you are in scope. Two questions: is your organization a Claude Enterprise organization with the Compliance API enabled, and are you signed in to Claude Code with that Enterprise account? If either is no, these endpoints do not return your sessions.
• Find out your organization's retention period. Six years is the default. A finite custom conversation retention period replaces it, and the shortest configured period applies. That number, not the default, is how long today's session is retrievable.
• Sweep instruction and skill files across your repositories for secrets-by-location, internal hostnames, and named customers. This is the cheapest fix on the list and the one with the widest blast radius.
• Replace the "read the secret so the agent can use it" pattern. Anywhere an agent is told to open a credentials file, move the value to an environment variable or a secret manager reference that the command resolves without the agent seeing it.
• If you own the compliance side, walk the list endpoint once. It filters on created_at.gte and created_at.lt only — no user or organization filter — and paginates forward with page and next_page. Sessions appear after a short processing delay, typically within minutes, so absence right after a session starts is not evidence it was not captured.
• Tell your developers. A governance capability that engineers discover during an investigation costs more trust than one announced in a team channel the week it ships.

The reasonable reaction here is not alarm. An organization that pays for Claude Enterprise has a defensible interest in what its agents were asked to do, and the documentation names eDiscovery exports and data loss prevention as the use cases this is built for. The useful reaction is narrower than alarm and more specific: the transcript is close to verbatim, it is unmasked, it is retained for six years by default, and it now has a documented retrieval path. Write your local sessions as if that were true, because as of August 11 it is.