Repository navigation
Unable to upload images without Access Denied error #49422
Description
What version of the Codex App are you using (From “About Codex” dialog)?
26.928.20755
What subscription do you have?
Plus
What platform is your computer?
Windows 11
What issue are you seeing?
Images are readable in regular ChatGPT but inaccessible in Work Mode with Astra. New Work chats and Chrome Incognito haven’t resolved it. The attachment tool repeatedly returns: “cannot create attachment directory: Access is denied. (os error 5).” This occurred September 29 around 9:00–9:17 p.m. Eastern.
What steps can reproduce the bug?
Feedback ID: no-active-thread-01a0efe4-fad0-7e80-b7c1-edb2c93875ba
What is the expected behavior?
It's supposed to be able to view the image.
Additional information
This happened previously but was able to fix it by going through Incognito Mode on Google Chrome. Now it's giving the error no matter what.
Activity
coconvggieez commentedon Sep 30, 2026
On September 30, the attachment error changed to “cannot create attachment directory: failed to prepare fs sandbox: failed to prepare windows sandbox wrapper: sandbox provisioning failed.” Running a command to list a local folder also failed with “Failed to create unified exec process … sandbox provisioning failed.” The same image opened successfully in regular ChatGPT.
vkle commentedon Sep 30, 2026
你可以尝试用管理员模式启动
vkle commentedon Sep 30, 2026
更改 无项目任务文件夹
martinburstein commentedon Sep 30, 2026
Additional reproduction: PDFs and PNGs fail in Windows desktop Work
I’m seeing the same exact error with both PDF and PNG attachments:
The assistant receives the attachment’s filename/reference, but the attachment-download tool fails before it can read the contents.
Environment
Surface: ChatGPT desktop app → Work, on Windows
Model: GPT-6 Astra High
Installed Windows package:
OpenAI.Codex_26.928.2636.0_x64__2p2nqsd0c76g0Observed: September 29–30, 2026; repeated testing September 30, approximately 9:30–10:20 a.m. Pacific
The app reports that it is up to date.
Reproduction
Start a new Work chat in the Windows desktop app.
Attach a PDF or PNG and ask the assistant to read it.
The assistant sees the attachment reference.
Its attachment-download attempt fails with the error above.
This persists across multiple new chats.
Comparison tests
Test | Result -- | -- PDF attachment in desktop Work | Fails PNG attachment in desktop Work | Fails with the same error Same PDF in regular Chat | Works Same PDF in web Work | Works Desktop Work reading the PDF through its full local Windows path | Works; both pages readable Desktop Work reading a saved PNG through its local path | Works Creating, reading, and deleting a temporary file in the active workspace | WorksUnlike the original report’s browser results, web Work succeeds in my testing.
Troubleshooting already attempted
Closed and reopened the desktop app.
Started multiple fresh Work chats.
Ran Windows’ Repair operation on the new ChatGPT app.
Checked for updates.
Switched the new-chat permissions setting away from Full access, then back, and tested again.
None resolved desktop attachment downloading.
Possible related permissions symptom — not a confirmed cause
The new-chat UI displayed Full access, but the assistants in the affected desktop sessions reported:
Those are assistant-reported session values, not an independently captured process trace. The saved Codex configuration also showed
danger-full-access, which differed from the reported effective session settings.This may relate to #25590 or #36497, but I have not established that the permissions discrepancy causes the attachment failure. Available logs did not identify the exact denied destination or responsible process.
No Windows folder permissions were changed, and no Process Monitor trace was captured.
Please let me know whether this belongs under the same issue and which diagnostic would best help identify the failing attachment-directory creation.
peteconr commentedon Oct 1, 2026
same problem here...
Surface: ChatGPT Windows desktop app → Work (Astra Medium)
App version: 26.928.31416 (Microsoft Store install)
OS: Windows 11 26H2 (issue started after updating, and updated ChatGPT from prior version in MS Store at same time)
What happens: Any image attachment in Work (paste / + upload / Appshots via both Alt keys) fails with: cannot create attachment directory: Access is denied. (os error 5)
What works: Regular Chat in the same app can read the same screenshots; Work on the web works
Tried: reboot, repair app, run as admin (no change), new Work threads
Session ID: no-active-thread-01a0f56b-d73b-78c2-98f7-87e0e6515006
spirosin commentedon Oct 1, 2026
Title: Windows Work Mode cannot read image attachments — Access denied (os error 5)
Windows desktop app version: 26.928.3736.0
Uploading an image in Work Mode consistently causes:
cannot create attachment directory: Access is denied. (os error 5)
coconvggieez commentedon Oct 1, 2026
The attachment problem is still happening in ChatGPT Work on Windows, iPhone 16, Opera GX and Google Chrome web browsers. I still cannot send images for the assistant to view unless through regular ChatGPT Chat. It receives the attachment reference, but cannot download and read the image. The same problem affects documents and long text or Markdown that the chat turns into an attached file. Pasting the chapter directly into several shorter chat messages worked, but attaching it did not.
There has also been a sandbox setup problem. Earlier, a brief message when opening ChatGPT said I needed to update Windows. I installed the pending Windows update, but it did not fix the issue. Later, when I opened ChatGPT as administrator, “Finish setting up Windows to continue” flashed briefly. I approved the sandbox setup prompt again.
Before that approval, even a basic local file command failed with “sandbox provisioning failed.” The available local logs repeatedly reported the sandbox setup marker as “missing or incompatible.” Only after I reopened the app as administrator and approved setup did local file commands work again. The assistant was then able to create and verify a PDF. That recovery did not fix attachment downloading: it still could not read the attached chapter.
The logs also showed that a sandbox firewall-settings change had triggered setup earlier, but they did not establish why setup was needed again or prove what produced the brief on-screen message. I updated Windows because the app prompted me to; I had not changed my Windows installation before this problem began.
So there appear to be two observable failures: attachment downloads still fail even when local file commands work, and at other times sandbox provisioning prevents local file commands too. Reapproving setup as administrator temporarily restored file commands, not the ability to read attachments.
JOSEHG74 commentedon Oct 1, 2026
Additional reproduction on October 1, 2026, with the currently offered Windows desktop release:
26.928.31416, build12553, prod channel. Update status:up_to_date.26.928.3736.0.0.159.2. Both binaries have identical SHA-256 hashes.A 612,227-byte PNG attachment is present and intact. Work can open and correctly describe the same image after it is copied into the conversation's local working directory. This is a workaround only.
The native
download_filetool repeatedly fails for the original attachment with:The message means access denied. It does not disclose the attempted directory. The exposed tool accepts only
file_id, so the caller cannot select a destination directory.In the same Work conversation, local shell commands successfully created and deleted an empty test file in a subdirectory of the actual working directory. Therefore local workspace writes work while attachment-directory creation fails.
library.prepare_materializereturned a prepared transfer of the correct byte count butworkspace_path: null. The expected local file did not exist afterwards. This result does not mean the transfer was completed.Further diagnostic observations, without claiming causation:
fs/readFile requires an environmentIdwith code-32602and no associated conversation. This has not been correlated with the attachment-download operation.helper_sandbox_lock_failed; subsequent local shell operations succeed. Those older failures have not been established as the cause of this download failure.request_permissions, preventing an in-session test of a targeted additional directory grant.Please inspect the actual destination, selected environment, and effective filesystem permissions used by native attachment downloads on Windows. Exposing the rejected directory in diagnostics would help distinguish destination resolution from permission enforcement. A fix should be validated with fresh attachments in Work without manual local copies or full-access workarounds.
No persistent security configuration or Windows ACLs were changed. Private paths, usernames, file and conversation identifiers, signed URLs, and raw logs are omitted.
RicRogerexXXx commentedon Oct 1, 2026
I’m seeing the same issue on my account.
Environment
Error
When I attach/paste a screenshot in Work and ask it to read the image, the attachment cannot be opened and Work reports:
cannot create attachment directory: Access is denied. (os error 5)Comparison tests
Troubleshooting already tried
Because the same failure happens in browser Work but not in regular ChatGPT or Codex, this does not appear to be a local Windows folder permission issue on my machine.
I can provide screenshots of the error or additional diagnostics if useful.
p4nzy917 commentedon Oct 2, 2026
Codex ChatGPT mode (Work / Astra) fails to download image attachments on Windows — root cause analysis
Related issue: openai/codex#49422
Symptom
On Windows, uploading image attachments in ChatGPT mode (Work / Astra) always fails with:
On the same machine, Codex mode downloads and reads attachments without any problem — the failure is specific to ChatGPT mode.
Environment: Windows 11 Pro for Workstations (10.0.26200); app package
OpenAI.Codex_26.928.4866.0_x64__2p2nqsd0c76g0; bundled Codex CLI 0.159.2; sandbox config[windows] sandbox = "elevated".Root cause
The elevated Windows sandbox backend in 26.928.4866.0 is broken: at the
elevatedlevel, the fs-helper component (codex.exe --codex-run-as-fs-helper), which performs the attachment download, has a malfunctioning filesystem-policy enforcement that denies all of its own write operations withos error 5— regardless of the target directory or how permissive the ACLs are.ChatGPT mode's attachment download happens to go through this exact path (fs-helper wrapped in the elevated sandbox), so it fails every time. Codex mode downloads attachments through a different path that does not involve this component/backend, so it works.
Workaround: switch the sandbox backend from elevated to restricted-token in
C:\Users\<you>\.codex\config.toml:Restart Codex after editing. Command execution remains sandboxed (restricted-token mode); only the defective elevated backend is bypassed.
Evidence
The real failing path. By intercepting the fs-helper process with a transparent stdin/stdout tap, we captured the exact request it receives. Attachment downloads target an
attachments\<uuid>directory inside the workspace, not~/.codex/attachments:{"operation":"fs/createDirectory","params":{"path":"file:///C:/Users/P4n/Documents/Codex/2026-10-02/new-chat/attachments/340fbbc7-…","recursive":true,"followSymlinks":false,"sandbox":null}} → {"status":"error","payload":{"code":-32600,"message":"Access is denied. (os error 5)"}}Local replay reproduces it 100%. Replaying the full captured invocation (
--run-as-windows-sandbox --permission-profile {…} --windows-sandbox-level elevated …) against the same workspace reproduces the exact error.OS permissions are fine. Inside the very same sandbox,
cmd.exe /c mkdirsucceeds in the workspace and in Temp. The token isCodexSandboxOffline+ enabledCodexSandboxUsersgroup + Medium integrity level, and the target ACLs grant Modify. Yet the fs-helper fails to write everywhere — workspace, Temp, even a directory with a fully open ACL.Controlled experiment. Changing only
--windows-sandbox-levelfromelevatedtorestricted-token, the identicalfs/createDirectorycall succeeds:{"status":"ok","payload":{"operation":"fs/createDirectory","response":{}}}Fix verified. After setting
sandbox = "unelevated"and restarting, uploaded images download successfully into<workspace>\attachments\<uuid>\and the model can read them.Mode difference. On the same machine, ChatGPT mode (Work / Astra) fails 100% of the time while Codex mode works. This proves the two modes use different attachment-download pipelines: ChatGPT mode goes through the elevated-sandboxed fs-helper (the broken path), Codex mode does not. Comparing these two code paths should lead straight to the regression.
Ruled out during troubleshooting
~/.codex/attachmentsCodexSandboxUsersModify~/.codex(33 capability-SID denies) overriding allowsC:\Users\Default, mkdir there deniedDefault\.codex\attachmentswith full grants (elevated)cap_sid[sandbox_workspace_write] writable_rootsAdditional facts established along the way:
~/.codex, explicit allows on writable subdirs likememories) works as designed and is unrelated.%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>on every launch.Suggested fix direction for the Codex team
elevatedbackend, leaving it with an empty writable set so every write is rejected withos error 5. Underrestricted-tokenthe same request succeeds.codex.exe --codex-run-as-fs-helperand which sandbox level is applied) should pinpoint the regression in 26.928.4866.0.System state after the workaround
Kept (the fix itself):
~/.codex/config.toml:[windows] sandbox = "unelevated"(previous value"elevated"; backup atconfig.toml.bak-kimi-20261002).Reverted temporary changes:
~/.codex/attachmentsACL (back to app-managed defaults),C:\Users\Default\.codex(deleted), bothcodex.exebinaries (restored to originals),writable_rootsconfig section (removed), all test directories and trace logs (cleaned up).Rollback once fixed upstream: after the issue is fixed and Codex updated, set
sandboxback to"elevated".Note: unelevated (restricted-token) mode does not require admin elevation for sandbox setup and offers slightly weaker isolation than elevated; for most workflows there is no practical difference.
Report date: 2026-10-02. All diagnosis and verification performed locally on the affected machine.
cbs01-ai commentedon Oct 3, 2026
Same exact issue here.
Version 26.930.21537
ChatGPT Windows app package 26.930.2377.0
"Unelevated" addresses the issues as stated above.
ChatGPT Work cannot access uploaded screenshots; normal Chat works. Work commands execute successfully, but attachment retrieval fails with OS error 5. App Repair, sandbox helper-folder recreation, and elevated sandbox reprovisioning did not resolve attachment access.
herooftheday77 commentedon Oct 3, 2026
Same issue here, too.
App Version 26.930.31730
Windows 11 Home
updated from 03 Oct 2026
cannot create attachment directory: access denied (os error 5)
before and after the update no difference.
In "Work" mode (Chat mode works):
Task was a simple longer text which was automatically attached as an .md file.
Tried it via Web Browser too. No difference, same error.
Tried it again. This time I started the conversation in WORK mode via Web first, using Astra medium. And it just worked right from the beginning...
PS:
Work runs with the cloud option enabled.
coconvggieez commentedon Oct 4, 2026
The only “fix” or workaround that I’ve found is opening the Work chat on my phone, iPad, or on the Web first and then switching back to the desktop app in that same chat. Opening it on desktop app first and trying another device or browser will not work.