File Studio

Give your AI agent a fast, private way to find the right file — without scanning your disk or burning tokens.

Your files are everywhere: source repositories, old projects, notes, exports, PDFs, spreadsheets, network drives, and years of archived work.

You know the answer is somewhere on your machine. Your AI coding agent does not.

Without a searchable index, Claude Code, Codex, or Gemini CLI must repeatedly list folders, open files, and scan content to understand what you have. That is slow, token-heavy, and impractical across large folders or multiple drives.

Traditional file search may find a filename, but it often cannot search deeply across code, documents, and structured data. Cloud-based search may work — but only after uploading content you would rather keep private.

File Studio solves that problem once.

It builds a private, local index of the folders and drives you choose. Search it directly inside VS Code, or let your existing AI agent query it with one command and retrieve only the most relevant files and snippets.

No server. No separate AI service. No uploaded files. No telemetry.

Search once. Stop making your agent rediscover everything.

File Studio turns your local files into an AI-ready search layer:

• Find files by name, path, type, size, or date.
• Search inside code, text, Markdown, JSON, XML, CSV, and TSV.
• Optionally search inside PDF, Word, PowerPoint, Excel, Outlook, and HTML files (after a one-time document-extraction setup — see below).
• Give Claude Code, Codex, or Gemini CLI ranked, line-numbered results instead of making them open files one by one.
• Compare two folders and copy only what's missing or changed — the source folder stays read-only.
• Index large folders and drives once, then re-index only what changed.
• Keep the entire index on your machine and under your control.

Use File Studio as a standalone file-and-content search tool — like Everything, but it searches inside your files — an AI-agent retrieval layer, or both.

The difference

Without File Studio

Your agent explores the filesystem over and over:

1. List folders.
2. Guess which files matter.
3. Open and read them.
4. Spend tokens on irrelevant content.
5. Repeat it all on the next task.

With File Studio

Your agent runs one local query and gets ranked results with file paths, matching snippets, and line numbers — faster answers, less context noise, and far fewer tokens spent on brute-force file discovery.

Bring Your Own Model. Connect Your Own Data.

File Studio is built around two principles from Lynx DI.

BYOM — Bring Your Own Model. Use the AI agent you already trust: Claude Code, Codex, or Gemini CLI. Your model account, credentials, and conversations stay with your chosen provider — File Studio does not host a model, proxy your prompts, or require a separate AI service. When your provider ships a smarter model, your workflow improves without touching your local data layer.

CYOD — Connect Your Own Data. Choose the folders, drives, and data sources you want searchable. File Studio indexes them directly on your machine; file names, metadata, and extracted content stay local — nothing is uploaded. Your source files are treated as read-only and are never moved, modified, or deleted.

Built for AI agents — useful without one

After each index build, File Studio generates AGENTS.md, CLAUDE.md, and GEMINI.md (byte-identical) at your workspace root, plus ready-to-run search tools under .index/bin/:

python .index/bin/search.py "<query>"         # ranked, deduped, line-numbered snippets
python .index/bin/query.py  "<read-only SQL>"  # metadata questions over the index

Supported coding agents auto-load the map and use these instead of scanning the filesystem — faster answers, far fewer tokens. You can also ignore the AI integration entirely and use File Studio as a fast local search interface inside VS Code.

Why use File Studio

• Search beyond the current repository. Index multiple projects, archives, folders, or entire drives.
• Reduce AI token waste. Retrieve relevant snippets before your agent reads full files.
• Keep private data private. Indexing and search happen locally, without a server.
• Choose speed or depth. Build a lightweight metadata index first, then add full-content search where it matters.
• Search mixed file types. Find information across code, notes, tabular data, PDFs, and Office documents.
• Compare & sync folders safely. Diff two folders and copy only what's missing or newer — source read-only, nothing deleted.
• Scale beyond editor search. Parallel, incremental indexing for very large directory trees.
• Stay in control. File Studio stays dormant until you explicitly configure roots or start an index build.

Get started

1. Install the extension and open the File Studio activity-bar view.
2. Run Configure Roots to Index and choose the folders or drives you want searchable. (This is the moment the .index folder is created — not before.)
3. Click Build Index — leave Index content off for the fastest name/path index, or turn it on to full-text index file contents.
4. Search from the panel, or run Quick Search the Index from the Command Palette.
5. (Optional) Run Set Up Document Extraction (MarkItDown) to also index PDF/Office/HTML content, then rebuild.

