Obsidian Everywhere v0.9.2 — Reliable attachment discovery

Obsidian Everywhere v0.9.2 — Reliable attachment discovery

v0.9.2 makes attachment access more reliable for remote MCP agents, especially
when a vault lives on a removable drive or network mount.

Highlights

• search_files now combines case-insensitive filename and vault-relative path
  matching with extracted-text search.
• Ordinary filenames containing punctuation, such as final.pptx, no longer
  fail as invalid full-text-search expressions.
• Folder, extension, and file-type filters are applied before the search limit,
  so unrelated notes cannot crowd attachments out of scoped results.
• An exact read_file path can safely index one existing file that a filesystem
  watcher has not observed yet.
• Mount Guard now recreates the filesystem watcher after a mount returns, waits
  for its initial walk, and then performs transactional reconciliation.
• Temporary Microsoft Office owner files such as ~$deck.pptx are excluded
  from indexing and removed from existing indexes during reconciliation.

Safety

Exact-path recovery rejects traversal, excluded paths, and symlink escapes. It
also observes Mount Guard before and after indexing, rolling back if the vault
becomes unavailable.

Upgrade

npm install -g obsidian-everywhere@0.9.2

Restart the local MCP service after upgrading. Existing vault indexes require
no manual migration or rebuild.

Obsidian Everywhere v0.9.1 — MCP Registry metadata fix

Obsidian Everywhere v0.9.1 — MCP Registry metadata fix

v0.9.1 is a metadata-only follow-up to v0.9.0. It shortens the public server
description to the MCP Registry's 100-character limit and adds a release
preflight check so the same mismatch is caught before publishing.

All reviewable Vault Git functionality, safeguards, documentation, and
cross-platform verification from v0.9.0 are unchanged. See the
v0.9.0 release notes
for the complete feature overview.

Obsidian Everywhere v0.9.0 — Reviewable Vault Git

Obsidian Everywhere v0.9.0 — Reviewable Git for local vaults

Obsidian Everywhere turns linked notes into focused AI context and makes that
context available to agents wherever they run. Graph traversal, full-text and
optional local semantic search, attachment extraction, and guarded edits still
operate against the vault on your own machine—even when the MCP client is on an
external server connected through authenticated HTTP or an HTTPS tunnel.

v0.9.0 adds stable, opt-in Vault Git tools. An agent can inspect and checkpoint
changes in a vault that is already managed with Git without receiving a remote
shell or unrestricted Git access. Git remains off by default, and each
deployment chooses its capability level explicitly.

Vault Git

• git_status, git_diff, and git_log provide bounded, local-only repository
  inspection in read mode.
• git_commit creates an unsigned commit from an exact list of reviewed files
  in commit mode.
• git_push publishes the reviewed HEAD only to its existing upstream through
  an operator-pinned, credential-free HTTPS destination in push mode.
• Commit and push use a preview followed by a five-minute, one-use approval.
• The service never fetches, pulls, changes branches, accepts arbitrary
  refspecs, or exposes a general-purpose git_exec tool.

The Git repository can be the vault root or one real folder inside the vault.
This is useful when the complete vault should remain searchable but only one
project folder is version-controlled. For example:

export OBSIDIAN_VAULT_PATH="/Volumes/SanDisk/jwhong"
export OBSIDIAN_EVERYWHERE_TOKEN="<long-random-token>"
export OBSIDIAN_EVERYWHERE_READONLY=true
export OBSIDIAN_EVERYWHERE_GIT_MODE=read
export OBSIDIAN_EVERYWHERE_GIT_REPO_PATH=DSLab

npx -y --package obsidian-everywhere@0.9.0 obsidian-everywhere-http

Here, graph, semantic, search, and file tools use the full
/Volumes/SanDisk/jwhong vault, while Git paths are relative to
/Volumes/SanDisk/jwhong/DSLab. Start in read mode and confirm git_status
and git_log from the remote client before enabling writes.

Push requires the ordinary write gate as well as an exact remote-to-URL mapping:

export OBSIDIAN_EVERYWHERE_READONLY=false
export OBSIDIAN_EVERYWHERE_GIT_MODE=push
export OBSIDIAN_EVERYWHERE_GIT_ALLOWED_PUSH_REMOTES=origin=https://github.com/owner/vault.git

