[jmathai]

I only learned about Native Messaging this week.

I've been hacking away at a browser-based tool that uses anthropic APIs on the backend. But what I really want is for the browser to talk to my local claude becuase I have MCPs, skills, network access for a bunch of things.

I started with a little proxy installed on my computer that the browser can call but knew it would never pass any security review. The alternative I didn't originally know about was Native Messaging.

It's a fairly benign way to let a browser talk to and execute commands on your computer. But doing it without disclosing is, I agree, very bad.

(tool I'm hacking away at needs to talk to local claude and acli: https://withlattice.com)

[flutas]

Check out the hidden --sdk-url CLI option for claude.

It turns it into a websocket endpoint you can just connect to (iirc it's what the Python SDK does under the hood).

detail: https://medium.com/coding-nexus/i-found-a-hidden-flag-in-cla...

[jmathai]

That’s very cool - did not know about that.

Listening for commands to run seems similarly dangerous as having a proxy installed!

[vbezhenar]

Nothing wrong about running http server on your localhost and talk to it. A lot of applications do that. The best thing: you don't need to appease extension appstores, you just ship.

The only nuance is that recent chrome versions treat it as a separate permission, so user need to allow it once.

Yes, native messaging is the "proper" way to do that, but, again, nothing wrong with localhost http server. You have origin headers so you can allow access from your whitelisted website, if necessary.

[horsawlarway]

I'd argue native messaging is much more secure.

You only have origin headers that you can trust if the traffic originated from a browser you trust.

Anything else on the machine that can send network traffic can now hook into your service. Which is quite a bit looser than being able to start a new process running that native message host and hook into its stdio.