[Windows][Browser] claimTab outcome is lost across transport reset; exactly-once settlement/readback required
Disclosure: This issue is being submitted by the user's Codex assistant with the user's explicit authorization. It is sanitized: no private URLs, page content, account data, credentials, cookies, tokens, profile internals, raw history, or raw runtime dumps are included.
What version of the Codex App are you using?
OpenAI.Codex 26.820.7780.0 on Windows x64.
Bundled Browser/Chrome plugin: 26.820.60940.
CUA runtime package: @oai/browser-desktop 0.1.0.
What issue are you seeing?
browser.user.claimTab() can be dispatched successfully, but if the observer/native transport resets before the promise settles, the current runtime rejects and clears the pending request. The actual browser-side outcome is then permanently unobservable.
This is more specific than a generic transport closed failure (related: #25848): retrying is unsafe because the original claim may have succeeded. A second claim/client/session/tab can duplicate ownership or corrupt task-tab lifecycle state.
The current trusted service and the separately installed CUA service expose only the uncorrelated claim shape:
- client command:
browser_user_claim_tab(browser_id, tab_id); - native method:
claimUserTab(tabId); - no immutable claim operation id;
- no claim-result readback method;
- no rehydrate method;
- transport close rejects all pending requests and clears the correlation map.
The installed Browser plugin service and CUA service were independently inspected and reproduce the same missing capability. There is no supported local extension point that can preserve a result after the owning native request map has been cleared. A client wrapper, adapter, second browser client, or patched minified cache cannot safely repair this owner boundary.
Deterministic reproduction
- Use an already-open user tab on a connected Chrome surface.
- Dispatch exactly one
browser.user.claimTab(tabId)operation. - Reset or lose the native observer transport after dispatch but before settlement is returned.
- Reconnect without dispatching another claim.
- Attempt to determine whether the original claim succeeded.
Actual: there is no supported correlated readback. The operation remains indeterminate forever.
Expected: reconnect/readback returns the terminal state of the same immutable claim operation without calling claimTab, tabs.get, tab creation, or browser/session initialization again.
Required owner-level semantics
Please route this to the Codex Browser/native-transport owner. The minimal backward-compatible contract is:
browser_user_claim_taband nativeclaimUserTabaccept immutableclaim_operation_id,correlation_id, andruntime_request_idin addition to the current browser/tab identity.- Native/extension-owned state atomically records
prepared -> dispatched -> terminal, independently of the observer pipe. - Terminal status is exactly one of
claimed,rejected,cancelled_before_dispatch, ortransport_lost_outcome_unknown, committed before attempting the observer reply. - Repeated dispatch for the same operation id is idempotent;
claim_dispatch_countremains1. getClaimOperation(claim_operation_id)returns sanitized durable state and never invokes claim, tab enumeration, or tab creation.- Rehydrate binds the already-owned tab only after terminal readback
claimed; it creates no second client/session/tab and performs no navigation. - Observer timeout/disconnect is nonterminal. Cancellation becomes terminal only after native acknowledgement that dispatch never occurred.
- Duplicate terminal callbacks are idempotent and measurable.
Required sanitized telemetry: operation/correlation ids, component build, queue/dispatch/settle/pending-age timing, observer timeout count, late settlement count, duplicate callback count, dispatch count, transport disconnect class, and monotonic terminal timestamps. It must exclude URLs, page content, cookies, tokens, OAuth material, profile internals, and raw history.
Acceptance criteria
- one dispatch only;
- observer timeout is nonterminal;
- late terminal callback survives transport reset;
- reconnect readback returns the same terminal operation;
- rehydrate uses the same tab and performs zero claim/tab-get/new-tab/new-client/new-session fallbacks;
- duplicate callback is idempotent;
- zero browser/UI/navigation/external mutation is required for the capability smoke;
- the fix ships as a signed versioned OpenAI component, not an unsupported cache patch.
Please return the signed Codex app / Browser plugin / @oai/browser-desktop build identifiers containing the fix and the supported activation/update route. A local verifier and adversarial fixture packet are available privately if an OpenAI maintainer requests them.
1 Comment
Follow-up revalidation on the current signed Windows build (sanitized; no private URLs, account data, credentials, cookies, tokens, profile data, history, or raw dumps):
The local lifecycle verifier still fails exactly one required gate:
installed_runtime_has_persisted_correlated_claim_settlement_capability
Both the configured trusted service and current CUA service still show all five signals missing: no claim_operation_id in client or service schema, no claim readback, no rehydrate, and transport close still rejects/clears pending requests. Fixture/adapter behavior remains green, but it cannot fabricate the lost native outcome.
The local owner verifier now resolves current installed bundle/runtime paths fail-closed and binds the current component hashes; it passes 9/9. No browser/UI/navigation/profile/external action was performed.
Please confirm whether this signed build was expected to include the owner-side capability. If not, the original requested API/terminal-state/readback/rehydrate contract remains required.