Small change to the Compliance API, large effect for anyone who has to show who did what with Claude: since Thursday the local session endpoints also return transcripts from Claude in Chrome. Beta, Claude Enterprise organizations only.
Three endpoints, one key
The sessions run on users’ machines, but you query them centrally:
GET /v1/compliance/apps/sessions/local
GET /v1/compliance/apps/sessions/local/{session_id}
GET /v1/compliance/apps/sessions/local/{session_id}/messagesYou need a Compliance Access Key carrying the read:compliance_user_data scope. Admin API keys won’t do it. There is no separate budget either — local sessions ride the normal Compliance API rate limit.
The new bit is the claude_in_chrome value in product_surface. It marks sessions from the Chrome extension’s built-in chat. Alongside it sit cowork, claude_code, claude_science and the office_agents/* surfaces for Word, Excel, PowerPoint and Outlook. Cowork and Claude Code are stable; everything else is still beta.
What’s in a transcript, and what isn’t
In: prompts, replies, tool calls with their results, and file contents insofar as they passed through a tool call as text. Tool blocks arrive with id, name and input as a JSON string.
Out: thinking blocks and the system prompt, which is swapped for a placeholder. Images and PDFs are gone, as is anything else binary, plus tool definitions, MCP configuration and citation metadata. Retention runs six years unless your organization set its own period.
Book ZDR and you won’t show up
Two exceptions matter more in practice than the rest: sessions with Zero Data Retention are excluded, and organizations with HIPAA readiness turned on never capture local sessions at all.
So if you’re planning a gapless audit trail and you’ve bought ZDR, you’re planning two things that cancel each other out. That’s not a bug — it’s the decision that sits at the start of setups like these, and one that deserves another look now that the browser is in scope.