OBSIDIAN_HOST env var causes double protocol in URL (https://https://)

[FiReCRaSHb]

Bug Description

The mcp-server.exe ignores the OBSIDIAN_HOST environment variable set in
claude_desktop_config.json and constructs a malformed URL with double protocol.

Error in logs

"path": "https://https//127.0.0.1:27124:27124/"

Environment

• MCP Tools version: 0.2.27
• OS: Windows 10
• Claude Desktop app

Steps to reproduce

1. Set OBSIDIAN_HOST=http://127.0.0.1:27123 in claude_desktop_config.json
2. Restart Claude Desktop
3. Check server log - URL still shows https://https//127.0.0.1:27124:27124/

Expected behavior

Server should use the URL from OBSIDIAN_HOST env var correctly.

Actual behavior

Server ignores env var and uses hardcoded URL with double protocol prefix.

[istefox]

Hi @FiReCRaSHb — thank you for the report and the clean trace.

This is a configuration footgun in the upstream OBSIDIAN_HOST semantics, not strictly a code bug. Upstream OBSIDIAN_HOST is treated as a hostname only (e.g. 127.0.0.1 or obsidian.lan), never a full URL. When you set OBSIDIAN_HOST=http://127.0.0.1:27123, the URL builder concatenates literally:

BASE_URL = "https://" + OBSIDIAN_HOST + ":" + DEFAULT_PORT
         = "https://" + "http://127.0.0.1:27123" + ":27124"
         = "https://http://127.0.0.1:27123:27124/"

Which matches what your log shows.

Two ways out

Quick fix (no install change)

Use OBSIDIAN_HOST as a hostname only:

"env": {
  "OBSIDIAN_HOST": "127.0.0.1"
  // (default protocol stays HTTPS:27124; if you want HTTP:27123 you also
  //  need to set OBSIDIAN_USE_HTTP=true and OBSIDIAN_PORT=27123 — see below)
}

Recommended fix (community fork on BRAT)

The community fork istefox/obsidian-mcp-connector (current release 0.3.9, installable via BRAT) introduced a single OBSIDIAN_API_URL convenience env var that accepts a full URL and parses it correctly:

"env": {
  "OBSIDIAN_API_URL": "http://127.0.0.1:27123"
}

Resolution order in the fork is host-port-protocol with most-specific-wins (OBSIDIAN_HOST / OBSIDIAN_PORT / OBSIDIAN_USE_HTTP override OBSIDIAN_API_URL), so existing granular configs keep working unchanged. The fork also ships several other fixes since 0.2.27 (heading-target silent EOF append #71, frontmatter array silent corruption, search_vault_smart double-parse, install/uninstall on Windows, etc.).

Upstream is officially unmaintained since 2026-04-24 (see #79), so no fix will land here. If you'd like to confirm the fork resolves your case, install via BRAT (Add Beta plugin → istefox/obsidian-mcp-connector) and let me know on istefox/obsidian-mcp-connector — happy to track any residual issue there.

[istefox]

Hi @FiReCRaSHb — heads-up so you don't have to wait on this one.

A fix for this bug shipped today in the community fork istefox/obsidian-mcp-connector 0.3.12. The fork is BRAT-installable from istefox/obsidian-mcp-connector and is being maintained as the continuation of this project (jack confirmed the unmaintained status of upstream on #79 a few days ago).

Tracking issue with the technical detail: istefox/obsidian-mcp-connector#21.

What the fix does: OBSIDIAN_HOST now accepts both forms — bare hostname (the documented form, unchanged) and a full URL like http://127.0.0.1:27123 (which produced your https://https://…:27124:27124/ malformed BASE_URL). When a URL form is used, its port and protocol parts feed PORT/USE_HTTP only where the more specific variables (OBSIDIAN_PORT, OBSIDIAN_USE_HTTP) are unset. There's also a new INFO log line at server boot that prints the resolved BASE_URL, so future misconfiguration of this kind is visible without a network round trip.

Not pinging maintainers — just leaving the pointer here for anyone who lands on this issue. Cheers.