Skip to content

Fix Codex 535 root landmark - #7

Open
gaopengbin wants to merge 2 commits into
CodeDrobe:mainfrom
gaopengbin:fix/codex-535-root
Open

Fix Codex 535 root landmark#7
gaopengbin wants to merge 2 commits into
CodeDrobe:mainfrom
gaopengbin:fix/codex-535-root

Conversation

@gaopengbin

@gaopengbin gaopengbin commented Aug 1, 2026

Copy link
Copy Markdown

Summary

  • preserve the existing main.main-surface Codex root landmark
  • add scoped #root main support for Windows Codex 26.727.6591 (build 535)
  • record the live Windows verification metadata

Evidence

A privacy-safe codedrobe dom snapshot against the live build 535 renderer found one #root main, while aside.app-shell-left-panel and .composer-surface-chrome still matched. The released 0.6.1 and 0.7.0-beta.0 adapters both failed only adapter:root.

With this patch, the same real renderer probe changes from compatible: false to compatible: true, with rootMatches: ["#root main"].

Verification

  • node --test tests/adapters.test.mjs (13 passed)
  • npm run typecheck
  • npm run pack:check

@thc282

thc282 commented Aug 11, 2026

Copy link
Copy Markdown

im think is it possible to using the generic fallback css selector
like in Codex Dream Skin

main:is(.main-surface, [data-app-shell-main-surface], [class*="_MainContentSurface_"])
fallback → main, [role="main"]

@gaopengbin

Copy link
Copy Markdown
Author

Thanks for the suggestion. I checked the generic selectors against the live Windows Codex renderer that motivated this PR.

I kept main.main-surface as the preferred landmark and #root main as the fallback because both remain anchored to the application root. A bare main or [role="main"] is too broad for a blocking app fingerprint: Codex also uses route-level and auxiliary main regions, so those selectors can turn a partial/secondary surface into a false-compatible renderer.

I also considered [data-app-shell-main-surface] and [class*="_MainContentSurface_"], but they were not present in the verified Windows build 535 snapshot. I would prefer adding them after we have renderer evidence from a build that uses them rather than guessing at a hashed-class convention.

I pushed e32ec38 to document this boundary and added regression assertions that reject bare main / [role="main"] fallbacks.

Validation:

  • node --test tests/adapters.test.mjs: 13 passed
  • npm run typecheck: passed
  • Full npm test: 95 passed, 5 existing Windows path failures (for example G:\G:\code\... fixture resolution), unrelated to this adapter-only change.

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