This appears to be a regression of a bug that staff already marked SOLVED in February, with a fix promised for 1.12.2. I’m on 1.13.7 (several releases later) and the exact same failure still reproduces.
Steps to reproduce
From a Windows terminal, with Obsidian running and a vault open (any vault)
- Run a command that combines a colon-style subcommand with key=value params, e.g.
property:set path="note.md" name="testprop" value="hello" -
- Compare against a non-colon command with params, e.g.
search query="test"
- Compare against a non-colon command with params, e.g.
-
- Compare against a colon command with no params, e.g.
daily:read
Reproduces identically via Git Bash, cmd.exe, PowerShell, and even a raw .NET System.Diagnostics.Process.Start call (no shell involved at all), so it is not shell-specific quoting or escaping.
- Compare against a colon command with no params, e.g.
Did you read and follow the Troubleshooting Guide? [Yes/No]
Yes.
Expected result
property:set, daily:append, property:read, search:context, template:read, and other colon-subcommands that accept key=value parameters should behave like their non-colon counterparts (create, search) — execute successfully, or print a meaningful error message.
Actual result
Any command combining a colon-subcommand with key=value params fails silently: exit code 255 (PowerShell LASTEXITCODE -1; Git Bash reports exit 127), with no stdout or stderr output at all.
Commands that fail:
property:set path="diagtest.md" name="testprop" value="hello"
property:set file="diagtest" name="testprop" value="hello"
property:read path="2026-09-13.md" name="status"
daily:append content="test entry"
search:context query="test"
template:read name="x"
Commands that succeed for comparison:
daily:read (colon subcommand, no params, exit 0)
search query="test" (no colon, has params, exit 0)
create name="diagtest" content="hello" (no colon, has params, exit 0, file created and verified)
files (no colon, no params, exit 0)
vaults (no colon, no params, exit 0)
help (no colon, no params, exit 0)
Pattern: works with no colon and no params, works with no colon and params, works with colon and no params, fails only when colon subcommand AND params are combined.
Isolation steps taken:
- Verified the correct binary is being invoked (the CLI redirector, not the GUI exe) via
fileon the resolved path. -
- Verified the vault is running and correctly targeted (
vaults,files,files totalall succeed and return sane data).
- Verified the vault is running and correctly targeted (
-
- Verified a real, existing file was used (
diagtest.md, created moments earlier via the workingcreatecommand and confirmed present infilesoutput).
- Verified a real, existing file was used (
-
- Captured stdout/stderr directly via System.Diagnostics.Process (bypassing all shell redirection) — confirmed both streams are empty, exit code -1 (255 unsigned).
-
- Ruled out the known, separate Git-Bash issue where the bare command resolves to the GUI exe instead of the CLI redirector — every test here called the fully-qualified redirector path directly, and the failure persists regardless.
Impact: any CLI-driven automation that needs to set or read frontmatter properties, append to the daily note, or do scoped/context search is currently unusable, even though equivalent non-colon commands and colon-commands-without-params work fine.
- Ruled out the known, separate Git-Bash issue where the bare command resolves to the GUI exe instead of the CLI redirector — every test here called the fully-qualified redirector path directly, and the failure persists regardless.
Environment
Obsidian version: 1.13.7 (installer 1.11.7)
OS: Windows 11 Enterprise (10.0.22631)
CLI binary: confirmed correct binary used, not the GUI exe
Vault: single vault, confirmed active
Obsidian.exe running: yes, confirmed via tasklist
Additional information
Related reports (I’m a new poster here so I can’t include links, sorry — searching the forum for these titles should find them):
- “CLI console shim silently fails on colon subcommands with key=value parameters” (Bug graveyard, posted by Middleway50, Feb 17) — marked SOLVED on Feb 18 with staff comment: “will be fixed 1.12.2. ETA unknown. Will require installation of an updated `obsidian.com``”. Thread auto-closed Mar 18 so I can’t reply there. This is the same bug, still present in 1.13.7.
-
- “Obsidian CLI property:* commands return exit code 255 when called via WSL2 interop” (Help, posted by easm002, Apr 9) — also closed (auto-closed after 90 days), reported the same symptom but attributed it to WSL2 interop specifically.
My testing shows this is neither WSL2-specific nor limited to property:* commands — it also affects daily:append, search:context, and template:read, and reproduces natively on Windows with no WSL2 involved. The cmd.exe workaround mentioned in the WSL2 thread did not hold in my testing either — it returned no visible error, but the property was never actually written when verified afterward.
- “Obsidian CLI property:* commands return exit code 255 when called via WSL2 interop” (Help, posted by easm002, Apr 9) — also closed (auto-closed after 90 days), reported the same symptom but attributed it to WSL2 interop specifically.
Happy to provide any further repro details, debug info, or test additional commands if useful.