Obsidian://open (and Web Clipper) works only when Obsidian is closed; no response when Obsidian is already running (Windows)

Bug graveyard
1

Environment

  • OS: Windows (desktop)

  • Obsidian app version: 1.12.1

  • Installer version shown in Obsidian: 1.11.7

  • Browser: Chromium-based (Chrome/Edge) with Obsidian Web Clipper

  • Vault name used by Web Clipper: obsidian-vault

Summary

Obsidian URI handling appears to fail when Obsidian is already running.
If Obsidian is not running, opening obsidian://open successfully launches Obsidian.
If Obsidian is already running, obsidian://open produces no visible response (Obsidian does not come to front, no action happens).
As a result, Obsidian Web Clipper cannot create notes while Obsidian is open.

Steps to Reproduce

  1. Close Obsidian completely.

  2. In the browser address bar, open:

    • obsidian://open

  3. Obsidian launches successfully.

  4. Keep Obsidian running.

  5. In the browser address bar, open again:

    • obsidian://open

  6. Nothing happens (no focus, no window activation, no action).

Expected Behavior

When Obsidian is already running, obsidian://open should bring the existing Obsidian window to the front (or at least trigger the URI handler in the running instance).
Web Clipper should be able to create a note while Obsidian is open.

Actual Behavior

When Obsidian is already running:

  • obsidian://open does nothing

  • Web Clipper generates the Obsidian URL, but Obsidian is not opened/activated and the note is not created

Evidence (Browser Console Logs from Web Clipper)

Web Clipper reaches URL generation successfully:

  • Content was extracted and variables were populated:

    • Updated currentVariables: { {{author}}: 'tawo', {{content}}: '![header image](...) ... (long content) ...' ... }

  • Clipboard API is blocked by Permissions Policy on the site when running in an iframe:

    • [Violation] Permissions policy violation: The Clipboard API has been blocked because of a permissions policy applied to the current document.

    • Standard clipboard API failed (running in iframe)... NotAllowedError...

  • Web Clipper falls back to the content-script method and succeeds:

    • Successfully copied to clipboard using content script fallback

  • Web Clipper then prints the generated Obsidian URL:

    • Obsidian URL: obsidian://new?file=Clippings%2F...&vault=obsidian-vault&clipboard

Despite the URL being generated, Obsidian is not activated and no note is created when Obsidian is already running.

Additional Notes / Constraints

  • The problem is reproducible consistently.

  • The same URI (obsidian://open) works only when Obsidian is closed, which suggests a failure to deliver URI events to the already-running instance (single-instance / IPC handling).

  • I cannot provide Obsidian’s internal developer console logs from my current location/network (unable to collect Obsidian-side logs right now). I can provide additional browser-side logs or test specific builds/settings if needed.

Request

Please advise whether this is a known issue in 1.12.x on Windows, and if there is a recommended workaround (e.g., reinstalling with the latest installer, specific setting, or a fix in a newer build). If there is a debug procedure that does not require collecting Obsidian-side developer console logs, I can follow it.

3 Likes
2

I am having the same issue with obsidian://daily Worked fine now won’t run if obsidian is already open.

3

Same behavior here.

Just adding environment info and that nothing gets logged in DevTools console.

SYSTEM INFO:
	Obsidian version: 1.12.1
	Installer version: 1.11.7
	Operating system: Windows 11 Pro for Workstations 10.0.26200
	Login status: logged in
	Language: en
	Catalyst license: insider
	Insider build toggle: on
	Live preview: on
	Base theme: dark
	Community theme: none
	Snippets enabled: 0
	Restricted mode: off
	Plugins installed: 0
	Plugins enabled: 0

RECOMMENDATIONS:
	none

Also happened with installer 1.11.4.

Happening with the packaged Obsidian.com and with the version that redirects for terminal outputs.

4

I am also having this happen in app version 1.12.1 in Firefox browsers (Floorp and LibreWolf) on Windows 10.

5

having the same issue but not just for obsidian://open. Same behavior when using a custom action that my plugin handles via registerProtocolHandler. This worked a few hours ago, and stopped working after updating obsidian.

If obsidian is open, the registeredProtoclHandler is never triggered, but if I close obsidian it causes obsidian to open

1 Like
6

Having the same issue for myself as well. Currently on version 1.12.1

Using clipper version 0.12

7

I have found the root cause, which is an unintentional change in the command line processing order where the URI is processed after checking if the user enabled CLI access.

In the next update (1.12.2) this should be fixed. In the meantime as a workaround, you can enable CLI (Settings - General - Advanced - Command line interface) to make it work again.

Sorry about that.

3 Likes
8

This is broken again for me with obsidian://daily

9

Oops, sorry - I was on 1.12.4 and upgraded to 1.12.5 and it’s working again. Thanks!