# Bug Report: `property:set` Silently Succeeds But Makes No Change on Externally-Written Files

Bug reports
1

property:set silently succeeds but makes no change when operating on externally-written files

I’ve run into a silent failure in the Obsidian CLI (installer 1.12.7+, Windows 11) that affects automation workflows where files are written to the vault by external processes. Posting here so others can recognise it and so the team has a clear reproduction case.

The problem: obsidian property:set exits with code 0 and produces no output — indicating success — but makes no change to the file when that file was written externally and Obsidian hasn’t yet re-indexed it.

Conditions that trigger it

All three must be true simultaneously:

  1. A file is written to the vault by an external process — Node.js fs.writeFileSync, PowerShell Set-Content, Python, any shell tool — anything other than Obsidian itself writing the file.
  2. The property:set command is issued before Obsidian’s file watcher has processed the change. On Windows this window is roughly 0–3 seconds.
  3. The file is not currently open in an Obsidian editor tab. Files open as tabs are in active memory and respond to CLI writes immediately. Files that exist only on disk and aren’t yet indexed do not.

This also affects existing files that have been modified externally, not just newly created ones. Obsidian was running throughout — this is not a “Obsidian not running” issue.

How I diagnosed it

I’m running a watcher-based inbox pipeline on Windows. A PowerShell watcher detects new .md files arriving in a folder, then immediately calls a Node.js script that writes default frontmatter fields via obsidian property:set:

obsidian property:set name=pipeline_stage value=1a path=00-Inbox/note.md

The command exits 0 with no output every time. But re-reading the file afterward shows pipeline_stage was never written.

Adding a deliberate 3–5 second delay between the external write and the property:set call fixed it every time. Removing the delay reproduced the silent failure every time. Files already open as editor tabs were never affected.

This confirms the root cause: property:set routes through Obsidian’s in-memory file state via IPC. When that state doesn’t yet include the externally-written file, the command silently no-ops instead of returning an error.

Why this matters

Exit code 0 with no output is universally interpreted as success by automation tooling. There is no way to detect this failure without defensively re-reading the file after every write. Silent success on a no-op write is particularly damaging in pipelines, because downstream steps proceed on the assumption the write landed.

Potential workaround using existing CLI commands

Calling obsidian open path=<file> before property:set forces the file into Obsidian’s active cache and may resolve the issue, at the cost of opening the file as a tab. We haven’t fully tested this as a general solution since opening every file in an automation pipeline is undesirable, but it may be useful as a targeted fix.

Suggested fix

property:set should return a non-zero exit code and an error message when the target file is not in the active index, for example:

error: file not indexed -- ensure Obsidian has processed the file before retrying

Alternatively, the command could trigger an immediate index refresh for the specified path before executing.

Environment

  • Obsidian app version: 1.12.7
  • Obsidian installer version: 1.12.6
  • OS: Windows 11
  • External write tool: Node.js fs.writeFileSync (UTF-8, LF line endings)
  • File watcher: PowerShell polling loop, 2-second interval
  • Obsidian was running throughout

Related forum reports

Three forum reports describe overlapping but distinct failure modes in the same CLI release window. Listed here for cross-reference; the team may wish to evaluate them together.

  1. CLI: tasks and tags silently return empty when called from terminal (post #111168, Feb 13, 2026) — Same symptom class: exit 0 with no useful output. Root cause differs: those commands default to “active file” scope when called from a terminal, producing empty results rather than vault-wide results. Not an indexing-lag issue.

  2. CLI console shim silently fails on colon subcommands with key=value parameters (post #111296, Feb 17, 2026) — Closest structural match: same command form (property:set key=value), same silent failure on Windows. Root cause is the .com console shim mishandling key=value parameter parsing for colon subcommands. This report is distinct: the shim bug fires on any file regardless of index state; the indexing-lag bug fires only when the file is not yet in Obsidian’s active cache. Both produce identical symptoms. If this report cannot be reproduced, the shim bug should be ruled out first.

  3. Open-source agent skill: prevents 13 silent failures (post #111169, Feb 13, 2026) — Community audit cataloguing 13 confirmed silent-failure patterns across CLI 1.12. The indexing-lag failure described in this report does not appear in that list, suggesting it was not encountered in that test suite — likely because testing did not involve externally-written files under timing pressure.

2