Bug: ctx_search returns no results due to overly strict project filtering

[AlexDoratu]

Bug Report: ctx_search returns no results due to overly strict project filtering

Environment

• context-mode version: 1.0.162
• Platform: Windows 11 Pro 10.0.26200
• Claude Code version: Latest
• Node.js version: (via Claude Code)

Description

ctx_search returns "No results found" for all queries, even when the database contains matching content and direct SQLite queries return results successfully.

Root Cause

The bug is in src/search/ctx-search-schema.ts line 133:

export function resolveProjectScope(
  raw: string | undefined,
  isSharedMode: boolean,
  getProjectDirFn: () => string,
): string | null | undefined {
  if (!isSharedMode) return undefined;
  if (raw === undefined) return getProjectDirFn(); // ← BUG HERE
  if (raw === "global") return null;
  return raw;
}

When project parameter is not provided, the function returns the current project directory, which enables sessionIdAllowSet filtering in searchWithFallback(). This filter is overly strict and excludes all valid results.

Steps to Reproduce

1. Index content using ctx_index:

ctx_index({
  content: "Test content with keywords: mempalace, Docker, context-mode",
  source: "test-document"
})

2. Verify content is in database:

-- Direct SQLite query works
SELECT content FROM chunks WHERE chunks MATCH 'mempalace' LIMIT 3;
-- Returns results successfully

3. Search using ctx_search:

ctx_search({
  queries: ["mempalace"],
  limit: 3
})
// Returns: "No results found"

Expected Behavior

ctx_search should return matching results from the indexed content.

Actual Behavior

ctx_search returns "No results found" even though:

• Content exists in the database
• Direct SQLite FTS5 queries return results
• The chunks have valid session_id values

Workaround

Adding project: "global" parameter disables filtering and returns results:

ctx_search({
  queries: ["mempalace"],
  limit: 3,
  project: "global"  // ← Workaround
})
// Returns: [matching results]

Proposed Fix

Change line 133 in src/search/ctx-search-schema.ts from:

if (raw === undefined) return getProjectDirFn();

to:

if (raw === undefined) return null;

This makes the default behavior "no filtering" instead of "filter by current project", which aligns with user expectations and prevents the overly strict filtering issue.

Impact of Fix

• Shared mode OFF: No change (returns undefined in both cases)
• Shared mode ON, no param:
  • Before: Filters by current project (causes bug)
  • After: No filtering (returns all results)
• Explicit project: "global": No change (returns null in both cases)

Additional Context

The sessionIdAllowSet filtering logic in store.searchWithFallback() appears to be working correctly when given the right session IDs. The issue is specifically in the default project scope resolution, which incorrectly enables filtering when it should be disabled.

Verification

After applying the fix:

1. Rebuild the plugin: npm run build
2. Reload plugins: /reload-plugins
3. Test search without project parameter:

ctx_search({ queries: ["test"], limit: 3 })
// Should now return results

---

Files involved:

• src/search/ctx-search-schema.ts (source fix)
• server.bundle.mjs (needs rebuild)
• src/search/unified.ts (filtering logic - working correctly)
• src/store.ts (searchWithFallback - working correctly)

[Adriftnote]

Confirming the same bug on v1.0.162 (Windows 11) for ctx_fetch_and_index content — not just ctx_index.

A fetch→search research workflow silently degrades: ctx_fetch_and_index reports success (e.g. ok=6 ... 141 sections 117.6KB indexed), but default-scope ctx_search returns 0 results / only session-memory captures — even for terms present verbatim in the fetched page. project: "global" retrieves the fetched content correctly, and the source: filter also works correctly once global is set (so source is fine — project is the only variable).

Same root cause as your resolveProjectScope line-133 finding (if (raw === undefined) return getProjectDirFn()), and your proposed fix (return null) would resolve the fetch→search case too. The failure is silent (empty results, no error), so it's easy to misdiagnose as "fetch/index broken" when the content is actually there and reachable under global.

I filed #835 before spotting this issue — closing it as a duplicate in favor of yours.

[AlexDoratu]

Thanks @Adriftnote for the independent Windows repro and for folding #835 in here — the ctx_fetch_and_index angle and the silent-failure framing are useful additions, and the evidence below builds on both.

I instrumented this on Windows with direct SQLite inspection, and I believe the root cause is narrower (and more fixable) than "the default project filter is too strict." It's a path-separator mismatch that only manifests on Windows. Sharing the evidence because it changes the correct fix.

The filter path (from the v1.0.162 bundle)

searchWithFallback keeps a chunk only when:

sessionId === "" || allowSet.has(sessionId)

The allow-set is built in the search path from:

getSessionIdsForProject(projectScope)
// → SELECT DISTINCT session_id FROM session_events WHERE project_dir = ?

and on undefined project, projectScope resolves to getProjectDir(), which is:

getProjectDir(){ return process.env.CLAUDE_PROJECT_DIR || process.env.VSCODE_CWD || process.cwd() }

No path normalization.

The asymmetry (hex-verified, across 7 projects, zero exceptions)

Table	Written by	Slash style
session_events.project_dir	hooks, from input cwd (attribution_source=input_cwd)	forward D:/work project/... (hex 2F)
session_meta.project_dir	server's own getProjectDir() via ensureSession()	back D:\work project\... (hex 5C)

session_meta is effectively a runtime snapshot of what getProjectDir() returns on Windows — backslashes, in every project's shard. Meanwhile the allow-set is queried against session_events, which stores forward slashes.

Direct counts on my DB for one project:

• WHERE project_dir = 'D:\work project\githubfind' (backslash, what search uses) → 0 sessions
• WHERE project_dir = 'D:/work project/githubfind' (forward, what's stored) → 13 sessions

So the allow-set comes back empty, every indexed chunk has a non-empty session_id, and the predicate filters all of them out → "No results". project: "global" "works" only because it bypasses the allow-set entirely (projectScope becomes null).

Why it's Windows-only

On macOS/Linux both cwd and the hook cwd are forward-slash, so the comparison matches and the bug never appears — consistent with every report here (incl. #835) being on Windows 11.

Implication for the fix

The proposed resolveProjectScope → return null makes the symptom disappear, but it does so by disabling project filtering for everyone, including platforms that have no bug. The targeted fix is to normalize the separator on both sides before comparison — e.g. canonicalize getProjectDir() output (and ideally the stored project_dir on the write path, so session_events and session_meta agree) to a single convention. That fixes the Windows mismatch while keeping project isolation intact cross-platform.

Happy to open a PR for the normalization approach if that direction works for you.