The complete setup and transport-specific environment names are documented in
the Vault Git guide.
For an external agent, first configure the
Remote Vault Bridge with ngrok,
verify the vault identity and read-only tools, and only then raise the write
capability.

Safety model

Vault Git uses fixed command shapes and argument arrays rather than a shell. It
validates the configured repository boundary, metadata layout, exact paths,
file modes, attributes, proposed Git tree, branch and upstream state, and the
exact push destination. It captures the vault, selected repository, and .git
identities at startup and rechecks them before every Git subprocess. Hooks,
repository-local includes and HTTP/network overrides, external diff and clean
filters, unsafe object layouts, symlinks, submodules, unresolved merges, and
histories that exceed review limits fail closed. Commit content, outgoing
commit messages, and changed blobs are checked for common secrets before an
approval can be used. Push rechecks the reviewed state and uses a compare-and-
swap lease so a changed remote-tracking ref cannot be silently overwritten.

Verification

The release adds real temporary-repository integration coverage for status,
diff, log, commit, push, nested repository selection, approval expiry and
one-use behavior, SHA-256 repositories, unusual filenames, and adversarial Git
configuration. The CI matrix runs the Git integration suite on Linux, macOS,
and Windows in addition to lint, formatting, type checking, the complete test
suite, build, package-content, and Docker runtime checks. Release publishing
now also verifies that the npm package, lockfile, MCP Registry metadata,
runtime version, and v-prefixed Git tag all agree before either registry is
updated.

Obsidian Everywhere v0.8.1 — Larger attachment limits

Obsidian Everywhere v0.8.1 — Larger attachment limits

This patch raises the conservative v0.8.0 extraction limits and makes them
operator-configurable.

• Source attachments: 32 MiB → 64 MiB by default.
• PDFs: 16 MiB → 48 MiB by default.
• Uncompressed Office/OpenDocument/EPUB entries: 8 MiB → 32 MiB by default.
• Each limit can be raised independently up to 1 GiB with documented
  environment variables.

The default values retain the project's 200 MiB RSS smoke-test target. Raising
them is useful for larger research documents but may require more process
memory.

Obsidian Everywhere v0.8.0 — Vault-wide attachment access

Obsidian Everywhere v0.8.0 — Vault-wide attachment access

v0.8.0 lets MCP clients read and search knowledge stored outside Markdown
notes while preserving the vault graph around those files.

Highlights

• New read_file and search_files tools.
• Local extraction for PDF, DOCX, PPTX, XLSX, OpenDocument, EPUB, RTF,
  text/code/data formats, and common images.
• Page, slide, and sheet selection with attachment backlinks.
• Lazy, sequential, hash-keyed extraction caching with strict input and output
  limits.
• A repeatable 200 MiB RSS gate; the release fixture peaks near 120 MiB.
• Transformer semantic search is now an optional peer and explicit opt-in, so
  the default install is lighter and has zero production audit findings.

Upgrade

npm install -g obsidian-everywhere@0.8.0

Existing source-checkout and npx users only need to restart their MCP client
or service after upgrading. Attachment extraction happens on demand and does
not require a migration command.

Obsidian Everywhere v0.7.0 — Remote Vault Bridge

Obsidian Everywhere can now serve a local Obsidian vault as graph and semantic
context to MCP clients running on another machine. The notes stay on the
machine you control; the client connects through authenticated Streamable HTTP
over a private network or an HTTPS tunnel.

What is new

• Remote Vault Bridge is now a first-class deployment path for Claude Code,
  Codex, and other Streamable HTTP clients.
• Local semantic retrieval and graph context bundles are available remotely,
  alongside the existing full-text, backlink, neighborhood, and path tools.
• Guarded remote edits can create, append, move, tag, and reorganize notes.
  Read-only mode remains available and is the recommended starting point.
• vault_status reports mount state, index freshness, indexed counts, write
  availability, the configured sentinel, and the last full reconciliation.
• Mount Guard (Beta) preserves the index and blocks writes if a removable
  drive, NAS share, or container mount disappears. When the vault returns, the
  server verifies it and performs a full reconciliation before reopening writes.
