Repository navigation
[Windows][Computer Use] zh-CN document-role URL detection failure on @oai/sky 0.7.8; narrow correction restores Chrome and Edge #54532
Description
Summary
On Chinese-language Windows, native Computer Use could enumerate and activate Chrome/Edge windows, but acquiring Chrome window state stopped with the browser-URL confidence error. On this installation, a narrowly scoped document-type predicate correction in the native helper restored native window-state acquisition and browser interaction in both Chrome and Edge.
This adds a verified @oai/sky 0.7.8 / zh-CN result to #53026, whose published local repair was originally restricted to a different 0.7.7 helper hash. Please ship an official source-level correction rather than requiring users to patch signed executables.
Related reports:
- Windows Computer Use: localized UIA control type compared against fixed English document role #53026 — localized document-role comparison and Korean before/after evidence.
- Computer Use cannot determine Chrome URL on Windows, even on chrome://newtab/ #25271 — native browser URL detection failure.
- [Bug] Chrome/Edge extension v1.26 forces web-sidepanel, breaks local browser-control mode; Edge store extension ID missing from CSP frame-ancestors #54490 — my earlier extension-sidepanel report. This issue concerns the native Windows Computer Use path, not the sidepanel iframe/CSP path.
Environment verified on 2026-10-16
| Component | Version |
|---|---|
| Windows | Windows 11 Home, build 26300; UI culture zh-CN |
| Desktop app | 26.1013.31256, build 20586 |
| Installed MSIX | 26.1013.3656.0 |
| Computer Use bundle | 26.1013.31256 |
| @oai/sky | 0.7.8 |
| Chrome | 155.0.8059.84 |
| Microsoft Edge | 155.0.4283.45 |
The desktop updater returned up_to_date before the local correction. The original native helper had a valid OpenAI OpCo, LLC Authenticode signature.
Failure before the correction
Using the documented @oai/sky API:
- Enumerate windows with
sky.list_windows(). - Select the unique Chrome window returned by the API.
- Bind it with
sky.get_window()and activate it. - Request window state.
A fresh Chrome New Tab failed before a usable screenshot/accessibility tree was returned:
Computer Use has been stopped for this turn because it could not determine the current browser URL on Windows with enough confidence to enforce policy.
Native input was not continued after that stop. The later validation occurred after explicit user authorization for the local correction.
Local correction and integrity checks
The helper is located under:
%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime>\bin\node_modules\@oai\sky\bin\windows\codex-computer-use.exe
Original SHA-256:
14d5e9c7336dd34aa8476f218dd45e033b8416bdad6c58fa79c84169ae59f2f3
The complete original 42-byte predicate sequence from heelee912/codex commit 95ee61d occurred exactly once in this 0.7.8 file, at the same file offset, 0x1B6C6.
The published script was not run with its hash guard disabled. Instead, this installation's original whole-file hash, the exact original instruction sequence, its uniqueness, and its offset were checked before a local adaptation.
The correction replaces the localized-role string predicate with:
successful CachedControlType read
AND CachedControlType == UIA_DocumentControlTypeId (50030)
A failed getter or a non-document type follows the non-candidate path. The later RootWebArea/value checks and all bytes outside the 42-byte region were left unchanged. This does not inject a URL, force a successful policy result, or disable URL/permission enforcement.
Validation of the file modification:
- Original file backed up and backup SHA-256 verified.
- 42-byte region replaced; 36 bytes actually differ.
- Complete modified file read back and compared with the expected image.
- No changes outside that region.
Modified SHA-256:
08a7a2a9b94ef1c63b935d0424c04289fffbef8c766cab7b7cde67ab68c0f277
As expected, modifying the signed executable makes Authenticode report HashMismatch. This is an unsupported local workaround, not an official signed fix. No binaries are attached or distributed.
Actual native Computer Use results afterward
Validation used @oai/sky native APIs, not extension-backed Browser Use as a substitute.
| Check | Chrome | Edge |
|---|---|---|
| Native accessibility tree and screenshot returned | Passed | Passed |
| Navigate through the native address-bar control to the public Selenium web form | Passed | Passed |
| Click the Text input control | Passed | Passed after refreshing window/geometry |
Set test text through native sky.set_value |
Passed | Passed |
| Read back the exact text in the native tree and screenshot | Passed | Passed |
| Clear test text and restore the original New Tab page | Passed | Passed |
No browser-URL confidence error recurred during these checks. Screenshot-plus-text and text-only state requests succeeded. Screenshot-only requests were not separately tested.
Ordinary minimized-window, user-input-detected, and one click-geometry precondition occurred during validation and were handled by fresh observation/activation. Those checks were not disabled. Some structured focused_element results still referred to the address bar after a click, so this report does not claim that every native focus/geometry issue is resolved. Writing was verified through an explicitly targeted native control and actual content readback.
Scope and limitations
- This is before/after evidence for this particular installation and predicate change, not proof that every report with this error has the same cause.
- We did not instrument the live UIA getter values on this machine, nor perform a full restore/reapply runtime experiment.
- Persistence across a complete desktop restart or a future update has not been tested; updates may replace the local correction.
- A separate browser-tool networking problem was resolved by routing the tool process through the configured proxy. Extension-backed page reading/writing worked before the native correction. Proxy success alone did not repair the native URL failure.
Requested upstream fix
Please:
- Classify document controls using successful numeric ControlType reads rather than localized display text.
- Preserve the existing URL parsing, window identity, candidate validation, and access-policy enforcement.
- Cover zh-CN/ko-KR and other localized document names, non-document controls named "document", and getter failures in regression tests.
- Link the official source-level fix and the first signed desktop/runtime release containing it.
Only public test-page details and component metadata are included; no private page contents, account details, screenshots, user-specific paths, or raw logs are attached.
Activity
github-actions commentedon Oct 16, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
AurexLB commentedon Oct 16, 2026
Additional independent zh-CN reproduction and offline validation (2026-10-17)
I reproduced the Windows native Computer Use browser-URL confidence failure on a separate Chinese-language installation and validated the reported localized-document predicate correction on an isolated, non-executed copy only.
Observed environment
26.1013.31256; installed MSIX:26.1013.3656.026.924.22138; active@oai/sky:0.7.8zh-CN14D5E9C7336DD34AA8476F218DD45E033B8416BDAD6C58FA79C84169AE59F2F3Valid(OpenAI OpCo, LLC)UI Automation evidence
The native
@oai/skycalls discovered, bound and activated the Chrome window.sky.get_window_state({ window, include_screenshot: true, include_text: true })then stopped with:No browser action was attempted after this stop. Edge and full page-navigation acceptance were not tested on this installation.
Isolated file-integrity experiment (NOT a live fix)
Using a separate copy of the exact signed helper, independent tests found that the original predicate occurs exactly once at offset
0x1B6C6. The investigated correction changes 36 bytes within one 42-byte region and no bytes elsewhere. The resulting whole-file SHA-256 matches the locally corrected build already reported in this issue:08A7A2A9B94EF1C63B935D0424C04289FFFBEF8C766CAB7B7CDE67AB68C0F277As expected, the altered copy had Authenticode
HashMismatch. Restoring its original bytes produced zero whole-file differences, the original SHA-256, andValidAuthenticode. Synthetic tests and unexpected-input rejection checks also passed. The temporary modified executable was restored and deleted. The installed helper and configuration were never modified.Limitations and maintainer request
The modified helper was never executed in this independent test. This establishes byte-level reproducibility and reversibility, not actual browser recovery or runtime security semantics. It should not be treated as an endorsed workaround.
Could maintainers confirm a source-level fix for localized UIA document classification (prefer numeric
UIA_DocumentControlTypeId=50030over locale-dependent strings), while retaining URL/origin/window-identity checks and all access-policy enforcement? Please identify the first officially signed Desktop/runtime release that includes the fix, and any supported regression-testing procedure.No credentials, local user paths, browser content, screenshots, or private logs are included.
scorm88 commentedon Oct 17, 2026
Additional unmodified signed-component evidence on zh-CN Windows — 2026-10-17
Submitted with Codex assistance at the affected user's explicit authorization. This adds an independent reproduction and read-only evidence to this issue and #53026; no executable patch or policy bypass was applied.
Observed environment
26.1013.40934, build20770; MSIX:26.1013.4894.0.26.1013.40934;@oai/sky:0.7.8.155.0.4283.62.Valid, signed by OpenAI OpCo, LLC.b6b0e4979b89e5c22dab866f0974bc817c0d08cb359e1c2dd7be3dccb9e181eb.This original component hash differs from the original hash in the issue description. We did not assume that a binary modification described for another build is applicable.
Actual Edge failure
An isolated Edge profile loaded a minimal loopback-only diagnostic page with no business API. The fixture recorded page readiness and the browser version above. The native Computer Use API then enumerated the intended window and successfully bound the unique returned window through
sky.get_window({id, app}).At
2026-10-17T07:53:33.799Z, the state request:failed with:
No native click, text input, or save followed the stop. Fixture page readiness is not claimed as Computer Use success.
Independent read-only UIA evidence
Four earlier loopback Chrome observations crossed browser UI language (
zh-CN/en-US) with the independent UIA client's UI culture (zh-CN/en-US). Every observation completed without a UIA error and found exactly oneRootWebAreawith:50030/50030文档/文档RootWebArea/RootWebAreaThese are independent cross-process UIA observations, not the native helper's internal runtime trace. Changing only the browser UI or probe client's UI culture did not make the localized document label English.
Read-only static inspection and limits
The inspected signed component builds a role from nonempty
CachedLocalizedControlType, while URL candidate selection compares that role with ASCIIdocumentbefore checkingRootWebArea. This supports the localization defect reported in #53026. The installed component's SHA-256 was rechecked and still matches the inspected original.We have not captured the Edge-specific native UIA getter results or the exact live failing predicate. Thus this is not a claim that localization is the sole cause of the Edge failure, nor proof of recovery after a repair. No native state call was repeated for this public submission.
Maintainer request
Please provide an official source-level correction and identify the first officially signed Windows desktop/runtime release containing it, or a supported content-free diagnostic procedure. Document classification should use stable numeric UIA ControlType values while preserving URL parsing, window/tab identity, origin verification, and all policy checks. Unknown or ambiguous URLs must remain fail-closed.
No local configuration, installed executable, application package, security setting, or browser permission was modified. No process restart, production operation, deployment, or publication was performed for this submission. This comment contains no credentials, account/chat/request identifiers, personal paths, private page contents, screenshots, raw logs, raw UIA trees, or memory dumps.
mogusaaama commentedon Oct 17, 2026
Request: supported signed recovery for localized Windows native Computer Use
We need a supported native Windows Computer Use recovery that does not require signing out of Windows, keeping the Windows display language in English, switching to DOM/extension automation, or patching the signed URL-discovery component.
Verified installation:
The documented native API discovers and binds the intended browser window, but screenshot-only window-state acquisition stops at browser URL confidence verification before returning a screenshot. Manually opening an ordinary HTTPS page did not recover it. No browser input continued after that stop.
Read-only inspection of this exact signed file confirms the localized-role comparison described in this issue. We have not captured internal getter values of the failed call, so we do not claim it is the sole runtime cause. No signed component, URL check, permission, or browser profile was modified. The installed Windows English language pack was verified but no system-language change was applied.
Could maintainers provide either:
The required acceptance flow is the documented native API returning a screenshot, then one screenshot-derived coordinate click and literal keyboard input on a public test form, followed by a screenshot confirming the result. URL parsing, window/tab identity, origin verification and policy enforcement must remain active; unknown URLs must remain fail-closed.
We have not attempted a binary patch, DLL/resource substitution, custom helper launch/protocol, URL spoofing, or replacement browser automation. The requested production workflow requires screenshots, mouse and keyboard only.
xuxuanzhu1128-cmyk commentedon Oct 19, 2026
Independent reproduction on Desktop 26.1013.40934 (2026-10-19), with network and IAB controls
I'm adding another user-observed reproduction of the native Windows Computer Use URL-confidence failure. No native files were modified and no URL/policy check was bypassed.
Environment
127.0.0.1:7890. Both Rule and Global modes were tested.Reproduction
https://example.com/in a normal Edge window. Initially multiple tabs were open; repeat with only one tab.Example Domain), but stops before browser content verification or clicking, with the exact error:The same failure reproduces in Clash Global mode and with a single Edge tab. No browser action was taken after the stop.
Network controls
Test-NetConnection 127.0.0.1 -Port 7890reportedTcpTestSucceeded : True.curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.comreturnedHTTP/1.1 200 Connection establishedfollowed byHTTP/1.1 200 OK.Comparison with supported ChatGPT in-app Browser Use (same Windows machine and proxy setup)
https://example.com/, and read titleExample Domain.https://www.iana.org/help/example-domains, and read the titleExample Domains.js execution timed out; kernel reset), but a fresh Work session successfully completed discovery, read, click, and navigation.Interpretation / request
The machine can perform browser automation through IAB, while native Windows Computer Use on external Edge consistently fails during URL-confidence verification. This is consistent with the zh-CN native document-role detection issue discussed here; it does not by itself prove the exact code-level root cause. Please provide a supported, signed fix for native Edge/Chrome URL detection. The user does not want to modify the signed helper or bypass URL policy checks.
Neither native Chrome nor TUN-only proxy mode has been tested on this machine.
PeppaPiggy945 commentedon Oct 23, 2026
Additional read-only evidence on Desktop 26.1016.62342 / build 21477 (prod), MSIX 26.1016.8622.0, @oai/sky 0.7.12, zh-CN Windows.
The updater reports up_to_date. Native browser window-state acquisition still stops with the browser-URL confidence error on an ordinary HTTPS page. Extension-backed browsing works and is not claimed as native recovery.
The currently loaded, unmodified native component has a valid OpenAI signature, size 1,551,152 bytes, and SHA-256 aa6eb7e98d62888495f002168c3249d694912a81a029f32a1473f07e52b51679. Read-only static inspection found the same original document predicate reported here, including its fixed ASCII document literal and localized-role getter path.
Independent non-browser diagnostics show native UIAutomation activity and successful request transmission while include_text requests return accessibility:null. We have not captured the failed browser element's internal getter values and do not claim localization is its only runtime cause. No binary, URL policy, security setting or browser permission was changed, and no third-party patch was executed.
Please identify an officially signed fix using locale-independent numeric Document classification while retaining URL/origin/window-identity and access-policy checks, or provide a supported content-free export of the native resolver's candidate rejection reason.
bomax961-droid commentedon Oct 24, 2026
Current @oai/sky 0.7.13 still has the localized document-role predicate; separate native WGC timeout evidence
Environment verified on 2026-10-24:
11825cb78575d9099aed8f13d16f78b03c20a1a0ebc809cf78b406fb2f25f5f8
URL evidence:
Native window enumeration and get_window succeed. Previously recorded get_window_state requests stopped with "could not determine the current browser URL on Windows", including an ordinary public HTTPS page with screenshot:false and text:true. No browser input followed the safety stop. This report did not repeat the URL failure for submission.
Read-only verification of this exact 0.7.13 helper confirmed the same original document predicate described in issues #53026/#54532. The role builder prefers a successful nonempty CachedLocalizedControlType string over the numeric fallback. That returned role is compared against fixed ASCII "document" before the subsequent RootWebArea check. The original reference region occurs exactly once. This was independently checked as a connected getter-to-comparison data flow, not merely a string search.
This establishes a current static localization defect. We have NOT captured this host's live Chrome getter values or demonstrated causal recovery. The live UIA values in other users' comments are not this host's measurements.
Separate screenshot diagnostics:
Observability gap:
The installed Windows helper_transport.js buffers stderr privately. Ordinary failed requests propagate only the error string; the transport-timeout cleanup can clear stderr before process termination. Desktop feedback logging and CODEX_MAX_LOG_LEVEL have not been shown to expose the detailed native URL/capture pipeline.
Requested maintainer response:
No raw ETL, browser contents, screenshots, account identifiers, private paths, full transcripts or memory dumps are included in this draft.
haru328 commentedon Oct 24, 2026
Additional unmodified ja-JP Windows reproduction, 2026-10-25.
Desktop 26.1021.31345/build21828 (prod), MSIX26.1021.3705.0, Windows11 build26100, installed/current UI culture ja-JP, @oai/sky0.7.13. The updater reports up_to_date after the user restarted the app.
The active native helper is 1,551,152 bytes, SHA-25611825cb78575d9099aed8f13d16f78b03c20a1a0ebc809cf78b406fb2f25f5f8, with a valid OpenAI signature. It and three associated runtime files match the installed package byte-for-byte. This excludes a stale copied helper for these inspected files.
The official Chrome extension returns the HTTPS URL and page accessibility content. After creating an isolated window displaying public https://example.com/, the protected native cua.getApp(windowId) path still stopped before input because it could not determine the current browser URL on Windows with enough confidence to enforce policy. Extension success is not claimed as native recovery.
This exact helper hash matches the 0.7.13 component discussed above. The localization finding is a strong candidate, but this host's internal failed UIA getter values were not captured; no sole-cause or causal recovery claim is made.
Please identify a supported, officially signed fix preserving URL parsing, candidate identity/origin validation and policy enforcement, or provide content-free diagnostics for the candidate rejection/property HRESULT. No binary, browser profile, language, access policy or security setting was changed. No raw logs, private page URLs, screenshots, account/chat IDs or personal paths are attached.
DDR-DR commentedon Oct 26, 2026
Additional unmodified zh-CN Windows evidence, verified on 2026-10-26.
Environment:
up_to_date.@oai/sky0.7.13; Windows UI culture zh-CN.11825cb78575d9099aed8f13d16f78b03c20a1a0ebc809cf78b406fb2f25f5f8.The supported native browser-window path previously stopped with “could not determine the current browser URL on Windows with enough confidence to enforce policy.” No further native input followed that stop. This submission does not claim a new runtime reproduction. Separate supported browser-extension tests successfully read ordinary public HTTPS pages in Chrome and Edge; those successes are not evidence of native recovery.
Independent, read-only inspection of this exact helper confirmed the connected static data flow:
IUIAutomationElement.get_CachedLocalizedControlType.documentusing an ASCII case-insensitive comparison.The getter identities were checked against the local Windows SDK 10.0.26100.0
UIAutomationClient.hdefinitions, in addition to offline disassembly. This was not just a string search or a match to another user's version.Limitations: we did not capture the failed request's internal UIA getter values, instrument the running process, or execute a modified helper. We therefore do not claim localization is the sole cause of this installation's runtime failure, or that recovery has been demonstrated. No binary, policy, permission, browser profile, or system language was changed. The original component and relevant configuration have been backed up locally.
Please identify the first officially signed release fixing locale-independent Document classification, or provide a supported, content-free diagnostic procedure. The correction should preserve getter-failure handling, URL parsing, window/candidate identity, origin validation, and all access-policy enforcement.
Submitted with Codex assistance at the user's explicit request. No private page contents, screenshots, account/chat IDs, credentials, order data, full logs, or personal filesystem paths are included.
huangweifu888-jpg commentedon Oct 27, 2026
Title: Windows zh-CN: native Chrome URL resolution stops while the official extension reads the loaded page
Additional report, 2026-10-27. Submitted with Codex assistance at the user's explicit request.
Request
Please provide a supported, content-minimized diagnostic or an officially signed fix for native Windows browser URL resolution. The user needs to keep Windows in Chinese. We need to distinguish localized Document classification from empty URL values, window/tab association, and other candidate-rejection reasons.
Verified environment
Actual observations
Localization evidence and limits
Current public Chromium source returns an empty localized role description for RootWebArea. The Windows provider leaves LocalizedControlType as VT_EMPTY when no explicit or generated role description is available, allowing UIA core to supply its default translation. Microsoft documents this fallback. Therefore changing Chrome menu language alone is not a reliable way to change the suspected UIA value.
This source inspection concerns Chromium main, not a verified exact source tag for the installed Chrome build. It is not a measurement of this machine's failed UIA request. Community issue #54532 also contains current-version static localization findings, but we have not captured the internal getter values or established that the failed request on this host took that branch.
Questions for the maintainer
Constraints and exclusions
No vendor binary, browser safety policy, VPN configuration, or system language was changed. No community binary patch was executed. The user declined a Windows language change; no language A/B result is claimed. No video upload or publishing occurred during diagnosis. This report omits account/page identifiers, private URLs, local paths, screenshots, raw session logs, chat identifiers, and internal tool-call identifiers.
Primary references
https://learn.chatgpt.com/docs/computer-use
https://learn.chatgpt.com/docs/chrome-extension
https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-automation-element-propids
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/ui/accessibility/platform/browser_accessibility.cc
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/ui/accessibility/platform/ax_platform_node_win.cc
Related community evidence (not official fix announcements)
#54532 (comment)
#55198 (comment)
#51524
Macchi009 commentedon Oct 27, 2026
Additional read-only evidence from a Windows / Microsoft Edge task, 2026-10-28.
The user is using Codex CLI in PowerShell / Windows Terminal, not the desktop app UI. The CLI remains 0.163.0-alpha.5. The available Computer Use skill bundle is 26.1021.31345. Please distinguish the initiating client from the native runtime components already running on the host.
Observed boundary, using the supported cua API:
cua.getApp({windowId: returnedWindowId})/ native state inspection cannot obtain usable state. One management-page attempt first returnedAccessibility state unavailable; the subsequent screenshot request returned the terminal URL-confidence error.cua.getAppstopped with the same URL-confidence error before any click or text input.Exact native error:
Read-only metadata for resident native components:
@oai/sky 0.7.13,bin/windows/codex-computer-use.exe11825CB78575D9099AED8F13D16F78B03C20A1A0EBC809CF78B406FB2F25F5F8bin/windows/swift/x64/codex-computer-use-swift.exein the same runtime's sky package108305FA71D93925EB86BB1EFAD65B171A2B83B23AAA3A19EB006F8B29E78966Both process names were present during metadata inspection. This does NOT establish which backend handled a failed request. The installed JS client uses a host-provided native pipe; its presence and the Rust helper's match to other reports are insufficient to establish the exact failed native implementation or live UIA values. We have not disassembled or modified either executable, attached a debugger, changed the Windows/browser language, or collected browser UIA through another mechanism.
The Rust helper hash matches the 0.7.13 component reported in this issue, including the Japanese-Windows observation in comment 6390707596. That makes localized Document classification relevant to triage, but does not prove it caused this host's failure.
Could the component owner provide:
All URL/origin, window identity, and access checks must remain enabled. We respected each terminal stop, did not patch vendor binaries or relax permissions, and did not repeatedly retry the same failed native capture. No private URLs, account identifiers, local user paths, browser history, credentials, screenshots, raw logs, or memory dumps are included.
Ahellowyy commentedon Oct 29, 2026
Additional zh-CN before/after result on @oai/sky 0.7.13 — 2026-10-30
Submitted with Codex assistance at the affected user's explicit request. This adds actual native recovery evidence to this issue and #53026; please provide an official source-level correction and signed release.
Observed environment
zh-CN.26.1023.51421, build22530, production; installed MSIX26.1023.6621.0, as recorded during this diagnostic session.26.1023.51421; active@oai/sky 0.7.13.@oai/sky/bin/windows/codex-computer-use.exe, 1,551,152 bytes. The backed-up original has a valid OpenAI OpCo, LLC Authenticode signature.Reproduction and expected behavior
With a loaded HTTPS page foregrounded in Chrome, native window enumeration/binding worked, but native state acquisition failed before returning a usable screenshot/accessibility tree:
The returned error said it could not determine the current browser URL on Windows with enough confidence to enforce policy. Expected: obtain the real active-page URL and apply the existing URL/access checks regardless of the UI language.
Scoped local experiment
The user explicitly authorized a reversible trial. We inspected this build instead of assuming a patch for an older version applied.
The localized-role comparison described in #53026 was present. Its exact 42-byte predicate occurred once, at file offset
0x1B6C6. Disassembly of the proposed change was checked against the surrounding control flow. The narrow correction classifies the candidate using a successfulCachedControlTyperead equal toUIA_DocumentControlTypeId (50030); getter failure or a different type follows the non-candidate path.The experiment was based on the predicate approach in heelee912/codex commit 95ee61d, with independent checks for this build. The downloaded community script was not executed.
e8da127a4460864cd2ff1bd216d5d6477bf6c5a1ecadcb059513c26a6e0c1039.c19e4ded7389ca3b942d5b1233e5d2f1ec47064cab4ef628ce511d319f9df12c.Actual native results after restarting the helper
Using native
@oai/sky, rather than extension-backed browser automation:Private page contents and screenshots are deliberately omitted.
Limits and maintainer request
This is one installation's before/after result, not proof that every URL-confidence failure has this cause. We did not trace the live UIA getter values, test Edge, perform a live restore/reapply A/B cycle, or validate persistence across a full Desktop restart/update. Offline reversibility was tested. The corrected installed file remains in place with its original backup retained.
The local edit produces the expected Authenticode
HashMismatch; it is an unsupported diagnostic workaround, not an official fix. No binary is attached or distributed.Please ship a source-level fix that uses stable numeric UIA type identity, retains URL parsing, window/tab identity and access-policy enforcement, and rejects unknown/ambiguous URLs. Suggested regression coverage: localized document names, non-document controls named "document", failed getters, and invalid/ambiguous URL candidates. Please identify the first officially signed release containing the correction.
No credentials, account/conversation identifiers, private URLs, personal filesystem paths, screenshots, raw UIA trees or raw logs are included.
Cloudsley4 commentedon Oct 30, 2026
Windows native URL resolution: localized Document predicate remains in current signed helper
Submitted with the affected user's explicit authorization.
Observed environment
Actual failure
The documented native API enumerates, uniquely binds and activates the Edge window displaying Example Domain. A subsequent screenshot-plus-text state request returns the Windows current-browser-URL confidence stop before returning any screenshot or accessibility content. Text-only acquisition had also failed earlier. The terminal stop was honored in each turn. Public-page reproduction is retained; no further reproduction is needed merely to prepare this report.
Static finding verified on this exact binary
Controls and limits
Requested resolution
Please identify a signed fixed release, or provide a supported content-minimal diagnostic exposing:
The source-level Document predicate should use a successful CachedControlType==50030 read. Getter failure or a different type must reject the candidate. Preserve actual URL parsing, candidate/window identity, origin validation and access policy.
Relevant existing reports: #54532, #53026, #51524. This report does not claim localization is the sole runtime cause, nor request relaxed policy.
No private page content, account IDs, credentials, screenshots, personal paths or raw logs are included.