patch_vault_file fails with non-ASCII heading names (Cyrillic, CJK, etc.)

[sergeyklochko]

Description

patch_vault_file returns an error when the target heading contains non-ASCII characters (Cyrillic, Chinese, Japanese, Arabic, etc.).

Error

MCP error -32603: Header 'Target' has invalid value: 'Детали'

Steps to reproduce

1. Create a note with a Cyrillic (or any non-ASCII) heading, e.g. ## Детали
2. Call patch_vault_file with target: "Детали", targetType: "heading"
3. The tool returns the error above immediately — the request never reaches the REST API

Root cause

The mcp-server binary sets the heading name directly as an HTTP header value:

Target: Детали

Go's net/http package rejects non-ASCII bytes in header values at the client side, so the request is never sent.

Notably, obsidian-local-rest-api already calls decodeURIComponent() on the Target header value on the server side — so it is ready to accept a percent-encoded value.

Fix

One line in the Go HTTP client, before setting the header:

req.Header.Set("Target", url.QueryEscape(target))

This makes encoding consistent with what the server already expects.

Impact

Any vault with non-English headings cannot use patch_vault_file at all. The only current workaround is to rename all headings intended for AI editing to ASCII — which is impractical for non-English users.

Environment

• MCP Tools: v0.2.27
• obsidian-local-rest-api: v3.6.1
• Obsidian: v1.12.7
• OS: macOS (arm64)

[istefox]

For anyone still waiting on this — it's been fixed in the community fork at https://github.com/istefox/obsidian-mcp-connector (commit see CHANGELOG.md, released in v0.3.0).

You can install today via BRAT by pointing to istefox/obsidian-mcp-connector, or wait for the community-store entry pending at obsidianmd/obsidian-releases#11919.

Opening from the fork side to surface the pointer — feel free to close if you're satisfied, or keep open to track the upstream decision.

[folotp]

Confirming this bug on macOS Tahoe 26.4.1 with Obsidian 1.12.7, Local REST API 3.6.1, wrapper 0.2.27. I hit the exact same signature on any target containing é, è, à, ç, ù, î, ô, œ, en-dash, em-dash, non-breaking space, or any other non-ASCII character — reproducible 100 % of the time, and effectively unusable on a French-language vault where section headings carry accents by default.

Two things worth adding:

1. Standards framing

The rejection is produced by RFC 9110 §5.5: HTTP field values are restricted to visible US-ASCII (0x21–0x7E) plus SP and HTAB. Anything outside that is rejected at the transport layer before the plugin ever sees it, which is why the error fires with Header 'Target' has invalid value regardless of what the server would do with the value. The canonical way to carry non-ASCII values in HTTP headers is RFC 8187 (Target*=UTF-8''<percent-encoded>), but the plain percent-encoded form in an ordinary Target: header works too if the server decodes it — which it does (see next point).

2. Empirical validation: the fix is strictly wrapper-side

The Local REST API plugin already calls decodeURIComponent() on the Target header value (as the issue notes). Verified this end-to-end from a Cowork session on 2026-04-22: a curl against the plugin with

Target: Anti-patterns%20op%C3%A9rationnels
Target-Type: heading
Operation: append

succeeded immediately on a heading that had failed with the raw-UTF-8 form seconds earlier (é = U+00E9, NFC → %C3%A9). No plugin-side change required. This means the minimal viable fix is a single line in the wrapper, before setting the header:

req.headers["Target"] = encodeURIComponent(target);

(Or encodeURI if you want to preserve / and :: unescaped for heading-path targets. A one-line unit test on a heading containing é would pin the regression.)

The full RFC 8187 form (Target*=UTF-8''…) remains the canonical answer and is worth considering if you ever add a header that needs to carry language metadata, but it is not required to fix this issue.

3. Real-world severity from a French vault

Documented occurrences over a 48-hour window: 5 incidents on 5 different headings, all 100 % reproducible, all resolved by manual percent-encoding or by falling back to create_vault_file for full-note rewrite. The workaround is accepted but fragile (it requires knowing a priori that a target is non-ASCII, and the LLM agents I drive this from do not always classify the character set correctly before calling). Getting this fixed wrapper-side removes a significant usability tax for any non-English vault.

---

Cousin wrapper bugs on the same surface, for cross-reference: #71 / PR #72 (silent append-EOF on heading targets, orthogonal cause), and #81 (Zod array-valued frontmatter rejection).

[istefox]

