Windows: ChatGPT Chrome side panel attachments hang on registry write; resetting the registry restores functionality

What issue are you seeing?

In the ChatGPT extension side panel on Windows, selected files do not become ready-to-send attachments. Diagnostics showed that transferring and copying the attachment files succeeds, but saving the shared attachment registry through fs/writeFile remains pending and blocks subsequent registry writes.

Environment when the issue occurred:

• Windows, local host.
• ChatGPT Chrome extension: 1.26.827.12125.
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg.
• Side panel page: codex-sidepanel/index.html.
• Registry: %USERPROFILE%\.codex\attachments\pasted-text-attachments.json.

The native host status returned ok: true, state: connected. The SAVE_TAB_CONTEXT_ASSET_CREATE, APPEND_CHUNK, and FINISH operations, followed by fs/createDirectory and fs/copy, succeeded for the selected files.

However, the registry persistence queue (registryWrite) remained pending. The client marked the fs/writeFile request as started; one diagnostic snapshot showed it had been waiting for 1,355 seconds with timeoutMs: 0. The queue of unsent requests was empty. No error was displayed to the user.

What steps can reproduce the bug?

Observed reproduction on the affected machine:

1. Open the ChatGPT side panel with an existing, accumulated attachment registry.
2. Select a local file using the + button.
3. File transfer and copying complete, but the attachment does not reach the ready state in the UI.
4. Inspect the attachment manager queue: registry persistence is waiting for fs/writeFile to complete.

An additional test wrote synthetic data to the same temporary file through the same request client, using a five-second diagnostic timeout:

These are the original data sizes before base64 encoding. The exact failure threshold has not been established. Reproduction with a synthetic registry in a clean profile has not been tested, so the steps above describe the observed scenario rather than a verified minimal reproducer.

What is the expected behavior?

A valid attachment registry should be saved successfully, and the selected attachment should become ready to send. If persistence fails, the UI should display an actionable error and allow the queue to recover instead of waiting indefinitely.

Additional information

The original registry was valid JSON, 83,197 bytes long. It contained 83 registered file paths, all pointing to existing files, and 25 text excerpts. The pending-removal list was empty. No JSON corruption was found.

Two workarounds restored attachment functionality:

1. A temporary runtime workaround intercepted only large registry writes: transfer the JSON to the existing native host in chunks, finalize the temporary file, and use fs/copy to copy it to the original registry path. Attaching files through + then worked.
2. Subsequently, the registry was reset while retaining the old file as a backup. The user confirmed that a new registry was created and attachments worked again. Deleting the directory containing the attachment files was not necessary.

The exact failing component has not been identified: the request may stall during transmission, processing, or response delivery. The observations suggest size-dependent behavior but do not establish a specific size limit or JSON corruption. Long-term behavior as the new registry grows has not been tested.

Related issues:

• #41263: clearing attachment state also restores functionality, but the reported trigger is an unsent attachment following an app update.
• #31020: involves the same registry file, but the reporter found corrupted JSON containing NUL bytes; the registry in this report was valid JSON.
• #41472: describes a similar indefinite attachment-preparation state in Windows Desktop.

This report adds browser-side-panel diagnostics: successful persistence of the attachment files themselves, a pending write of a valid shared registry, and a comparison of small and large write requests. Attachment contents, registry contents, and private logs are omitted.

Start by tracing the attachment manager's registryWrite queue and the fs/writeFile request path described in the report, then reproduce the size-dependent behavior with valid registry data. Done means large attachment registries persist without hanging and the queue either recovers or presents the reported actionable error.