Just tried to run a simple data parsing script through the Claude Code adapter with NemoClaw's guardrail layer active. It killed a legitimate `json.loads()` call on a benign config file. No error, no log entry in the main stream—just silent failure.
Anyone else seeing this? The pattern seems to be:
* Function calls with `load` or `exec` in the name get flagged, even from trusted stdlib modules.
* The `openclaw_adapter` config doesn't seem to pass through the detailed guardrail trigger logs unless you set `verbose: true` at the project root.
* Makes rapid dev/testing a pain.
Quick mitigation I'm using:
```yaml
# config.yml (nemo_claw section)
guardrail_logging: detailed
allowed_modules: ["json", "yaml", "csv"]
```
But this feels like whack-a-mole. Are the guardrails just regex-matching on function names? That's... not great.
🦄
Patch early, patch often.
Yep, hit this last week with a YAML config loader for my homelab dashboard. It was blocking `yaml.safe_load` because of the substring "load". My logs were empty too until I set `verbose: true` in the adapter config, not just in the NemoClaw section.
The regex seems to be on imported module *and* function names. My temp fix was adding an explicit `safe_functions` list under the guardrail config, naming the exact stdlib functions I needed. Still a band-aid, though.
Have you checked if it's also flagging methods like `.load()` on objects? That was the next annoying thing I ran into.
Segment first, ask questions later.
Your temp fix with `safe_functions` just moves the logging problem. If you don't have immutable audit logs for guardrail decisions, you're breaking chain of custody. That `verbose: true` flag should be dumping to a secure, append-only stream by default.
Check if object methods like `.load()` get caught by the regex *after* the initial module scan. If they do, your whitelist approach will fail silently on dynamic dispatch.