From 890f63bf7649660a196ceabdeb642490dcfcecdc Mon Sep 17 00:00:00 2001
From: Steve Krisjanovs <steve.krisjanovs@gmail.com>
Date: Wed, 1 Jul 2026 10:47:43 -0400
Subject: [PATCH] fix(web): redirect to sign-in on 401, instead of failing
 silently
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Follow-up to fix/loopback-auth-bypass. That fix made 401 a real, reachable
response for the picker's own client JS for the first time — before it,
a request from a trusted-looking client essentially never got a 401, so
nothing in the browser code had to handle it. Two client-side gaps as a
result:

- The picker's poll loop (GET /api/sessions every 3s) just caught the
  resulting error and flipped the status dot to "offline" forever, with
  no indication the real problem is "sign in again" and no way to get
  there from the page.
- The session-attach page's WS reconnect loop had the same problem, but
  worse: browsers don't expose a rejected WebSocket handshake's HTTP
  status at all, so there's no way to even detect "this failed because
  of auth" from the WS event alone.

Fix: install a global fetch() wrapper in both the picker's script and the
session-attach page's script — any 401 redirects to
/login?returnTo=<path> instead of letting the caller's existing catch
block just show a generic failure. For the WS case, the reconnect loop's
onclose handler now also fires a throwaway authed fetch
(GET /api/sessions) alongside scheduling the reconnect; if the session is
actually invalid, that fetch 401s and the wrapper redirects the whole
page, tearing down the doomed reconnect loop within one cycle instead of
retrying forever.

Verified live: loaded the picker with a valid v2 session cookie, cleared
the cookie mid-session (simulating expiry/revocation while a tab stays
open), and confirmed the next poll cycle (~3s) navigated the browser to
/login?returnTo=%2F with the correct page title, rather than sitting on
"offline".

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Au8T9RPCb6wbgiEecQrBfZ
---
 packages/llmux/src/daemon/web/server.ts | 43 +++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/packages/llmux/src/daemon/web/server.ts b/packages/llmux/src/daemon/web/server.ts
index 00f17eb..5f64112 100644
--- a/packages/llmux/src/daemon/web/server.ts
+++ b/packages/llmux/src/daemon/web/server.ts
@@ -794,6 +794,25 @@ ${renderHeader({
 </footer>
 <script>
 (function(){
+  // Any 401 anywhere in this SPA means the session cookie is missing or
+  // expired. Before the loopback-trust auth bypass was removed, a request
+  // from a trusted-looking client essentially never got a 401, so nothing
+  // here ever had to handle it — the poll loop's catch block just flips
+  // the status dot to "offline" forever, with no indication the real
+  // problem is "sign in again" and no way to get there. Wrap fetch once,
+  // globally, so every call site's existing catch block still fires (this
+  // throws, same as any other fetch failure) but the page also redirects
+  // to sign-in instead of being stuck.
+  const _fetch = window.fetch.bind(window);
+  window.fetch = async function(input, init){
+    const r = await _fetch(input, init);
+    if (r.status === 401 && !location.pathname.startsWith('/login')){
+      location.href = '/login?returnTo=' + encodeURIComponent(location.pathname + location.search);
+      throw new Error('unauthorized — redirecting to sign in');
+    }
+    return r;
+  };
+
   const container = document.getElementById('list-container');
   const dot = document.getElementById('refresh-dot');
   const label = document.getElementById('refresh-label');
@@ -2682,6 +2701,23 @@ function sessionPage(name: string): string {
 <script src="${XTERM_FIT_JS}"></script>
 <script>
 (function(){
+  // Same fetch wrapper as the picker's script (see fix/loopback-auth-bypass):
+  // any 401 means the session cookie is missing or expired — redirect to
+  // sign-in instead of leaving this page's one fetch call (respawn) fail
+  // silently. The WS attach connection itself can't be checked this way —
+  // browsers don't expose a rejected WS handshake's HTTP status — so an
+  // unauthorized reconnect loop below also fires a throwaway authed fetch
+  // to surface the same redirect instead of "reconnecting…" forever.
+  const _fetch = window.fetch.bind(window);
+  window.fetch = async function(input, init){
+    const r = await _fetch(input, init);
+    if (r.status === 401 && !location.pathname.startsWith('/login')){
+      location.href = '/login?returnTo=' + encodeURIComponent(location.pathname + location.search);
+      throw new Error('unauthorized — redirecting to sign in');
+    }
+    return r;
+  };
+
   const name = ${jsonName};
   const version = ${jsonVersion};
   const dot = document.getElementById('title-dot');
@@ -2812,6 +2848,13 @@ function sessionPage(name: string): string {
         return;
       }
       if (everConnected) setStatus('closed', 'disconnected — reconnecting');
+      // The WS close event never carries the handshake's rejected HTTP
+      // status (browsers don't expose that), so an unauthorized attach
+      // would otherwise just say "disconnected — reconnecting" forever.
+      // Fire a throwaway authed fetch — the wrapper above redirects to
+      // sign-in if it 401s; any other outcome just falls through to the
+      // normal reconnect.
+      fetch('/api/sessions', { cache: 'no-store' }).catch(function(){});
       scheduleReconnect();
     };
     ws.onerror = function(){