Repository navigation
Windows: ChatGPT Work cannot access Computer Use tools and fails to download image attachments #49459
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.928.20755 (build 12246, prod channel)
What subscription do you have?
Pro
What platform is your computer?
Windows 10 (OS version 10.0.19045), x64
What issue are you seeing?
I am experiencing two issues in ChatGPT Work on the Windows desktop app.
- Computer Use tools are unavailable in Work
Steps to reproduce:
- Open a ChatGPT Work chat.
- Select “Computer / Control Windows apps” from the @ menu.
- Ask it to list the currently open windows.
Actual result:
The assistant reports that neither node_repl nor cua_repl is available in the session, so it cannot use Computer Use.
Expected result:
Work should be able to invoke Computer Use and list open windows.
Checks performed:
- The “Any application” setting is enabled.
- The node_repl MCP server is configured and enabled.
- node_repl.exe is running.
- In a Codex chat on the same computer, @oai/sky initializes successfully and sky.list_windows works.
- Explicitly selecting the Computer plugin in Work still reproduces the issue.
- Image attachment downloads fail in Work
Steps to reproduce:
- Take a screenshot with Win+Shift+S.
- Paste it into a Work chat and send it.
- Ask the assistant to read the image.
Actual result:
The image thumbnail appears, but the download_file tool fails with:
cannot create attachment directory: path contains a reparse point
Expected result:
The assistant should be able to download and read the uploaded image.
Checks performed:
- Retrying the existing attachment reproduces the error.
- Restarting the computer did not resolve it.
- Uploaded screenshots can be read in a Codex chat on the same computer.
- Work can read the image when it is saved as a local file.
- No ReparsePoint was found in the checked working directory, its parent directories, or the temporary directory.
- The error does not identify the rejected path, and download_file does not allow specifying an output directory.
App version: 26.928.20755 (build 12246, prod channel).
OS: Windows 10, version 10.0.19045, x64.
The built-in update check reports that the app is up to date.
Both issues remain unresolved. Please investigate Work’s Computer Use tool availability and the Windows attachment directory path validation.
What steps can reproduce the bug?
Feedback ID: 01a0f030-191b-7d40-a57b-21416b57b8f3
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Sep 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
get-off-my-train commentedon Oct 4, 2026
Additional reproduction with a controlled Windows API check.
Environment:
cannot create attachment directory: path contains a reparse pointThis is a regression: image attachments worked previously and then stopped working, which now blocks normal screenshot/image-based Work usage for an active project.
Diagnostics performed without changing permissions or security settings:
Checked every filesystem segment of the active Work workspace path under:
C:\Users\<user>\Documents\Codex\2026-10-04\new-chat-3and:
C:\Users\<user>\AppData\Local\TempResults:
ReparsePoint = falseon all checked segments.Read-only Windows API reproduction:
C:\...withOBJ_DONT_REPARSE0xC000050B/STATUS_REPARSE_POINT_ENCOUNTEREDOBJ_DONT_REPARSE\Device\HarddiskVolume...\...withOBJ_DONT_REPARSEThis reproduces the same namespace/no-follow behavior described in #46290.
Important limitation: Work's attachment downloader does not reveal the exact attachment-directory path it is trying to create, so I cannot prove that its failing call uses the identical path form. However, there are no actual filesystem reparse points in the checked workspace/Temp paths, and the drive-letter +
OBJ_DONT_REPARSEfalse positive is reproducible on the same machine.This strongly suggests that the Work attachment-download path validation may be hitting the same Windows DOS-drive namespace problem.
Please prioritize this regression. For screenshot-heavy project work, Work is effectively unusable when attachments cannot be opened. It would also help if the error exposed the rejected attachment-directory path so the failure could be diagnosed directly.