resolver identity change permanently disables the hook

When the resolver prop changes reference (e.g., during a session reload that re-creates the App subtree), React will run this effect's cleanup followed by a fresh effect invocation. The cleanup sets cancelled = true and clears all timers — but the fresh invocation finds startedRef.current === true and returns immediately without re-establishing any timers. The update check is silently dead for the rest of the session.

In the current production code path resolver is always the module-level resolveStartupUpdateNotice (a stable reference), so this never fires. But the hook's API contract does not document or enforce this constraint, and a future caller who wraps the resolver in an anonymous function would trigger a hard-to-debug failure.

The fix is to either (a) reset startedRef.current = false in the cleanup so the effect can restart if its dependencies change, or (b) hold the resolver in a useRef so it is always current without being a reactive dependency:

const resolverRef = useRef(resolver);
resolverRef.current = resolver;

useEffect(() => {
  if (startedRef.current || !enabled || !resolverRef.current) {
    return;
  }
  // ... use resolverRef.current() inside runUpdateCheck
}, [enabled]); // resolver intentionally not a dep

inFlight flag never resets on a hanging fetch

The inFlight guard prevents overlapping checks, which is correct. However, fetch has no built-in timeout. If the npm registry is reachable but extremely slow and the TCP connection never closes, the promise returned by resolver() may hang indefinitely. inFlight stays true for the entire session and every interval tick (at the 6-hour boundary) returns early, so the notice can never appear.

Consider wrapping the fetch call in AbortController + setTimeout to enforce a reasonable upper bound (e.g. 5 s), or propagate the signal via UpdateNoticeDeps:

const controller = new AbortController();
const timeoutId = setTimeout(() => controller.abort(), 5_000);
try {
  const response = await fetchImpl(DIST_TAGS_URL, { signal: controller.signal });
  ...
} finally {
  clearTimeout(timeoutId);
}

Alternatively, wrapping the entire resolver() call in Promise.race([resolver(), timeoutPromise]) inside the hook achieves the same effect without touching updateNotice.ts.

Dev/unknown builds always trigger the notice

resolveCliVersion() returns "0.0.0-unknown" when no package.json is found (e.g., running from source, CI, or an unpackaged dev build). isPrereleaseVersion("0.0.0-unknown") matches the pattern /^\d+\.\d+\.\d+-[0-9A-Za-z.-]+$/, so isComparableInstalledVersion returns true. Since "0.0.0-unknown" is semver-less-than any real release, isNewerVersion returns true for every published version, and the notice fires on every dev-mode startup.

A simple guard at the top of selectUpdateNotice would suppress this:

function selectUpdateNotice(installedVersion: string, distTags: ParsedDistTags): UpdateNotice | null {
  if (installedVersion === "0.0.0-unknown") {
    return null;
  }
  if (!isComparableInstalledVersion(installedVersion)) {
    return null;
  }
  // ...
}

Or you could integrate this into isComparableInstalledVersion directly.

Missing test coverage for several important paths

The existing tests cover the happy-path variants well, but a few important branches are untested:

1. Already up-to-date: no test verifies that resolveStartupUpdateNotice returns null when the installed version equals (or is newer than) the latest dist-tag. This is the most common runtime outcome and the most important invariant.

2. Non-OK HTTP response: there is a test for a thrown error but none for a response.ok === false case (e.g. a 404 or 503 from the registry). The if (!response.ok) return null branch is completely uncovered.

3. Prerelease install where latest is the higher update: the test "beta installs choose the higher newer version" only covers the scenario where beta wins the comparison. There is no test for when latest is the higher of the two newer versions for a prerelease user.

4. Unknown/dev version string: no test asserts the behaviour when resolveInstalledVersion returns "0.0.0-unknown" or another non-standard string (see related comment on selectUpdateNotice).