[DOCS] Cowork monitoring docs state events are "metadata only" by default; first-party orgs receive full prompts, responses and tool arguments
Documentation Type
Incorrect/outdated documentation
Documentation Location
https://claude.com/docs/cowork/monitoring Contradicting page: https://support.claude.com/en/articles/14477985-monitor-claude-cowork-activity-with-opentelemetry Also affected: https://claude.com/docs/third-party/claude-desktop/telemetry#content-capture https://code.claude.com/docs/en/monitoring-usage
Section/Topic
Cowork OpenTelemetry monitoring: content capture defaults, the standard event list, and standard attribute availability.
Current Documentation
From https://claude.com/docs/cowork/monitoring:
"By default, events include metadata only. User prompt content, model response text, and tool details are included only when you enable them with the otlpContentCapture setting."
From the support article, on the same subject:
"User prompt content is included in events by default."
and
organisations with policies against logging prompts should "configure filtering or redaction in your collector before routing events downstream."
The same reference page documents six event types (user_prompt, assistant_response, tool_result, api_request, api_error, tool_decision) and lists session.id, organization.id, user.account_uuid, user.account_id, user.email, user.id, workspace.host_paths and terminal.type as standard attributes present on events.
What's Wrong or Missing?
1. The stated default is wrong, and the two official pages contradict each other.
On a first-party Claude for Teams plan, with only the three admin fields set (OTLP endpoint, protocol, headers) and no other configuration anywhere, we received full content:
prompt— complete user prompt text. Records of 5,636 and 8,910 characters within one hour.response— complete model response text, largest observed 25,995 characters.tool_input— full tool arguments: absolute file paths, file contents, shell commands, search query strings.
The support article is correct; the reference page is not. An administrator reading the reference page will enable the integration believing no content is exported. In our case that put commercially sensitive material into a Grafana stack whose access list had never been scoped for it.
Environment: Claude for Teams (first-party), desktop 1.34493.1 (255293), telemetry scope com.anthropic.claude_code.events 2.1.237 (desktop) / 2.1.241 (cloud).
2. The documented remedy is unreachable for the audience being told to use it.
The page links otlpContentCapture as the control, but the target is /docs/third-party/claude-desktop/telemetry, and that key is read only from MDM or managed-configuration profiles on third-party deployments (Bedrock, Vertex, Foundry, gateway). A first-party organisation has no path to it. The page does not say so.
3. Claude Code's OTEL_LOG_* flags do not reach Cowork, and nothing says so.
Cowork emits under scope com.anthropic.claude_code.events and CLAUDE_CODE_ENABLE_TELEMETRY=1 is present in the Cowork session environment, so it reads as though the Claude Code content toggles apply. We delivered all five org-wide via Admin settings > Claude Code > Managed settings, restarted fully, and started a new session (b0ada465-402d-5286-b622-e32146bf4772, 2026-08-25T13:33:18Z). The prompt attribute still contained the complete prompt text.
4. Nine emitted event types are undocumented, including the three highest-volume streams.
Observed in one six-hour window: hook_execution_start (112), hook_execution_complete (112), mcp_server_connection (101), hook_registered (14), plugin_loaded (12), retention_sweep (10), at_mention (4), permission_mode_changed (4), skill_activated (1). Also seen elsewhere: api_refusal, compaction, subagent_completed.
This matters for ingest cost forecasting and for retention or cardinality policy written from the documented list.
skill_activated deserves specific mention: it carries skill_name, skill_source, plugin_name and invocation_trigger with no content, and is the only clean way to measure skill usage. Without knowing it exists, the skill name is only reachable inside tool_input as {"skill":"<name>","args":"<free text>"}, so an organisation redacting content to protect prompts loses all skill visibility. Same for MCP: every MCP call reports tool_name="mcp_tool" with the real name only inside tool_parameters.
5. Documented enum values are incomplete.
invocation_trigger also emits claude-proactive, which was the largest bucket in one sample (17 of 37). skill_source also emits bundled.
6. skill_name uses different taxonomies on different events.
skill_activated emits anthropic-skills:morning, productivity:memory-management, custom_skill. api_request emits morning, morning-apheris, third-party. The two cannot be joined, so skill activation counts and skill spend do not reconcile. Nothing warns of this.
7. Standard attributes are absent on cloud sessions.
Sessions with cowork_surface="remote" carry none of user_account_uuid, user_account_id, user_email, organization_id or process_owner. Not empty strings; absent. process.owner is separately documented as "standard OpenTelemetry process metadata and is present on all deployments", which is not the case. cowork_surface itself is undocumented and is the only reliable way to distinguish the surfaces.
The underlying bug is tracked in #88490. This entry is about the documentation not reflecting it.
8. Minimum version numbers disagree between pages.
The reference doc says desktop 1.1.4173 or later. The support article says 1.22209.3+ for cloud sessions and 1.1.4173+ for local. Neither states clearly which applies to which surface, and the two version schemes are not obviously comparable.
Suggested Improvement
Replace the default-behaviour paragraph. Suggested text:
On third-party deployments, events include metadata only by default. Prompt text, model response text and tool details are included only when an administrator enables them withotlpContentCapture. On first-party (claude.ai) deployments, user prompt content, model response text and tool arguments are included by default, andotlpContentCaptureis not available. If your organisation has a policy against logging prompt content, configure filtering or redaction in your collector before routing events downstream. See [link to a redaction example].
Add a short "Applies to" note wherever otlpContentCapture is referenced, stating that it is MDM-delivered and third-party only.
Add an explicit statement on both the Cowork monitoring page and https://code.claude.com/docs/en/monitoring-usage that OTEL_LOG_USER_PROMPTS, OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_TOOL_DETAILS, OTEL_LOG_TOOL_CONTENT and OTEL_LOG_RAW_API_BODIES govern Claude Code sessions and have no effect on Cowork sessions.
Complete the event table with the nine missing types, marking which are high volume. Give skill_activated and plugin_loaded their own attribute tables, since they are the metadata-only path to skill and plugin usage.
Complete the enum lists for invocation_trigger and skill_source, and note that skill_name is not comparable across skill_activated and api_request.
Qualify the standard attributes table by surface. A column marking which attributes are present on cowork_surface="remote" versus desktop would prevent anyone building per-user reporting on attributes that will be absent for most of their volume. Document cowork_surface.
Reconcile the version requirements into one table: surface, minimum version, scheme.
A worked redaction example would help a lot. We ended up writing an OpenTelemetry Collector config that deletes prompt, response and tool_input while first extracting skill_name and the MCP tool name out of them, because a naive delete costs you all skill and MCP visibility. Happy to contribute it if useful.
Impact
High - Prevents users from using a feature
Additional Context
We are a Claude for Teams customer in the EU. We enabled Cowork OTel on 24 August 2026 and discovered the content export the following day while building a usage dashboard. We have since deployed our own OpenTelemetry Collector to strip prompt, response and tool_input before anything reaches Grafana Cloud. That works, but it required standing up internet-facing infrastructure purely to undo a default the documentation says does not exist.
Related issues:
- #88490 — cloud Cowork sessions export without identity attributes (the bug behind point 7)
- #89483 — appears to be a duplicate of #88490
Separate from the documentation: there is currently no first-party control for content capture at all. If it would be useful, we can raise that as a feature request under the appropriate template rather than in this issue.
Two smaller things found while debugging, mentioned in case they belong elsewhere: OTLP export failures are entirely silent in the UI (a malformed header produced 401 no credentials provided at the gateway with no symptom in Cowork beyond missing data), and the OTLP headers admin field accepts a value containing a newline without validation, which is what produced that 401.