Windows desktop troubleshooting blocked: attachments listed as available but local files cannot be read

Summary

During troubleshooting of Codex in the Windows ChatGPT desktop app, attached diagnostic files are listed as available with scratch paths, but the assistant cannot consume them. Image attachments repeatedly produce No such file or directory (os error 2). This creates a support loop: the assistant asks for diagnostics, the user supplies attachments, and the assistant asks the user to paste or split the same information again.

This report is submitted by the assistant at the user's explicit request. Private paths, account information, project names, and diagnostic contents have been omitted.

Environment

• Windows desktop app, Codex surface
• Agent environment shown in settings: Windows native
• Integrated terminal: PowerShell
• Exact desktop/bundled Codex version and Windows build: not verified; the diagnostic attachment containing version output could not be read

Reproduction sequence observed in this conversation

1. The desktop UI shows Windows setup incomplete / setup stopped, alongside failure to create a local project.
2. The assistant requests PowerShell diagnostic output.
3. The user supplies output as TXT and Markdown attachments, and also uploads screenshots.
4. Attachment metadata announces that copies are available at local scratch paths.
5. Image loading repeatedly fails with the following error (path anonymized):

Codex could not read the local image at `/workspace/scratch/<session>/upload/<attachment>.png`: No such file or directory (os error 2)

6. Some earlier screenshots remained visually available in the conversation despite the local-image error, but the assistant had no callable local filesystem/terminal reader for the TXT/Markdown contents. Attachment instructions also directed it to read the scratch copies instead of using the Library tool.
7. The assistant repeatedly requested repasting/smaller excerpts, shifting the ingestion failure onto the user without resolving the original setup problem.

Expected behavior

• Announced attachment paths should exist in the active execution environment and have a usable reader, or attachment contents should be exposed through a working supported alternative.
• An attachment ingestion failure should be distinguishable from the user's local Windows sandbox/setup failure.
• The assistant should obtain actionable setup diagnostics without requiring users to repeatedly reformat and resubmit the same output.

Actual impact and uncertainty

The user cannot complete troubleshooting or create the intended local project. Native setup and attachment ingestion are two observed failures; their causal relationship is unknown. Administrator and non-administrator setup paths were attempted/reported unsuccessful, but the effective fallback configuration and current backend error were not verified. This report does not claim that a specific Windows permission or sandbox implementation is the root cause.

Please route the attachment availability/tool-capability mismatch to the relevant desktop/Work team if it belongs outside this repository.

Start by reproducing the attachment failure in the Windows desktop Codex surface, using the reported scratch paths and PowerShell diagnostic attachments. Trace whether the announced paths are available and whether a supported reader can access TXT, Markdown, and image uploads. Done means attachment contents are readable or a supported alternative is exposed, and ingestion failures are distinguishable from Windows setup failures.