Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   mcpIssues related to the use of model context protocol (MCP) serversIssues related to the use of model context protocol (MCP) servers

   browser

   on Oct 20, 2026
2. github-actions commented on Oct 20, 2026

   

   github-actionsBot

   on Oct 20, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • [macOS][Chrome Browser Use] Auth0 page loading stalls with paused-document-response guard; Cancel reportedly releases loading #55166

   Powered by Codex Action
3. mattastovall commented on Oct 21, 2026

   

   mattastovall

   on Oct 21, 2026

   Author

   More actions

   Fresh reproduction on October 20, 2026 at 19:50 CDT (October 21 at 00:50 UTC), after deploying the app-side source-import/rendering fixes.

   • Official app updater: up_to_date; installed version 26.1013.40934, build 20770, prod channel. No fixed/diagnostic build was offered by the updater or posted in this issue.
   • Same existing Figma Animator app and BlueChew audience. No app replacement, permission expansion, or authentication changes.
   • Serving backend commit dcc91a4fa3ec5e4717f5a961211fc925755b061d, revision figma-animator-rdcc91a4fa3ec-cad845610409.
   • A fresh ChatGPT web conversation called animator_open_workspace({}) once with Browser Control attached, without reusing a UI session. The completed deterministic composition was then read without mutation. Both native 9:16 and 16:9 MP4s exist, but neither rendered in this panel.
   • Server-correlated launch: d8f27a2d-8f52-4e23-8150-0f849aa61684; bundle SHA-256 aa4d20bc92a4fdfe49977f4b2fc77e8eb1375c50b592ac43e20db7886a1d0275. Independent read-only MCP status remained awaiting_render_ack, rendered:false, evidence:none.
   • Supported debugger event capture started before launch (cursor 102). It captured Fetch.requestPaused for the sandbox HTML Document, HTTP 200, sequence 140, request interception-job-10491.0. The subsequent filtered read ended at cursor 149, hasMore:false, truncated:false; no later matching events. This is a bounded filtered event capture, not a complete network trace or a continuation-outcome trace.
   • Page.getFrameTree through the supported tab CDP API returned exactly: Raw CDP is unavailable while Browser Use is resolving a paused document response.
   • Visible ChatGPT result: Couldn’t display Figma Animator MCP; the right-side workspace remained blank.

   No Try again, debugger detachment, force-continue command, guard bypass, installed bridge patch, new media generation, or app/audience change was used. Private screenshots are retained locally; no transcript, signed media URLs, headers, cookies, or raw logs are attached.

   Still need bridge-side diagnostics exposing the owned Document continuation's actual completion/rejection/timeout and terminal ownership state, or an official fixed build retaining the guard. The current evidence confirms the failed launch and blocked inspection boundary; it does not identify the internal continuation error.
