diff --git a/frontend/src/components/modal/FandomPicker.vue b/frontend/src/components/modal/FandomPicker.vue
index 8f1147e..cb84aa2 100644
--- a/frontend/src/components/modal/FandomPicker.vue
+++ b/frontend/src/components/modal/FandomPicker.vue
@@ -19,7 +19,7 @@
         :item-title="(f) => f.name"
         :item-value="(f) => f.id"
         label="Fandom" clearable density="compact"
-        @keydown.enter="onSearchEnter"
+        @keydown.enter.capture="onSearchEnter"
         @keydown.tab="onSearchTab"
       />
       <v-divider class="my-3" />
@@ -92,12 +92,20 @@ function onConfirm () {
   if (f) emit('confirm', f)
 }
 
-// Enter on the search field. When the menu is open Vuetify is picking the
-// highlighted item (it sets selectedId + closes the menu) — don't also accept
-// on that keystroke. With the menu closed and a value chosen, Enter accepts.
-function onSearchEnter () {
+// Enter on the search field — bound in the CAPTURE phase so this runs BEFORE
+// Vuetify's own input keydown handler (which opens the menu on Enter). When the
+// menu is open, let Vuetify pick the highlighted item (it sets selectedId +
+// closes the menu). When it's closed and a fandom is already chosen, accept it
+// and stop the event so Vuetify never (re)opens the menu — that re-open was the
+// bug: Enter popped the dropdown instead of submitting (operator-flagged
+// 2026-06-07).
+function onSearchEnter (e) {
   if (menuOpen.value) return
-  if (selectedId.value != null) onConfirm()
+  if (selectedId.value != null) {
+    e.preventDefault()
+    e.stopPropagation()
+    onConfirm()
+  }
 }
 
 // Tab from the search field goes to the "new fandom" text field (operator-