Tool coverage audit and additions

[djdarcy]

Summary

Audit all Claude Code tools and ensure complete coverage in the session logger.

Current Coverage

From TOOL_CATEGORIES in log-command.py:

Category	Tools	Status
bash	Bash	✅
system	LS, Glob, Grep, Read	✅
io	Write, Edit, MultiEdit, NotebookEdit	✅
todo	TodoWrite	✅
task	TaskCreate, TaskUpdate, TaskList, TaskGet	✅
meta	Task	✅
search	WebSearch, WebFetch	✅
ui	AskUserQuestion	✅
skill	Skill	✅
mcp	mcp__*	✅ Auto-detected

Tools to Add/Verify

Tool	Category	Content to log
EnterPlanMode	system	(marker only)
ExitPlanMode	system	(marker only)
ToolSearch	system	query
TaskOutput	task	task_id
TaskStop	task	task_id

Tasks

• Add missing tools to TOOL_CATEGORIES
• Add content extraction in get_command_content() for new tools
• Verify WebSearch/WebFetch are actually triggering hooks
• Test with a session that uses plan mode tools
• Document any Claude Code tool list changes

Analysis

See 2026-02-01__19-10-22__session-logger-enhancements-analysis.md for detailed analysis.

[djdarcy]

Architecture Notes for #1 Integration

When implementing tool coverage (#8), we need to design with the configurable logging system (#1) in mind:

Configuration File Design

• Need a config schema that allows per-tool or per-category enable/disable
• Consider YAML or JSON for user-editable config
• Default config should enable everything, user overrides specific channels

Code Modularization Goals

• Extract tool-specific logic into a registry pattern
• Each tool handler should be self-contained (name, category, content extractor)
• Avoid hardcoded if/elif chains that grow unbounded

Future-Proofing for Claude Code Changes

• Tool detection should gracefully handle unknown tools (log tool name + raw input)
• Consider auto-discovery of new tools rather than explicit enumeration
• MCP tools already use prefix pattern (mcp__*) - extend this approach

Proposed Architecture

# Tool registry pattern
TOOL_REGISTRY = {
    "Grep": {
        "category": "search",
        "extractor": lambda input: f'{input.get("pattern")} | "{input.get("glob", "")}"'.rstrip(' | ""'),
        "default_enabled": True
    },
    "Write": {
        "category": "io",
        "extractor": lambda input: format_write(input),
        "default_enabled": True
    },
    # ...
}

# Unknown tool fallback
def get_tool_handler(tool_name):
    if tool_name in TOOL_REGISTRY:
        return TOOL_REGISTRY[tool_name]
    if tool_name.startswith("mcp__"):
        return MCP_DEFAULT_HANDLER
    return UNKNOWN_TOOL_HANDLER  # Logs tool name + first param

This allows:

• Easy addition of new tools (just add to registry)
• Per-tool configuration in Feature: User-configurable logging channels and file routing #1
• Graceful handling of new/unknown tools
• Reduced code duplication

Recommendation: Implement #8 as a refactor toward this architecture, not just adding more elif branches.

[djdarcy]

Progress Update - v0.1.4

✅ Tools Added

Added to TOOL_CATEGORIES:

• EnterPlanMode → system
• ExitPlanMode → system
• TaskOutput → task
• TaskStop → task

⚠️ Notes

• ToolSearch not found in actual Claude Code usage - may not exist or use different name
• WebSearch/WebFetch were already in categories, verified working
• All tools now have content extraction in get_command_content()

Remaining

• Test with a session that actually uses plan mode tools to verify logging
• Confirm full tool list against Claude Code documentation if available

[djdarcy]

Research: Claude Code Task System Evolution (2026)

Two Task Systems Exist

System	Tools	Status	Storage
Legacy (Todos)	TodoWrite	Still available	Memory-only (ephemeral)
New (Tasks)	TaskCreate, TaskUpdate, TaskList, TaskGet, TaskOutput, TaskStop	Default since v2.1.16	~/.claude/tasks/{sessionId}/*.json

New Task System Details (v2.1.16+)

Key Features:

• Dependency tracking (addBlockedBy, addBlocks)
• Task status workflow: pending → in_progress → completed (or deleted)
• Owner assignment for multi-agent coordination
• Background task management via TaskOutput/TaskStop
• Session-scoped (not persistent across sessions)

Environment Variables:

• CLAUDE_CODE_ENABLE_TASKS=false - Revert to old TodoWrite system
• CLAUDE_CODE_DISABLE_BACKGROUND_TASKS - Disable background task functionality

Tools We're Currently Tracking

✅ All task tools are in TOOL_CATEGORIES:

"TodoWrite": "todo",
"TaskCreate": "task",
"TaskUpdate": "task",
"TaskList": "task",
"TaskGet": "task",
"TaskOutput": "task",
"TaskStop": "task",

Task Log Format (.tasks_*.log)

Current format extracts rich information:

{CREATE: "Subject" #123 }
{UPDATE: #123 status=completed }
{UPDATE: #123 owner=Plan blockedBy=[1,2] }
{LIST }
{GET: #123 }

Future Plugin Integration

The .tasks_*.log file is designed for consumption by a task management sync plugin that will:

1. Parse task operations in real-time
2. Create/update tasks in external tools (Todoist, Linear, GitHub Issues, etc.)
3. Support bidirectional sync

Configuration Considerations (for Issue #12)

Add to session-logger.json schema:

{
  "task_logging": {
    "enabled": true,
    "include_legacy_todos": true,
    "log_file": "tasks",
    "sync_integration": {
      "enabled": false,
      "provider": null
    }
  }
}

Sources

• Claude Code Tasks Are Here - Medium
• Claude Code Todos to Tasks - Medium
• Claude Code Changelog
• Claude Code System Prompts - Piebald-AI