4. mattastovall commented on Oct 21, 2026

   

   mattastovall

   on Oct 21, 2026

   Author

   More actions

   Minimal control experiment now deployed and reproduced on October 20 at ~22:01–22:16 CDT (October21 ~03:01–03:16UTC). This removes the Figma workspace from the reproduction.

   Same existing MCP registration and audience throughout. Browser Control stayed attached; no Try again, debugger detachment, forced continuation, installed-runtime patch or guard change.

   Control	App content	ChatGPT web result
   Static	506-byte HTML, no JavaScript, SDK, images or external resources	Blank, then Couldn’t display Figma Animator MCP
   SDK	Same small document with bundled @modelcontextprotocol/ext-apps1.1.2, connection status and visible-frame acknowledgment; no Figma, navigation/restoration or generation	Same failure; no visible status, no acknowledgment
   Standards-only SDK	Identical SDK HTML bytes; bypasses production registration/result wrapper; only _meta.ui.resourceUri, standard resource MIME and empty connect/resource CSP lists	Same failure

   The SDK control connects and acknowledges a visible frame in an isolated local browser with the official AppBridge host. That is a protocol control, not ChatGPT rendering proof.

   The standards-only descriptor is deliberately minimal:

   server.registerTool(name, {
     title: 'Launch control: sdk',
     description: 'Read-only UI launch diagnostic',
     inputSchema: {},
     annotations: { readOnlyHint: true, destructiveHint: false, openWorldHint: false },
     _meta: { ui: { resourceUri: 'ui://figma-animator/launch-control/sdk/v2' } }
   }, handlerReturningTextAndStructuredContent);

   Its registered resource returns mimeType:'text/html;profile=mcp-app' and the inline HTML/bundle. No openai/outputTemplate, ui/resourceUri, openai/widgetAccessible, production result shaping, external scripts, client storage, Figma calls, nested frames or media are involved in that control. Authentication remains the existing endpoint's normal boundary. The SDK connection is new App(..., {}, {autoResize:false}) followed by app.connect(); visible text distinguishes document load, JavaScript start and connection.

   Final serving commit cd26c46fcf6112d72331dcbb3a83f3419eeb5ed6, revision figma-animator-rcd26c46fcf61-04636eb1efb3; CI521/521passed and deploy probes passed. Actual served resource bytes were independently read and hashed.

   Standards-only SDK launch 9e105358-0bc0-4819-af74-84df02dd133b, HTML SHA-256 ae8b30fd1810c303456f1e19ceaac26004bd02d3adfbbbbfdcc8313ba8490e9f. Server logged launch requested at03:16:26.319UTC and the v2 SDK resource read at03:16:28.358UTC, excluding a stale v1 descriptor/resource. Independent read-only status remains awaiting_render_ack, rendered:false, evidence:none.

   Supported pre-launch event cursor captured through final cursor158, not truncated, no more matching events. It includes:

   • Sandbox Fetch.requestPaused, Document, HTTP200, sequence151, request interception-job-12286.0.
   • The child target is not waiting for a debugger; earlier controls also report waitingForDebugger:false.
   • Page.getFrameTree is rejected: Raw CDP is unavailable while Browser Use is resolving a paused document response.
   • Visible host failure card; no control text rendered.

   Earlier static/SDK launch receipts: 2036a01c-a18b-4d2c-94b3-3bc33b12301e and b87ea9e9-8aa7-4208-9308-95cce761aefa. Both have matching pending statuses; the static document has no SDK, so its missing acknowledgment alone is expected and was not used to diagnose failure.

   This reproduces without Figma workspace logic and without its compatibility registration helper. It narrows the failure to shared ChatGPT sandbox/document delivery under inspection, but does not reveal the internal continuation error or prove that every MCP app is affected. Still need a supported per-owned-document continuation outcome trace or official fixed build retaining the guard.

   No private transcripts, screenshots, signed URLs, headers, cookies, credentials or raw logs are attached. No media generation occurred. Private screenshots and bounded filtered evidence retained locally.
