Start with a separate vault
claude-obsidian turns source material into linked, source-cited Obsidian pages. That makes it worth evaluating for research notes whose summaries need to retain their evidence. The practical commitment is reviewing proposed changes and keeping backups, rather than simply installing an assistant and leaving it unattended.
The README at our measured commit describes immutable source capture, claim and source ledgers, read-only queries, and a transaction core for writes. Helpers return drafts; one orchestrator combines the operation. Target hashes detect changes made after planning, and a journal supports rollback after an interrupted write. These are documented controls, not a guarantee against data loss. The current README also explains that the lock coordinates cooperating local writers, not other devices or external editors.
What our run actually established
Our run took place on October 13, 2026, at commit 32ac5a0. The exact stored commit is 32ac5a02c4e082e4a5628ca810776375e134708e. Our sandbox used Python 3.12 with 3 CPUs and 8 GB RAM.
The test command in our sandbox exited 1 after 151 seconds. Installation and build returned zero, with stored durations of 9 and 6 seconds respectively. The installed dependency footprint was 35 packages and 38 MB.
The attached stored parser summaries record 525 passed, 4 failed, a total field of 529, and 5 skipped separately. They do not establish exhaustive unique test coverage; we have not reconciled a complete log or performed a new execution. Skipped tests are not failures.
The raw footer names four failures in tests/test_setup_wrappers.py: test_dragonscale_check_reports_actual_extension_state, test_dragonscale_default_is_a_read_only_plan, test_mode_apply_forwards_exact_review_approval, and test_mode_uses_cwd_vault_without_empty_array_failure. Each reports VAULT_SENTINEL_MISSING for /work/repo and an unexpected exit code. The tail establishes the observed wrapper failures, but does not isolate their cause. It does not show the concurrent transaction failure described in the previous page text.
Our harness stores each command's outcome, exit code, elapsed time and output tail alongside parsed counts. The testing methodology explains that reporting model and its limits. That page is provenance context, not evidence that its current procedure was used unchanged for this older run.
The audit record contains zero recorded pip-audit advisories. Scan coverage is unknown: no scannedPackages field establishes which packages were checked, and the stored packages value is zero. This is not a security assessment.
We did not establish interactive agent behavior, answer accuracy, successful ingestion of a research collection, native Windows operation, or synced-vault recovery. The recorded build success is a command outcome, not proof of deployment or a completed user workflow.
Check extraction and privacy before choosing it
The pinned README says PDF and EPUB capture retains metadata, hash and size without built-in semantic extraction. URL and YouTube operations need a configured external runner, and OCR needs an external tool. Local BM25 retrieval is available; remote models and contextual processing require explicit egress consent.
Those boundaries matter before you collect a large inbox. Verify the extraction path for your actual source formats before expecting linked notes from them.
Local files also do not mean wholly local AI processing. The current README explicitly says that notes read through Claude Code are sent to Claude. Additional web research and remote models require permission, but your selected agent still determines where its input is processed.
Native Windows supports inspection and previews; vault writes require WSL. Keep review and apply in that environment. For synced vaults, test on a copy and retain independent backups because external editors and other devices do not share the local writer lock.
Choose an interface or discovery tool for a different need
Obsidian Copilot brings OpenCode, Claude Code, and Codex into Obsidian. Consider it when working inside the Obsidian interface is your main requirement. Its README describes an agent that can inspect notes, use tools and create files with permissions you control. That establishes an interface alternative; it does not establish equivalent provenance or transaction behavior.
Smart Connections uses local embeddings to surface semantically related notes. Consider it when rediscovering existing notes is the task. It can complement a source-capture workflow, rather than replace its ingestion and transaction machinery. Its current README says Smart Chat is a separate plugin, so bundled chat should not drive this choice.
How to read the ratings
These are editorial ratings, not benchmark results. The scale is 1 for substantial documented obstacles, 2 for material setup friction, 3 for useful capability with unresolved limits, 4 for strong supporting evidence, and 5 for unusually complete evidence within the dimension being assessed. Setup considers prerequisites and observed command outcomes; documentation considers coverage of operation and limits; community considers visible project participation rather than adoption; maturity considers operational evidence and unresolved failures.
Setup ease remains 2/5 because the small install still requires environment-aware approvals and the wrapper tests failed. Documentation remains 5/5 for its explicit installation, transaction, platform, recovery and capability guidance; that rating does not certify every link or instruction. Community remains 4/5 based on visible contributions and issue participation in the supplied primary pages, not inferred production usage. Maturity remains 3/5 because the documented safeguards coexist with an unsuccessful sandbox test command and untested interactive workflows.
Before adopting an existing vault, create a separate trial vault, inspect the first operation, check that the agent can read its required contracts, and exercise the source formats and recovery path you intend to use.