fix(doctor): emit tool-policy profile audit at debug level#87865
fix(doctor): emit tool-policy profile audit at debug level#87865Kailigithub wants to merge 1 commit into
Conversation
When tools.profile is set to a named profile (e.g. "coding"), the tool-policy
pipeline removes tools that don't belong to that profile. The resulting audit
lines ("tool policy removed N tool(s) via tools.profile (coding): ...") are
expected behavior, not actionable doctor findings.
These lines were emitted at info level, causing normal doctor output to look
noisy when a profile filter is active. Now they are emitted at debug level so
they appear in verbose/debug logs but not in regular doctor output.
The fix is isolated to auditToolPolicyFilter in tool-policy-audit.ts. Only
steps whose label starts with "tools.profile" are affected; other audit paths
(agents.allow, tools.deny, etc.) continue to log at info level.
|
Codex review: needs real behavior proof before merge. Reviewed May 28, 2026, 11:21 PM ET / 03:21 UTC. Summary PR surface: Source +2. Total +2 across 1 file. Reproducibility: yes. from source inspection: current main routes profile-filter tool removals through an info-level audit call, and the pipeline labels profile filtering as Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Keep the narrow log-level approach, add focused regression coverage for profile-filter debug audits, and require a redacted real Do we have a high-confidence way to reproduce the issue? Yes from source inspection: current main routes profile-filter tool removals through an info-level audit call, and the pipeline labels profile filtering as Is this the best way to solve the issue? No, not merge-ready yet: the runtime change is a narrow fit, but the PR does not update the focused test mock/expectations and does not include real doctor-output proof. The safer path is to keep the code change small while proving the debug path and normal doctor output. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: reasoning high; reviewed against 5a84869c061d. Label changesLabel justifications:
Evidence reviewedPR surface: Source +2. Total +2 across 1 file. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
|
@Kailigithub thanks for the PR. ClawSweeper is still waiting on real behavior proof before this can move forward. Useful proof can be a screenshot, short video, terminal output, copied live output, linked artifact, or redacted logs that show the changed behavior after the fix. Please redact private tokens, phone numbers, private endpoints, customer data, and anything else sensitive. Once proof is added to the PR body or a comment, ClawSweeper or a maintainer can re-check it. |
Summary
openclaw doctoremits repeated audit lines at info/console level for expected tool-profile filtering:These are expected and non-actionable — the tools are correctly removed by the profile filter. Emitting them at info level makes normal doctor output look noisy.
Root Cause
auditToolPolicyFilterintool-policy-audit.tsalways usesinfolevel regardless of step type. Profile-filter steps (whosestepLabelstarts withtools.profile) are routine housekeeping, not doctor findings.Fix
When
stepLabelstarts withtools.profile, emit the audit log atdebuglevel instead ofinfo. This preserves the diagnostic path for verbose/debug logging while cleaning up normal doctor output.All other audit paths (
agents.allow,tools.deny, sandbox policies, etc.) continue to log atinfolevel unchanged.Verification
auditToolPolicyFilterCloses #87798