probe treats Codex avatar-overlay CDP target as a full app window

[fu1104759681-lang]

Summary

@codedrobe/core@0.6.1 treats Codex Desktop's hidden avatar-overlay CDP page as a complete Codex application window. The main window passes all adapter and theme-required selector checks with zero warnings, but the overlay lacks the main root/sidebar/composer nodes, so the overall probe exits with failure and blocks apply/verify.

Environment

• Windows
• Codex Desktop: 26.715.4045.0
• CodeDrobe Core: @codedrobe/core@0.6.1 (temporary execution, not globally installed)
• Local DevTools endpoint: http://127.0.0.1:9345
• Theme id/version: vr-business-future@2.0.0

CDP targets

The DevTools endpoint exposes two page targets:

1. Main window: app://-/index.html
2. Hidden overlay: app://-/index.html?initialRoute=%2Favatar-overlay

Only one normal Codex window is visible in the Windows UI; the second target is an internal hidden overlay.

Steps to reproduce

1. Start Codex Desktop with remote debugging enabled on a loopback port.
2. Confirm /json/list exposes both the main app://-/index.html target and the initialRoute=/avatar-overlay target.
3. Run theme inspect for a valid Codex theme.
4. Run theme probe against the DevTools endpoint.

Actual behavior

• The main window is fully compatible.
• Root, sidebar, main, composer, and all theme-required selectors match on the main window.
• The main-window result has zero warnings.
• Core also performs full-window required-node checks against the avatar-overlay target.
• The overlay is missing main-window-only nodes, causing the aggregate probe result to fail.
• probe does not expose a target URL or target id filter, so there is no supported way to restrict the operation to the main window.

Expected behavior

Internal non-main-window targets such as initialRoute=/avatar-overlay should not cause the complete Codex application compatibility check to fail.

Suggested fixes

Any of the following would unblock the safe workflow:

• Ignore page targets whose URL contains initialRoute=/avatar-overlay by default.
• Select only the canonical main app://-/index.html target for full-window adapter/theme checks.
• Detect overlays as a separate target type and run only checks applicable to that surface.
• Add a target URL/target id include-or-exclude option consistently to probe, apply, and verify.

Safety impact

The documented safe workflow requires a successful inspect -> probe -> apply -> verify sequence. Because the aggregate probe fails, applying the otherwise compatible theme would require bypassing the compatibility guardrail. No forced apply was attempted.

[anhao]

@fu1104759681-lang

Thanks for the excellent report — the target list, version, and URL details made this straightforward to confirm.

Root cause. You identified it exactly: the Codex adapter matched every app:// page, so the hidden initialRoute=%2Favatar-overlay surface (a feature-gated overlay window that newer 26.715 builds create at startup) was checked as if it were a main window. We reproduced your exact failure against a real 26.715 renderer: the main window passes with zero warnings while the overlay fails adapter:root, and the aggregate probe exits non-zero.

Fix — shipped in 0.7.0-beta.0. Two layers, matching your first and third suggestions:

The Codex adapter no longer matches the avatar-overlay target (encoded and literal route forms), so it is excluded from probe, apply, verify, watch, and screenshots.
More generally, probe and verify now judge compatibility per window, the way apply always has: a secondary window missing the main-window DOM is reported with "skipped": true instead of failing the run, and the command fails only when no window qualifies. verify never skips a window the theme is installed on, so real regressions still fail. This means the safe inspect → probe → apply → verify workflow stays intact even if future builds introduce other hidden surfaces before we ship an explicit exclusion.
We held off on a target URL/id filter option for now — with per-window judgment the workflow shouldn't need one — but we're open to adding it if a concrete case calls for it.

Could you verify on your setup?

npx --yes @codedrobe/core@0.7.0-beta.0 probe --app codex --port 9345 --json

Expected: only the main app://-/index.html target in the output, exit code 0, and the full apply/verify flow unblocked (no forced apply needed). Once you confirm, we'll promote the same content to 0.7.0 on latest.