MacOS hostname drift issue

[swickson]

On macOS, the system hostname can silently change between reboots or network transitions. This is particularly common in setups where:

• The dock and wireless network are on separate VLANs, each assigning a different IP and hostname
• Rebooting away from the home network causes macOS to revert to the default computer name (e.g. macbook-dock.internal → macbook-wireless.internal)

When this happens, agents in the registry retain the old hostname as their hostId. The current normalizeHostId() function only performs basic string normalization (lowercase, strip .local suffix) — it has no awareness that a stale hostname still refers to the local machine.

Impact

• Broken mesh visibility — remote peers can't match local agents to the correct host
• AMP messages fall back to relay instead of direct mesh delivery
• Wake/hibernate failures — agents with stale hostIds are treated as "remote" and the server proxies to itself, returning "unreachable"
• Startup failures — createSession() can inherit a stale TMUX env var from a parent tmux session that no longer exists after reboot

Proposed fix

• normalizeHostId() and needsHostIdNormalization() should call isSelf(), which checks the hostname against all known aliases and local IPs in the hosts config. If a hostId is recognized as this machine but doesn't match the current hostname, it should be automatically migrated to the canonical self ID.
• createSession() should unset the TMUX env var to prevent stale parent socket errors.
• Additionally, validateHosts() should preserve old hostnames as aliases during self-host migration, and registerPeer()/syncWithAllPeers() should detect and migrate peer hostname changes instead of silently treating them as "already known."

We have a working fix in our fork and are happy to open a PR if there's interest.

[jpelaez-23blocks]

Fixed in v0.26.6 (PR #320)

What was the problem

macOS can silently change your hostname via DHCP or Bonjour collision (e.g., mac-studio → mac-studio-2). When this happens, isSelf() — the core function that determines "is this host entry me?" — compares against os.hostname() and fails to match the old hostname stored in hosts.json. The machine loses its identity in the mesh network: it appears as a ghost remote peer, sync breaks, and sessions route incorrectly.

How we fixed it

We added a cached alias lookup as the last fallback in isSelf(). At startup, loadStoredSelfAliases() reads hosts.json and identifies the self host entry using a two-pass strategy:

1. Pass 1 — hostname match (guaranteed safe): Find a host whose id matches the current OS hostname or legacy 'local'.
2. Pass 2 — IP alias match (hostname drift case): If no hostname matches, find hosts whose stored aliases contain one of our current IPs. Only trust this if exactly one host matches — if ambiguous (e.g., two hosts share an IP after DHCP reassignment), we skip and don't guess.

Once the self host is identified, its id and all aliases are cached. isSelf("old-hostname") then returns true because the old hostname is in the cache.

What we intentionally did NOT change

• No changes to migrateHost(), validateHosts(), registerPeer(), syncWithAllPeers(), or session routing
• No active host ID rewriting or migration — the old hostname stays as-is in hosts.json
• No IP-only matching without the exactly-one-match safety guard

The fix is a single file (lib/hosts-config.ts), 49 lines added.

Thanks

Thank you @bikramSingh91 for reporting this with clear reproduction steps. This is a real macOS behavior that's well-documented but easy to miss in networked applications. Your report helped us identify and fix it cleanly.