Not Started: Worker init can fail on mode path resolution and appear as DB timeout

[silentbalanceyh]

Before submitting

• I searched existing issues and confirmed this is not a duplicate

---

⚡ Quick Bug Report (Recommended)

Use the automated bug report generator for comprehensive diagnostics:

# Navigate to the plugin directory
cd ~/.claude/plugins/marketplaces/thedotmack

# Run the bug report tool
npm run bug-report

Plugin Paths:

• macOS/Linux: ~/.claude/plugins/marketplaces/thedotmack
• Windows: %USERPROFILE%\.claude\plugins\marketplaces\thedotmack

Features:

• 🌎 Auto-translates any language to English
• 📊 Collects all diagnostics automatically
• 🤖 AI-formatted professional issue
• 🔒 Privacy-safe (paths sanitized, --no-logs option)
• 🌐 Auto-opens GitHub with pre-filled issue

---

📝 Manual Bug Report

Bug Description

claude-mem failed to initialize and got stuck in a half-started state. Health checks responded, but the worker never became usable. The surface symptom looked like a DB startup problem, but tracing the startup sequence suggested the earlier failure was mode file path resolution.

Steps to Reproduce

1. Install/use claude-mem@thedotmack on Claude Code 2.1.81 on macOS.
2. Let the worker start through normal hook/session flow.
3. Observe that the worker responds to health checks but remains uninitialized.
4. Observe repeated timeouts/errors in logs and hooks.

Expected Behavior

The worker should fully initialize, load the code mode, initialize the database, connect the MCP server, and report healthy state with both initialized: true and mcpReady: true.

Environment

• Claude-mem version: failing install was 10.6.1; after local rebuild/sync, 10.6.2 worked
• Claude Code version: 2.1.81
• OS: macOS
• Platform: Claude Code

Logs

Worker logs are located at:

• Path: ~/.claude-mem/logs/worker-YYYY-MM-DD.log
• Example: ~/.claude-mem/logs/worker-2025-12-14.log

Please paste relevant log entries (last 50 lines or error messages):

Background initialization failed Critical: code.json mode file missing
DB not initialized
Database initialization timeout
Worker failed to start (health check timeout)

Additional observed health output while failing:

{
  "status": "ok",
  "initialized": false,
  "mcpReady": false
}

Additional Context

What I found from tracing startup:

• Worker initialization order appears to be:
  1. ModeManager.loadMode(modeId)
  2. dbManager.initialize()
  3. mark initialization complete
  4. connect MCP server
• The key failure log was Critical: code.json mode file missing
• But plugin/modes/code.json was actually present
• This suggests runtime package root / mode path resolution was wrong rather than the file actually being absent
• The startup path seems fragile around:
  • src/shared/paths.ts → getDirname() / getPackageRoot()
  • src/services/domain/ModeManager.ts → loading modes/code.json
• In the failing built artifact, there were signs of embedded absolute build-machine paths, which may make runtime mode lookup brittle

What I ruled out:

• Resetting SQLite DB + WAL + SHM did not fix it
• Removing Chroma data did not fix it
• tmux settings were unrelated
• SessionEnd hook errors were downstream symptoms, not root cause

Why it started working again:

• I rebuilt from local source and synced the plugin again
• After that, the worker started successfully and reported:

{
  "version": "10.6.2",
  "initialized": true,
  "mcpReady": true
}

So the issue is no longer reproducing for me after rebuilding/syncing, but the underlying path-resolution logic still seems worth hardening.

[github-actions]

The GitHub issue describes a bug in the claude-mem plugin where the worker initialization fails due to a mode file path resolution problem, which is misdiagnosed as a database timeout. While the worker responds to health checks, it remains uninitialized, preventing functionality. Logs indicate a critical missing code.json mode file error, although the file is present, suggesting fragile runtime path resolution stemming from build-time artifact paths or logic in src/shared/paths.ts. The user attempted various fixes, such as resetting the SQLite database and removing Chroma data, but resolved the issue by rebuilding the plugin locally and syncing it, upgrading successfully to version 10.6.2. The user recommends hardening the path-resolution logic and startup sequence to prevent future occurrences, as the underlying fragility persists despite the immediate resolution.