Skip to content

/clear command causes transcript file issues breaking Stop hooks context extraction #3046

Closed as duplicate

Description

@teren-papercutlabs

Bug Description

When using the /clear command in Claude Code, the Stop hook fails to extract context from the conversation transcript, causing it to fall back to a generic message instead of generating contextual responses.

Steps to Reproduce

  1. Set up a Stop hook that reads transcript files to generate contextual responses
  2. Have a conversation with Claude Code
  3. Use the /clear command
  4. Continue the conversation
  5. When Claude completes a response, the Stop hook receives a transcript path that doesn't exist

Expected Behavior

After /clear, the Stop hook should still be able to access the current session's transcript with messages that come after the clear command.

Actual Behavior

The Stop hook receives a transcript path but the file doesn't exist in the filesystem, causing context extraction to fail.

Debug Information

# Hook receives this data:
{"session_id":"1e8899c0-9589-41ba-84a2-2429ea69bc0d","transcript_path":"/Users/teren/.claude/projects/-Users-teren-projects-orion/1e8899c0-9589-41ba-84a2-2429ea69bc0d.jsonl","hook_event_name":"Stop","stop_hook_active":false}

# But the file doesn't exist:
ls: /Users/teren/.claude/projects/-Users-teren-projects-orion/1e8899c0-9589-41ba-84a2-2429ea69bc0d.jsonl: No such file or directory

Environment

  • Claude Code version: 1.0.33 (latest)
  • OS: macOS 24.5.0 (Darwin)
  • Hook type: Stop hook

Additional Context

This appears related to issue #2538 where /clear doesn't fully reset context. In this case, it seems the transcript file is either:

  1. Deleted when /clear is used but the hook still receives the old path
  2. Never recreated after /clear for the continuing session
  3. Stored in a different location after /clear

Impact

This breaks any Stop hooks that rely on reading conversation context to provide intelligent responses, forcing them to use generic fallback messages.

Activity

  1. self-assigned this
    on Jul 7, 2025
  2. github-actions commented on Aug 14, 2025

    @github-actions

    This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

  3. locked as resolved and limited conversation to collaborators on Aug 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area:corebugSomething isn't workinghas reproHas detailed reproduction stepsplatform:macosIssue specifically occurs on macOS

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions