diff --git a/main.js b/main.js
index 43cebfd4..03570a43 100644
--- a/main.js
+++ b/main.js
@@ -1353,18 +1353,13 @@ function loadSession() {
     return { tabs: urls.map((url) => ({ url, title: "", favicon: null })), active };
   } catch { return empty; }
 }
-// Session restore, FULLY LAZY: nothing navigates at launch. Every restored
-// tab — including the one that was active at close — comes up as a dormant
-// WebContentsView in the strip, painted from the saved title + favicon, and
-// only triggers a page load when the user asks for it specifically (clicks
-// the chip, hits reload, types in the URL bar). This drops the whole startup
-// renderer load to zero page renderers (chrome.html + the overlays + the
-// strip only), so launch is near-flat whether the session has 2 or 50 tabs
-// and the RAM-at-launch footprint is just the chrome plus the strip —
-// a saved heavy page doesn't come back as a 500 MB renderer the user
-// didn't even ask to see. The previously active tab stays highlighted in
-// the strip so the user can one-click it back; its content area sits with
-// the tab's solid background until that happens.
+// Session restore, lazy except for the page on screen: only the tab that was
+// active at close loads at launch. Every other restored tab comes up as a
+// dormant WebContentsView in the strip, painted from the saved title +
+// favicon, and loads only when the user activates it (clicks the chip, hits
+// reload, types in the URL bar). Launch therefore costs one page renderer
+// whether the session has 2 or 50 tabs, and a saved heavy page in the
+// background doesn't come back as a 500 MB renderer nobody asked to see.
 function restoreTabs() {
   const saved = settings.restoreSession ? loadSession() : { tabs: [], active: 0 };
   if (!saved.tabs.length) { createTab(); return; }
@@ -1372,16 +1367,19 @@ function restoreTabs() {
     try { createTab(null, { background: true, pending: saved.tabs[i] }); }
     catch (e) { console.warn("session restore: tab failed:", e?.message); }
   }
-  // Pick the saved active slot as the chip the strip highlights at launch.
-  // A plain setActive() would materialise it (defeating the point of fully-
-  // lazy restore), so apply activeId + visibility by hand — the user
-  // clicking that same chip is what triggers the first navigation.
+  // The tab that was active at close loads now — it is the page the user
+  // sees, and leaving it blank until clicked read as a broken restore. Every
+  // other tab stays dormant until it is activated. activeId + visibility are
+  // applied by hand rather than through setActive(), which would also run
+  // the switch-time side effects (sidebar restore, nav push) for a tab the
+  // user did not switch to.
   const idx = Math.min(Math.max(0, saved.active | 0), tabs.length - 1);
   const target = tabs[idx];
   if (target) {
     activeId = target.id;
     try { target.view.setVisible(true); } catch {}
     for (const t of tabs) if (t.id !== activeId) { try { t.view.setVisible(false); } catch {} }
+    if (target.pending) materializePending(target);
   }
   emitTabs();
 }