Hey all, been running NanoClaw in a staging environment for a few weeks now and the logging is... intense. I'm pulling down gigs of logs daily, and a lot of it seems like internal debug chatter that shouldn't be flying around in production.
Why not just set the default to `WARNING` or even `ERROR`? The `INFO` level seems to capture every single tool call, intermediate step, and API handshake. For example, I'm seeing full prompt/response cycles for simple RAG queries and the complete JSON payloads for every external API call the agent makes. That's a huge PII and key exposure risk if these logs get shipped to a central system, right?
I get that verbose logs are great for debugging during development, but for a hardened deployment, this feels like the opposite of secure by default. Am I missing a config flag somewhere, or is everyone just accepting this and writing custom log filters?
My current workaround is a custom logging config in Python that overrides the third-party libraries, but that's fragile and feels like I'm fighting the framework:
- Override loggers for `langchain`, `openai`, `httpx`
- Set them all to `WARNING`
- Add a filter to scrub certain key patterns from any remaining `INFO` entries
Isn't this something that should be baked into the `production` profile of the Helm chart or the Docker image? Curious how others are handling it.
You're not wrong about the default being verbose. The INFO level is intentional for triage - when an agent acts weird in production, you often need that full context to see *why*.
Your workaround is what we all do. The main config flag is `OC_AGENT_LOG_LEVEL`, but it doesn't propagate to all the underlying libs. Your custom Python config isn't fragile, it's necessary. I'd add a regex filter for your API keys and any known PII patterns right there.
Bigger issue: if logs with raw API payloads are hitting your central system unchecked, your log ingestion pipeline needs sanitization too. That's a policy-as-code rule waiting to be written.
--Priya
I agree the logs are useful for triage, but exposing that data by default violates the principle of least privilege for information. It forces every deployer to also become a log filtering expert.
The `OC_AGENT_LOG_LEVEL` issue you mentioned is a real pain point. Even if you set it, you often need to also set `LOGURU_LEVEL` or patch the logging config for libraries like `httpx`. It's not a single env var, it's a cascading config problem.
Your point about policy-as-code for the ingestion pipeline is correct, but that's a second line of defense. The container itself shouldn't be emitting the sensitive data in the first place. We treat the app as untrusted and use runtime sandboxing (gVisor, seccomp) for actions; we should apply the same logic to its observability outputs. Logging at `INFO` should mean "informative about the process," not "here are all the secrets."
r