Claude Desktop (Windows): "View usage in Settings" opens the Settings dialog without moving keyboard focus into it

App: Claude Desktop 1.52386.3.0 (MSIX, x64), Windows 11 Pro 10.0.26200
Assistive technology: NVDA
Area: Code tab, usage popover → "View usage in Settings"

Steps to reproduce

1. With NVDA running, open the usage popover (usage ring / "Usage").
2. Activate the arrow link "View usage in Settings".

Expected

The Settings dialog opens on the Usage section and keyboard/screen-reader focus moves into the dialog
(WCAG 2.4.3 Focus Order; ARIA dialog pattern: focus moves into a modal dialog when it opens).

Actual

The dialog opens visually, but focus stays behind it. NVDA cannot reach the dialog content until the user
clicks inside the dialog once with the mouse. For a keyboard-only or blind user the dialog is effectively
unreachable.

Root cause (from the shipped bundle resources/ion-dist/assets/v1/, minified names)

1. The Settings dialog opts out of initial focus. In shared-20-bCuAiMba.js the settings modal renders a
   Base UI Dialog.Popup with initialFocus: ex, where function ex(){return!1}. Returning false tells
   Base UI not to move focus when the dialog opens.
2. The fallback only covers one case. An effect focuses the popup only when the settings content chunk
   goes from not-loaded to loaded and document.activeElement is null or <body>:
   !t&&e!==null&&S&&(document.activeElement===null||document.activeElement===document.body)&&M.current?.focus().
   When the chunk is already loaded, or when something else still has focus, nothing moves focus.
3. The usage popover is not closed first, so focus is never on <body>. In c51de9054-DCjU9aJk.js the
   popover's onSettingsClick only records analytics (Te=t(()=>{Q("settings")},[Q])), whereas
   onUpgradeClick and onBuyCreditsClick also close the popover (Z(!1)). The link handler in
   c5afb3665-DoubTiQ4.js then calls the settings store's open("usage"). Focus therefore remains on the
   "View usage in Settings" link inside the popover, which now sits under a modal dialog, so condition 2
   never holds.
4. The same open("usage") path without focus handling exists in two other entry points:
   c2d611398-I-hhE0OY.js (usage summary link) and cddc0f8fa-DG9nySe8.js (At(), icon button
   "View usage in Settings"). Note that the store's focused option (open(section, subpath, {focused:true}))
   only changes the dialog header presentation; it does not move keyboard focus.

Suggested fix

• Let the Settings dialog take initial focus (remove the initialFocus override returning false, or focus the
  popup/first control on open) whenever it is opened by a user action, regardless of the current
  document.activeElement or whether the content chunk was already loaded.
• Close the usage popover in onSettingsClick, as the other popover actions already do, and make sure the
  popover's focus return to its trigger does not pull focus back out of the dialog.
• On closing Settings, return focus to the usage trigger.

Notes

The root cause was established by reading the shipped bundle; the symptom is reproduced by the reporter with
NVDA. No live instrumentation was run.

Claude Code context

• Reported from a Claude Code session in the Code tab of Claude Desktop on Windows; the bug was hit there.
• Claude Code bundled with the app at the time of the report: 2.1.266 (Claude Desktop 1.52386.3.0).
• Rechecked on Claude Desktop 1.52386.6.0 with Claude Code 2.1.270: the same code is still present
  (initialFocus returning false in shared-20-bCuAiMba.js, the fallback that only focuses the dialog when
  document.activeElement is <body>, and onSettingsClick in c51de9054-DCjU9aJk.js recording analytics only).