@@ -150,10 +150,11 @@ type UsageAggregate struct {
 // usageAdmissionVersion identifies the CURRENT admission rule for the
 // aggregate. Bump it whenever Apply changes which records are counted (2:
 // internal tool calls and blocked policy decisions joined the timeline; 3:
-// management built-ins excluded again per GlanceSelection rule 1), so
-// pre-change snapshots are rebuilt instead of carried forward with hours
-// counted under the old rule.
-const usageAdmissionVersion = 3
+// management built-ins excluded again per GlanceSelection rule 1; 4: successful
+// code_execution wrappers excluded — their sub-calls are tool_call records that
+// count on their own), so pre-change snapshots are rebuilt instead of carried
+// forward with hours counted under the old rule.
+const usageAdmissionVersion = 4
 
 func newUsageAggregate() *UsageAggregate {
 	return &UsageAggregate{
@@ -197,12 +198,14 @@ func (a *UsageAggregate) tool(server, toolName string) *ToolUsage {
 //     glance row-for-row, or the bars under the list disagree with the list
 //     above them — the single most confusing thing a dashboard can do.
 //
-// The glance shows tool_calls, the internal tool calls that are mcpproxy's own
-// work (retrieve_tools, describe_tool, code_execution, upstream_servers …) and
-// blocked policy decisions, so all three enter the timeline. Internal
-// call_tool_* records are the one exclusion: they mirror a direct dispatch that
-// ALREADY emitted its own tool_call record with the same request id, so
-// counting them too would double every direct call.
+// The glance shows tool_calls, some of the internal tool calls that are
+// mcpproxy's own work (retrieve_tools, describe_tool — plus any internal call
+// that FAILED) and blocked policy decisions, so all three enter the timeline.
+// Internal call_tool_* records are excluded: they mirror a direct dispatch that
+// ALREADY emitted its own tool_call record with the same request id, so counting
+// them too would double every direct call. Successful code_execution records are
+// excluded for the same double-counting reason one level up — see
+// applyInternalToolCall.
 func (a *UsageAggregate) Apply(rec *storage.ActivityRecord) {
 	if rec == nil || rec.ToolName == "" {
 		return
@@ -295,11 +298,14 @@ func (a *UsageAggregate) applyBlocked(rec *storage.ActivityRecord) {
 // handleCallToolVariant, which emits both) — counting both would double it.
 //
 // SUCCESSFUL internal calls count only for the built-ins the glance actually
-// rows (GlanceSelection rule 3: retrieve_tools, describe_tool,
-// code_execution): a successful upstream_servers or quarantine_security call
-// is management chatter the glance hides, and counting it would put bars over
-// hours with no rows. Failures count regardless — any internal failure is a
-// glance row.
+// rows (GlanceSelection rule 3: retrieve_tools, describe_tool): a successful
+// upstream_servers or quarantine_security call is management chatter the glance
+// hides, and counting it would put bars over hours with no rows. A successful
+// code_execution is out for a different reason — the sub-calls its script made
+// are tool_call records that already count, so the wrapper would double them
+// under a name no upstream owns. Failures count regardless — any internal
+// failure is a glance row, and a script that died before dispatching anything
+// has nothing else to represent it.
 func (a *UsageAggregate) applyInternalToolCall(rec *storage.ActivityRecord) {
 	if strings.HasPrefix(rec.ToolName, storage.InternalCallToolPrefix) {
 		return
@@ -319,13 +325,19 @@ func (a *UsageAggregate) applyInternalToolCall(rec *storage.ActivityRecord) {
 
 // glanceInternalTools are the built-ins whose SUCCESSFUL calls appear as rows
 // in the tray glance (GlanceSelection.swift rule 3) and therefore in the
-// timeline; glanceManagementBuiltins are excluded from the glance entirely
-// (rule 1), success or failure. Keep both in lockstep with the Swift sets and
-// with AppState.countsTowardUsageTimeline.
+// timeline: retrieve_tools and describe_tool. code_execution is NOT one of them
+// — it is an internal primitive, and the upstream calls its scripts make are
+// tool_call records that count on their own, so counting the wrapper too would
+// bar a script twice while naming no tool. A FAILED code_execution still counts,
+// through the failure branch in applyInternalToolCall: it has no sub-calls to
+// speak for it.
+//
+// glanceManagementBuiltins are excluded from the glance entirely (rule 1),
+// success or failure. Keep both in lockstep with the Swift sets and with
+// AppState.countsTowardUsageTimeline.
 var glanceInternalTools = map[string]bool{
 	"retrieve_tools": true,
 	"describe_tool":  true,
-	"code_execution": true,
 }
 
 var glanceManagementBuiltins = map[string]bool{
 
@@ -132,7 +132,7 @@ func TestActivityService_SnapshotLoad_RebuildsWhenTheAdmissionRuleChanged(t *tes
 
 	// The store holds an internal call the OLD rule never counted.
 	require.NoError(t, mgr.SaveActivity(&storage.ActivityRecord{
-		Type: storage.ActivityTypeInternalToolCall, ToolName: "code_execution",
+		Type: storage.ActivityTypeInternalToolCall, ToolName: "retrieve_tools",
 		Status: storage.ActivityStatusSuccess, Timestamp: base,
 	}))
 
 
@@ -10,24 +10,52 @@ import (
 	"github.com/smart-mcp-proxy/mcpproxy-go/internal/storage"
 )
 
-// glanceRows applies the SAME admission rule the activity list uses by default
-// (storage.DefaultActivityFilter) so the two populations can be compared
-// directly rather than by eye.
+// glanceRows counts the rows the TRAY GLANCE renders for these records, so the
+// timeline can be compared against them directly rather than by eye.
+//
+// It is two stages, because the glance is NOT the activity list:
+//
+//	stage 1 — storage.DefaultActivityFilter, the list's own default admission.
+//	  It is what the Web UI shows, and it deliberately keeps the code_execution
+//	  parent row: the list is that script's drill-down home.
+//	stage 2 — the glance's extra narrowing (GlanceSelection rules 1 and 3). The
+//	  tray has five rows, so it drops what something else already represents: a
+//	  successful code_execution (its sub-calls are tool_call records of their
+//	  own), successful management chatter, and sheds that never ran.
+//
+// Stage 2 is spelled out literally instead of reading glanceInternalTools /
+// glanceManagementBuiltins, so this stays an independent oracle rather than a
+// restatement of the code under test.
 func glanceRows(records []*storage.ActivityRecord) int {
 	filter := storage.DefaultActivityFilter()
+	rowsOnSuccess := map[string]bool{"retrieve_tools": true, "describe_tool": true}
+	management := map[string]bool{"upstream_servers": true, "quarantine_security": true}
+
 	n := 0
 	for _, rec := range records {
-		if filter.Matches(rec) {
-			n++
+		if !filter.Matches(rec) {
+			continue
+		}
+		if rec.Type == storage.ActivityTypeInternalToolCall {
+			if management[rec.ToolName] {
+				continue // rule 1: never a row, whatever the status
+			}
+			if rec.Status == storage.ActivityStatusSuccess && !rowsOnSuccess[rec.ToolName] {
+				continue // rule 3: on success, only the discovery built-ins row
+			}
 		}
+		if rec.Type == storage.ActivityTypeToolCall && rec.Status == storage.ActivityStatusRejected {
+			continue // spec 093: a shed call never executed
+		}
+		n++
 	}
 	return n
 }
 
 // The bars under the Recent list have to count the rows in it. They used to
-// count tool_calls only, so an agent whose traffic was mostly retrieve_tools
-// and code_execution — which is most agents — looked at a list of work under an
-// almost empty histogram.
+// count tool_calls only, so an agent whose traffic was mostly retrieve_tools —
+// which is most agents — looked at a list of work under an almost empty
+// histogram.
 func TestUsageAggregate_TimelineMatchesTheGlancePopulation(t *testing.T) {
 	ts := time.Date(2026, 6, 1, 10, 0, 0, 0, time.UTC)
 	records := []*storage.ActivityRecord{
@@ -37,7 +65,10 @@ func TestUsageAggregate_TimelineMatchesTheGlancePopulation(t *testing.T) {
 		// mcpproxy's own built-ins: visible in the glance, and until now
 		// invisible in the histogram.
 		{Type: storage.ActivityTypeInternalToolCall, ToolName: "retrieve_tools", Status: storage.ActivityStatusSuccess, DurationMs: 5, Timestamp: ts},
+		// A script that ran: the glance shows the calls it MADE, not the
+		// wrapper, so this record is a row in neither list nor histogram.
 		{Type: storage.ActivityTypeInternalToolCall, ToolName: "code_execution", Status: storage.ActivityStatusSuccess, DurationMs: 400, Timestamp: ts},
+		{Type: storage.ActivityTypeToolCall, ServerName: "jira", ToolName: "get_issue", Status: storage.ActivityStatusSuccess, DurationMs: 30, Timestamp: ts, ParentID: "exec-1"},
 		{Type: storage.ActivityTypeInternalToolCall, ToolName: "describe_tool", Status: storage.ActivityStatusError, DurationMs: 2, Timestamp: ts},
 		// A policy block: a red row in the glance.
 		{Type: storage.ActivityTypePolicyDecision, ServerName: "evil", ToolName: "exfil", Status: storage.ActivityStatusBlocked, Timestamp: ts},
@@ -52,10 +83,42 @@ func TestUsageAggregate_TimelineMatchesTheGlancePopulation(t *testing.T) {
 	require.Len(t, timeline, 1)
 	assert.EqualValues(t, glanceRows(records), timeline[0].Calls,
 		"every row the user sees must be a call in the histogram")
+	assert.EqualValues(t, 6, timeline[0].Calls,
+		"two dispatches, the script's sub-call, retrieve_tools, the failed "+
+			"describe_tool and the block — but not the code_execution wrapper")
 	assert.EqualValues(t, 3, timeline[0].Errors,
 		"the failed dispatch, the failed built-in and the block are all failures")
 }
 
+// code_execution is an internal PRIMITIVE, not a call the user made: a script
+// that ran is represented by the upstream calls it issued, which are tool_call
+// records that count on their own. Counting the wrapper too would put a bar
+// under a name no upstream owns and double the script.
+//
+// A FAILED one is the exception, and the reason is that it has no children: a
+// script that died of a syntax error dispatched nothing, so its own record is
+// the only trace of the attempt anywhere.
+func TestUsageAggregate_CodeExecutionWrapperCountsOnlyWhenItFailed(t *testing.T) {
+	ts := time.Date(2026, 6, 1, 10, 0, 0, 0, time.UTC)
+
+	agg := newUsageAggregate()
+	agg.Apply(&storage.ActivityRecord{
+		Type: storage.ActivityTypeInternalToolCall, ToolName: "code_execution",
+		Status: storage.ActivityStatusSuccess, DurationMs: 400, Timestamp: ts,
+	})
+	assert.Empty(t, agg.Timeline(), "a successful script bars through its sub-calls, not through itself")
+	assert.Empty(t, agg.Tools, "and it is not an upstream tool either")
+
+	agg.Apply(&storage.ActivityRecord{
+		Type: storage.ActivityTypeInternalToolCall, ToolName: "code_execution",
+		Status: storage.ActivityStatusError, DurationMs: 3, Timestamp: ts,
+	})
+	timeline := agg.Timeline()
+	require.Len(t, timeline, 1)
+	assert.EqualValues(t, 1, timeline[0].Calls, "a script that never dispatched has only its own row")
+	assert.EqualValues(t, 1, timeline[0].Errors)
+}
+
 // The direct dispatch path emits BOTH a tool_call record and a call_tool_*
 // internal record for one call. The glance hides the internal one; so must the
 // histogram, or every direct call is counted twice.
@@ -97,9 +160,9 @@ func TestUsageAggregate_BuiltinsStayOutOfThePerToolRollup(t *testing.T) {
 }
 
 // Successful management built-ins (upstream_servers, quarantine_security, …)
-// are not glance rows — GlanceSelection rule 3 admits only retrieve_tools,
-// describe_tool and code_execution plus any internal failure — so a config
-// sweep must not paint bars over an hour with no visible rows.
+// are not glance rows — GlanceSelection rule 3 admits only retrieve_tools and
+// describe_tool plus any internal failure — so a config sweep must not paint
+// bars over an hour with no visible rows.
 func TestUsageAggregate_SuccessfulManagementBuiltinsStayOutOfTheTimeline(t *testing.T) {
 	ts := time.Date(2026, 6, 1, 10, 0, 0, 0, time.UTC)
 	agg := newUsageAggregate()
 
@@ -659,6 +659,19 @@ final class AppController: NSObject, NSApplicationDelegate, NSWindowDelegate, NS
         connectClientForm.dismiss()
     }
 
+    /// The "Add Server..." item, built in one place because it is now rendered
+    /// from two: normally as the first entry of the Servers submenu, and at the
+    /// top level only when there are no servers and therefore no submenu.
+    ///
+    /// `target` is set explicitly — an item in a submenu with a nil target would
+    /// fall back to the responder chain, and the tray has none while the menu is
+    /// open, so the click would silently do nothing.
+    func makeAddServerItem() -> NSMenuItem {
+        let item = NSMenuItem(title: "Add Server...", action: #selector(showAddServer), keyEquivalent: "n")
+        item.target = self
+        return item
+    }
+
     @objc private func showAddServer() {
         showMainWindow()
         // First switch to the Servers tab so ServersView is mounted and
@@ -1070,23 +1083,26 @@ final class AppController: NSObject, NSApplicationDelegate, NSWindowDelegate, NS
             menu.addItem(.separator())
         }
 
-        // Quarantine
-        if appState.quarantinedToolsCount > 0 {
-            let quarantineItem = NSMenuItem(
-                title: "\(appState.quarantinedToolsCount) quarantined server(s)",
-                action: nil, keyEquivalent: "")
-            quarantineItem.isEnabled = false
-            quarantineItem.image = NSImage(systemSymbolName: "shield.lefthalf.filled",
-                                            accessibilityDescription: "quarantine")
-            menu.addItem(quarantineItem)
-            menu.addItem(.separator())
-        }
+        // No standalone quarantine line: "N quarantined server(s)" was a
+        // disabled, grey, non-actionable row, and the same fact is already
+        // carried — actionably — by the Needs Attention submenu above. The menu
+        // had grown long enough to scroll, and an informational row that cannot
+        // be clicked is the first thing to spend.
 
         // Servers — as a SUBMENU (not flat list)
         if !appState.servers.isEmpty {
             let serversMenuItem = NSMenuItem(title: "Servers (\(appState.servers.count))", action: nil, keyEquivalent: "")
             let serversSubmenu = NSMenu()
 
+            // "Add Server..." lives HERE, not at the top level: adding a server
+            // is a servers-menu action, and hoisting it out cost a permanent
+            // top-level row in a menu that had started to scroll. The Cmd+N key
+            // equivalent still works from a submenu — AppKit walks the whole menu
+            // tree when matching key equivalents — and still displays beside the
+            // title once the submenu is open.
+            serversSubmenu.addItem(makeAddServerItem())
+            serversSubmenu.addItem(.separator())
+
             for server in appState.servers {
                 let item = NSMenuItem(title: server.name, action: nil, keyEquivalent: "")
 
@@ -1200,9 +1216,14 @@ final class AppController: NSObject, NSApplicationDelegate, NSWindowDelegate, NS
         }
 
         // Actions
-        let addServer = NSMenuItem(title: "Add Server...", action: #selector(showAddServer), keyEquivalent: "n")
-        addServer.target = self
-        menu.addItem(addServer)
+        //
+        // "Add Server..." normally lives inside the Servers submenu. The one
+        // exception is a proxy with no servers at all: there is no Servers
+        // submenu to hold it then, and the very user who most needs to add one
+        // would be left without a way to do it from the tray.
+        if appState.servers.isEmpty {
+            menu.addItem(makeAddServerItem())
+        }
 
         // Spec 091 FR-001: the native connect journey, beside Add Server. The
         // item is built by its router so the item and its routing are tested
@@ -1334,9 +1355,9 @@ final class AppController: NSObject, NSApplicationDelegate, NSWindowDelegate, NS
         docsItem.target = self
         menu.addItem(docsItem)
 
-        let issueItem = NSMenuItem(title: "Report an Issue…", action: #selector(reportIssue), keyEquivalent: "")
-        issueItem.target = self
-        menu.addItem(issueItem)
+        // No "Report an Issue…" item: the menu had grown long enough to scroll
+        // on a normal display, and the tracker is still reachable through the
+        // GitHub link in the About panel's credits block.
 
         let aboutItem = NSMenuItem(title: "About MCPProxy", action: #selector(showAboutPanel), keyEquivalent: "")
         aboutItem.target = self
@@ -1643,10 +1664,6 @@ final class AppController: NSObject, NSApplicationDelegate, NSWindowDelegate, NS
         NSWorkspace.shared.open(ProjectLinks.docs)
     }
 
-    @objc private func reportIssue() {
-        NSWorkspace.shared.open(ProjectLinks.issues)
-    }
-
     /// Shows the standard About panel (app name + version) with a credits block
     /// that links back to the homepage, source, and docs — so "About MCPProxy"
     /// carries the way back to the project, not just a version string.
 
@@ -118,8 +118,17 @@ enum GlanceSelection {
     /// Proxy administration built-ins. Never shown, whatever their status.
     static let managementBuiltIns: Set<String> = ["upstream_servers", "quarantine_security"]
 
-    /// Discovery/execution built-ins that are worth a row even on success.
-    static let glanceInternalTools: Set<String> = ["retrieve_tools", "code_execution", "describe_tool"]
+    /// Discovery built-ins that are worth a row even on success.
+    ///
+    /// `code_execution` is deliberately NOT here. It is an internal primitive —
+    /// a wrapper around the upstream calls a script makes — and since those
+    /// sub-calls became `tool_call` records of their own they speak for it far
+    /// better than it did: the glance now shows the REAL work ("jira_get_issue
+    /// ×3") instead of one opaque "code_execution" row that named no server and
+    /// no tool. A FAILED code_execution still rows, through rule 3's failure
+    /// branch below — a script that died of a syntax error has no children to
+    /// speak for it, so its own record is the only trace there is.
+    static let glanceInternalTools: Set<String> = ["retrieve_tools", "describe_tool"]
 
     /// How many rows each list shows.
     static let rowLimit = 5
@@ -148,8 +157,10 @@ enum GlanceSelection {
             return entry.outcomeClass == .blocked
         }
 
-        // Rule 3 — discovery/execution built-ins, plus any internal failure
-        // (a wrapper that died before dispatch has no upstream record).
+        // Rule 3 — discovery built-ins, plus any internal failure (a wrapper
+        // that died before dispatch has no upstream record). A SUCCESSFUL
+        // code_execution falls through both clauses on purpose: its sub-calls
+        // are the rows now.
         if entry.type == "internal_tool_call" {
             return glanceInternalTools.contains(tool) || entry.status != "success"
         }
@@ -178,9 +189,10 @@ enum GlanceSelection {
     /// per sub-call — the counter suffix in `mintCorrelationIDAt` is what makes
     /// it unique — and names the script through `parent_id`, which carries the
     /// parent's request id rather than a shared one. No child shares an id with
-    /// another child or with the parent, so a multi-tool script renders as the
-    /// script's own row plus one row per sub-call (the transparency the feature
-    /// exists for) instead of collapsing to one.
+    /// another child or with the parent, so a multi-tool script renders as one
+    /// row per sub-call (the transparency the feature exists for) instead of
+    /// collapsing to one. The successful wrapper itself never reaches this step
+    /// — rule 3 dropped it — so those rows are the script's whole story.
     ///
     /// Note the legacy `ToolCallRecord` written beside it still carries
     /// `RequestID: u.executionID` ("Use execution ID as request ID to link