Cognee Search

Cognee Memory Search

Search both session memory and the permanent knowledge graph, optionally filtered by data category.

Automatic session search

Session memory is searched automatically on every user prompt via the UserPromptSubmit hook. You do not need to run this skill to access current-session context.

Data categories

Knowledge is organized into three categories via node_set:

Instructions

Search goes through the running Cognee server (POST /api/v1/recall) — the source of truth. Use the wrapper below: it queries the server first, scoped to the plugin's dataset ($COGNEE_PLUGIN_DATASET, default agent_sessions — the same dataset all plugin writes target, so unrelated datasets don't bleed in), and falls back to cognee-cli only if the server is unreachable.

One broad search is usually enough — the UserPromptSubmit hook already injects session/trace/graph context every turn, so avoid running many targeted searches (each is an extra permission prompt for the user).

Search (server-first)

# session cache + permanent graph (default)
${CLAUDE_PLUGIN_ROOT}/scripts/cognee-search.sh "$ARGUMENTS"

# permanent graph only
${CLAUDE_PLUGIN_ROOT}/scripts/cognee-search.sh "$ARGUMENTS" 10 --graph

# current session only
${CLAUDE_PLUGIN_ROOT}/scripts/cognee-search.sh "$ARGUMENTS" 10 --session

# deterministic code graph (indexed repos only — see the cognee-code skill)
${CLAUDE_PLUGIN_ROOT}/scripts/cognee-search.sh "MyClass" 10 --code

Structural code questions belong to --code, not here. "What calls X", "what breaks if I change X", "list all endpoints" are answered exactly and token-free by the code graph — see the cognee-code skill for the operations and for indexing a repository. Use this skill's semantic search for conceptual questions that name no symbol ("how does auth work here?").

Filter by category (optional)

Categories (user_context / project_docs / agent_actions) filter by node set. cognee-cli recall does not expose this — pass node_name to the server directly:

curl -s -X POST "${COGNEE_BASE_URL:-http://localhost:8011}/api/v1/recall" \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: ${COGNEE_API_KEY:-}" \
  -d '{"query": "...", "top_k": 5, "only_context": true, "scope": ["graph"], "node_name": ["project_docs"], "datasets": ["'"${COGNEE_PLUGIN_DATASET:-agent_sessions}"'"]}'

Ground-truth a suspicious result (debugging)

The server is authoritative. If a search returns empty but you expect content, confirm directly — do not conclude "not found" from empty CLI output:

curl -s -X POST "${COGNEE_BASE_URL:-http://localhost:8011}/api/v1/recall" \
  -H "Content-Type: application/json" \
  -H "X-Api-Key: ${COGNEE_API_KEY:-}" \
  -d '{"query": "...", "top_k": 5, "only_context": true, "scope": ["graph"], "datasets": ["'"${COGNEE_PLUGIN_DATASET:-agent_sessions}"'"]}'

(An authed/cloud server needs COGNEE_API_KEY; a local single-user server ignores an empty key. If the response is an {"error": ...} object rather than a list, the server was reachable but rejected/failed the request — that's an error, not "no results".)

Fallback only — server unreachable

cognee-cli is a thin client over the same server and can print empty stdout even when content exists. Use it only when the server is down, and treat empty output as inconclusive, never as "no results":

cognee-cli recall "$ARGUMENTS" -k 5 -f json

Understanding results

Results include a _source field:

• "session" — from the session cache (current conversation)
• "graph" — from the permanent knowledge graph
• "code" — deterministic facts from an indexed repository's code graph

Session entries tagged with [category:agent] are automatic tool call logs.

Decision table