fix(codex): handle current desktop CDP layout - #2281
Conversation
|
Lane C review note: I would not merge this PR as-is. The Codex overlay target problem is real, but the target-selection half is This PR also bundles a separate Local exact-head checks I ran for this PR:
Current-main merge-tree also reports overlapping edits in |
|
#2244 has now merged as the generic core fix for #2242 (main f909f1e), so this mixed PR is superseded on its target-selection half. Closing it to prevent the superseded hard-coded route logic from being merged later. If the Codex response-virtualization problem still reproduces on current main, please split only that adapter-local change into a new PR with its own trace and tests. |
Summary
codex asktrack the latest assistant message identity instead of relying on virtualized turn/message countsReproduction
On Windows with OpenCLI 1.8.6 and current Codex Desktop, CDP 9238 exposes both:
app://-/index.html?initialRoute=%2Favatar-overlayapp://-/index.htmlBecause both targets otherwise receive the same effective score,
/jsonorder can select the overlay.codex statusthen reports Connected, whilecodex askcannot find the composer.After selecting the main renderer, prompts can be sent. Current Codex also virtualizes the thread DOM, so the number of
[data-content-search-turn-key]elements may stay unchanged while a new assistant response replaces the visible turn. Assistant messages expose stable per-message identity throughdata-content-search-unit-key/data-response-annotation-target, which this change uses for polling, with the old turn-count behavior kept as a fallback for older builds.Validation
askCommand.func(..., timeout: 60)returnedDIRECT60_OKLocal Vitest startup was blocked by a Windows Rolldown/native-binding lock in the temporary dependency install, so repository CI is the source of truth for the full test matrix.