Skip to content
Second Brain Chronicles
Go back

Obsidian's CLI Cut My Tool Calls by 60%

Obsidian's CLI Cut My Tool Calls by 60%

47 tool calls in fifteen minutes. That was a normal Tuesday morning — read a daily note, search for a project file, append a log entry, check tasks, search again. Each vault interaction cost two to three tool calls, and a typical session hit twenty-plus interactions before lunch. By the time I got to the actual work I’d sat down to do, the session already felt sluggish — like explaining something to someone who keeps losing their place.

Every one of those tool calls eats context window — the finite resource that determines whether Claude can hold the full picture of what I’m doing or starts forgetting the beginning of our conversation. Burn half of it on filesystem navigation and you get an assistant that can find your files but can’t remember why you wanted them. I was paying for a thinking partner and getting a file browser.

Then Obsidian 1.12 shipped with a CLI.

The Old Way

Before the CLI, reading a vault file meant a minimum of two steps, often three:

# Step 1: Find the file (Glob or Grep — you rarely know the exact path)
# Step 2: Read the file contents
# Step 3: If appending, read first to know current state, then Edit/Write

Appending a section to today’s daily note — the single most common vault operation — required reading the file first just to avoid overwriting it. Three tool calls for what should be one operation.

What I expected: The CLI would be a convenience wrapper. Slightly fewer keystrokes.

What actually happened: It changed the relationship from “Claude searches a filesystem” to “Claude queries an index.”

The Index Changes Everything

The CLI doesn’t scan the filesystem. It talks to the running Obsidian app, which already has every file, every link, every tag indexed in memory. When I ask for a file by wikilink name, it resolves it instantly through that index — no glob pattern, no directory traversal, no guessing at paths.

# One command. No search step. No read-before-write.
obsidian read file="20260228" vault=Cerebro
obsidian append file="20260228" content="\n## New Section" vault=Cerebro

The command surface is broader than I expected — reads, writes, search, tasks, tags, templates, and one that stopped me cold: eval.

Full CLI command reference

Reading & Writing: read, append, prepend, write Search: search (file paths), search:context (with matching lines) Tasks: tasks todo, tasks done, task toggle, task done (by line number) Tags & Links: tags, tag, backlinks, unresolved Templates: templates, template:read, template:insert Vault Info: vault, wordcount Advanced: eval (execute JS in Obsidian context), dev:screenshot, dev:console

Most commands support format=json|tsv|csv|text|md|paths. Scope with path= or file= on large vaults — unscoped scans on 24K+ files are slow.

The Moment It Clicked

The Templates plugin had been pointing at a stale path for months. Some vault reorganisation had moved the templates folder, and the plugin was still looking in the old location. I’d never noticed because I don’t create templates that often. When I did try, the plugin would just show an empty list and I’d manually navigate.

Fixing it through the GUI: open Obsidian Settings, scroll to Core Plugins, find Templates, click the folder picker, navigate to the right path, save. Five clicks minimum, and I’d need to know the current path was wrong first.

Fixing it through eval:

obsidian eval code="
  app.vault.setConfig('corePlugins.templates.folder', '00 System/00 - Templates/')
" vault=Cerebro

config updated: corePlugins.templates.folder → "00 System/00 - Templates/"

One command. Repeatable if the path changes again. And more importantly: it runs JavaScript inside the Obsidian app context. That’s not a file operation — it’s direct access to the application state. I can query plugin configs, read the file index, check which files are open. The vault isn’t a folder anymore. It’s a queryable database.

When to Use What

Not everything moved to the CLI. Some operations are still better with the original tools:

OperationBest ToolWhy
Read a file by nameCLI readResolves wikilinks, no search needed
Append to daily noteCLI appendNo read-before-write
Search vault contentCLI searchUses Obsidian’s index
Check tasksCLI tasksFilters by path, completion status
Complex multi-line editEdit toolSurgical string replacement with context matching
Frontmatter changesEdit toolStructured YAML needs precise editing
Files outside vaultRead/WriteCLI only sees what Obsidian sees
Large vault-wide scansScoped CLIMust scope with path= — unscoped scans are slow on 24K+ files

The CLI handles the 80% case — read, search, append, check tasks. The original tools handle the precision work. The decision isn’t “which is better” but “which avoids unnecessary round trips.”

The Numbers

The 60% figure isn’t a benchmark. It’s a rough count from comparing tool call logs across sessions.

MetricBefore CLIAfter CLI
Read a daily note2-3 calls (search + read)1 call
Append a log entry3 calls (search + read + write)1 call
Search vault content1-2 calls (grep + read results)1 call
Check incomplete tasks2-3 calls (grep + filter + read)1 call
Typical morning session (20 interactions)~50 tool calls~22 tool calls

Those 28 saved tool calls aren’t just efficiency. Each one was consuming context window — the AI’s working memory. Fewer tool calls means more room for actual thinking about the problem at hand, instead of burning capacity on “where is the file and what does it currently say?”

I wrote a full command reference at ~/.claude/expertise/obsidian-cli.md and updated the global CLAUDE.md to prefer the CLI for vault operations. The rules are explicit: CLI for reads, searches, appends, task queries. Read/Edit/Write for complex edits, frontmatter, and files outside the vault. (I wrote a longer setup guide with configuration examples on jimchristian.net.)

The deeper thing isn’t the tool count reduction. It’s this: an AI assistant reading a vault file-by-file is like a librarian who has to walk the stacks for every query. An AI assistant querying through the application’s index is like a librarian with the catalogue system. Same library. Fundamentally different relationship with the knowledge inside it.

And the librarian who walks the stacks forgets what you asked for by the time they get back.


Share this post on:

Previous Post
My iPad Wiped 25,743 Files in Two Minutes
Next Post
One iPhone Screenshot, Eight Sites Broken