Repository navigation
probe treats Codex avatar-overlay CDP target as a full app window #5
Description
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:
- Main window:
app://-/index.html - 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
- Start Codex Desktop with remote debugging enabled on a loopback port.
- Confirm
/json/listexposes both the mainapp://-/index.htmltarget and theinitialRoute=/avatar-overlaytarget. - Run
theme inspectfor a valid Codex theme. - Run
theme probeagainst 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-overlaytarget. - The overlay is missing main-window-only nodes, causing the aggregate probe result to fail.
probedoes 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-overlayby default. - Select only the canonical main
app://-/index.htmltarget 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, andverify.
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.
Activity
anhao commentedon Jul 21, 2026
@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?
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.