MacOS: Getting "accept incoming network connections" prompt dialog for thv frequently

[BobDickinson]

I get this dialog periodically (I've seen it a dozen times today) when running thv run commands, but not every time. In theory if you allow the app under firewall settings (which I've done) you're never supposed to see it again. That being said, there are people complaining about getting the dialog even when the app is allowed under firewall settings going back to 2016.

I have seen conjecture that binding to all interfaces, as the proxy appears to do, can contribute to this.

toolhive/pkg/transport/proxy/httpsse/http_proxy.go

Line 112 in 8b429e7

Addr: fmt.Sprintf(":%d", p.port),

I'm not sure if that's intentional (binding to external interfaces), but it seems like localhost / 127.0.0.1 might be more appropriate. If there is a use case for binding the proxy to an external interface, them maybe that should be configurable.

[rdimitrov]

@BobDickinson – Just a heads-up: I’ve opened a PR that should address this issue – #366. I wasn’t able to reproduce the problem locally, so if you have a chance to try it out on your end, that’d be really helpful. Appreciate it! 🙏

[BobDickinson]

@BobDickinson – Just a heads-up: I’ve opened a PR that should address this issue – #366. I wasn’t able to reproduce the problem locally, so if you have a chance to try it out on your end, that’d be really helpful. Appreciate it! 🙏

The PR looks good. Happy to give it a try.

Are you planning to release it, or do you need me to test a local build first?

[ChrisJBurns]

@BobDickinson If you could give a local build a try that would be amazing! @rdimitrov can't reproduce it on his mac unfortunately. I'll be testing it out on the Kubernetes Operator to ensure there's no regression there.

To build it locally, you should only need to run task install. If not, let us know and we can update the docs

[BobDickinson]

OK, well, good news / bad news (mostly bad news).

Good news: I verified (via netstat) that when no host name is provided it only binds to the internal interface (127.0.0.1).

Bad news: I still see the firewall warning. I tested with the new version (v0.0.33-3-g4c4daf6), got the warning, and verified that the pid for the proxy (the only module matching the name) was only listening on the expected 127.0.0.1 interface. So the code is working as intended, but the guess that listening on all interfaces is what caused the firewall messages was wrong. Even after adding the firewall approval for the new version, I still saw it on subsequent runs (as before). I then did a bunch of tests just manually doing run/stop over and over. It took about 50 tries, then the warring came back consistently. I wrote a Node.js test harness and when run from that it happens almost every test run (that could be because the parent test process is being rebuilt each time). It's possible that the fact that the port is being opened in a detached process is the issue. It's possible that code-signing would help. I really have no idea. I'll keep pondering.

More bad news: On my system, the node dns resolution resolves localhost to ::1 (the ipv6 interface) first, which means that's what node fetch uses. The MCP node module uses fetch for the SSE transport. So when I try to use the SSE transport to connect to the URL that ToolHive reports (http://localhost:xxxx/sse#tool) I get an ECONNREFUSED ::11:xxxx (where xxxx is the port) because the ToolHive proxy is no longer listening on the ipv6 loopback (when it was just doing :port it listened on both interfaces). So this change actually broke my app.

You could make the argument that it would be more correct to publish the bound 127.0.0.1 as the host from ToolHive (which would prevent this). So instead of:

CONTAINER ID   NAME        IMAGE                                               STATE     TRANSPORT   PORT    URL
21180dc0cbd5   fetch       toolhivelocal/uvx-mcp-server-fetch:20250512221955   running   stdio       36610   http://localhost:36610/sse#fetch

You would report:

CONTAINER ID   NAME        IMAGE                                               STATE     TRANSPORT   PORT    URL
21180dc0cbd5   fetch       toolhivelocal/uvx-mcp-server-fetch:20250512221955   running   stdio       36610   http://127.0.0.1:36610/sse#fetch

Alternatively you could special case localhost and listen on 127.0.0.1 and ::1.

Sorry for opening this can of worms.

[rdimitrov]

Thanks for the detailed investigation — this is super helpful! 🚀

The good news is definitely reassuring: it confirms the code is correctly binding to 127.0.0.1 as intended, which rules out one major concern. Appreciate you verifying that so thoroughly.

As for the firewall warnings, it's unfortunate that they persist. It sounds like we’ve ruled out interface binding as the root cause, which is progress in itself, even if it’s not the result we hoped for.

Regarding the ::1/localhost issue — great catch. I'm responsible for this by commenting out the IPv6 port binding. I think for the time being enforcing IPv4 by moving away from localhost(I missed it resolves to both IPv4 and IPv6) to 127.0.0.1 could be the simplest solution so far. I will update the PR to do that so it doesn't break your node testing above and leave us only with the bad news 😃

Of course, later we can add IPv6 support back, i.e. if a hostname is configured we'll have to lookup what addresses it resolves to and do the port binding for both IPv6 and IPv4 (whichever is present of course).

No worries at all about raising this — getting feedback from actual users is what we want and it’s great to have it on the radar now. Thanks again for the thoughtful deep dive 🙏

edit: I've just updated the PR to enforce IPv4 binding for localhost 👍

[ChrisJBurns]

Nothing to add here from me but really appreciate the troubleshooting @BobDickinson! ❤ It's analysis like yours that lays the ground-work for tools that work in all scenarios!