[BUG] Desktop (macOS): main process repeatedly navigates the Code tab to nonexistent /epitaxy/n9, replacing the window with "Page not found"

Summary

In the Claude desktop app's Code tab, the main window repeatedly navigates by itself to /epitaxy/n9, a route that does not exist. The window then shows the full-screen "Page not found … Go back home" page. This interrupts whatever the user is doing, with no user input involved. Over one day it happened several dozen times, roughly every 4–15 minutes, while code sessions were open.

The navigation does not start in the web app. It arrives over the desktop bridge's Navigation.navigate IPC event, which the main process sends.

Environment

• Claude desktop 2.19675.1 (macOS, arm64)
• macOS 26.5 (25F71)
• Web build reported by the app: c0da11fc31
• Code tab, several local Claude Code sessions open

What happens

1. With a local code session open, the window jumps from /epitaxy/local_<uuid> to /epitaxy/n9, with no click or keypress.
2. The router can't match n9 to a session, so the not-found boundary renders (NEXT_NOT_FOUND) and the whole window turns into "Page not found". The session is still there; the user has to click "Go back home" and reopen it.

The target is always exactly /epitaxy/n9, never anything else.

Evidence

I installed a diagnostic hook from DevTools. It wraps the TanStack router's history.push and router.navigate and records the caller. Every occurrence has the same router call:

router.navigate({ to: "/epitaxy/n9", search: {}, hash: "", resetScroll: true })

and the same call stack (production bundle names):

Lr.commitLocation              vendor-router-C87f5xnt.js:1:43305
Lr.buildAndCommitLocation      vendor-router-C87f5xnt.js:1:43927
Lr.navigate                    vendor-router-C87f5xnt.js:1:44754
(anonymous)                    vendor-router-C87f5xnt.js:1:68961
Object.o [as push]             shared-common-mcp-msg-1-BMNBr3BE.js:2:49769
p                              shared-23-BEJIxVYC.js:10:161245
(anonymous)                    shared-23-BEJIxVYC.js:10:161484   <- dt.onNavigate(...) subscriber
n                              app.asar/.vite/build/mainView.js:1  <- Navigation.onNavigate preload listener
emit / onMessage               node:electron sandbox_bundle         <- ipcRenderer message

The listener in shared-23 is the onNavigate subscription, which calls e.push(path). The preload side is:

onNavigate(t){ let n=(e,n)=>t(n), r=A+"Navigation_$_navigate"; return e.ipcRenderer.on(r,n), ... }

So the main process is emitting Navigation.navigate("/epitaxy/n9"), the same path notification click-throughs use (getDispatcher(webContents)?.dispatchNavigate(getSessionRoute(id))). It looks like a session route is being built from an ID that is not a real session ID.

Timing

• Several occurrences land within ~30 ms of the window regaining focus. Main log at the same second: [SkillsPlugin] Window focused — polling now.
• Others occur at idle, with no input for many minutes.
• Early in the day they only happened while one particular session was open. Later they happened with other sessions open too, so it doesn't look tied to one session's content.
• main.log has no Dispatching navigation or handoff: line at those times, so the sender is one of the dispatchNavigate call sites that does not log.
• Around many occurrences main.log shows setFocusedSession null, my-access out-of-band refetch requested, and local_star-sync-notice isStarred.

One time, two navigations to /epitaxy/n9 came 3 s apart.

Workaround confirmation

Dropping only navigations matching ^/epitaxy/n\d+$ in router.history.push fully removed the symptom. Over 4 hours the hook blocked 38 such navigations, and the not-found screen never appeared. Every other navigation went through normally.

Expected

• The main process should never dispatch a session route for an ID that doesn't resolve to a session.
• Ideally, an unknown /epitaxy/<id> should not replace the whole window with the global not-found page while a session is open.