[Windows 26.721.4979.0] ChatGPT Work output preview crashes on null `path.win32.dirname`
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:
.pngand.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
- Open an online ChatGPT Work task in the Windows desktop app.
- Have the Work task generate an output artifact such as a PNG or Markdown file.
- After the task completes, click the artifact in the right-side Outputs panel.
- A preview tab opens.
- The tab immediately displays
Tab content cannot be displayed(localized UI) with a Retry button. - Click Retry; the same error returns.
- 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
dirnameexception. - 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
cwdor 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.win32object.
Related but not identical issues
- #20662 — same
Cannot read properties of null (reading 'dirname')/path.win32-is-null failure, but in the Windows Settings surface. - #32719 — Windows Markdown and DOCX preview tabs fail while the files remain valid outside the preview.
- #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.
2 Comments
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
Additional reproduction on the same Windows desktop build, but through a local skill mention in the composer rather than a ChatGPT Work output.
Environment
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\26.721.41059\skills\control-chrome\SKILL.mdSteps
/chrome.SKILL.mdtab opens and immediately shows Tab content cannot be displayed with Retry.The renderer reports the same exception as this issue:
The mention DOM contains a complete, valid Windows path in both
skill-mention-pathanddata-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:
C:\Users\...\SKILL.mdto/C:/Users/.../SKILL.mdmakes 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-_.jsand the copy extracted directly from the installed Microsoft Storeapp.asarhave the same SHA-256:The packaged helper is the same
P6iWindows branch described in the issue, while the bundled path implementation containswin32:null.