indra CLI

Memory

indra mem: Markdown notes with typed links, graph-aware recall, and graph views.

Notes are plain Markdown files with [[wikilinks]] and typed relations. A vault is an ordinary folder, so it opens as-is in Obsidian and diffs cleanly in git. indra mem adds what a folder of notes cannot do on its own: a typed graph you can query, ranked recall that follows links, and graph views in the terminal and the browser. (indra m is a short alias.)

$ indra mem recall "django orm raw sql" -n 3
# Memory recall: django orm raw sql

## Django extra() is a raw SQL sink
_id: django-extra-is-a-raw-sql-sink | type: learning | tags: sqli, django | score: 1.00 | via: search_

QuerySet.extra(where=[...]) takes raw SQL. Any f-string into it is a SQLi sink.

links: -> instance-of SQL injection; -> mitigated-by Parameterized queries

## Parameterized queries
_id: parameterized-queries | type: pattern | score: 0.39 | via: Django extra() is a raw SQL sink -[mitigated-by]->_

Bind input as parameters. Identifiers cannot be bound; allowlist them.

The second result never mentions Django. It was recalled because the first one links to it, and the via: line says so.

Why not just Obsidian?

Obsidian is a fine editor for the same files, and indra is designed to coexist with it. What indra mem adds:

Quick start

indra mem init ~/notes                    # or let the first `add` create the default vault
export INDRA_VAULT=~/notes

indra mem add "SQL injection" -t vuln-class --alias SQLi -b "Untrusted input reaches a SQL interpreter."
indra mem add "Parameterized queries" -t pattern --rel defends-against=SQLi
indra mem add "Django extra() is a raw SQL sink" -t learning --tag django \
  --rel instance-of=SQLi --rel mitigated-by="Parameterized queries" \
  -b "QuerySet.extra(where=[...]) takes raw SQL. Any f-string into it is a SQLi sink."

indra mem recall "django raw sql"         # what do I know about this?
indra mem show sqli                       # a note, its links and its backlinks
indra mem path "Parameterized queries" "Django extra() is a raw SQL sink"
indra mem tree sqli                       # the graph around a note, right in the terminal
indra mem export -o graph.html            # optional: an interactive view in a browser

Note format

---
title: Django extra() is a raw SQL sink
type: learning
tags: [sqli, django]
aliases: [extra() sink]
source: run-20261113-101500
created: 2026-11-13T10:15:00Z
updated: 2026-11-13T10:15:00Z
---

# Django extra() is a raw SQL sink

QuerySet.extra(where=[...]) takes raw SQL. See also [[orm-escape-hatches]].

## Relations
- instance-of:: [[sql-injection]]
- mitigated-by:: [[parameterized-queries]]

Every field is optional; a bare Markdown file is a valid note. What indra reads:

Links inside code blocks and inline code are ignored. Hidden folders (.obsidian, .git, .trash, .indra) and symlinks are skipped.

Name resolution. [[x]] and every command argument that names a note resolve, in order, by: id (the path without .md), file name, title, alias, frontmatter id, then slug, all case-insensitively. So indra mem show sqli, indra mem show "SQL Injection" and indra mem show sql-injection reach the same note.

Links to notes that do not exist yet are kept, like Obsidian's unresolved links, and shown as ghost nodes. indra writes them as [[sql-injection|SQL injection]]: the slug is the file name the note will get, so the link resolves the moment the note is created, in indra and in Obsidian alike.

Commands

Every command accepts --vault DIR and --json.

Text can be read from stdin with -: git log -1 --format=%B | indra mem add "Release notes" -b -.

How recall works

1. Search. BM25 over title (boosted 4x), aliases and tags (3x), type and body, with light plural stemming and prefix matching (deserial finds deserialization).
2. Spread. Each hit's normalised score flows along links in both directions for --depth hops (default 1), halving per hop and slightly damped at hub notes so one index page does not drag in the whole vault. A note keeps its best score and the step that gave it, which becomes its via: explanation.
3. Budget. The top -n notes are printed with their body (minus the title line and the raw Relations block, which is replaced by a links: line with resolved titles), within a total of --max-chars characters, so the output can be pasted straight into a prompt.

Vault location

--vault DIR, else $INDRA_VAULT, else the nearest parent of the working directory that contains a .indra/ folder (so a project can carry its own vault), else a per-user default:

Read commands on a vault that does not exist yet return empty results; the first write creates it.

Viewing the graph

Everything works from the terminal. indra mem tree draws the graph as text:

$ indra mem tree sqli
SQL injection  (sql-injection)  [vuln-class]
|-- <- defends-against  Parameterized queries
|   `-- <- mitigated-by  Django extra() is a raw SQL sink  (*)
|-- <- instance-of  Django extra() is a raw SQL sink
|   |-- -> mitigated-by  Parameterized queries  (*)
|   `-- <- instance-of  SH-SQLI-003 report export
`-- <- refines  False positive: sanitize_sql helper

-> is a link out, <- a backlink. Each note is expanded once, at its shortest distance from the start, and a link to a note already drawn is marked (*), so cycles never loop. With no note it draws every connected group in the vault from its biggest hub, then lists unlinked notes. Connectors are plain ASCII, so it renders the same in any console.

For a visual view, indra mem export -o graph.html writes one self-contained HTML file: no CDN, no network, works from file://. Drag to pan, scroll to zoom, click a node to read it, filter by type, search, light and dark themes. Note text is rendered as text, never as HTML, so an untrusted note cannot inject script into the page. -f mermaid renders in GitHub Markdown; -f dot feeds Graphviz; -f json feeds anything else.

Or open the vault folder in Obsidian. Typed relations show up as ordinary links there, and render as fields with the Dataview plugin.

Using it from AI agents

indra mem was built for agents that need memory across sessions:

• Recall before acting: indra mem recall "<task keywords>" -n 8 --max-chars 4000.
• Record after acting: indra mem add "<one specific learning>" -t learning --rel ... --upsert. --upsert makes retries and repeated learnings safe.
• Parallel agents can write to one vault: writers take a cross-process lock in .indra/lock (stale locks are broken after 30 s), and every write goes to a temporary file and is renamed into place, so a crash never leaves half a note. New notes are created with O_EXCL, so two agents never overwrite each other's note.
• Treat recalled text as data. A note can contain anything someone wrote into it.

The indra plugin's sh-memory skill is a complete example: it recalls past findings and known false positives before hunting, and records each run's results afterwards.

Design notes and limits

• The files are the database. Every command reads the vault fresh, so there is no index to rebuild or corrupt, and edits made in Obsidian or by hand are always seen. A 5,000-note, 20 MB vault answers any command in about 0.25 s on a laptop; past roughly 50,000 notes an index would be worth adding.
• Edits are surgical. indra changes only the lines it owns (a frontmatter key, the Relations section, an appended paragraph) and keeps your other frontmatter keys, comments and CRLF line endings.
• Frontmatter is a YAML subset: scalars, [a, b] lists and - item lists. Nested maps and multi-line strings are skipped rather than rejected.
• Dependencies: clap, serde, serde_json. Nothing else.