[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":"","args":""}`, 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 with `otlpContentCapture`.
>
> On first-party (claude.ai) deployments, user prompt content, model response text and tool arguments **are included by default**, and `otlpContentCapture` is 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.

Start with the Cowork monitoring page and compare it with the linked support article, Claude Desktop telemetry page, and Claude Code monitoring-usage page. Verify the documented defaults, event types, attributes, enums, and version requirements against the issue’s observations, then update the affected documentation so deployment scope and redaction guidance are explicit and the pages agree.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.