Public access links

Understand what a reachable host link provides and how access is authorized.

A public link provides an internet route to an agent hosted by Mellow on a Mac. It does not deploy that agent to a cloud machine, keep a sleeping Mac online, or automatically create a browser chat application. The client using the link still needs the supported protocol and a valid access grant.

Enable a route deliberately

Open the selected agent's network or sharing controls and enable its relay connection. Review the confirmation, then wait for the public route to become ready. Copy the URL displayed by the running app rather than assembling an address from an old example; the deployment determines its domain and path.

Test the connection with a supported client and a narrowly scoped access key. A route that answers a health request is reachable, but that does not prove an authenticated agent task can run. Verify an actual harmless request before using the route for a workflow.

Mobile's Reach From Anywhere can manage the relay routes needed by the paired device. Use that control for the companion workflow rather than manually copying recovery information.

What the link does and does not provide

The host must be online, awake enough to serve requests, and running Mellow. Provider readiness and tool approvals remain host concerns.

Understand the transport boundary

Mellow peer clients use Secure Channel to encrypt the inner request between endpoints. The relay forwards that encrypted payload without reading its content. It can still observe routing information, connection timing, and traffic size.

Ordinary HTTPS API traffic has a different boundary: HTTPS terminates at the service handling that endpoint. A third-party client does not gain peer encryption merely by using the same public hostname. Check the client's protocol before sending sensitive content.

Protected remote agent-execution routes require the peer protocol. A client that receives an upgrade-required response should implement or update that protocol rather than disabling the protection.

One active host for an agent address

An agent route is associated with its serving host. If the same agent identity is restored and served by another Mac, the newer tunnel can supersede the old one. A status such as On another device means the original host should not endlessly compete for that address.

Choose the intended host before using Serve From This Mac or toggling the route. Separately created agents with different identities are distinct even when their display names match.

Turn off access

Disabling a relay stops that public route. Revoking a client grant prevents that client from authenticating. These are different controls: use grant revocation to remove a particular client, and route disablement to stop serving the agent through that link.

A Cloud workspace connection is separately authenticated. Signing out of Cloud is not a substitute for disabling a local agent's public route.

Troubleshooting

No public address appears: check relay configuration, network access, host process health, and the route probe result.

Unauthorized: inspect the grant's scope and expiry. Reachability is already a different stage from authorization.

Upgrade required: update the connecting peer or use the supported Secure Channel implementation.

Works locally but not remotely: check the public route and relay status independently of local discovery.

Stops when the Mac sleeps: review host power settings and Mobile's keep-awake option where applicable. A relay cannot execute the Mac's work itself.

On another device: determine which restored host is intentionally serving the agent before taking the route back.

For ordinary local integrations, prefer the loopback server route described in Connecting applications when remote access is unnecessary.