diff --git a/PROJECT_STATUS.md b/PROJECT_STATUS.md
index ae2120b..69d11ff 100644
--- a/PROJECT_STATUS.md
+++ b/PROJECT_STATUS.md
@@ -1,6 +1,6 @@
 # Aurora Admin v2 — Project Status
 
-_Last updated: 2026-07-03 (late session — Site Editor support, permissions bug fix, Comments sub-app, taskbar rewrite)_
+_Last updated: 2026-07-03 (latest session — universal content-area scroll cap, sidebar accordion, scroll-anchoring fix)_
 
 ## What this project is
 
@@ -113,6 +113,17 @@ get back up to speed instead of relying on prior chat history.
     over the page gradient. `--aurora-sidebar-gap` is a shared CSS var
     (`shell-frame.css`) that the toolbar's `left` offset and `#wpcontent`'s
     `margin-left` both add too, so nothing overlaps when the gap changes.
+  - **Native-menu accordion**: only one WP-native-menu section's submenu is
+    open at a time (`Sidebar.vue`'s `openId` ref) — expanding one collapses
+    whichever else was open, instead of the list growing indefinitely as
+    more sections get expanded. Was previously a `Set` of independently
+    toggleable ids (each section remembered its own open/closed state);
+    replaced with a single id so opening any section closes the rest.
+    Starts on whichever section matches the current page (each nav is a
+    full page load in this multi-page admin, so this is computed once at
+    mount, not reactively). The separate "Aurora" branded nav section below
+    it keeps its own independent expand/collapse state
+    (`localStorage['aurora-nav-expanded']`) — not part of this accordion.
 
 ## Theme system (rewrite — supersedes the old dark_mode 3-state model)
 
@@ -362,6 +373,41 @@ page navigation via a taskbar.
   calc(100vh - toolbar-h - 40px)`, and per spec `min-height` always wins over
   a smaller `max-height`; fixed by adding `min-height: 0` to the
   taskbar-specific override.
+- **Universal content-area height cap** (this session): the taskbar-only
+  `max-height`/`overflow-y: auto` treatment above is now applied to
+  `#wpbody-content` unconditionally (not just when `html.aurora-has-taskbar`
+  is set), capped to `calc(100vh - toolbar-h - 40px)`. Several native and
+  Aurora pages with a lot of content (Add Plugins, Add User, Profile,
+  Appearance > Fonts, the file editors, every Settings page, Activity Log,
+  Database Explorer, Comments) used to grow taller than the viewport and
+  force the *whole document* to scroll — janky since the sidebar/toolbar
+  are fixed, so scrolling just moved the content away from them with a lot
+  of dead space. Now the content card's own box is capped and scrolls
+  internally, same as the toolbar/taskbar reservations already did.
+  - **Scroll-anchoring bug this surfaced**: making `#wpbody-content` a real
+    scroll container exposed a second, unrelated bug on Add Plugins — its
+    plugin-card grid renders via JS well after first paint, inserting a lot
+    of content *above* whatever was already visible in the now-scrollable
+    box. Chrome's scroll anchoring "corrects" for that by silently jumping
+    `scrollTop` down to compensate, so the page loaded already scrolled
+    ~1700px into the content instead of at the top. Fixed with
+    `overflow-anchor: none` on `#wpbody-content` (and the taskbar/dashboard-
+    frame variant) — the standard fix for this class of bug, opting the
+    container out of anchoring entirely.
+  - **Phantom document-level scrollbar**: independently, Add Plugins also
+    left the outer `<html>`/`<body>` scrollable with ~1200px of empty dead
+    space below the frame, even though every element inside `#wpbody-content`
+    measured as properly capped to the viewport — narrowed down to some
+    interaction between the plugin grid's async rendering and the browser's
+    own scrollable-overflow bookkeeping (root cause not fully pinned down;
+    forcibly shrinking or hiding `#wpbody-content` reduced but didn't
+    eliminate it, and no single oversized/mispositioned descendant could be
+    found). Since the intended design already has the sidebar/toolbar fixed
+    and every page's real content scrolling *internally* within its own
+    frame, the document itself was never supposed to scroll at all — fixed
+    directly by adding `overflow: hidden` to `html.aurora-ready`/`body`,
+    which removes the dead scroll space outright regardless of what was
+    causing it.
 - **Block editor / Site Editor framing**: neither editor renders inside
   `#wpcontent`'s normal box model — each has its own fixed, full-viewport
   root (`.interface-interface-skeleton` itself on `post.php`/`post-new.php`;
@@ -475,10 +521,10 @@ page navigation via a taskbar.
 
 ## Current state
 
-No task in progress. Earlier this session rebuilt the entire theming system
+No task in progress. An earlier session rebuilt the entire theming system
 (fixed color presets, gradient backgrounds, "independently-painted gradient"
 seam bugs) and added the macOS-style window chrome + taskbar feature
-end-to-end (pushed as commits `4a547d2`/`b0b0a99`). Later the same session:
+end-to-end (pushed as commits `4a547d2`/`b0b0a99`). Later that same session:
 root-caused and fixed the Menu Creator/Activity Log/Role Editor "Sorry, you
 are not allowed to access this page" bug (was `remove_submenu_page()`
 corrupting WP's own capability lookup); added a 6th sub-app, Comments; fixed
@@ -487,8 +533,18 @@ taskbar from a single sessionStorage slot to a list supporting multiple
 minimized windows; and extended the window-chrome/taskbar framing to the
 Site Editor (`site-editor.php`), including tracking down a CSS
 over-constraint bug (`top`+`height`+`bottom` all set on a fixed-position box
-silently ignoring `bottom`) that was making its frame run past the viewport.
-All of it was live-verified in Chrome against the LocalWP site. This batch
-of changes was uncommitted at the point this doc was last updated — commit
-and push it as one of the next steps if not already done by the time this is
-read.
+silently ignoring `bottom`) that was making its frame run past the viewport
+(pushed as commit `8153d43`).
+
+This session: capped every native/Aurora page's content area to the
+viewport with internal scrolling instead of letting tall pages grow past it
+and scroll the whole document (see "Universal content-area height cap"
+above), which surfaced and fixed two more bugs along the way — a Chrome
+scroll-anchoring jump on Add Plugins, and a phantom document-level
+scrollbar with a large empty gap below the frame. Also made the sidebar's
+native-menu sections a single-open accordion instead of letting multiple
+stay expanded at once. All of it was live-verified in Chrome against the
+LocalWP site (build hot-patched into
+`/Users/kris/Local Sites/aurora/.../aurora-admin/app/dist` for iteration —
+the repo's source files are the actual edits; that copy is just the
+compiled build artifact, not a separate edit surface).
diff --git a/app/src/shell/components/Sidebar.vue b/app/src/shell/components/Sidebar.vue
index 705eab2..c6ba122 100644
--- a/app/src/shell/components/Sidebar.vue
+++ b/app/src/shell/components/Sidebar.vue
@@ -63,21 +63,16 @@ const isSectionActive = (item) => {
   return (item.submenu || []).some((sub) => normalize(sub.url) === current.value);
 };
 
