[Bug]: ui get-focused reports no focus in Sandbox while the target text box has keyboard focus

Describe the bug

In Daylight running in Windows Sandbox, winapp ui get-focused reports hasFocus:false even though the target text box reports HasKeyboardFocus:true and Daylight's main window is foreground.

This was reproduced in all six sandbox trials. The same sequence against the existing local Daylight installation returned the correct focus in all six trials using the same CLI version. Classify this as sandbox-reproduced, not proven universally sandbox-only: the local installation's exact source revision was not independently verified.

To Reproduce

Use CLI 0.6.3-prerelease.52 and Daylight, a public WinUI demo at https://github.com/nmetulev/daylight. The original reproduction fixture is pinned to commit dba44790c3cdc516c7ec81eda18ac58998ac45c8; these live checks used existing registered installations without rebuilding them.

1. Launch Daylight in a connected managed sandbox. Discover its current process ID and main HWND with winapp ui list-windows -a Daylight --on sandbox --json. Do not reuse historical IDs.
2. Open a blank editor with winapp ui invoke AddTaskButton -a <PID> --on sandbox. Keep it unsaved.
3. Run:

winapp ui focus TaskTitleInput -a <PID> --on sandbox
winapp ui get-focused -a <PID> --on sandbox --json
winapp ui get-focused -w <HWND> --on sandbox --json
winapp ui get-property TaskTitleInput -a <PID> --on sandbox -p HasKeyboardFocus --json
winapp ui list-windows -a <PID> --on sandbox --json

4. Repeat five times, then repeat the queries after a guarded winapp ui click TaskTitleInput -a <PID> --on sandbox.
5. Cancel the blank editor without saving.

Observed on September 18, 2026:

Check	Sandbox	Local comparison
Mismatches in five focus trials plus one click trial	6/6	0/6
get-focused by PID and HWND	hasFocus:false	hasFocus:true, correct title control
Title HasKeyboardFocus	True	True
Daylight main window foreground	Yes	Yes
Independent managed UIA focused-control process ID	0	Correct app process ID

All trial commands exited 0. The sandbox's owned PopupHost was not foreground, so the observations were not simply input being directed at an active popup.

An independent read-only guest query using .NET UIAutomationClient successfully returned the focused TaskTitleInput, with HasKeyboardFocus:true, process ID 0, and native HWND 0. Its raw ancestor chain reached Daylight's actual process ID and main HWND. Independent foreground-window inspection identified that same main HWND. The local equivalent returned the app's process ID directly.

Likely cause, not yet proven: the shared GetFocusedElementAsync implementation calls CUIAutomation8.GetFocusedElement() and rejects a result whose own process ID differs from the requested app. A focused child reporting PID 0 would be rejected even when its parent window identifies the target app. The method also converts query exceptions to null, so instrument the exact COM call before assigning the cause conclusively. The independent probe used managed UIA, not the CLI's exact COM call.

Source inspected: UiAutomationService.GetFocusedElementAsync.

Expected behavior

get-focused should correctly identify a focused control belonging to the selected app, including when ownership can be established through its parent window rather than its own process ID.

Recommended investigation/fix:

• Confirm whether the exact CLI COM call returns a focused element with PID 0 or encounters a query failure.
• If the PID check is responsible, establish target membership through verified UIA ancestors when direct ownership information is missing.
• Preserve app/window scoping and rejection of unrelated apps; do not remove ownership checks or weaken input safety guards.
• Distinguish a focus-query failure from a successful finding that focus belongs elsewhere.
• Add regression coverage for missing child process identity, valid parent ownership, and unrelated focus. Repeat the sandbox/local checks, including owned popups.

Screenshots

N/A. Reproduction uses structured focus, property, foreground-window, and independent UIA results.

OS Version and details

CLI: 0.6.3-prerelease.52 on both targets. Windows host and managed Windows Sandbox: native ARM64. Guest OS: Windows build 28000. Sandbox viewer connected and interactive for the focus trials.

Local comparison used the existing registered Daylight installation with explicit user approval; its exact Git revision was not independently verified. No app code changes, saved edits, resets, or reinstalls were made. The local test instance was closed after canceling the blank editor.

Start in src/winapp-CLI/WinApp.UIAutomation/Services/UiAutomationService.cs at GetFocusedElementAsync, then run the listed sandbox focus sequence and inspect the exact COM result and process identity. Add regression coverage for missing child identity, valid parent ownership, and unrelated focus; done means get-focused reliably identifies the selected app while preserving scoping and safety checks.