v0.32.4

Fixes a first-run trap that leaves new sites unreachable, and the stale state that kept their URLs showing a port long after everything was configured.

Fixes

A site created from an app is no longer born unreachable. Setting up a site writes an /etc/hosts entry and trusts a certificate, and both need admin rights. From a terminal you get the macOS password dialog and it just works. From an app — anything driving agent-local through its API — the daemon could not ask, the entry was never written, and the site was reported as created and running while its domain resolved to nothing. The failure existed only as a passing progress message.

Creating, attaching and importing a site can now be asked to show that password dialog, and so can doctor_fix, so a client can finish setup or repair it from inside the app. It stays off unless asked, so nothing pops a dialog on an unattended machine.

A failed /etc/hosts write is never swallowed again. Renaming a site and creating a branch preview discarded the result entirely: the new domain simply never resolved and nothing said why. Both now report it, alongside the setup paths that already did.

GET /status reports setup state. Clients get setup: {root, bare_urls, ok, detail, fix} — enough to finish setup before creating the first site rather than discovering the gap as a site that does not load.

The bare-URL alias is re-checked instead of assumed. Whether the portless 127.0.0.2 address is available was cached for the lifetime of the daemon, and a daemon that first looked before the alias existed believed it was missing forever. Everything downstream follows from that: URLs kept their :10443 port, and new hosts entries were written to 127.0.0.1 instead of the alias, so bare URLs would not have worked even once the alias came up. Restarting the daemon was the only cure. A positive answer is still cached; a negative is now re-checked within seconds.

Install

brew install jefrontv/tap/agent-local

Already installed? agent-local update