Repository navigation
[Bug]: Proxy cannot start when bound to a Tailscale IP and no proxy is running ("Proxy ownership is unverified; startup refused") #8045
Description
Summary
With hostname set to the machine's Tailscale IPv4 (e.g. 100.x.y.z) and the proxy NOT running, ocx start / ocx restart / the service wrapper all fail forever with:
Proxy ownership is unverified; startup refused. PID record and recovery journal were preserved. Retry when the owner can be verified.
The service wrapper loops every 5s with the same error; the proxy never comes back. Reproduced on 2.96.0 (dev). The same machine starts fine on 2.93.0, which predates #7851.
Cause (diagnosed, not yet fixed)
recoverStartJournalAfterOwnerRecheck (src/cli/start-owner-fence.ts, added by #7851) throws unless observeProxyLiveness(START_OWNERSHIP_LIVENESS).kind === "absent". For a configured non-loopback, non-wildcard bind host, discoverLiveProxy (src/server/proxy-liveness.ts) probes http://<tailscale-ip>:<port>/healthz through proxyIdentityAtObserved. When nothing listens, connecting to the machine's own Tailscale IP times out instead of being refused (observed: curl to 100.x.y.z:10100 fails after 2003 ms, while 127.0.0.1:10100 is refused immediately). isConnectionRefused is false for a timeout, so sawUnknown = true and the endpoint is reported "unknown", never "absent". Startup is then refused permanently.
Reproduce
hostname= Tailscale IPv4 in~/.opencodex/config.json, role hub, Windows 11.- Stop the proxy / service, so nothing listens on the port.
ocx start-> the error above.
Expected
When nothing is bound to the configured address, startup should proceed. Suggestions: treat a timeout against an address that belongs to a local interface as "dead" when a loopback probe is refused, or confirm absence by attempting to bind hostname:port (success => no owner), instead of treating every non-refused failure as "unknown".
Related
#7851 (introduced the check), #7871 / #7874 (post-merge fixes for the same area, not covering this case).
Activity
github-actions commentedon Oct 31, 2026
Issue closed: insufficient detail
Thanks for taking the time to submit this issue. It was closed automatically because the structured report is missing information needed to evaluate or reproduce it.
Please edit the issue to add:
See the Contributing guide for details.
Once the report passes the automated checks, it will be reopened automatically unless a maintainer has changed its state.
Ingwannu commentedon Oct 31, 2026
The technical report and linked #8046 identify a concrete startup-liveness problem; this closure is the quality bot's missing-field result, not a shipped fix. Please put the existing steps under the form's exact
### Reproductionheading (currently### Reproduce) and complete the current client/version/OS fields so the validator can reopen it.#8046 is still Draft. My exact-head review independently reproduced an IPv6 bind-host spelling problem and requested the focused fix plus test-layout/owning lifecycle documentation updates. The fix must preserve unknown on a failed bind and must not delete PID/journal state merely because an HTTP probe timed out. I did not start/restart a real proxy, alter the Tailscale setup or treat this issue as resolved.
fix(start): bind-prove the raw IPv6 address within the discovery dead…