Hello — I am still experiencing a persistent ChatGPT Work Mode tool and workspace failure after the mitigation reported on the OpenAI Status page.
Timeline
- Work Mode was functioning normally earlier on September 14, 2026.
- I first noticed the issue at approximately 4:00–6:00 AM PDT (11:00–13:00 UTC).
- It has continued across multiple Work threads and clients.
- OpenAI has since posted a related incident stating that some ChatGPT Plus users had limited access to Work Mode workspace tools and files. The status page says a mitigation was applied and the service recovered, with monitoring ongoing:
Elevated errors affecting Work Mode in ChatGPT - OpenAI Status - The issue remains reproducible on my account after that mitigation.
Environment
- ChatGPT Plus
- Model: GPT-5.6 Sol, primarily High reasoning and occasionally Extra High
- ChatGPT web app in Safari on macOS
- ChatGPT macOS desktop app
- ChatGPT iOS app used as a comparison
- Reproduced both inside and outside Projects
Primary symptom: persistent tool warning
Every user turn in a Work thread triggers the following warning:
Some tools are temporarily unavailable
This occurs regardless of whether the input is:
- Plain text
- An uploaded image
- An uploaded video
The warning appears after every turn in both the ChatGPT web app and the macOS desktop app.
The interface does not identify which tools are unavailable, provide any diagnostic details, or offer a way to reload or reinitialize the affected tools.
Scope
I can reproduce the warning in:
- Existing Work threads
- Newly created Work threads
- Work threads inside multiple Projects
- Work threads outside Projects
Regular Chat threads under the same account do not display the warning.
This makes the issue appear specific to Work Mode rather than to one conversation or Project.
Functional failures discovered during testing
The warning is not merely cosmetic. Several capabilities that previously worked are currently unavailable.
1. Markdown and local file creation fail
I asked the assistant to create and save a minimal Markdown file.
The assistant could still converse and access some connected capabilities, but it did not have a usable local execution/file-writing path from which to create the source .md file. Consequently, no downloadable file was produced.
2. Uploaded PNG files produce a local workspace error
On every PNG uploaded during testing, across at least five consecutive uploads, the message delivered to Codex contained this diagnostic:
Codex could not read the local image at /workspace/scratch/.../upload/<file>.png: No such file or directory (os error 2)
The image nevertheless became visible to the assistant through the separate attachment/vision pathway.
This suggests that the attachment upload completes, but the local workspace file is unavailable when Codex first attempts to read it.
3. Uploaded video files can no longer be analyzed
I uploaded a .MOV file to an affected Work thread. The attachment uploaded successfully, but the assistant had no available capability to open the video, extract frames, play it, or otherwise inspect its contents.
The same account and workflow had previously been able to analyze uploaded videos.
OpenAI’s current documentation states that ChatGPT can accept video-file attachments and may use tools to analyze them, while noting that availability varies and that analysis may be incomplete or inaccurate:
I understand that video analysis is not guaranteed on every platform or account. However, its disappearance coincides with the repeated Work Mode warning, local file-creation failure, and local image-path errors.
iOS comparison
The same Work thread behaves differently in the iOS app:
- The “Some tools are temporarily unavailable” warning is not displayed.
- However, the underlying capability failures remain.
- Markdown creation still fails.
- Uploaded media still cannot be processed normally.
- PNG uploads still generate the local workspace
No such file or directorydiagnostic on the Codex side.
This suggests that the iOS client may not surface the warning even though the underlying Work Mode tool state remains degraded.
Troubleshooting and comparisons performed
I have tested:
- New and existing Work threads
- Multiple Projects
- Work threads outside Projects
- Web and macOS desktop clients
- The same thread in the iOS app
- Plain-text, image, and video inputs
- Regular Chat threads as a control condition
Changing threads, Projects, clients, and input types does not restore the missing capabilities.
Expected behavior
- Work Mode tools should initialize consistently.
- The warning should not appear after every turn.
- If a tool is unavailable, the interface should identify it and provide a recovery action.
- A minimal Markdown file should be creatable.
- Uploaded images should exist at the local path supplied to Codex.
- Supported video attachments should remain available to the relevant analysis tools.
- The web, macOS, and iOS clients should accurately reflect the same underlying tool state.
Could this account or its Work sessions still be affected by the September 14 incident despite the reported mitigation?
I can provide affected thread identifiers, exact timestamps, and additional screenshots privately if needed.
Figure 1&2. The Work Mode warning displayed after every user turn, regardless of input type.
Figure 3. Assistant-visible diagnostic from the affected Work thread; the raw ENOENT error occurred on every tested PNG upload.
