Clicking a pane after switching worktrees does not update the active pane highlight

[marvtub]

Summary

When using split panes, clicking into a pane after switching worktrees does not always update which pane looks active.

The terminal itself appears clickable, but the visual active-pane state stays on the previous pane. The transparency/dimming only updates after clicking the already-highlighted pane again, then clicking the other pane.

Steps to reproduce

1. Open a worktree with two terminal panes.
2. Switch to another worktree.
3. Switch back, or switch between worktrees with split panes.
4. Click into the pane that is not currently highlighted.

Expected behavior

The pane I click should immediately become the active/highlighted pane.

Actual behavior

The highlighted pane does not change on the first click. It only updates after clicking the currently highlighted pane again, then clicking the other pane.

Notes from a quick code check

This looks like the visual active-pane state is tied to the Ghostty surface becoming first responder. Normal mouseDown forwards the click to Ghostty, but does not appear to explicitly focus the clicked surface when the window is already active. So the click can reach the terminal without updating Supacode's active-pane state.

A likely fix is to focus the clicked surface on mouseDown before forwarding the click.

[marvtub]

I dug a bit deeper and this looks pretty pinpointable.

Current hypothesis

After switching worktrees, the sidebar can still be the app's focused control, while Supacode remembers the previously active terminal pane for that worktree.

The pane dimming/highlight is based on that remembered active pane. When I click a different pane, the click is forwarded into the terminal, but the clicked pane does not always become the app's focused terminal surface. Because of that, Supacode never updates which pane is active, so the transparency/highlight stays stale.

That also explains the weird workaround: clicking the already-highlighted pane first seems to restore the focus chain, then clicking the other pane works.

Why I think this is the issue

The visual dimming is driven by activeSurfaceID in TerminalSplitTreeView.

That value is updated through recordActiveSurface(...), which runs when a Ghostty surface reports onFocusChange(true).

But normal left click handling in GhosttySurfaceView.mouseDown only sends the click to Ghostty. It does not explicitly make the clicked surface the first responder when the window is already active.

There is a separate mouse-down focus path, but it only runs when the app/window is inactive. So it does not cover the common case after switching worktrees inside an already-active Supacode window.

How to verify

Add temporary logs in these places:

1. GhosttySurfaceView.mouseDown

   • clicked surface id
   • current window.firstResponder
   • whether the window is key

2. GhosttySurfaceView.becomeFirstResponder / focusDidChange(true)

   • surface id

3. WorktreeTerminalState.recordActiveSurface(...)

   • old active surface id
   • new active surface id

Then reproduce the bug.

Expected log pattern if this hypothesis is correct:

• On the broken click, mouseDown fires for the clicked pane.
• But becomeFirstResponder, focusDidChange(true), and recordActiveSurface(...) do not fire for that pane.
• activeSurfaceID stays pointed at the previously highlighted pane.

A quick fix experiment would be to make mouseDown focus the clicked surface before forwarding the click to Ghostty, e.g. only when window.firstResponder !== self. If the bug disappears with that change, that confirms the root cause.

[marvtub]

One correction after digging further: the first theory (“mouseDown does not focus the pane”) is probably too narrow. A small AppKit probe suggests a normal custom NSView usually becomes first responder before mouseDown.

The more likely root cause is a focus-state mismatch after switching worktrees:

• Supacode can mark the remembered active pane as focused when a worktree appears.
• But if the sidebar is still the actual macOS focused control, Supacode does not always move first responder back to the terminal pane.
• That leaves the app with two different ideas of focus:
  • Supacode/Ghostty thinks pane A is focused/highlighted.
  • macOS first responder may still be the sidebar or another control.
• Clicking pane A first realigns those states. After that, clicking pane B works.

A more precise verification would be to log this sequence:

1. On worktree switch / terminal appear:

   • remembered active pane id
   • current window.firstResponder
   • whether Supacode calls makeFirstResponder for the remembered pane

2. On the first broken click into pane B:

   • whether becomeFirstResponder(B) fires
   • whether focusDidChange(true) fires
   • whether recordActiveSurface(B) fires
   • what activeSurfaceID is after the click

Expected failing pattern:

• After switching worktrees: activeSurfaceID = A, but window.firstResponder is not pane A.
• First click into pane B does not complete the full becomeFirstResponder -> focusDidChange -> recordActiveSurface path, or the old pane remains internally focused.
• Click pane A: first responder and internal focus line back up.
• Click pane B again: active pane updates correctly.

So the fix may be less “focus on every mouseDown” and more “do not set terminal/Ghostty focus unless AppKit first responder is also moved, or explicitly repair first responder when restoring a selected worktree.”

[sbertix]

Hey 👋

Thanks, could you attach a video of the issue on the latest Supacode version? 🙇‍♂️
I'm having trouble replicating this and I'm trying to understand if I grasped the issue correctly