What happened?
With macOS Keyboard navigation enabled (System Settings → Keyboard; AppleKeyboardUIMode = 3), pressing Tab in the ⌘W close-confirmation dialog does not cycle that dialog's buttons. Focus moves into the window behind the dialog instead.
I expected focus to stay trapped inside the dialog until it is dismissed, which is what a standard AppKit sheet or modal session does.
Because the dialog stays on top, the focused control is not visible. Pressing Space then activates a control the user cannot see, while a confirmation dialog is on screen. That makes ⌘W unpredictable for anyone who drives the app from the keyboard — the dialog cannot be answered by keyboard, and the keys that would normally answer it can trigger something else entirely.
Guess at the cause, low confidence and from the outside: this looks like the usual difference between an AppKit sheet / runModal session, which traps focus for free, and a custom overlay presented in the same window, which does not. Scoping focus to the dialog's container would be the fix.
Related but distinct: #294 (sidebar → terminal arrow-key focus) and #662 (accessibility, large text). Neither covers focus containment in dialogs.
Steps to reproduce
- Open System Settings → Keyboard and enable Keyboard navigation.
- In Supacode settings, make sure Confirm before closing a surface (
confirmCloseSurface) is enabled.
- Open a worktree with at least one terminal surface.
- Press ⌘W. The close-confirmation dialog appears.
- Press Tab a few times.
Expected: focus cycles among the dialog's own controls and stays inside the dialog.
Actual: focus leaves the dialog and lands on controls in the window behind it. No visible focus ring appears on the dialog.
Supacode version and build
0.10.8 (1785775286)
macOS version
macOS 26.6 (25G72)
System locale
en_US
Mac hardware
Apple M1 Pro
Are you planning to fix this yourself?
Before submitting
Happy to test a build.
What happened?
With macOS Keyboard navigation enabled (System Settings → Keyboard;
AppleKeyboardUIMode = 3), pressing Tab in the ⌘W close-confirmation dialog does not cycle that dialog's buttons. Focus moves into the window behind the dialog instead.I expected focus to stay trapped inside the dialog until it is dismissed, which is what a standard AppKit sheet or modal session does.
Because the dialog stays on top, the focused control is not visible. Pressing Space then activates a control the user cannot see, while a confirmation dialog is on screen. That makes ⌘W unpredictable for anyone who drives the app from the keyboard — the dialog cannot be answered by keyboard, and the keys that would normally answer it can trigger something else entirely.
Guess at the cause, low confidence and from the outside: this looks like the usual difference between an AppKit sheet /
runModalsession, which traps focus for free, and a custom overlay presented in the same window, which does not. Scoping focus to the dialog's container would be the fix.Related but distinct: #294 (sidebar → terminal arrow-key focus) and #662 (accessibility, large text). Neither covers focus containment in dialogs.
Steps to reproduce
confirmCloseSurface) is enabled.Expected: focus cycles among the dialog's own controls and stays inside the dialog.
Actual: focus leaves the dialog and lands on controls in the window behind it. No visible focus ring appears on the dialog.
Supacode version and build
0.10.8 (1785775286)
macOS version
macOS 26.6 (25G72)
System locale
en_US
Mac hardware
Apple M1 Pro
Are you planning to fix this yourself?
ready.Before submitting
ready.Happy to test a build.