[Bug]: Pressing Enter in a confirmation dialog cancels instead of confirming #18167

Scope update (2026-10-11 12:12 UTC), after the maintainer's reply: the fix follows the approved initialFocus approach with targeted call sites: the desktop and server update prompts, relay client install, and the browser import "quit" and "try again" steps (#18187). Destructive confirms keep Cancel focused, which includes "remove a hub" (that example below was wrong: its action is destructive). PR stack merge/rebase, reset credits and other non-destructive confirms are left for follow-ups.

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Trigger any confirmation dialog. For example, wait for the desktop update prompt ("Install update … and restart T3 Code?"), or go to Settings → Usage and remove a hub.
2. Without touching the mouse, press Enter.

Expected behavior

I'd expect Enter to activate Confirm, since it's the button highlighted as the primary action.

Actual behavior

The dialog closes as if Cancel had been pressed. Space does the same.

As far as I can tell, this happens because focus lands on Cancel, the first button, when the dialog opens. So Enter and Space activate Cancel, even though Confirm is the one that looks like the default.

The same thing seems to happen in:

• every AlertDialog;
• a few plain Dialog confirmations: merge or rebase a PR stack, install the relay client, and the browser import "quit" and "try again" steps.

Impact

Minor bug or occasional failure

Version or commit

Seen in the desktop Nightly while it offered 0.0.46-nightly; reproduced on main @ 98beed1

Environment

macOS, T3 Code Nightly desktop app; also reproduced in Chrome against a local dev build of main

Logs or stack traces

Screenshots, recordings, or supporting files

before-default.png

Workaround

Press Tab to move focus to Confirm before pressing Enter, or click Confirm.

A possible fix, if it helps

I'm happy to help with this, though I'd rather check with you first that it's the direction you want. One option that seemed small and safe: when a dialog opens, focus its primary action, using Base UI's initialFocus.

• Enter and Space would confirm, Esc would still cancel, and Tab would reach Cancel. That's the standard button behavior the WAI-ARIA alert dialog pattern describes, and roughly what Windows message boxes do.
• Destructive confirmations would keep focus on Cancel, so running a destructive action would still need a deliberate Tab.

I have a small PR along these lines ready. I'll only open it if you think this approach makes sense.

One open question, about macOS: native macOS alerts go a step further. Return runs the default button even when focus is on another button, and Space activates the focused one. I didn't go that way, because on the web a focused button is expected to respond to Enter, and screen reader users rely on that. If you'd prefer the macOS behavior in the desktop app, I'd be glad to add a small layer limited to macOS on top of this.

Thank you for T3 Code, and for taking a look!