Which Claude sessions does the Compliance API actually capture?

Anthropic added Claude in Chrome to the Compliance API’s session coverage on 18 September 2026, extending a table that already listed Cowork, Claude Code, Claude Science and Claude for Microsoft 365. Read on its own, that looks like coverage converging on complete. Read the rest of the documentation and the exclusions turn out to be wider than the coverage: whole categories of session never reach a compliance reviewer, and a common way of polling for new ones throws sessions away for good.

Which Claude sessions does the Compliance API actually capture?

The Compliance API splits sessions by where they run. Local session endpoints cover apps on a user’s machine: Cowork in Claude Desktop, Claude Code in the terminal, Claude Desktop or an IDE extension, the Claude Science desktop app, Claude for Microsoft 365’s Excel, PowerPoint, Word and Outlook add-ins, and, as of the 18 September 2026 release, the Claude in Chrome browser extension’s built-in chat. Remote session endpoints cover the opposite case: Cowork sessions started on claude.ai web or mobile, which run in Anthropic-managed cloud infrastructure rather than on the user’s device. Each session carries a product_surface value naming which of these created it, from cowork to claude_in_chrome to office_agents/excel. Coverage of Claude Science, Microsoft 365 and Claude in Chrome is still in beta; only Cowork and Claude Code sessions are marked stable in Anthropic’s documentation.

Which sessions never reach the Compliance API at all?

Two exclusions are absolute rather than partial. The documentation states plainly that the Compliance API does not capture local sessions for which zero data retention is in effect, or any local sessions from organizations with HIPAA readiness enabled. That exclusion covers every session in those organizations. It is not limited to the sessions that happen to touch protected health information. A third gap sits in how Claude Code authenticates: only sessions signed in with a Claude Enterprise account reach these endpoints, so Claude Code run with a Claude Console API key, or through Amazon Bedrock, Google Cloud or Microsoft Foundry, is invisible to a compliance reviewer relying on this API. A fourth gap is about naming rather than policy. Claude Code cloud sessions run on Anthropic’s cloud infrastructure instead of a user’s laptop, but they are explicitly not remote sessions in this API’s sense. The remote session endpoints return Cowork sessions only, so a security team auditing “everything that ran in the cloud” will miss an entire product by trusting the label.

How does the local session polling window silently drop sessions?

An integration that wants to catch newly active sessions polls the list endpoint with updated_at.gte set to the time of its previous run. The documentation describes exactly where that goes wrong: updated_at on the list endpoint is a lower bound, and for a session still active at a window boundary it can momentarily lag behind the session’s true last activity, because a new call only becomes queryable after a short indexing delay. A bound set to the exact previous run’s start time silently and permanently drops a session whose final call was still indexing at that moment, because once the bound advances past that call, no later run returns it. The fix is to set each run’s updated_at.gte a few minutes earlier than the previous run’s start time rather than at that exact timestamp, and to run a periodic reconciliation pass over older windows as a backstop.

How a fixed polling bound permanently drops a session

Show as text

How a fixed polling bound permanently drops a session. Sequence diagram between Export job and Compliance API. 1. Export job to Compliance API: list, updated_at.gte = T0. 2. Compliance API to Export job: Sessions active up to that instant. 3. Export job to Export job: Next run sets updated_at.gte to T0 again. 4. Export job to Compliance API: list, updated_at.gte = T0. 5. Compliance API to Export job: That session never appears again.

#	From	To	Message
1	Export job	Compliance API	list, updated_at.gte = T0. T0 is the previous run's exact start time.
2	Compliance API	Export job	Sessions active up to that instant. One call finishing right at T0 is still indexing.
3	Export job	Export job	Next run sets updated_at.gte to T0 again. The still-indexing call is now before the bound.
4	Export job	Compliance API	list, updated_at.gte = T0
5	Compliance API	Export job	That session never appears again. No later window's lower bound reaches it.

What does a captured session transcript actually include?

