frontend/app/tab/tab.scss (1)

99-106: Indicator glow is overridden on hover.

The hover rule at lines 137–139 (body:not(.nohover) .tab:hover .tab-inner) has higher specificity than .tab.has-indicator .tab-inner, so the colored glow disappears when the user hovers over an indicator tab. If you want the glow to persist on hover, you could add a .has-indicator override inside the hover block, e.g.:

♻️ Optional: preserve glow on hover

 body:not(.nohover) .tab:hover,
 body:not(.nohover) .tab.dragging {
     ...
     .tab-inner {
         border-color: transparent;
         background: rgb(from var(--main-text-color) r g b / 0.1);
     }
+    &.has-indicator .tab-inner {
+        background: rgb(from var(--tab-indicator-color) r g b / 0.15);
+    }
     ...
 }

pkg/blockcontroller/shellcontroller.go (1)

619-665: Duplicated block-data fetch and close-on-exit logic with checkCloseOnExit.

This goroutine fetches blockData and evaluates the same closeOnExit / closeOnExitForce conditions that checkCloseOnExit (Line 666→697) also fetches and evaluates independently. Consider extracting the shared block-data fetch and close-on-exit predicate into a helper, or restructuring so both consumers share a single DB read.

Not a correctness issue — just duplication that could drift over time.

pkg/blockcontroller/shellcontroller.go (3)

647-717: Duplicated clear-event block can be hoisted.

Lines 671-678 and 683-690 publish the exact same clear event. Since both the early-return path (closeOnExit) and the normal exit path need to clear the running indicator first, hoist the clear event before the if closeOnExitForce || ... check to remove duplication.

♻️ Suggested refactor

-			if closeOnExitForce || (closeOnExit && exitCode == 0) {
-				// Clear running indicator before block gets deleted
-				if bc.ControllerType == BlockController_Cmd {
-					clearEvent := wps.WaveEvent{
-						Event:  wps.Event_TabIndicator,
-						Scopes: []string{waveobj.MakeORef(waveobj.OType_Tab, bc.TabId).String()},
-						Data:   wshrpc.TabIndicatorEventData{TabId: bc.TabId, Indicator: nil},
-					}
-					wps.Broker.Publish(clearEvent)
-				}
-				return
-			}
-			// Clear running indicator before exit indicator to prevent
-			// PersistentIndicator from resurrecting the amber glow
-			if bc.ControllerType == BlockController_Cmd {
-				clearEvent := wps.WaveEvent{
-					Event:  wps.Event_TabIndicator,
-					Scopes: []string{waveobj.MakeORef(waveobj.OType_Tab, bc.TabId).String()},
-					Data:   wshrpc.TabIndicatorEventData{TabId: bc.TabId, Indicator: nil},
-				}
-				wps.Broker.Publish(clearEvent)
+			// Clear running indicator before block deletion or exit indicator
+			// to prevent PersistentIndicator from resurrecting the amber glow
+			if bc.ControllerType == BlockController_Cmd {
+				clearEvent := wps.WaveEvent{
+					Event:  wps.Event_TabIndicator,
+					Scopes: []string{waveobj.MakeORef(waveobj.OType_Tab, bc.TabId).String()},
+					Data:   wshrpc.TabIndicatorEventData{TabId: bc.TabId, Indicator: nil},
+				}
+				wps.Broker.Publish(clearEvent)
+			}
+			if closeOnExitForce || (closeOnExit && exitCode == 0) {
+				return
 			}

---

531-536: Consider extracting the exit-indicator-enabled check into a helper.

The same pattern — read from block meta, then fall back to global settings — appears at both start (lines 531-536) and exit (lines 658-663). A small helper like isExitIndicatorEnabled(meta MetaMapType) bool would reduce duplication and keep the fallback logic in one place.

Also applies to: 658-663

---

667-680: Potential race with checkCloseOnExit — benign but worth a note.

Both this goroutine (line 647) and checkCloseOnExit (line 718) run concurrently, each independently fetching block data and evaluating closeOnExit/closeOnExitForce. The indicator-clear event here may race with block deletion in checkCloseOnExit. This is benign (clearing an indicator on a soon-to-be-deleted block is a no-op), but a comment noting the intentional concurrency would help future readers.

pkg/blockcontroller/shellcontroller.go (2)

647-717: Exit indicator goroutine is well-structured. Fresh DB read, proper panic handling, parameter capture for exitCode/exitSignal, and the clear-before-set pattern to avoid PersistentIndicator resurrection are all solid.

Minor DRY note: the clear-event construction is duplicated at lines 672-678 and 684-690. A small helper (or hoisting to a local closure) would reduce the repetition, but this is optional.

---

667-680: Potential race with checkCloseOnExit on the same DB read.

Both this goroutine and checkCloseOnExit (line 718) independently fetch blockData and evaluate closeOnExit/closeOnExitForce. Since checkCloseOnExit sleeps for closeonexitdelay (default 2s) before deleting the block, the ordering is safe in practice—but if closeonexitdelay is set to 0, the block could be deleted before this goroutine finishes publishing the clear event. Currently harmless (publishing to a deleted tab is a no-op on the frontend), but worth being aware of.

frontend/app/tab/tab.scss (1)

121-137: Consider extracting indicator background rules into a shared mixin to reduce duplication.

The indicator background rules are repeated in both the default .tab context (Lines 121-137) and the hover/drag context (Lines 172-183). While the duplication is necessary for specificity overrides, a SCSS mixin could keep them in sync:

♻️ Suggested mixin

+@mixin indicator-backgrounds {
+    &.has-indicator .tab-inner {
+        background: rgb(from var(--tab-indicator-color) r g b / 0.15);
+    }
+    &.has-indicator.active .tab-inner {
+        background: rgb(from var(--tab-indicator-color) r g b / 0.2);
+    }
+    &.indicator-breathing .tab-inner {
+        background: rgb(from var(--tab-indicator-color) r g b / calc(0.08 + var(--breathe-phase) * 0.14));
+    }
+    &.indicator-breathing.active .tab-inner {
+        background: rgb(from var(--tab-indicator-color) r g b / calc(0.12 + var(--breathe-phase) * 0.14));
+    }
+}

Then use @include indicator-backgrounds; in both contexts.

Also applies to: 172-183