5. jyunhao914 commented on Oct 23, 2026

   

   jyunhao914

   on Oct 23, 2026

   Last edited by jyunhao914

   More actions

   Additional reproduction on 2026-10-23 (Asia/Taipei), with an existing packaged HTML visualization in ChatGPT Work. This extends the evidence; it is not a claim that the internal continuation defect has been identified.

   Environment

   • ChatGPT desktop 26.1016.62342, build 21477, prod. The official updater reports up_to_date.
   • Chrome was fully quit through its normal menu, verified stopped, and reopened. Its installed version after restart is 156.0.8078.47. An earlier same-day HAR recorded Chrome/155.0.0.0; browser upgrade versus connection reset cannot be isolated as separate variables.
   • Official extension-backed Browser Control; its connection was re-established before the post-restart test and remained attached throughout the attempted render.

   Reproduction and outcome

   1. An existing 784,063-byte original form was referenced again without regeneration or byte changes. It had previously rendered and submitted settings successfully through native UI without the Browser Control debugger connection.
   2. With Browser Control attached, a new visualization reference failed with the exact host diagnosis: TimeoutError: MCP sandbox RPC timed out.
   3. A bounded, read-only event capture started before the new reference. It recorded Page.frameNavigated to about:blank, followed by Fetch.requestPaused for the corresponding sandbox Document response, HTTP 200. The filtered buffer was paged to completion, hasMore:false, truncated:false.
   4. After Chrome was fully restarted and Browser Control reconnected, a fresh reference to the unchanged original HTML failed again. The capture showed the same about:blank -> sandbox Document response pause (HTTP 200) sequence. No successful form rendering was observed.

   Evidence limits

   • The readEvents capture does not expose Browser Control's internal continuation command, its completion/rejection, or its pending ownership state. A Fetch.requestPaused event by itself is normal and does not prove a permanently outstanding request.
   • Network.enable was not invoked, so lack of Network.loadingFinished events is not treated as a complete network trace.
   • A previous same-byte reversible control (native success -> attached failure -> debugger cancellation -> native success) establishes an association with attachment in this environment, not the exact faulty branch. Cancellation is not accepted as the requested fix.
   • No raw CDP send commands, forced request continuation, guard changes, alternate browser automation transport, installed-runtime modifications, cookie inspection, account permission changes, or third-party workaround extensions were used.
   • Public source search in openai/codex did not expose hasOwnedPausedResponses or a matching repair PR. This is not proof that no private fix exists.

   Requested engineering diagnosis and acceptance
   Please provide a supported per-owned-document lifecycle trace containing stage, owner/session/frame, security decision completion, response-body operation start/result, terminal continuation/fulfillment/failure command start/result, and ownership cleanup. It should distinguish response-body retrieval stalls, continuation rejection, and stale ownership without disclosing headers/cookies.

   Chrome's Fetch contract requires a terminal response for a paused request and warns that interfering while getResponseBody is outstanding, or continuing an already-consumed response stream as-is, has invalid/undefined behavior. A repair needs to preserve URL authorization, settle each owned request exactly once through a valid stage transition, clean state on cancellation/detach/navigation, and expose a bounded actionable failure. These are contract-derived review requirements, not a verified patch for the closed implementation.

   Acceptance: a fresh original form must mount on its first attempt while the official Browser Control remains attached, then accept changed page count and submit the correct values. Repeat on a new form reference and a fresh chat; no reload, debugger cancellation, source regeneration, or weakened guards.

   Sources
   https://learn.chatgpt.com/docs/chrome-extension#troubleshooting
   https://developers.openai.com/plugins/deploy/troubleshooting
   https://github.com/ChromeDevTools/devtools-protocol/blob/master/pdl/domains/Fetch.pdl
   #55650

   No private chat URLs, account identifiers, document content, headers, cookies, tokens, screenshots or raw logs are included.

   Follow-up at 2026-10-23 10:56 UTC: supported network-diagnostic attempt

   • In a newly created Chrome tab opened directly to the same existing test conversation, one documented CDP Network.enable request was rejected with: Raw CDP is unavailable while Browser Use is resolving a paused document response. No network instrumentation was enabled by this attempt.
   • This is a direct observation of the guard in this environment, stronger than inferring it from Fetch events alone. It still does not identify which request was owned or which internal stage failed.
   • The retained readEvents buffer included sandbox Document responses with HTTP 200, but was marked truncated:true; it is not a complete trace. Existing visualization cards changed from loading to the host error state while the connection remained attached. This was an existing-card remount, not an additional fresh-form acceptance trial.
   • The prior “no raw CDP send commands” statement describes the reproduction before this follow-up. This single diagnostic command was subsequently attempted and rejected. No forced continuation, interception changes, alternate inspection transport, or further raw command retry followed the guard rejection.
   • Please provide a supported way to correlate this guard with owned request lifecycle completion; the public readEvents surface does not expose that correlation.

   Follow-up: connected workflow succeeds with active readiness waits (2026-10-23)

   This supersedes the earlier all-failing attached workflow result for the specific invocation pattern below; it does not establish a shipped runtime fix.

   After reading #55659, we tested supported CUA locator readiness waits while the browser invocation remained active through iframe mounting. We did not cancel the debugger, reload/Try again, force a Fetch continuation, change security guards, or modify installed runtime files.

   • Previously failing original form instances rendered on opening their conversation while the invocation stayed active.
   • A newly generated outline form using the same released template first-mounted successfully. Page count 1 → 4; submitted JSON, form acknowledgment, and the assistant's final acknowledgment all agreed on 4.
   • A newly generated existing-slides form first-mounted successfully. Its render trigger and nested-iframe readiness wait ran in one invocation (25.604 seconds from prompt submission, including generation). Page count 2 → 1; submitted JSON and both acknowledgments agreed on 1.
   • The outline test's marker appeared before its iframe. An immediate following invocation waited on the actual nested form. This is not described as an uninterrupted single invocation for that entire generation.
   • The new tests were settings-only: no artifact production or Drive writes. The previously verified actual Drive-permission-refusal fallback is separate versioned evidence.

   Earlier, a fresh target conversation and a 212-byte static HTML control with no JavaScript or external resources also timed out under the ordinary split-call pattern. Its bounded filtered capture contained HTTP 200 Document pauses and about:blank frame navigation. These observations are separate from the successful active-wait cases, not a controlled proof of the precise internal exception.

   Read-only inspection of a bundled Document response handler found ownership recorded before continuation, released after successful settlement, and event-handler rejection silently caught. The captured paused responses had only a tabId source, text/html content type, no attachment disposition, and no x-openai-site-instruction header. We have not captured the exact swallowed exception from the live worker or established that the inspected bundle copy is the loaded service. REA semantic analysis was partial; focused text inspection supplied these observations.

   The current actionable workaround is to keep the supported invocation active until actual nested-form readiness. The idle-between-invocations defect remains unresolved here. No claim that a package update fixes Browser Control, and no live application of the candidate runtime patches from #55659.

   Follow-up: extracted-source RED/GREEN regression and idle-gap failures (2026-10-23 12:15 UTC)

   A bounded offline reproduction now calls methods extracted from the installed desktop browser service and the bundled node_repl source. This is stronger than a hand-written model of the client, but host RPC and provider endpoints are mocked, and the loaded live worker path has NOT been established.

   • Input desktop service SHA-256: 3b3fdb19a1f4642898e2bf974f8ff98767d453fd4500cf2e89415720b1e36ad4.
   • Input node_repl SHA-256: c18d0dfd772715d0135b9c86add5cf26978bed7c45851420dfa81755855c6e1b.
   • Baseline active callback continues normally. A callback arriving after originating execution ends fails with node_repl exec context not found, dispatches no continuation, and retains the owned response (regression exit 1).
   • The candidate adapted from the reproduction linked in Browser runtime leaves delayed iframe Document responses paused after CUA execution ends #55659 passes this offline regression (exit 0). It carries a trusted execution-active predicate through the factory, preserves originating request metadata, and allows cached parameters only when both originating session and turn match. It retains active policy reads, privileged configuration guards, target/provider validation, and Dot access checks.
   • Do not simply clear metadata when execution ends: that loses owner identity and may borrow a newer execution's cached authorization. Tests cover same-session/new-turn and cross-session interleavings, another execution active, released target, provider revocation, and privileged config denial. All reject unauthorized continuation.
   • Denied responses still require correct lifecycle disposal upstream; this candidate does not claim that cleanup is solved. No unconditional finally-clearing, installed-runtime patch, forced Fetch continuation, or guard bypass was used.

   Separate live tests used the original packaged form with three source routes (topic, PDF, PPTX). Source routing worked: the topic requested requirements before an outline, and the synthetic three-page PDF/PPTX were read with the correct titles/counts. First form loading failed in all three routes while Browser Control stayed connected. PDF had 94.138 seconds and PPTX 272.223 seconds between browser operations. The PPTX host error dialog explicitly reported TimeoutError: MCP sandbox RPC timed out. Re-displaying the same packaged form also failed; it was not counted as a first-load test. No manual settings transfer was used. Page-edit/submission acceptance remains unexecuted because those forms did not mount.

   These observations do not identify the exact swallowed exception in the live worker. They provide a concrete source-level candidate plus the still-failing live acceptance test. Please integrate/review the owner-bound lifecycle fix in the trusted worker/service and validate real provider cleanup. No shipped fix or successful idle-gap runtime acceptance is claimed.

   Follow-up: account-free live reproduction after desktop restart (2026-10-23 13:00 UTC)

   The existing source-based hypothesis now has a local Chrome reproduction after restarting the desktop app. This adds no ChatGPT generation, plugin call, uploaded document, Drive operation, or external network dependency.

   • A loopback HTTP parent embeds a same-origin child. The server delays that child's 83-byte HTML response by six seconds; the parent checks the child's actual heading and reports FAIL after 18 seconds.
   • Browser Control remained connected. The first CUA invocation returned at 12:58:18.091Z while the child was about:blank. The server sent HTTP 200 at 12:58:23.078Z, after that invocation had ended. The parent reported FAIL at 12:58:35.068Z.
   • The next browser observation started at 12:59:07.840Z (49.749 seconds between calls), still showing FAIL and about:blank.
   • Supported readEvents recorded a Document Fetch.requestPaused at the response stage, with HTTP 200, text/html and Content-Length 83. Its response Date agrees with the server timeline. No raw CDP send command was attempted. The buffer is truncated:true for earlier entries, so this is bounded evidence, not a full network trace or proof of the internal continuation result.
   • Process inspection identified the active bundled cua-repl launcher. Static inspection of that launcher's startup code maps the browser service to @oai/browser-desktop/service by default; an environment override is possible. This strengthens the package-path attribution but still does not prove the actual worker's loaded module or capture its swallowed exception.
   • No installed-runtime changes, forced continuation, guard changes, debugger cancellation, long-call keepalive, or browser reload were used in this new run.

   This is consistent with the late-response context failure in the extracted-source regression and isolates the problem from the presentation workflow. It does not establish a shipped fix. Original topic/PDF/PPTX first-load, page-edit and direct-submit acceptance remains closed.