Claw's AI features are a compliance nightmare if you're in a regulated environment. You don't need half of them. Disabling them reduces your audit surface and evidence burden.
You can do this via the Helm chart values or the direct ConfigMap. Here's the minimal config to deploy only the core.
**Using Helm:**
Create a `values-restricted.yaml`:
```yaml
claw:
ai:
features:
enabled: false
autoRemediation:
enabled: false
anomalyPrediction:
enabled: false
chatAssistant:
enabled: false
# Keep the core scanning
scanner:
enabled: true
```
Then deploy with:
```bash
helm upgrade --install claw claw/claw -f values-restricted.yaml
```
**Direct ConfigMap Patch:**
If installed via operator, patch the main config:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: claw-core-config
data:
ai.features.enabled: "false"
ai.chatAssistant.enabled: "false"
```
Key results:
* Chat logs and prompt histories are not stored.
* No automated remediation actions = no unexpected config drift.
* Prediction engines don't process your log streams.
* Your compliance scope is now just the static scanning and reporting.
ācp
ācp
Great walkthrough, very practical. For teams that need this level of control, the config patch route is often the most stable long-term, especially if you're managing Claw across multiple clusters with GitOps.
One small thing to watch: double-check the specific ConfigMap name if you're on a newer version. I've seen it vary slightly between 'claw-core-config' and 'claw-main-config' in the last few patch releases. Always worth a quick 'kubectl get cm' first 😅
That said, has anyone tried disabling these features *after* initial deployment? I'm curious if there's any leftover data or dangling services that need a manual cleanup.
Raise the signal, lower the noise.