What version of the Codex App are you using (From “About Codex” dialog)?
26.818.41705 (CFBundleVersion 6971)
Bundled app-server: 0.149.0-alpha.4.1
What subscription do you have?
Unknown — the subscription tier is not exposed in the local diagnostics used for this report.
What platform is your computer?
Darwin 24.6.0 arm64 arm
macOS 15.7.9 (24G830)
What issue are you seeing?
During an image-to-SVG task invoked with the official Figma connector (@Figma / figma@openai-curated-remote), Codex App displayed a reconnect state (Reconnecting 1/5) and the workflow failed to deliver the requested local SVG.
The task asked Codex to inspect a local PNG, ignore the slide header/logo, recreate only the architecture diagram as a PPT-compatible SVG using Iconify icons, and keep the “现场数据源” connector strictly horizontal.
The local Codex App logs confirm that this was not only a UI status message. In the affected thread, the ChatGPT pub/sub transport closed and the reconnect attempt received a Cloudflare managed-challenge HTML page instead of the expected service/WebSocket response:
2026-08-23T07:44:49.605Z
chatgpt_pubsub_transport_closed
2026-08-23T07:44:49.605Z
chatgpt_pubsub_reconnect_scheduled
retryCount=0
delayMs=4598.872...
2026-08-23T07:44:54.445Z
sa_server_request_failed
errorMessage="<html> ... Enable JavaScript and cookies to continue ..."
2026-08-23T07:44:54.445Z
chatgpt_pubsub_connection_failed
errorMessage="<html> ... Cloudflare managed challenge ..."
2026-08-23T07:44:54.445Z
chatgpt_pubsub_reconnect_scheduled
retryCount=1
delayMs=9197.744...
2026-08-23T07:45:04.991Z
chatgpt_pubsub_transport_opened
Although the pub/sub transport later reported as opened, the user-visible workflow did not recover into a completed artifact. The intended output directory remained empty.
A later app-process transition also recorded:
[IpcRouter] Socket error
errorCode=EPIPE
errorMessage="write EPIPE"
The key user-facing problem is that the UI does not distinguish whether Reconnecting 1/5 refers to:
- the model response stream;
- ChatGPT pub/sub;
- the Figma connector;
- connector authentication/discovery;
- or the local app-server/IPC connection.
Because the task was explicitly invoked with @Figma, the failure appears to the user as “Figma cannot connect,” even though the available evidence points more specifically to the Codex App ChatGPT pub/sub path receiving a Cloudflare challenge. No successful Figma operation result was surfaced.
No raw logs are attached because they contain local paths and Cloudflare challenge tokens. The evidence above is sanitized.
What steps can reproduce the bug?
- Open Codex App on macOS.
- Open a local project with workspace write permission.
- Attach a local PNG image. The reproduced source used a filename containing Chinese characters.
- Invoke the official Figma connector with
@Figma.
- Ask Codex to inspect the image and generate a standalone SVG in the local workspace.
- Continue the task for several minutes while local design/tool preparation is running.
- Observe
Reconnecting 1/5.
- Observe that no actionable component-specific error is shown.
- After the connection appears to recover, check the intended output directory.
- The requested SVG has not been created.
Affected thread/session ID:
01a02d78-f71d-7242-b843-854b7603b4a7
The same thread is present in the desktop log immediately before and after the pub/sub failure.
The original local path has been redacted:
/Users/<redacted>/Downloads/.../ChatGPT Image 2026年8月23日 14_29_57.png
What is the expected behavior?
Codex App should either:
- keep the ChatGPT pub/sub/response stream stable and complete the
@Figma task; or
- recover the in-progress turn after a transient disconnect; or
- fail promptly with a component-specific, actionable error.
The reconnect UI should identify the failing layer, for example:
Reconnecting ChatGPT pub/sub (1/5)
Figma connector is not currently being retried
If a Cloudflare challenge HTML page is returned where a service/WebSocket response is expected, Codex App should classify and surface that condition instead of displaying a generic reconnect counter.
Completed local work and the planned output state should survive a reconnect. If the requested output can be produced locally without Figma, the app/agent should be able to continue using that fallback rather than leaving the user with no artifact.
Additional information
Impact:
- The Figma workflow appears completely unavailable to the user.
- The reconnect status does not identify the failing component.
- The task can consume substantial time while producing no artifact.
- A later “transport opened” event does not guarantee that the interrupted workflow resumes successfully.
Requested improvements:
- Identify the connection being retried in the UI.
- Include a copyable failure classification/request ID.
- Detect Cloudflare challenge HTML returned to pub/sub/service requests.
- Preserve/resume in-progress turns after pub/sub reconnection.
- Add a targeted “Retry Figma connector/tool call” action.
- Do not imply artifact generation is underway until an actual tool call or local write has started.
- Surface whether the local write operation started and whether it can safely resume.
Related but not duplicate reports found before filing:
This report adds a current macOS Codex App reproduction with exact app/app-server versions, a single affected thread ID, sanitized pub/sub timestamps, Cloudflare-challenge evidence on the pub/sub reconnection path, and a concrete @Figma task that failed to produce its promised local artifact.
What version of the Codex App are you using (From “About Codex” dialog)?
26.818.41705 (CFBundleVersion 6971)
Bundled app-server:
0.149.0-alpha.4.1What subscription do you have?
Unknown — the subscription tier is not exposed in the local diagnostics used for this report.
What platform is your computer?
What issue are you seeing?
During an image-to-SVG task invoked with the official Figma connector (
@Figma/figma@openai-curated-remote), Codex App displayed a reconnect state (Reconnecting 1/5) and the workflow failed to deliver the requested local SVG.The task asked Codex to inspect a local PNG, ignore the slide header/logo, recreate only the architecture diagram as a PPT-compatible SVG using Iconify icons, and keep the “现场数据源” connector strictly horizontal.
The local Codex App logs confirm that this was not only a UI status message. In the affected thread, the ChatGPT pub/sub transport closed and the reconnect attempt received a Cloudflare managed-challenge HTML page instead of the expected service/WebSocket response:
Although the pub/sub transport later reported as opened, the user-visible workflow did not recover into a completed artifact. The intended output directory remained empty.
A later app-process transition also recorded:
The key user-facing problem is that the UI does not distinguish whether
Reconnecting 1/5refers to:Because the task was explicitly invoked with
@Figma, the failure appears to the user as “Figma cannot connect,” even though the available evidence points more specifically to the Codex App ChatGPT pub/sub path receiving a Cloudflare challenge. No successful Figma operation result was surfaced.No raw logs are attached because they contain local paths and Cloudflare challenge tokens. The evidence above is sanitized.
What steps can reproduce the bug?
@Figma.Reconnecting 1/5.Affected thread/session ID:
The same thread is present in the desktop log immediately before and after the pub/sub failure.
The original local path has been redacted:
What is the expected behavior?
Codex App should either:
@Figmatask; orThe reconnect UI should identify the failing layer, for example:
If a Cloudflare challenge HTML page is returned where a service/WebSocket response is expected, Codex App should classify and surface that condition instead of displaying a generic reconnect counter.
Completed local work and the planned output state should survive a reconnect. If the requested output can be produced locally without Figma, the app/agent should be able to continue using that fallback rather than leaving the user with no artifact.
Additional information
Impact:
Requested improvements:
Related but not duplicate reports found before filing:
Broken pipe#32555 — general Codex Desktop WebSocket/Broken pipe behavior.This report adds a current macOS Codex App reproduction with exact app/app-server versions, a single affected thread ID, sanitized pub/sub timestamps, Cloudflare-challenge evidence on the pub/sub reconnection path, and a concrete
@Figmatask that failed to produce its promised local artifact.