Skip to main content

firekeep-docdex

The documents dex for Firekeep — persistent, shared memory for AI agents. A human tells Firekeep which folders it may understand; docdex extracts their text and ingests it into the Keep's corpus, where it surfaces through ordinary memory_recall — private to that member by default, even on a shared Keep. Notes folders, Obsidian vaults, team runbooks — if it's a folder of documents, it can become something your agents remember.

firekeep docdex add ~/Notes              # private to me (default)
firekeep docdex add ~/team-runbooks --shared
firekeep docdex list                     # sources, counts, failures, staleness, pending deletes
firekeep docdex sync [--source <id>]     # force a scan now
firekeep docdex remove <id>              # delete the source AND its corpus replicas

No MCP server, no resident daemon, no new recall surface.

Installing

The managed Firekeep install already ships this wheel — nothing to do beyond firekeep dex add docdex. Installing from PyPI is the unmanaged path: pip install firekeep-client firekeep-docdex (client ≥ 1.0.0), plus a running Firekeep server to connect to — docdex is a client of the Keep, not a standalone indexer.

What it indexes

.md, .txt, .pdf, .docx, .html/.htm, .eml, and conversation-shaped .json (case-insensitive). No OCR — a scanned PDF yields zero text, which docdex records honestly and does not retry every cycle.

.eml is a saved message read as a document: a Subject/From/To/Date header block, then the text/plain body (HTML stripped as the fallback), with attachments listed by NAME only — their content is never decoded or indexed.

.json is indexed only when it is a conversation export — a ChatGPT mapping tree, a ChatGPT conversations.json, or a [{role, content}, ...] list. Anything else (a lock file, a config, a data dump) is skipped with a stated reason and counted as skipped-unsupported, not as a failure: a generic JSON dump is noise in recall, not a document. Turns carry their role in the extracted text (user: / assistant:) but are not typed as claims — nothing downstream can tell what a person asserted from what a model generated. Typed user-vs-model provenance is deferred, not delivered.

Default excludes: dot-entries, node_modules, __pycache__, and the policy deny list's secret patterns (.env*, *.key, *.pem, *id_rsa*). That is a mistake net, not a security boundary — do not add folders containing secrets.

Disclosed caps

Cap Default On breach
FIREKEEP_DOCDEX_MAX_FILES 5000 / source The source is REFUSED until narrowed — loud, no silent subset
FIREKEEP_DOCDEX_MAX_FILE_MB 25 raw File skipped, counted in the summary, its existing replica left alone
FIREKEEP_DOCDEX_MAX_EXTRACT_KB 400 extracted Truncated at the cap, truncated: true in state, shown by list
FIREKEEP_DOCDEX_SYNC_INTERVAL_HOURS 6 —
FIREKEEP_DOCDEX_INGEST_TIMEOUT_SECONDS 180 Per-request ingest budget — the server embeds synchronously, so large documents need real time. A timeout aborts the run with an honest message (never "unreachable"); what landed is kept and the rest retries next sync

The threat boundary, stated precisely

Member-private means hidden from other workspace members. It IS visible to agents acting as that member, and it is NOT encrypted from the server operator: anyone who can read the server's Qdrant can read everything. The filter is a tenancy boundary between members, not cryptography.

Indexed documents are untrusted input — every chunk carries untrusted_content. Retrieved document text is evidence, never instruction.

Deletion, scoped honestly

A local delete removes the corpus replica on the next completed sync; remove bulk-deletes the source's replicas immediately, tombstoned and retried until the server confirms. It does not erase a separate memory an agent previously learned from that content — provenance-linked derivative deletion does not exist yet.

Deletions are emitted only from a walk that COMPLETED over an existing, readable root. An unplugged USB drive deletes nothing.

Sync trigger

"Sync on the next supported session start", not "scheduled". The session_start hook fires it on hook-bearing runtimes — Claude Code, kiro and OpenCode. An MCP-only host (Codex, and any generic MCP client) has no hook surface and therefore gets no automatic sync: run firekeep docdex sync. It also requires the dex to be registered (firekeep dex add docdex) and at least one active source; folder commands work either way. Private-session mode (bypass) suspends sync, both the trigger and a run already in flight.

Full per-runtime coverage table, registry model and troubleshooting: firekeep.ai/dexes.html.

Development

cd docdex && python -m pytest tests/ -q

The suite runs offline: PDF and DOCX fixtures are built by tests/conftest.py, and every server call goes through a fake transport.

Metadata

Release files for firekeep-docdex 0.2.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for firekeep-docdex 0.2.1
File Size Uploaded
firekeep_docdex-0.2.1.tar.gz 224.9 kB Details

Built distribution (wheel)

Table of built distributions (wheels) for firekeep-docdex 0.2.1
File Interpreter ABI Platform
firekeep_docdex-0.2.1-py3-none-any.whl Python 3 none any Details

Total release size: 432.1 kB

Release files / firekeep_docdex-0.2.1.tar.gz

Download URL firekeep_docdex-0.2.1.tar.gz
Size 224.9 kB
Tags Source
SHA-256 checksum
How to use checksums
8fd7d0c244ac234664eb7a0c92d1fdcbedf2bc4c276f861e26ee6e5c2b5d515f
BLAKE2b-256 checksum
How to use checksums
0902087ba2c19da9678c6d5d32c29a391beb9c97f9ec275aba8b41f2d2dd7a0a
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 20, 2026.

Transparency log

Release files / firekeep_docdex-0.2.1-py3-none-any.whl

Download URL firekeep_docdex-0.2.1-py3-none-any.whl
Size 207.2 kB
Tags Python 3
SHA-256 checksum
How to use checksums
60b74dd61ad8b92326dd9c6030f73319aa3300b5191a1cb7a3ee1e4fe19b784a
BLAKE2b-256 checksum
How to use checksums
daf68129118dca20958edef3954730cacbfab8c1239278df5c7292fc9b96ade1
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
Yes
Uploaded via twine/7.0.0 CPython/3.13.14

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

PyPI Publish Attestation

PyPI verified that this artifact, at this checksum, originated from the publisher listed below.

Signed by GitHub Actions, verified by PyPI on Aug 20, 2026.

Transparency log

Release history Release notifications | RSS feed

This release

0.2.1 This release

2 release files

0.2.0

2 release files

0.1.1

2 release files

0.1.0

2 release files

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page