By default the index lives in a .index folder inside the opened workspace. To keep it elsewhere (off a workspace, or on a faster drive), point diskIndex.databasePath at an empty folder before building.

Requirements & dependencies

You only need Python to full-text index documents (PDF/Office/HTML) or try the Tantivy engine. File/path indexing and content indexing of code and text need nothing beyond the extension.

Base Python (one time). MarkItDown/Tantivy run inside a virtual environment the extension creates, which needs a base Python 3.10+ with venv:

• Windows / macOS: install from python.org/downloads; on Windows tick "Add python.exe to PATH."
• Linux: ensure venv is present (Debian/Ubuntu: sudo apt install python3-venv).

The extension auto-discovers py, python3, and python on your PATH; if yours lives elsewhere, set diskIndex.pythonPath. Everything installs into .index/py-env — nothing system-wide, and deleting .index removes it cleanly.

The two indexes: metadata vs content

File Studio keeps file metadata and file content in separate databases so they coexist:

• File metadata (index.db) — names, paths, size, dates, type, extension. Fast to build (no reading file bodies); ideal for "where is that file?" across millions of files.
• Full content (content.db) — everything above plus extracted, full-text-searchable file contents.

The Search index section in the sidebar shows both, marks which is active (the one search and browse use), and lets you switch with a click. Building content never overwrites your metadata index, and vice versa.

What gets indexed

File Studio always indexes file names, paths, size, dates, type, and extension. When content indexing is on:

• Code, text, Markdown, JSON, XML, CSV, TSV are read and indexed directly — no Python required.
• PDF, DOCX, PPTX, XLSX, XLS, Outlook .msg, HTML are extracted with MarkItDown (needs the Python environment above). Without it, they're indexed by name and metadata only.

Search engines

File Studio's search layer is pluggable, and every option runs locally, in-process (no server):

• SQLite + FTS5 (default, built in) — BM25-ranked full-text search. Powers the in-app Search panel and the .index/bin/search.py agent tool. Nothing to install.
• Tantivy (optional) — a Rust/Lucene-style index built from your content DB via Build Tantivy Index, exposed to agents through .index/bin/search_tantivy.py (same ranked JSON) for A/B benchmarking. The Search tab has an Engine dropdown to compare FTS5 vs Tantivy side by side (Tantivy runs a process per query, so it's Enter-to-search).
• Semantic / vector (experimental) — a search-provider seam plus a --mode hybrid flag designed for embedding-based retrieval (sqlite-vec + a local embedding model). No embedding model ships yet, so hybrid currently falls back to lexical.

Commands

Settings

Privacy & storage

File Studio stores a rebuildable local index (index.db and/or content.db), a small config.json, a lynx-index.log, and — if you set up extraction — a py-env virtual environment, all under .index (or your diskIndex.databasePath).

• Nothing is created until you adopt a folder for indexing (Configure Roots / Build / Index a Folder).
• Extracted text and snippets are stored only in the local database, so search is instant.
• No indexed content is uploaded and nothing is sent to a model. The MarkItDown and Tantivy setup commands download Python packages from PyPI; indexing and search themselves are fully local.
• The extension reads your files but never moves, modifies, or deletes them. (Folder Copy writes only to a destination you explicitly choose and confirm; the source is never changed, and nothing is deleted.)

Troubleshooting

• Documents don't match on content. Run Set Up Document Extraction (MarkItDown) and confirm a base Python 3.10+ with venv is on your PATH (or set diskIndex.pythonPath). Until then, documents index by metadata only.
• "Build Tantivy Index" fails. It needs the same Python 3.10+ base as MarkItDown. Check the Output panel for the pip install tantivy log.
• Search feels incomplete after adding files. Run Build Index again to pick up new or changed files.
• Searching the wrong thing. Check the Search index section in the sidebar — you may be on the metadata index when you want content (or vice versa). Use Switch Search Index.
• Indexing is slow in cloud-synced or network folders. Add slow subtrees to diskIndex.excludeDirs.
• Need to inspect the index files. Run Reveal Index Database Location or check diskIndex.databasePath.

More from Lynx DI

File Studio is built by Lynx DI. Explore more at lynxdi.com.

License

Proprietary — Copyright © 2026 Lynx DI. All rights reserved. See the LICENSE file. Bundled third-party open-source components remain under their own licenses; see the NOTICE file.