Link to the code that reproduces this issue

https://github.com/gurkerl83/next-pages-client-stale-manifest-repro

To Reproduce

1. Clone the reproduction repository.
2. Install dependencies with pnpm install.
3. Start the app in development with pnpm dev.
4. Open /docs/start in the browser.
5. Confirm the handler route is shown as missing.
6. Click Materialize example.
7. Click Go to example so the navigation happens client-side.
8. Observe that the request is rewritten by proxy.ts from /docs/example to /docs/_handlers/example.
9. Observe that the server can already serve /docs/_handlers/example, but the browser can still throw Expected component 'RewrittenOnlyComponent' to be defined.
10. Hard-refresh /docs/example and observe that the page then renders correctly.

If you want to retry the exact first-hit scenario, click Reset handlers, restart pnpm dev, and open /docs/start again.

Current vs. Expected behavior

Following the steps above, I expect the client-side navigation to adopt the rewritten page component once the server can already serve the rewritten handler page.

Instead, on the first client-side navigation in development:

• the browser starts from the catch-all page at /docs/start
• the handler page /docs/_handlers/example is created afterward
• proxy.ts rewrites the client-side /_next/data/... request for /docs/example to /docs/_handlers/example
• the server can already serve the rewritten handler page and return the correct data
• but the client can still keep rendering the previously loaded catch-all page component
• the catch-all page then tries to render rewritten handler data and throws Expected component 'RewrittenOnlyComponent' to be defined

A hard refresh on /docs/example works, which suggests the rewritten handler route is valid on the server but the client-side route adoption is stale during the first rewritten data transition.

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.6.0
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: 10.30.2
Relevant Packages:
  next: 16.2.1-canary.2 // Latest available version is detected (16.2.1-canary.2).
  eslint-config-next: N/A
  react: 19.2.4
  react-dom: 19.2.4
  typescript: 5.9.3
Next.js Config:
  output: N/A

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

Pages Router, Turbopack

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

next dev (local)

Additional context

This issue was discovered while building next-slug-splitter, which uses proxy.ts to create handler pages on demand during development instead of generating all routes upfront at startup.

The sequence that triggers the bug:

1. Browser loads a catch-all page (e.g. /docs/start)
2. A handler page (e.g. /docs/_handlers/example) is materialized after boot
3. proxy.ts rewrites a client-side navigation to the new handler page
4. Server returns the correct rewritten data
5. Client still renders the old catch-all component — stale manifest

This blocks any tool that wants to offer lazy, on-demand route generation in dev mode via proxy-based rewrites.

The repro sets skipProxyUrlNormalize: true only so proxy.ts can observe the raw /_next/data/... request shape — it is not the suspected source of the bug.

Relevant client code:

• next/dist/client/page-loader.js
• next/dist/shared/lib/router/router.js

The repro also sets skipProxyUrlNormalize: true, but that is only there so proxy.ts can observe the raw client-side /_next/data/... request shape. It is not the suspected source of the bug.