fix: report blocked PostToolBatch findings to Cloud

[Mr-Lucky]

Summary

Report blocked Claude Code PostToolBatch findings to Cloud using bounded, sanitized summaries and aggregate counts.

Raw tool results, sensitive values, and absolute paths remain local. Documentation and regression coverage are updated accordingly.

Type

• Bug fix
• New feature / detection rule
• Refactoring
• Documentation

Testing

• npm run build passes
• npm test passes (32 tests)
• Manually tested the change

Targeted verification: node --test dist/tests/runtime-cloud.test.js passes all 93 tests.

The complete test suite was interrupted after environment-dependent CLI, network, and daemon tests failed or hung under sandbox restrictions.

Related Issues

Closes #

[github-actions]

AgentGuard PR Review

1. severity: high — src/runtime/audit.ts (buildAuditEvent / isClaudePostToolBatchEvent)

   • What can go wrong: The new special-case routes every Claude Code PostToolBatch event to upload nativeHookAuditInput(event) even when the event is malformed or not actually a blocked finding. For these events, shouldReportAuditEventToCloud() now reports based only on hasMaterialAuditFinding(event), but buildAuditEvent() still emits input from the native-hook formatter. If that formatter is not designed for PostToolBatch, it can serialize unexpected fields or leak raw batch content into Cloud payloads instead of the intended bounded summary.
   • Fix suggestion: Add a dedicated postToolBatchAuditInput()/postToolBatchSummary() path that explicitly whitelists the batch fields to upload, and gate it on the same material-finding conditions as reporting. Avoid reusing generic native-hook formatting for a new event class.

2. severity: medium — src/runtime/audit.ts (shouldReportAuditEventToCloud)

   • What can go wrong: PostToolBatch reporting is now unconditional on hasMaterialAuditFinding(event) without checking whether the event is explicitly blocked/continuation-stopping. Any future Claude Code batch event with a material finding but no actual block could be uploaded, broadening Cloud egress beyond the documented “blocked” case.
   • Fix suggestion: Include an explicit check for decision === 'block' and metadata.continuationBlockedOnly === true (or the equivalent authoritative block indicator) before reporting PostToolBatch events.

3. severity: medium — src/tests/runtime-cloud.test.ts new test

   • What can go wrong: The test stubs fetch with return jsonResponse(..., 202), but does not verify that the client treats 202 as success in all call paths. If AgentGuardCloudClient.ingestEvents() only accepts 200/201, this test will fail at runtime or mask a regression depending on implementation details not covered here.
   • Fix suggestion: Confirm the client’s success-status handling includes 202, or adjust the test/mocking to match the actual accepted status codes and assert the client’s response handling explicitly.