Even a session inside every included category is not returned in full. Thinking blocks are never included, in local or remote transcripts alike. The request’s system prompt is never returned either; a marker message reading “[system prompt content not shown]” stands in for it once per session. Images, PDFs and other binary or structured blocks come back as a placeholder such as “[image content not shown]”, and citation metadata on a web-search-grounded answer is stripped from a text block that otherwise reads normally, with truncated set to true as the only sign anything is missing. Tool inputs and tool result text are capped at 10,000 bytes each by default, rising to about 1 MiB per string on request, and a tool_use input cut off at that boundary is no longer valid JSON, so parsing it without checking the truncated flag first will throw on exactly the sessions with the largest, and often most interesting, tool calls.

What a local session transcript includes and omits

Show as text

What a local session transcript includes and omits. Diagram: 4 ordered layers. User prompts and assistant text, then Tool calls and tool result text, then System prompt (breakpoint), then Thinking, images, PDFs, citations.

#	Layer	Note
1	User prompts and assistant text	Sent as is, only size-truncated
2	Tool calls and tool result text	10,000 bytes each by default
·	System prompt (breakpoint)	Replaced by one marker message
3	Thinking, images, PDFs, citations	Never returned, placeholder only

What happens to a session’s transcript after Claude compacts its context?

Session transcripts intersect with Claude’s compaction features in a way neither document mentions the other. When a client rewrites or compacts its conversation history mid-session, the Compliance API inserts a synthetic_marker record at that point and continues the transcript with whatever the client sent afterward. For an organization with a finite custom retention period, a second marker withholds the rewritten history entirely, so only the latest user turn and what follows it are shown. Nothing here is a deletion in the retention sense: the underlying calls are still subject to the same six year or custom retention window as everything else. It reads as one to a reviewer who does not know to look for the marker type, because a synthetic_marker record and a genuinely empty turn look identical unless the code checks provenance.type before rendering.

How many Compliance API requests can you make before you get rate limited?

The Compliance API allows 600 requests per minute per parent organization, one budget shared across every Compliance Access Key and Admin API key under that parent and across every /v1/compliance/* endpoint, rather than a separate budget per key or per endpoint. The remote session endpoints carry a second request budget on top of that shared limit, and its 429 response always reports a retry-after of 1 second, described in the documentation as a minimum wait rather than the actual reset time, so a client that treats that value as authoritative will hammer the same limit repeatedly. A related trap sits in the 404s: “Local sessions are not available” means the endpoints are temporarily unavailable to your whole organization and can clear on its own, while “Local session not found” means one specific session is gone or unreadable. Both share the not_found_error type, similar to how Claude’s auto permission policy also collapses distinct outcomes under one field, so code that branches on type instead of message text will treat a transient outage as a permanently missing session.

Should you rely on the Compliance API as your only session record?

No, not if any part of your organization touches the categories it excludes. The Compliance API’s own documentation offers the honest comparison: OpenTelemetry logging is push rather than pull, captures host and device metadata the Compliance API never returns, and is the only option for Claude Code sessions run through a Console API key or a third-party cloud platform. A team that needs a defensible record for eDiscovery or DLP across an organization with any HIPAA-ready or ZDR-enabled users, any non-Enterprise Claude Code usage, or any Claude Code cloud sessions cannot get that record from the Compliance API alone, whatever the word “compliance” in its name implies. The API is still the right default for what it does cover: it needs no collector, works with a key most Enterprise organizations already hold, and the transcript format is stable enough to build a real export pipeline around. Pair it with OpenTelemetry logging for the sessions it structurally cannot see, rather than assuming Chrome coverage closed every gap.

What does the documentation still leave unanswered?

Two things are not stated anywhere in the Compliance API docs. The size of the remote session endpoints’ second rate limit budget is never given a number, only that it exists and that its 429 caps retry-after at one second regardless of how much of the budget is actually left, so a client cannot budget against it the way it can budget against the disclosed 600-per-minute shared limit using the anthropic-ratelimit-requests-remaining header. And the documentation does not say through which endpoint, if any, a Claude Code cloud session becomes visible, only that it is excluded from both session endpoint families by definition. Anthropic’s own comparison table names Claude Code cloud sessions as a case the remote endpoints do not cover, without naming what does. Until that is answered publicly, treat any Claude Code cloud usage in a Claude Enterprise organization as unaudited by this API, and confirm the gap directly with Anthropic before representing coverage to a customer or a regulator.