evaluate_expression: every ctx.vault call throws "Cannot read properties of undefined (reading 'length')

[carkur]

Ran into a small problem here that the agent suggested I submit here - tried to keep it concise. Thanks for this awesome plugin - it's really fantastic, and definitely my favorite out of the different copilot-style plugins I've used in different applications.

Plugin version: 3.6.1
Obsidian: desktop, 1.13.7
OS: Fedora KDE 44

Description
The evaluate_expression sandbox runs minimal expressions fine, but any call
touching the ctx.vault bridge throws Cannot read properties of undefined (reading 'length') before user code can even inspect the return value:

• ctx.vault.read(path) - same error
• ctx.vault.readBinary(path) - same error
• ctx.vault.list("/") - same error
• A probe wrapping everything in try/catch and only reading Object.keys(ctx.vault)
  • same error (so the throw originates inside the bridge, not in user code)

Occurs for any path, including root-level files; sync and await both fail.

Steps to reproduce

1. evaluate_expression({ ok: true }) - succeeds.
2. evaluate_expression with any ctx.vault.read(...) or ctx.vault.list(...)
   call - same TypeError as above.

Expected: read returns file content; list returns entries.
Actual: internal TypeError from the vault adapter.

Additional notes from VO agent

• Worked in earlier sessions (batch file slicing on 2026-08-18/19); broken since
  2026-08-19 and still broken after an Obsidian restart.
• No setting in the settings dump controls this (no sandbox/eval toggle exists).
• evaluate_expression is not listed in the generated tools reference
  (docs/reference/tools.md - 82 tools, seven groups) - flagging in case the
  adapter was recently refactored.

Happy to provide more info if needed, though it's a bit hard for me to "see" as it's largely on the agent's side.

[pssah4]

Thanks, this is a real bug and the repro detail helped a lot.

The TypeError does not come from the vault bridge. It comes from how evaluate_expression serializes its own result. When the expression evaluates to undefined, JSON.stringify(undefined) returns the JS value undefined (not the string "undefined"), and the next line reads .length on it and throws exactly the message you saw. The catch then surfaces that internal TypeError as the tool result, which is why it looked like it came from the bridge.

That also explains the probe. A bare Object.keys(ctx.vault) or ctx.vault.list("/") returns a defined value and does not crash. What crashes is any expression whose top-level value is undefined. The most common shape is a try/catch where return sits only in the catch branch, so the try branch computes a value but never returns it. A successful return await ctx.vault.read("Notes/x.md") returns content and is unaffected.

So the vault access works; the result formatter did not tolerate an undefined result. The fix is in: undefined and any non-string result now serialize safely, and an empty result returns a clear "did not return a value" message instead of an internal error. It ships in the next release.

Two things would let me confirm your exact case: (1) one verbatim expression string your agent sent that failed, and (2) whether wrapping the call so it explicitly returns the value, e.g. return await ctx.vault.read("some/file.md"), works for you today. Nothing changed in the plugin on 2026-08-19 (this code path has been frozen since July), so the trigger was almost certainly a change in the shape of the expressions being sent, not a plugin update.

One correction on the docs note: evaluate_expression is in the generated tools reference (it is listed with its full signature), so no adapter refactor happened here. The bug is purely in the result formatter, which is reassuring in the sense that your vault access path is intact.

[carkur]

Per the agent:

---

Your diagnosis is exactly right, and I've now reproduced it live on 3.6.1 with read-only probes.

Verbatim failing expressions (both throw Cannot read properties of undefined (reading 'length')):

try { Object.keys(ctx.vault); } catch (e) { return "ERR: " + e.message; }
try { const c = await ctx.vault.read("Untitled.md"); } catch (e) { return "ERR: " + e.message; }

The first one never touches the vault bridge — it only reads Object.keys — which confirms the throw is in the result formatter, not the adapter.

And your suggested shape works today: return await ctx.vault.read("Untitled.md"); succeeds (returns "" — the test file is empty, but the call is clean). Object.keys(ctx.vault) returns ["read","readBinary","list","mkdir","write","writeBinary"], and ctx.vault.list("/") returns the real vault structure. The bridge is healthy; your fix's undefined-result path covers every case I reproduced.

One extra note, maybe worth a doc tweak: statement-style code without an explicit return (e.g. const c = await ctx.vault.read("Untitled.md");) fails even earlier at the transform step with Transform failed: Unexpected "const" — a different, cryptic error. That's what made the original report look like "the bridge is broken": two distinct cryptic failures, both blamed on the adapter. A one-line hint in the docs ("the sandbox expects an expression or an explicit return") would steer agents away from the shape entirely.

And for the record: the 08-19/20 "regression" was a change in expression shape, not a plugin change — my successful end-of-build verification on 08-21 used return JSON.stringify(...), consistent with your "no plugin change since July."

---

I hope that helps! I'm using Deepseek-flash-v4 here - it probably doesn't matter, but if there's some variation between agents in interpretation, etc., I figured I'd mention it if it helps with reproducibility, etc.