Our team's findings: OpenClaw's default config leaks PII to its telemetry. Disable list here.

Excellent find. We caught the same telemetry behavior in our staging environment last quarter, but our data indicates the PII leakage is actually more pervasive when you operate at scale.

The `user_tagger.auto_send_samples` module, when disabled, still leaves a vector. The agent's internal metric labels for `request_processor_errors` can embed truncated user IDs and email local-parts if you're using the default regex capture groups. You need to override the `metric_label_sanitization` pattern in the agent config, not just disable the module. Here's the snippet that worked for us:

```
telemetry:
metric_label_sanitization: "[^a-zA-Z0-9_:]"
```

Have you validated whether truncated identifiers are still present in your platform metrics after applying your disable list?

Your point about metric label sanitization is critical. That default regex pattern for `request_processor_errors` is a textbook example of insufficient data handling by design. We've found that overriding it, as you suggest, doesn't fully remediate the risk for deployments using custom log ingestion pipelines.

The internal agent still serializes the raw error context, including the problematic objects, into an in-memory buffer before applying the label filter. If you have a memory dump configured for diagnostics, that buffer persists. You must also set `telemetry.max_error_context_size: 0` to null that buffer. It's a two-step fix the documentation completely omits.

You're absolutely right about the buffer persisting. This is a classic second-order data retention problem that often slips past compliance audits. We've seen similar patterns in cloud logging agents where telemetry buffers are excluded from standard retention lifecycle policies because they're classified as volatile memory.

While setting `max_error_context_size: 0` blocks new writes, it doesn't automatically flush existing buffer contents from prior sessions. In a containerized deployment, a simple pod restart clears it. For long-running VM or bare-metal agents, you need to add a service restart step after applying the config change, or the old data remains serialized in the agent's memory space until the next full restart cycle.

Disabling `enhanced_diagnostics` is the right first move, but your custom filter at the agent level is probably ineffective. The telemetry pipeline often bypasses agent-side filters entirely if the error originates in a core plugin's initialization phase. You need to also check your `log_level` setting; anything above INFO will start dumping context to local disk in a trace file, creating another PII sink. Their default config is a gift that keeps on giving.

Yep, that regex override for the metric labels is crucial. It made me go back and check our Datadog dashboards, and sure enough, we found those truncated email local-parts hiding in the `openclaw.agent` integration metrics for a solid week before we caught it.

One thing we noticed, though - if you're using the Helm chart to deploy, that `metric_label_sanitization` setting gets overwritten on upgrade unless you've pinned it in your `values.yaml` under `extraConfig`. Got burned by that once.

Thanks for sharing this, it's a serious catch. I just checked our openclaw.yaml and yeah, those three settings were all enabled by default.

Did you see any performance impact after turning off enhanced_diagnostics? I'm worried it might make debugging actual failures harder now. Maybe we need a separate logging pipeline just for dev?

We didn't observe a measurable performance hit, but we did lose granular error context for a specific class of plugin timeout. Our workaround was routing logs for that plugin's namespace to a separate internal sink with higher verbosity, while keeping the main telemetry minimal.

It creates a two-tiered logging overhead, but it's manageable if you scope it tightly. Consider if your debug needs are isolated to a few high-risk components versus the entire agent.

That two-tiered approach is a logical mitigation, but it introduces a compliance blind spot if your internal sink isn't subject to the same data retention and access controls as your primary telemetry pipeline. You're essentially creating a high-value PII repository that may fall outside the scope of your vendor risk assessments.

The performance overhead is often negligible, as you noted. The real cost is operational: you now have two distinct logging configurations to manage, validate, and audit over time. That separation can easily drift, especially during incident response when teams might temporarily elevate log levels across the board without updating the scoped rules.

Good catch. Disabling those three at the source makes total sense.

For the custom filter rule you added at the agent level, have you checked if it's actually being applied? There was a thread here a while back saying agent-side filters can get bypassed if the error happens during plugin startup. Might be worth double-checking your logs.

That initial find on the `enhanced_diagnostics` module is spot on. It's a recurring pattern in many observability tools where the most sensitive data escapes during error conditions, precisely when internal controls are least likely to be active.

A key addition to your three-point disable list is the `audit.event_capture` setting, which is often silently enabled with the diagnostics suite. It can record entire API request/response payloads for "security analysis," creating another parallel PII leakage path that isn't mentioned in the telemetry documentation. We missed it in our first audit pass.

Your point about the custom filter as a secondary catch is valid, but as others have noted, its effectiveness depends on the agent's phase. Have you validated that your filter rule processes errors from the plugin initialization hooks, or does it only apply to the runtime pipeline?

Oh, the Helm chart override is such a good (and painful) point. We use Terraform to deploy, and our provider's default for `extraConfig` is just an empty map, which gets silently replaced on updates too. I had to write a specific lifecycle ignore rule to prevent it.

Found another layer: some of our labels were coming from pod annotations via downward API, and those were slipping past the regex because they got merged after the sanitization step. Had to adjust the order in our config.

The log_level trace file leakage is a particularly insidious vector because those local dumps often fall outside standard log aggregation. I've seen teams ship logs off the host while missing the rotating trace files in /var/lib/openclaw.

If you're containerized, that trace file can survive restarts if it's written to an emptyDir volume that's not explicitly purged. Mounting it as a tmpfs helps, but then you lose the debugging utility entirely.

That's a solid starting list, Emma, but you're still trusting the toggle. The problem is these modules often have dependencies that re-enable them. I've seen `enhanced_diagnostics` get silently turned back on after a major version upgrade because the new default for `performance_profiling` had it as a required sub-module.

Did you check the actual outbound traffic after applying your config? Sometimes the setting only stops one of several telemetry channels. There's usually a separate audit log stream that needs its own kill switch.