Link to the code that reproduces this issue

https://github.com/azu/next-16.2.1-router-replace-params-bug

To Reproduce

1. pnpm install && pnpm run build && pnpm run start
2. Open http://localhost:3099/page-a?foo=bar&test=true directly in browser (full page load)
3. Click "router.push('/page-b')" button — navigates to /page-b
4. Click "router.replace('/page-a')" button
5. Observe: URL becomes /page-a?foo=bar&test=true instead of /page-a

Summary

Current vs. Expected behavior

When calling router.replace("/page-a") with a path that has no query string, the URL should navigate to that exact path without any query parameters.

Instead, Next.js 16.2.2 restores query parameters from a previously cached navigation entry for that pathname. This affects window.location.href, useSearchParams(), and the browser address bar.

Works correctly on Next.js 16.1.6. Regression in 16.2.0+.

Provide environment information

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:54:55 PST 2026; root:xnu-12377.91.3~2/RELEASE_ARM64_T6031
  Available memory (MB): 65536
  Available CPU cores: 16
Binaries:
  Node: 22.9.0
  npm: 10.8.3
  Yarn: 1.22.22
  pnpm: 9.15.4
Relevant Packages:
  next: 16.2.2 // Latest available version is detected (16.2.2).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 6.0.2
Next.js Config:
  output: export

Which area(s) are affected? (Select all that apply)

Runtime

Which stage(s) are affected? (Select all that apply)

next start (local)

Additional context

• Works correctly on Next.js 16.1.6, broken on 16.2.0, 16.2.1, 16.2.2
• next dev works correctly — only the built static export is affected
• Both router.replace and router.push are affected
• Navigating to a different pathname clears params correctly; the bug only triggers when navigating to a pathname that was previously visited with query parameters
• Automated test included in the repo: pnpm test (requires Playwright)

Possibly related to #92152 (stale searchParams caching), which may share the same root cause in the router cache.