abhigyanpatwari/GitNexus · warning

[gitnexus serve] Bound to a wildcard address (${boundHost});

Error message

[gitnexus serve] Bound to a wildcard address (${boundHost}); browser write routes ${admitted}

What it means

When gitnexus serve binds a wildcard address (normalizeBoundHost cannot normalize it), this startup warning states exactly which origins browser write routes accept: loopback only, or loopback plus the single PUBLIC_ORIGIN host when that is configured. The point is that a wildcard bind widens reachability but does not widen browser-write acceptance, and the message tells you how to widen it deliberately.

Source

Thrown at gitnexus/src/server/middleware.ts:288

      { [PUBLIC_ORIGIN_ENV]: raw, hostname: publicOrigin.hostname },
      `[gitnexus serve] Browser write routes also accept origins on ${publicOrigin.hostname}.`,
    );
  } else if (raw) {
    logger.warn(
      { [PUBLIC_ORIGIN_ENV]: raw },
      `[gitnexus serve] Ignoring ${PUBLIC_ORIGIN_ENV}=${raw} — not a single reachable origin, ` +
        `so it admits nothing. Set it to one host, optionally with a scheme and a port.`,
    );
  }

  if (!boundHost || normalizeBoundHost(boundHost) !== undefined) return;
  const admitted = publicOrigin
    ? `accept loopback origins (localhost/127.0.0.1/[::1]) and ${publicOrigin.hostname} via ` +
      `${PUBLIC_ORIGIN_ENV}.`
    : `accept only loopback origins (localhost/127.0.0.1/[::1]). To admit writes from a specific ` +
      `LAN address, bind --host <that-address> instead of a wildcard; to admit them from a ` +
      `public origin, set ${PUBLIC_ORIGIN_ENV} to it.`;
  logger.warn(
    { host: boundHost },
    `[gitnexus serve] Bound to a wildcard address (${boundHost}); browser write routes ${admitted}`,
  );
}

/** Loopback + RFC1918 + link-local: the hops a self-hosted install sees. */
export const DEFAULT_TRUST_PROXY = 'loopback, linklocal, uniquelocal';

/** Overrides {@link DEFAULT_TRUST_PROXY}; a public cloud LB needs it set. */
export const TRUST_PROXY_ENV = 'GITNEXUS_TRUST_PROXY';

/**
 * Sanity ceiling on a hop count, well past any real proxy chain — it exists to
 * catch a digit string long enough to overflow to `Infinity`, not to make any
 * value under it safe. The correct hop count is the exact number of proxies you
 * control; each extra hop hands the caller one more entry of the chain.
 */
export const MAX_TRUST_PROXY_HOPS = 16;

View on GitHub (pinned to aac7515d2a)

Solutions

  1. Bind to the specific address that needs access: gitnexus serve --host 192.168.1.10
  2. Keep the wildcard bind but set GITNEXUS_PUBLIC_ORIGIN to the one origin that needs browser writes
  3. Leave as-is when only loopback writes are intended: the wildcard then only widens read reach

Example fix

# before
gitnexus serve --host 0.0.0.0        # writes: loopback only (+ this warning)

# after
gitnexus serve --host 192.168.1.10   # writes from that interface's origin accepted
Defensive patterns

Strategy: validation

Validate before calling

const WILDCARDS = new Set(['0.0.0.0', '::', '']);
if (boundHost !== undefined && WILDCARDS.has(boundHost)) {
  // Expect the wildcard-bind warning: browser write routes stay
  // loopback(+PUBLIC_ORIGIN)-only. Decide deliberately:
  //   bind --host <specific address>  OR  set GITNEXUS_PUBLIC_ORIGIN.
}

Type guard

function isWildcardBind(host?: string): boolean {
  return host === undefined || host === '' || host === '0.0.0.0' || host === '::';
}

Prevention

When it happens

Trigger: Running gitnexus serve --host 0.0.0.0 (or '::') at startup — typical in Docker or port-publishing setups. Read routes serve every interface; write routes stay loopback(+PUBLIC_ORIGIN)-only.

Common situations: Containerized deployments publishing port 4747 with a wildcard bind; users then surprised that write requests from LAN browsers are refused by CORS despite the server being reachable.

Related errors


AI-assisted analysis of abhigyanpatwari/GitNexus@aac7515d2a (2026-08-20). Data as JSON: /api/errors/fb8f1514ffa9c941. Report an issue: GitHub.