Open Link confirmation in Ghostty Nightly

[pilif]

While in general, I appreciate the need for confirming link clicks in the terminal, but I must ask - is there a way to turn this new dialog off, at least for some URL-schemes?

I do not need Ghostty ask me to confirm each and every file link emitted by my static analyzer that I have just run manually.

[tt-a1i]

No, not selectively in the current nightly.

The new macOS code opens http, https, mailto, and safe local file: URLs directly. Other schemes, such as editor-specific links, go through the confirmation dialog because they can launch an application through Launch Services.

The only related setting added by the change is:

link-osc8 = false

That turns OSC 8 hyperlinks off completely. It doesn't keep them enabled while skipping confirmation for chosen schemes.

This is the change that introduced the policy:

#13634

[pilif]

I wish there was a way to skip confirmations completely (I'm aware of the dangers) or to provide a list of protocols assumed to be safe

In this case, the phpstorm:// one will cause my IDE to open the file in question and jump to the line provided as the argument. I have configured the static analyzer to emit such URLs rather than file URLs because the IDE is not associated with these file types and I don't want to do that because the IDE is very much project-based and overkill for random single files.

I know I'm probably a case of XKCD 1172, but this change is a huge downgrade in usability for me

[pilif]

Would you accept a PR that adds a osc8-trusted-schemes config entry that allows the user to provide a comma separated list of trusted schemes?

Like

osc8-trusted-schemes=phpstorm://,vscode://

[joshbode]

Also affected by #13634 is that file:// URLs with the machine hostname preceding the path are rejected (with the dialog warning The target is not an absolute URL with a scheme), unless the hostname is localhost or empty, e.g.

file:///Users/josh/some_file.txt             # accepted
file://localhost/Users/josh/some_file.txt    # accepted
file://whiskeyjack/Users/josh/some_file.txt  # rejected, even though that's my machine

Including the hostname in OSC8 file:// URLs is a non-configurable convention followed by GNU ls --hyperlink and fd --hyperlink, delta, among others.

[XhstormR]

I encountered the same issue when using the fd-find command to search for local files; fd outputs paths in the format file://{host}{path}, and neither fd nor Ghostty offers a way to configure this behavior, resulting in the error:
"Ghostty Blocked This Link, The target is not an absolute URL with a scheme."

[brainsaysno]

+1 for a trusted-schemes setting (e.g. the osc8-trusted-schemes @pilif proposed above).

Note that as of 1.4.0 this no longer only affects OSC 8: "macos: treat links from unknown sources as untrusted" routes regex-matched links (link-url and custom link entries) through the same UntrustedURL policy, so link-osc8 = false is no longer a workaround, every non-http(s)/mailto/file link prompts.

My case: tooling that prints desktop-app deep links (linear://, slack://) many times a day. A per-scheme allowlist (scheme names, not prefixes) would keep the protection for unknown handlers while removing the prompt for ones I've explicitly trusted.