bug: basename(cwd) project detection causes data fragmentation in monorepos

[ACT900]

Summary

claude-mem uses basename(process.cwd()) to determine the project name for observations, sessions, and ChromaDB embeddings. In monorepo or multi-directory projects, this causes observations to be silently split across multiple project names, making them invisible to startup context injection and project-scoped queries.

Reproduction

1. Start Claude Code from /home/user/projects/my-app → project = my-app ✅
2. During the session, a hook fires while CWD is /home/user/projects/my-app/apps/web (e.g., after cd apps/web && pnpm tsc) → project = web ❌
3. Observations from step 2 are tagged as project web, not my-app
4. Next session started from /home/user/projects/my-app → startup context injection queries WHERE project = 'my-app' and misses all web observations

Impact on our system

We discovered 442 observations and 2,819 ChromaDB embeddings fragmented across wrong project names:

Project	Observations	Actual Source
my-app	12,233	✅ Correct
web	395	❌ Should be my-app (from apps/web/ subdirectory)
my-app-old	47	❌ Should be my-app (old directory name for same project)

These observations were completely invisible to:

• Startup context injection (session-start hook)
• Any search using project parameter
• The timeline view filtered by project

Root cause

In worker-service.cjs, the fp() function:

function fp(t) {
  if (!t || t.trim() === "") return "unknown-project";
  let e = path.basename(t);
  if (e === "") return "unknown-project";
  return e;
}

This is called during session-init with the CWD from hook input. There's a separate HC() function that does git rev-parse --show-toplevel, but it's not used for the project name stored on observations.

Suggested fixes (in order of preference)

1. Environment variable override (simplest, most flexible)

Add CLAUDE_MEM_PROJECT to settings.json. If set, always use it as the project name regardless of CWD.

{
  "CLAUDE_MEM_PROJECT": "my-app"
}

2. Git root detection for project name

Replace basename(cwd) with basename(git_root) when inside a git repository:

function fp(t) {
  if (!t || t.trim() === "") return "unknown-project";
  try {
    const gitRoot = execSync('git rev-parse --show-toplevel', { cwd: t, encoding: 'utf-8' }).trim();
    return path.basename(gitRoot);
  } catch {
    return path.basename(t) || "unknown-project";
  }
}

3. Sticky project name per session

Once a session is initialized with a project name, persist it for the entire session. Don't re-derive the project from CWD on subsequent hook calls.

Workaround

We manually merged the fragmented data:

-- SQLite
UPDATE observations SET project = 'my-app' WHERE project IN ('web', 'my-app-old');
UPDATE sdk_sessions SET project = 'my-app' WHERE project IN ('web', 'my-app-old');
UPDATE session_summaries SET project = 'my-app' WHERE project IN ('web', 'my-app-old');

-- ChromaDB (chroma.sqlite3)
UPDATE embedding_metadata SET string_value = 'my-app' 
WHERE key = 'project' AND string_value IN ('web', 'my-app-old');

This is not sustainable long-term as the split recurs whenever hooks fire from a subdirectory.

Environment

• claude-mem: v10.5.2 (hooks running from v10.4.0 due to fix: resolve hook crashes and CLAUDE_PLUGIN_ROOT fallback (#1215, #1220) #1229/fix(#1215): PR #1229 fallback path points to marketplace source, not installed cache — hooks still fail when CLAUDE_PLUGIN_ROOT unset #1242 fallback path issue)
• Claude Code: v2.1.51+ (Linux)
• OS: Ubuntu (Linux 6.17)
• Project structure: monorepo with apps/api/ and apps/web/ subdirectories

[github-actions]

This GitHub issue highlights a bug in claude-mem where it uses basename(process.cwd()) to detect project names, causing data fragmentation in monorepos or multi-directory projects. This issue occurs because observations, sessions, and embeddings are tagged with different project names when working in subdirectories, which leads to data being improperly categorized and becoming invisible to certain project-scoped queries and operations like startup context injection and search. The root cause is that project names are derived from the current working directory (CWD) rather than using a more consistent approach, such as determining the Git repository root. The problem has led to significant data fragmentation, as shown in the provided statistics, and necessitated manual data merging as a temporary workaround. Proposed fixes include adding an environment variable override for the project name, using Git root detection to derive the project name, or persisting the project name throughout a session to prevent inconsistency. The report emphasizes the unsustainability of manual workarounds and advocates for

[ACT900]

@greptileai Can you review this issue? Specifically:

1. Trace the fp() function in worker-service.ts that derives the project name from basename(cwd) — confirm it's used for all observation/session storage
2. Check whether HC() (the git root detection function) is ever used for project naming, or only for internal session tracking
3. Verify that context-generator.cjs uses WHERE project = ? for startup context injection — meaning misattributed observations are invisible
4. Assess which of the three suggested fixes (env override, git-root detection, sticky session name) would be least disruptive to implement

The core claim is that monorepo users lose observations silently when hooks fire from subdirectories, because basename(cwd) produces different project names for the same git repository.

[hatawong]

Hit a similar path-based fragmentation bug in my project. Two additional gotchas beyond basename(cwd):

1. macOS /tmp is a symlink to /private/tmp — if your hook receives the resolved path from Claude Code's JSON input but your scripts use $(pwd) (which returns the logical path), you get two different project IDs for the same project. Fix: always use pwd -P or fs.realpathSync() to normalize.

2. Claude Code resolves symlinks in CWD — the hook's JSON input contains the resolved path, but any script invoked by the LLM (not by the hook directly) gets the logical path from $(pwd). This means hooks and LLM-invoked scripts can disagree on the project identity.

Our solution was to encode the full resolved path as the project ID (e.g., -Users-hata-my-app with slashes replaced by dashes). Not pretty, but unambiguous — no basename collisions, no symlink confusion, and monorepo subdirectories map to their actual location.