Hi @folotp — excellent forensic summary, especially the RFC 9110 / RFC 8187 framing. That exact diagnosis + one-line fix (encodeURIComponent on Target / Target-Delimiter headers) landed on the community fork in v0.3.0 and has been stable through v0.3.5 (current release). A regression test covering Cyrillic, CJK, accented + bracketed strings is pinned in 0.3.3 so it won't silently regress.

If you install the fork via BRAT (istefox/obsidian-mcp-connector), I'd expect the é / à / ç / en-dash / NBSP repro on your French vault to pass immediately. Your confirmation on the record would let @jacksteamdev close this issue with confidence if the co-maintainership discussion on #79 resumes — you're the first person to test systematically on a real non-ASCII vault.

Cross-refs for the other issues you've touched this week:

• patch_vault_file silently corrupts content when targeting headings in nested sections #71 — heading-path resolution fixed in 0.3.0. Your block-in-table extension is a newly-identified gap; follow-up coming on that thread.
• [Bug] get_vault_file(format: "json") fails Zod validation on any note with array-valued frontmatter (aliases, tags, up, …) #81 — fix en route. Schema relaxation, 1 line of code, PR inbound.
• [Bug] patch_vault_file replace corrupts sections containing markdown tables with inline code-span heading refs #83 — confirmed novel. Root cause likely lives in upstream coddingtonbear/markdown-patch, not the wrapper. Separate follow-up.

Thanks again for the detail — these reports make the difference between a "probably fixed" status and a clean close.

[folotp]

@istefox — confirming the v0.3.0+ encodeURIComponent fix on a real non-ASCII vault.

Test setup: Obsidian 1.12.7, Local REST API 3.6.1, mcp-tools-istefox 0.3.7.

Cases tested (all H2 nested under H1, to isolate the transport layer):

• Latin-1 accented characters (é, à, ç, ù, î, ô, œ) — pass.
• Em-dash (—) and en-dash (–) — pass.
• Non-breaking space ( ) inside the heading text — pass.
• Combination heading (Conclusion — synthèse finale, three of the above) — pass.

All cases produce in-place replace, no append-EOF, no Header 'Target' has invalid value rejection. The RFC 9110 / RFC 8187 framing maps cleanly onto the implementation, and the regression test pinned in 0.3.3 should keep this stable.

One caveat for future readers of this thread: if the heading is a true-root ## (no H1 parent), the call still appears to fail — but the failure cause is the heading-half bug from #71, not the non-ASCII transport. I posted the details on #71 to keep the scope here clean.

This issue can close from my side. Thanks for the fast turnaround.

[istefox]

@folotp — appreciated, thanks for closing the loop with the systematic non-ASCII coverage. The Latin-1 / em-dash / NBSP cases on a real French vault are exactly the kind of confirmation that turns "probably works" into a closeable issue.

For anyone arriving here later: the fix is shipped in the community fork istefox/obsidian-mcp-connector (v0.3.0+, regression-tested in 0.3.3, current release 0.3.9), installable via BRAT. Upstream is officially unmaintained per #79, so this thread will likely stay open here — but the actual code path is fixed and stable for end users via the fork.

Your separate root-orphan H2 finding on #71 is also addressed in v0.3.9, with a wrapper-side rejection that points the caller at the workarounds (add an H1 anchor, or pass createTargetIfMissing=false).

[istefox]

Hi @sergeyklochko — heads-up that this thread will likely sit on the unmaintained upstream (per #79). The non-ASCII heading-name surface is fully resolved in the community fork istefox/obsidian-mcp-connector 0.4.0 (released 2026-05-04), via a different mechanism than your proposed one-line Go client fix.

The 0.4.0 fork drops the Go mcp-server binary entirely — the MCP server now runs in-process inside the Obsidian plugin (Streamable HTTP on 127.0.0.1:27200). Heading targets are passed as JSON args in the request body, processed in TypeScript in-process, and delivered to Obsidian's vault APIs natively. There's no HTTP header serialization step where Go's net/http could reject non-ASCII bytes.

Net effect: patch_vault_file with target: "Детали" — or any non-ASCII heading name in any script (Cyrillic, CJK, Arabic, Hebrew, …) — works end-to-end on 0.4.0. Different architecture, same observed correctness.

Install: BRAT pointing at istefox/obsidian-mcp-connector, or drop main.js + manifest.json from the 0.4.0 release into <vault>/.obsidian/plugins/mcp-tools-istefox/.