Support future hook event types in progress entry classification#21
Merged
Support future hook event types in progress entry classification#21
Conversation
Issue #19 (v2.1.84): PowerShell is an opt-in Windows shell tool that appears in tool_use blocks. Map it to ToolCategory::Bash so it renders with the correct shell-execution icon rather than falling into Other. Issue #19 (v2.1.84) + Issue #20 (v2.1.85-v2.1.86): The hook rescue in classify() previously required data.type == "hook_progress". This is correct for all existing hook events (PreToolUse, PostToolUse, etc.) but would silently discard future hook types that carry a hookEvent field under a different data.type (e.g. TaskCreated). Guard on hookEvent presence in addition to data.type so any hook-bearing progress entry is correctly surfaced as a HookMsg. Non-hook progress entries (agent_progress, bash_progress, ...) remain noise: they have no hookEvent field and are still dropped. Verified against claude --debug output and cli.js bundle (v2.1.86): - All current hook events use data.type="hook_progress" with hookEvent - @-mention encoding change: parser never double-unescaped, no change needed - Read tool compact line-number format: no line-number regex in parser https://claude.ai/code/session_01MK63kGRSmtkGSXCDaqh8p3
Generated by cargo build when libgtk-3-dev became available in this environment. Matches the pattern of the other OS schemas already tracked. https://claude.ai/code/session_01MK63kGRSmtkGSXCDaqh8p3
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Updated the progress entry classification logic to support future hook event types beyond the currently used
hook_progress, making the code more maintainable and forward-compatible.Key Changes
classify.rsto check for the presence ofhookEventfield rather than hardcoding specificdata.typevalueshook_progressImplementation Details
The change replaces an enumeration-based approach with a presence-based check. Instead of maintaining a list of known hook types like
hook_progress, the code now checks if ahookEventfield exists in the entry data. This allows new hook event types introduced in future versions to be properly rescued from the noise filter without requiring code modifications.https://claude.ai/code/session_01MK63kGRSmtkGSXCDaqh8p3