Skip to content

fix(codex): handle current desktop CDP layout - #2281

Closed
yoruuuchan wants to merge 1 commit into
jackwener:mainfrom
yoruuuchan:fix/codex-desktop-cdp
Closed

fix(codex): handle current desktop CDP layout#2281
yoruuuchan wants to merge 1 commit into
jackwener:mainfrom
yoruuuchan:fix/codex-desktop-cdp

Conversation

@yoruuuchan

Copy link
Copy Markdown

Summary

  • deprioritize Codex's auxiliary avatar-overlay CDP target so the main renderer is selected
  • make codex ask track the latest assistant message identity instead of relying on virtualized turn/message counts
  • add regressions for both behaviors

Reproduction

On Windows with OpenCLI 1.8.6 and current Codex Desktop, CDP 9238 exposes both:

  • app://-/index.html?initialRoute=%2Favatar-overlay
  • app://-/index.html

Because both targets otherwise receive the same effective score, /json order can select the overlay. codex status then reports Connected, while codex ask cannot 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 through data-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

  • real Windows Codex Desktop E2E through CDP: askCommand.func(..., timeout: 60) returned DIRECT60_OK
  • JS syntax checks passed for the modified Codex command and regression test
  • regression tests added for CDP target selection and response detection

Local 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.

@jackwener

Copy link
Copy Markdown
Owner

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 src/browser/cdp.ts core behavior, not adapter-local. There is also a narrower dedicated PR for the same root cause: #2244, which breaks ties generically toward the unrouted main Electron document instead of hard-coding the Codex avatar-overlay route. That is the smaller/Ockham fix for #2242.

This PR also bundles a separate codex ask response-virtualization change in clis/codex/ask.js. That may be a real adapter fix, but it should be split and reviewed on its own evidence rather than merged together with a superseded core target-selection change.

Local exact-head checks I ran for this PR:

  • npm run build -> PASS
  • npx vitest run clis/codex/ask.test.js clis/codex/sidebar.test.js src/browser.test.ts -> 58/58 PASS
  • node dist/src/main.js validate codex -> PASS, 16 commands

Current-main merge-tree also reports overlapping edits in src/browser.test.ts, so it is not a clean lane C merge candidate.

@jackwener

Copy link
Copy Markdown
Owner

#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.

@jackwener jackwener closed this Aug 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants