Summary

Mint one hook event id per ai-guardrails hook and send it on both requests the hook makes, so a Cycode violation can be resolved back to the exact hook event that produced it.

Changes

• AIHookPayload.hook_event_id — a UUID minted per payload via default_factory. One payload is one hook event, so no per-IDE parser has to change.
• build_ai_guardrails_scan_parameters — sends it in the guardrail scan metadata, alongside conversation_id / generation_id.
• AISecurityManagerClient.create_event — sends it as the event's id, the same way create_conversation already sends the conversation id.
• Tests for the payload (uuid, unique per event, explicit value honoured) and the client (the reported id is the payload's, and two hooks of one prompt report distinct ids).

Why

A guardrail hook makes two independent requests: the scan (which becomes a violation) and the hook event report. Neither can learn an id the other was assigned, and the event is reported in the handler's finally — after the scan has already gone out. Minting the id here is what lets both name the same event without either waiting on the other.

generation_id cannot stand in for it. The IDE mints one per prompt, so every hook of that prompt shares it, and some IDEs supply none at all — codex reads turn_id, cursor reads generation_id, claude-code digs it out of the transcript and may come back with None.

Both consumers already tolerate its absence, so this can ship independently:

• ai-security-manager treats the event id as optional and mints one itself when it is missing, and accepts a redelivery of an id it already stored (this hook path retries on network failure).
• secret-detector omits the hook_event_id detection detail entirely when it is not sent.

Testing

pytest tests/cyclient/test_ai_security_manager_client.py tests/cli/commands/ai_guardrails/ — 302 passed.

🤖 Generated with Claude Code