Hook error blocking operations: Unable to connect to claude-mem service

[atulmahankal-leapswitch]

Hook error blocking operations: Unable to connect to claude-mem service

Problem Statement

Users are experiencing frequent UserPromptSubmit operation blocked by hook errors when Claude Code is working. The error indicates that the claude-mem plugin is unable to connect to its callback service, preventing it from saving observations and memory data. While this doesn't affect core Claude Code functionality, it disrupts the user experience with repeated error messages.

Environment

• Claude-mem: 9.0.4
• Claude Code: 2.0.74 (Claude Code)
• Node.js: v20.19.4
• Bun: 1.3.4
• OS: Linux 6.14.0-37-generic (x64)
• Platform: linux

Configuration Details

• Plugin Path: ~/.claude/plugins/marketplaces/thedotmack
• Data Directory: ~/.claude-mem
• Database: ~/.claude-mem/claude-mem.db (exists, 11948.00 KB)
• Worker Status: Running (PID: 214673, Port: 37777, Uptime: 8 minutes)
• Active Sessions: 0
• SSE Clients: 1

Key Settings

{
  "CLAUDE_MEM_MODEL": "claude-sonnet-4-5",
  "CLAUDE_MEM_WORKER_PORT": 37777,
  "CLAUDE_MEM_WORKER_HOST": "127.0.0.1",
  "CLAUDE_MEM_LOG_LEVEL": "INFO",
  "CLAUDE_MEM_CONTEXT_OBSERVATIONS": 50
}

Steps to Reproduce

1. Enable the claude-mem plugin in Claude Code
2. Use Claude Code for normal operations (any prompt submission)
3. Observe repeated hook errors during operation

Actual Behavior

The following error appears repeatedly during Claude Code operations:

UserPromptSubmit operation blocked by hook:
  Hook error: Error: Unable to connect. Is the computer able to access the url?
  Original prompt: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Investigation shows:

• The claude-mem plugin is enabled in settings: "claude-mem@thedotmack": true
• The plugin attempts to call a callback URL after each action to save observations/memory
• The callback service is unreachable despite the worker showing as "Running"
• Database exists and appears to have data (11.9 MB)

Expected Behavior

The claude-mem plugin should either:

1. Successfully connect to the callback service without errors, OR
2. Gracefully handle connection failures without blocking operations or showing repeated errors

Root Cause Identified

The worker service PID becomes stale/mismatched with the actual running process. The ~/.claude-mem/worker.pid file contains an old PID while a different worker process is running, causing connection failures.

For example:

• worker.pid shows PID 268641
• Actual running process is PID 267376
• This mismatch causes the hooks to fail to connect

Workaround

Restarting the worker service resolves the issue:

# 1. Kill the existing worker process
pkill -f "worker-service.cjs"

# 2. Restart the worker manually
cd ~/.claude/plugins/cache/thedotmack/claude-mem/9.0.4 && bun scripts/worker-service.cjs start

# 3. Verify it's working
curl -s http://127.0.0.1:37777/api/readiness
# Should return: {"status":"ready","mcpReady":true}

After restarting, hooks execute successfully without connection errors.

Suggested Fix

The plugin should:

1. Detect stale PID files and auto-recover
2. Verify the worker process is actually running before attempting connections
3. Implement a health check retry mechanism before failing hooks

Contact

• Email: atulmahankal@gmail.com
• GitHub: @atulmahankal

[github-actions]

The issue describes a problem where the claude-mem plugin fails to connect to its callback service, causing repeated UserPromptSubmit operation blocked by hook errors during operations in Claude Code. Although this does not disrupt the core functionality of Claude Code, it negatively impacts user experience by generating frequent error messages. The problem persists even though the plugin is enabled, the worker is running, and the required database exists. Likely causes include a misconfigured callback URL, network or firewall issues preventing localhost connections, worker initialization issues, or a race condition. The plugin is critical for saving observations and memory data, and users currently have to disable it or tolerate the errors as a workaround. Expected behavior would involve successful callback connections or graceful error handling without interruptions. Further investigation is necessary to confirm the root cause and resolve the issue.

[thedotmack]

This is a generic connectivity error that occurs when the worker service isn't running. This is covered by #729 (startup blocking) and #728 (auto-start failure). If you're still experiencing this on v9.1.1, please comment on those issues.