Claude review:

PR #6924: Fix theme dev shortcut to editor tracking non page requests

Summary: Good bug fix. The approach of using Sec-Fetch-Mode: navigate to distinguish real page navigations from AJAX/fetch requests is the right solution. Two issues need addressing before merge.

Issue 1: console.log left in production code

packages/theme/src/cli/utilities/theme-environment/html.ts — the new isNavigationRequest function contains a console.log:

function isNavigationRequest(event: H3Event): boolean {
  console.log('Sec-Fetch-Mode:', event.headers.get('sec-fetch-mode'))
  return event.headers.get('sec-fetch-mode') === 'navigate'
}

This looks like a debug leftover. It should either be removed entirely or replaced with outputDebug() (which is already imported and used elsewhere in this file) if the logging is intentionally desired.

Issue 2: Behavioral regression — lastRequestedPath will never be set when the header is missing

The old code unconditionally set lastRequestedPath on every request. The new code only sets it when Sec-Fetch-Mode is exactly "navigate". This means if the header is absent entirely (e.g., older browsers, curl, non-browser clients, or requests made with mode: 'no-cors'), lastRequestedPath will never get updated and will stay at its initial empty-string value.

The existing test at line 42 ('sets lastRequestedPath to the rendering URL') is updated in the PR to pass {'sec-fetch-mode': 'navigate'}, but there's no coverage for the case where the header is completely absent (vs. present but non-navigate). Consider whether the check should be:

function isNavigationRequest(event: H3Event): boolean {
  const mode = event.headers.get('sec-fetch-mode')
  // If the header is missing (non-browser client), default to treating it as navigation
  return mode === null || mode === 'navigate'
}

This would preserve the original behavior for clients that don't send Sec-Fetch-Mode while still filtering out AJAX requests (which always send the header with a non-navigate value like cors, no-cors, or same-origin). The current implementation is probably fine for the real-world use case (browsers always send this header), but it's a subtle behavioral change worth being intentional about.

Minor notes

• Changeset is present and correctly scoped — good.
• Tests cover both the positive case (navigate) and negative case (cors) — good.
• The createH3Event helper was nicely extended to accept headers.

Verdict: Fix the console.log, consider the missing-header edge case, and this is good to ship.

Thanks for the claude review @tyleralsbury. 🤦 on the console.log. That's been fixed. As for the part about the headers. This header should be available on all modern browsers (at least 2023 onwards). Since users are navigating links via browser, I would expect this is okay. Happy to hear if there are any differing opinions.

Coverage report

Test suite run success

3789 tests passing in 1448 suites.

Report generated by 🧪jest coverage report action from ae77bc6

🤖 Code Review · #projects-dev-ai for questions
React with 👍/👎 or reply — all feedback helps improve the agent.

✅ Complete - No issues