[Windows 26.721.4979.0] ChatGPT Work output preview crashes on null `path.win32.dirname`

[zhangchenyue888]

Summary

After updating the Windows ChatGPT/Codex desktop app to AppX package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0, output artifacts from an online ChatGPT Work task no longer open in the desktop preview.

Clicking a generated PNG or Markdown output opens the right-side preview tab, but it immediately shows the localized equivalent of:

Tab content cannot be displayed

Retrying produces the same result. The exact same artifacts can be previewed and downloaded from ChatGPT Web and from the mobile app.

This reproduced on two separate Windows computers after both were fully restarted into the same desktop-app version. One laptop initially appeared unaffected because the previous app process had not fully exited after the update; after a complete exit/relaunch, it reproduced there as well.

Environment

Primary reproduction machine:

• Windows 10 Pro 10.0.19045, x64
• Microsoft Store / MSIX package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Package status: Ok
• Surface: online ChatGPT Work inside a ChatGPT Project
• Artifact types reproduced: .png and .md
• Artifact URI shape: sandbox:/workspace/scratch/<redacted-id>/<artifact>

A second Windows laptop running the same updated desktop version reproduces the same failure. Web and mobile remain unaffected.

Steps to reproduce

1. Open an online ChatGPT Work task in the Windows desktop app.
2. Have the Work task generate an output artifact such as a PNG or Markdown file.
3. After the task completes, click the artifact in the right-side Outputs panel.
4. A preview tab opens.
5. The tab immediately displays Tab content cannot be displayed (localized UI) with a Retry button.
6. Click Retry; the same error returns.
7. Open the same Work on ChatGPT Web or mobile; the artifact previews/downloads successfully there.

In the desktop conversation body, the corresponding output links may also render as gray/non-clickable text even though the artifacts are valid.

Renderer error

The desktop log records this exception immediately after clicking the output:

TypeError: Cannot read properties of null (reading 'dirname')
    at P6i (app://-/assets/app-initial-BbEVL4-_.js:4893:110724)
    at pB  (app://-/assets/app-initial-BbEVL4-_.js:4893:105207)

The error occurs synchronously, before any artifact-content download or file-read request is observed.

A read-only inspection of the packaged renderer bundle shows the relevant helper in minified form:

function P6i(e) {
  return kf(e)
    ? Ul(e) || Wl(e)
      ? R6i.default.win32.dirname(e)
      : R6i.default.posix.dirname(e)
    : null
}

The preview caller uses the equivalent of:

resolvedCwd = cwd ?? P6i(path)

For these cloud Work outputs, the desktop-side item metadata has no local host/cwd. The observed crash is consistent with the fallback path being treated as a Windows/UNC path and calling R6i.default.win32.dirname(...), while R6i.default.win32 is null in this renderer build.

Regression evidence

On the primary machine:

• The current package folder was installed on July 25, 2026.
• Desktop logs from July 18–24 contain many online Work route records but no instances of this dirname exception.
• After the July 25 update, the same exception appears repeatedly across at least two separate online Work tasks.
• Both Windows machines reproduce only after fully entering the updated app version.

This makes local file corruption, a single project, network access, or a single-computer configuration unlikely.

Expected behavior

• Online Work artifacts should preview and download in the Windows desktop app as they do on Web and mobile.
• Missing cwd or an unsupported path flavor should not crash the entire preview tab.
• The preview should fail soft or normalize the path without dereferencing a null path.win32 object.

Related but not identical issues

• Windows app Settings crashes when external agent import panel renders (path.win32 is null) #20662 — same Cannot read properties of null (reading 'dirname') / path.win32-is-null failure, but in the Windows Settings surface.
• [Windows] Markdown and DOCX previews fail while Review diff still works #32719 — Windows Markdown and DOCX preview tabs fail while the files remain valid outside the preview.
• Windows Desktop cannot preview WSL files because fs/watch treats raw /home paths as local #33773 — Windows preview failure caused by losing path/host context.

This report is specifically for online ChatGPT Work output artifacts in Windows desktop 26.721.4979.0.

Privacy note

Project names, artifact names/content, account identifiers, and raw logs are intentionally omitted. A sanitized log excerpt or feedback/session ID can be provided if maintainers need it.

[josh8472]

Confirming the same issue on Windows. Outputs from online ChatGPT Work conversations appear grey, and selecting a DOCX or PDF opens a preview tab showing “Tab content couldn’t render”. Chat Inline links to generated files are also missing or unusable in the desktop conversation (ie, the file name is there, but it's not a clickable link), despite appearing and working correctly on chatgpt.com.

The same files open and download correctly through the web version. Repairing and resetting the desktop app did not help.

Trace ID: no-active-thread-019fa133-7aff-7cb2-b280-989ea9a3eb3d

[Rat0323]

Additional reproduction on the same Windows desktop build, but through a local skill mention in the composer rather than a ChatGPT Work output.

Environment

• Windows desktop package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Skill: bundled Chrome skill
• Local file: C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\26.721.41059\skills\control-chrome\SKILL.md

Steps

1. In the composer, type /chrome.
2. Select Chrome: Control Chrome so it becomes an inline skill mention.
3. Before sending the message, click that inline mention.
4. The internal SKILL.md tab opens and immediately shows Tab content cannot be displayed with Retry.

The renderer reports the same exception as this issue:

TypeError: Cannot read properties of null (reading 'dirname')
    at P6i (app://-/assets/app-initial-BbEVL4-_.js:4893:110724)
    at pB  (app://-/assets/app-initial-BbEVL4-_.js:4893:105207)

The mention DOM contains a complete, valid Windows path in both skill-mention-path and data-prompt-link-href. The file exists, is readable, and the exception occurs before a file-read RPC is issued.

There is also a useful control case:

• After sending the message, clicking the rendered skill link successfully opens the same file in VS Code.
• Changing only the in-memory preview target from C:\Users\...\SKILL.md to /C:/Users/.../SKILL.md makes the internal tab render the same file successfully.

This isolates the failure to the composer's inline skill-mention -> internal preview path on Windows, rather than the skill file, permissions, authentication, API provider, or model request routing.

For build provenance, the runtime-served app-initial-BbEVL4-_.js and the copy extracted directly from the installed Microsoft Store app.asar have the same SHA-256:

B7255AE117A54BF16C7F45834054CD16ABD9B24CF5AA9DBD7C796F59743E556A

The packaged helper is the same P6i Windows branch described in the issue, while the bundled path implementation contains win32:null.