[macOS][26.818] External-contact task hangs at “Verifying recipient” while personal Plus account receives workspace-settings 401

What version of the Codex App are you using?

• ChatGPT/Codex Desktop release: 26.818.41509
• Bundle build: 6962
• Bundled Codex CLI/app-server: 0.149.0-alpha.4.1

What subscription do you have?

ChatGPT Plus on a personal account (not a workspace account).

What platform is your computer?

macOS 26.5.2 (build 25F84), Apple Silicon (arm64).

What issue are you seeing?

On 2026-08-24, an external-contact action launched from a regular ChatGPT conversation in the macOS desktop app stopped making progress.

The user asked the assistant to find a retailer's contact details and send a short product-availability inquiry. The assistant announced that it would check the contact details and send the inquiry, but the UI then remained at:

Sending product-availability inquiry

After the user sent a follow-up ?, the UI changed to:

Verifying recipient

It remained stuck there. The app did not show the resolved recipient, a message draft, a pre-send approval prompt, a recoverable error, or a send receipt. Consequently, the user cannot determine from the UI whether any external message was sent.

The rest of the desktop UI remained available; this was not a project-content error and no local project was involved.

What steps can reproduce the bug?

1. Sign in to the macOS desktop app with a personal ChatGPT Plus account.
2. Open a regular ChatGPT conversation, not a Project.
3. Provide a public product page and ask the assistant to contact the retailer about availability.
4. Observe the action remain at “Sending product-availability inquiry” without completion.
5. Send a short follow-up message.
6. Observe the action remain at “Verifying recipient” without a recipient, approval prompt, completion, or actionable error.

What is the expected behavior?

Before an external message is sent, the app should resolve and display the recipient and message, request confirmation at the appropriate action boundary, and then provide an unambiguous success receipt.

If recipient resolution, authorization, or browser/tool routing fails, the action should stop with a visible, recoverable error and a safe retry path. It should not remain indefinitely in an in-progress state, and it should never leave the user uncertain whether an external side effect occurred.

Correlated sanitized desktop-log evidence

The visible reproduction occurred at approximately 11:23 CEST (09:23 UTC). The local logs around the incident contain the following sequence:

09:21:14Z  IAB browser session window removed
09:21:14Z  IpcRouter Socket error: errorCode=EPIPE, errorMessage="write EPIPE"
09:21:14Z  ipc-connection-reset broadcast received
09:21:14Z  app-server connection changed from connected to disconnected

09:22:03Z  desktop app relaunched
09:22:15Z  GET /backend-api/accounts/{account_id}/settings -> HTTP 401
              {"detail":"Must use workspace account for this operation"}
09:22:22Z  a /work/conversation/{redacted} route was captured with browserTabId=null
09:22:24Z  the same account-settings request again returned HTTP 401
              {"detail":"Must use workspace account for this operation"}

The EPIPE/IPC reset happened in the immediately preceding desktop process, before the visible reproduction, so it is reported as correlated lifecycle context rather than asserted as the direct cause. The repeated workspace-only settings 401 occurred after relaunch and immediately before the stuck external-action state.

Why this is not an exact duplicate

• #40222 reports a macOS app-server crash/recovery screen and failed feedback upload after the same workspace-settings 401. In this incident the distinctive user-facing failure is an external action that remains stuck at recipient verification without a success/failure outcome.
• #39202 concerns WebSocket recovery and conversation synchronization. This incident adds an action-specific failure path involving recipient verification, a /work/conversation route, and repeated workspace-only settings 401 responses on a personal Plus account.

These issues may share an authentication, route-lifecycle, or desktop IPC boundary, but the failure mode and safety impact here are different.

Troubleshooting and controls

• The app had already fully relaunched immediately before the reproduction.
• The account is a personal ChatGPT Plus account, so a workspace-only settings request should not block or destabilize the action.
• The failure occurred in a regular ChatGPT conversation and did not depend on repository or project contents.
• No successful-send confirmation was displayed, so the user did not retry the external message blindly.

Suggested fix area

Please make the personal-account path avoid or gracefully handle the workspace-only settings endpoint, and make external-action state transitions transactional:

1. resolve recipient and route ownership;
2. expose the recipient/message and obtain required confirmation;
3. execute at most once using an idempotency key;
4. return a durable success receipt or a visible recoverable failure;
5. reconcile or cancel the pending action after an IPC/app-server reconnect.

Privacy note

The retailer, product URL, shared-chat URL, account/thread/session/request identifiers, local paths, and raw logs are intentionally omitted. A privately shared conversation link and additional sanitized excerpts can be provided to an authorized maintainer if needed.