ChatGPT Chrome Extension control wedges during file upload/download workflows

Open 💬 2 comments Opened Jul 24, 2026 by as12015kimo-ctrl
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows, Codex desktop browser control through the ChatGPT Chrome Extension can become wedged during ChatGPT file attachment and download workflows.

This report is intentionally redacted: it contains no private logs, conversation content, conversation URLs, account identifiers, project names, or local file paths.

Observed behavior

  1. Connecting to or claiming an existing ChatGPT tab can hang for 60–120 seconds. Creating a fresh controlled tab and navigating it to the same conversation works more reliably.
  2. A small ZIP selected through the file chooser shows an attachment card, but the Send action may time out or do nothing. In one occurrence, the text was sent while the attachment was absent.
  3. Clicking a ChatGPT attachment can start the download, yet the browser-control call never resolves and the extension control host becomes unresponsive. Retrying can create duplicate downloads.
  4. Playwright-backed clicks can fail after about three seconds with a CDP Runtime.evaluate timeout, while DOM/CUA interactions may still work in the same tab.

Recovery currently required

  • Restart only the Chrome extension control host/session (not Chrome itself).
  • Rebuild the control session.
  • Create a fresh controlled tab rather than reusing the wedged tab binding.

Expected behavior

  • File upload/send provides a deterministic completion or failure signal.
  • The attachment remains associated with the message when Send succeeds.
  • Downloads expose a reliable completion event and downloaded-file path.
  • Cancellation and timeout failures propagate without leaving the extension host wedged.
  • A safe tab rebind/recovery path exists without restarting Chrome.

Environment

  • Windows
  • Codex desktop
  • ChatGPT Chrome Extension
  • Exact version not captured

No attachments or private diagnostic data are included.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34882
  • #34472

Powered by Codex Action

as12015kimo-ctrl · 1 month ago

Thanks. I reviewed both suggested issues. #35051 partially overlaps with them, but the currently observed failure is not fully covered by either report.

  • #34882 identifies a specific Windows attach / executeCdp race that produces Debugger is not attached. I did not capture that underlying error in this case. The distinctive failures here occur during the file-transfer lifecycle: an attachment card can appear but Send can time out or send text without the file, and a download can start while the browser-control call never resolves.
  • #34472 reports a stale session on macOS where DOM operations continue to time out even in a fresh tab. In this Windows case, creating a fresh controlled tab is often an effective recovery, and DOM/CUA operations may still work while Playwright/CDP actions fail.

The file-workflow-specific behavior in #35051 is:

  1. The ZIP attachment card is visible before Send, but Send may time out, do nothing, or produce a text-only message.
  2. A download can begin successfully, but the control request remains pending and the extension control host becomes wedged.
  3. Retrying an unresolved download can create duplicate downloaded files.
  4. Recovery requires rebuilding the extension control session; restarting Chrome itself is not required.

These issues may share lower-level tab/session-control infrastructure, but I am keeping #35051 open for the upload/send/download completion and attachment-association behavior unless maintainers prefer consolidation.