Restricted mode enabled (all community plugins disabled)
Default theme, no CSS snippets
Search index rebuilt
Full restart of Obsidian
Sandbox vault as control (CLI search works there)
Expected result
obsidian search query=hello should return a list of matching files, consistent with the GUI search results.
Actual result
The CLI search command returns empty output with exit code 0 on a vault with ~2,740 files. The same command works correctly on small vaults (1–20 files). GUI search works correctly on all vaults.
Additionally, triggering a search via the JavaScript API (eval) confirms the search engine itself is functional:
This suggests the CLI search command uses a different code path that does not wait for the search to complete on larger vaults (possible race condition / missing await).
Environment
Obsidian version: 1.12.4
Installer version: 1.12.4
Operating system: Windows 11 Pro 10.0.26200
Login status: logged in
Language: en-GB
Catalyst license: none
Insider build toggle: off
Live preview: on
Base theme: adapt to system
Community theme: Vanilla AMOLED 1.0.0
Snippets enabled: 1
Restricted mode: on
Additional information
Vault contains ~2,740 markdown files across 141 folders
The search total flag also returns empty (not even “0”)
Occasionally the CLI returns “No matches found.” instead of empty output, but still no actual results
All other CLI commands (files, tags, tasks, read, vault) work correctly on the same vault
The issue does not appear to be related to userIgnoreFilters in app.json — tested with and without
Tested with community theme disabled as well — no change
Perhaps unrelated, but it now returns as this. I can only think it could be because I kept obsidian open when sleeping the PC? I have no idea if this is the same issue or a new one.
Bash(obsidian vault=Chimaera folders folder=Home)
[39200:0322/161205.635:ERROR:chrome\browser\process_s
ingleton_win.cc:454] Lock file can not be created!
Error code: 32
**Symptoms — nondeterministic across consecutive runs against the same app process:**
`obsidian search query=“term”` → usually **empty stdout, exit 0**. It returns fast (0.3–0.6 s over timed runs), so it’s not a timeout — the search engine doesn’t appear to be consulted at all.
Sometimes the same command returns `No matches found.` — wrong, the term has hundreds of hits in the GUI.
Occasionally the process **hangs** (>12 s, zero output) — no pipes involved, output redirected to a file.
`search query=… total` is tri-state across runs: empty string / `0` / never the real count.
**Control test:** the identical command on the small Sandbox vault returns 17 results, deterministically. This rules out syntax or vault-targeting errors (`vault=` passed as first argument).
GUI search and plugin JS APIs return correct results — only the CLI search path fails.
A graceful app restart **fixed `backlinks`** (it also returned empty before) but did **not** fix `search`/`search:context`.
This matches the original report: large-vault-only, empty with exit 0, GUI unaffected — consistent with the CLI search path not awaiting search completion. Possibly the 1.12.3 fix “CLI: Fixed the CLI hanging for some longer content” regressing on large vaults.
Happy to provide `dev:console` dumps captured during failing runs, a screen recording of consecutive nondeterministic runs, or to test a patched build.