-// Which sections are manually expanded. Active section starts expanded.
-const expanded = ref(new Set());
+// Accordion: only one section's submenu open at a time, so expanding one
+// closes the rest instead of the list growing indefinitely. Starts on
+// whichever section is active (each nav is a full page load in this
+// multi-page admin, so there's no need to react to URL changes afterward).
+const openId = ref(props.menu.find((item) => isSectionActive(item))?.id ?? null);
 
-const isExpanded = (item) => {
-  return expanded.value.has(item.id) || isSectionActive(item);
-};
+const isExpanded = (item) => openId.value === item.id;
 
 const toggle = (item) => {
-  const next = new Set(expanded.value);
-  if (next.has(item.id)) {
-    next.delete(item.id);
-  } else {
-    next.add(item.id);
-  }
-  expanded.value = next;
+  openId.value = openId.value === item.id ? null : item.id;
 };
 
 // Aurora's own branded nav section (Settings, Menu Creator, Admin Notices,
diff --git a/app/src/shell/shell-frame.css b/app/src/shell/shell-frame.css
index 0e05598..7e39ac6 100644
--- a/app/src/shell/shell-frame.css
+++ b/app/src/shell/shell-frame.css
@@ -103,6 +103,18 @@ html.aurora-ready body {
      background instead of a seam between "sidebar" and "page". */
   background-attachment: fixed;
   font-family: var(--aurora-font-family);
+  /* The sidebar/toolbar are position:fixed and every page's real content
+     now scrolls internally within its own frame (#wpbody-content or
+     .aurora-dashboard-frame, both capped to the viewport with their own
+     overflow-y: auto below) — so the document itself is never meant to
+     scroll. Some native pages (Add Plugins' plugin-card grid is the one
+     that surfaced this) leave a huge dead scrollable area at the document
+     level — a WP/browser quirk around lazily-rendered content reserving
+     scroll space against the page rather than the inner container — which
+     showed up as being able to scroll the whole window down to a big
+     empty gap below the frame. Locking the document's own scroll removes
+     that dead space outright, regardless of what's causing it. */
+  overflow: hidden;
 }
 
 /* !important here defeats WordPress's own responsive #wpcontent margin
@@ -196,6 +208,24 @@ html.aurora-ready #wpbody-content {
   margin: 16px var(--aurora-gutter-r) 24px 24px;
   padding: 32px;
   min-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
+  /* Cap the card's own height to whatever's left below the toolbar and let
+     *it* scroll internally, instead of growing to fit tall native pages
+     (Comments, Plugins, Add User, Settings, Activity Log, Database
+     Explorer, ...) and forcing the whole document to scroll — the sidebar/
+     toolbar are fixed, so a tall #wpbody-content just meant a lot of empty
+     scroll distance below the fold with nothing visibly moving except the
+     content. Same fix as the taskbar-present case below, just unconditional. */
+  max-height: calc(100vh - var(--aurora-toolbar-h) - 40px);
+  overflow-y: auto;
+  /* Chrome's scroll anchoring tries to keep whatever's in view visually
+     stable when content shifts above it. Several native pages (Add Plugins'
+     plugin-card grid, most visibly) render their real content via JS well
+     after the initial paint, inserting it above stuff that was already
+     visible in this now-scrollable box — anchoring then "corrects" by
+     jumping scrollTop down to compensate, landing the page scrolled to
+     the middle/bottom on load instead of the top. Opting this container
+     out of anchoring is the standard fix for that class of bug. */
+  overflow-anchor: none;
   box-sizing: border-box;
   /* WP core sets #wpbody-content { float: left; width: 100% }, which (with
      box-sizing left alone) ignores the margin above and overflows past the
@@ -250,6 +280,7 @@ html.aurora-has-taskbar .aurora-dashboard-frame {
       var(--aurora-sidebar-gap) * 2
   );
   overflow-y: auto;
+  overflow-anchor: none;
 }
 
 /* The block editor's skeleton is already positioned with fixed insets