• English and Korean ngrok tutorials cover read-only-first setup, stable
  domains, automatic startup, validation, token rotation, troubleshooting, and
  security.
• Static bearer authentication now uses constant-time comparison and failed
  authentication attempts are rate-limited.

Watch the workflow

Watch the 44-second Remote Vault Bridge demo.

The video follows a product-research use case: a remote agent retrieves evidence
for Project Lumen through semantic and graph context, appends an interview
finding to the local vault, blocks a write when the drive disappears, and
reconciles the index when it returns.

Start here

Try the local sample vault without touching your notes:

npx -y obsidian-everywhere demo

For remote access, follow the
Remote Vault Bridge with ngrok tutorial.
Start read-only, verify the remote vault identity and note counts, then enable
writes only if you need them.

Beta feedback wanted

Mount Guard remains Beta because removable drives, NAS shares, and container
mounts behave differently across operating systems. We are looking for five
people willing to test a real remote-vault setup and report what is clear,
fragile, or missing. No vault contents need to be shared.

Join through
Beta Issue #18,
or ask setup questions in
Discussion #19.

Security notes

The bearer HTTP server does not provide TLS by itself. Use it only behind a
private network or an HTTPS-terminating tunnel, use a long unique token, and
never commit the token or tunnel credentials. Public OAuth connectors keep
write tools disabled unless explicitly enabled.

v0.6.0

Added

• bulk_update_frontmatter / bulk_remove_frontmatter_field — folder- or vault-wide frontmatter edits in one call, mirroring bulk_replace's dry-run default, maxFiles guard, and rollback snapshot (restorable via the existing rollback_bulk_edit). Only notes where a value actually changes are touched.
• list_notes gained an optional properties: string[] to project named frontmatter fields alongside each listed note (from the already-indexed data, no extra reads) — e.g. properties: ["status", "project"] to audit consistency across a folder without a read_note per file.
• See DECISIONS.md D23 for the rationale — both gaps were found live during a real vault reorganization, where removing one redundant field from ~90 notes required 88 individual tool calls.

v0.5.2

Fixed

• Every tool's input arguments are now strictly validated (z.object(shape).strict()) instead of silently dropping unrecognized parameters. Previously a typo'd param name (e.g. regex_search({ paths: [...] }) instead of the real { folder: ... }) produced no error at all — the call "succeeded" but silently ran with that parameter unset, returning subtly wrong (often whole-vault-scoped) results indistinguishable from a correct call. Now it returns a clear Unrecognized key(s) in object: '...' tool error. See DECISIONS.md D22.

v0.5.1

Fixed

• fullScan, applyFileUpsert, and applyFileDelete now run inside a single SQLite transaction (VaultDB.transaction). Previously a crash partway through a scan — e.g. the frontmatter-YAML crash fixed in 0.5.0, hit repeatedly on a real deployment before that fix shipped — could leave files with their content written but their links not yet written (a separate, later pass), and the mtime+hash "unchanged" short-circuit meant those files were silently skipped on every future scan, permanently undercounting backlinks/outlinks and inflating orphan counts. See DECISIONS.md D21.

Obsidian Everywhere v0.5.0

Added

• semantic_search — meaning-based search via local embeddings (Xenova/multilingual-e5-small, int8-quantized, ~120MB), finding conceptually related notes even without shared vocabulary, including across languages. Fully local: no API key, cloud account, or Ollama process. Embeddings are computed lazily (only once a semantic tool is actually used) and incrementally (only new/changed notes, up to 50 per call).
• get_related gained an optional method: "semantic" (default stays "jaccard", unchanged) using the same embedding infrastructure, for finding topically similar notes that share no tags or links at all.
• See DECISIONS.md D20 for the full design rationale (why local-only, why brute-force cosine over a vector-search extension, why lazy/bounded indexing, and the two npm audit advisories accepted as unreachable for this project's text-only usage).

Fixed

• A note whose frontmatter isn't valid YAML (e.g. a Templater placeholder like {{date:YYYY-[W]ww}}, valid template syntax but not valid YAML) no longer crashes the entire indexing pass — and with it the whole process, repeatedly, on every restart. It now degrades to "no frontmatter, whole file as body" for that one note and keeps going.