We are seeing a persistent Skills runtime propagation issue in a ChatGPT Business workspace. This started around May 4–5, 2026 for our workspace. Newly uploaded or created Skills appear correctly in the Skills UI and are marked installed/enabled, but they are not available to the model at runtime. Older Skills created before the issue started still work.
Observed behavior:
- Affected Skills appear in the Skills UI/backend.
- They are marked enabled/active.
- The Skill metadata and files are visible from the UI side.
- The model cannot read `skills:///SKILL.md`.
- The model cannot read `skills:///skill.md`.
- `/home/oai/skills/` is not present in the runtime.
- The model may see metadata/catalog references, but cannot access the actual Skill resources or invoke the Skill.
We have tested:
- New chats
- Logout/login
- Chrome and Safari
- Incognito/private browsing
- Different devices
- Different networks
- No VPN
- Reinstalling Skills
- Deleting and re-uploading Skills
- Creating new Skills with new names
- Valid Skill packages
- Older Skills still working
This looks like a mismatch between the Skills UI/backend/catalog layer and the runtime resource layer, possibly a workspace-level propagation, indexing, cache, or permissions-state issue.
We have repeatedly contacted OpenAI Support about this issue and provided HAR files, screen recordings, reproduction steps, affected Skill names, timestamps, and business impact details under support case `08516212`. Support has indicated that this may be related to an internally tracked issue, but we still do not have a workaround, timeline, or workspace-level remediation.
Question: Is anyone else on ChatGPT Business seeing newly created/uploaded Skills appear installed in the UI but fail to mount or become available at runtime?
Hi @fredmyhr, totally get how confusing this is, especially seeing the Skills installed but unavailable in the same session.
There’s already an escalated case with the engineering team on this one. We’ll keep this thread open and share an update once we hear back.
In the meantime, feel free to share any additional details you think might help the team investigate faster.
-Mark G.
I’m having similar problems in our Business account with Skills. Here’s a summary of where we’re at and we’re pretty keen for this to get fixed:
Several user-created Skills appear correctly in the Skills UI and can be opened in Edit, but they are not available to ChatGPT in a new chat. When we ask ChatGPT to use or access one of these installed Skills, it reports that it cannot see the Skill in the runtime-accessible skill library.
We have completed the following troubleshooting steps:
-
Confirmed the affected Skills appear under the Installed tab.
-
Confirmed they open successfully in Edit.
-
Confirmed they contain a SKILL.md file.
-
Confirmed the YAML frontmatter includes name and description.
-
Corrected one Skill’s YAML name from uppercase to lowercase.
-
Uninstalled and reinstalled the handoff Skill.
-
Refreshed ChatGPT.
-
Tested again in a new chat.
-
Created a brand-new minimal test Skill called kirsty-runtime-test.
-
Tested the new Skill in a fresh chat.
The issue still persists. Even the newly created minimal test Skill appears in the Skills UI but is not available in chat. The assistant continues to report that it cannot access or read the Skill.
The default skill-creator Skill does appear to work, but user-created installed Skills are not being mounted into the active chat runtime. This suggests a mismatch between the Skills UI/editor and the runtime-accessible Skill library.
This issue is also affecting other users, so it may be account-level, workspace-level, or a broader product issue.
Hey guys, just giving an update that the case is actively being worked on right now. I’ll circle back here once there’s a clearer update or fix to share so others running into the same thing have visibility too.
Also, welcome to the community @Kirsty3, appreciate the extra troubleshooting details.
-Mark G.
Thanks Mark, appreciate the update.
We can also see that something appears to have changed on our side now. Some of the affected Skills are working again, and we are able to upload and use new Skills in cases where this previously failed. I do not want to assume the issue is fully resolved yet, but the behavior does look different from before. Can you confirm whether engineering identified the root cause and whether a fix has been deployed? If so, was this related to the Skills runtime propagation/mounting issue discussed in this thread?
It would also be helpful to know whether the fix is considered complete, still rolling out, or still under investigation. Since we use Skills for production workflows in our Business workspace, we need to understand when it is safe to rely on newly created and updated Skills again.
Echoing fredmyhr question above.
I’ve definitely noticed a change, but would like to be able to definitively tell our workpalce users if this issue has been fully resolved.
Thank you for your patience folks. Initial findings suggest there can be a delay between a Skill appearing installed in the UI and it actually becoming available at runtime.
So far, logs and code review point to enabled-skills caching causing stale runtime state. In short, a Skill may look selectable before backend systems fully recognize it.
This also appears consistent with a few broader Skills reliability reports already being tracked. Still actively under investigation, but wanted to share the early context publicly.
-Mark G.
Quick update from our side: the issue is happening again. After the earlier change, Skills appeared to work again for a while, and we were able to upload and use new Skills. However, I just uploaded a new Skill now and we are seeing the same behavior again: the Skill appears installed in the UI, but it is not available at runtime and ChatGPT behaves as if it does not exist.
So this does not appear to be fully resolved. The behavior still matches the enabled-skills caching / stale runtime state issue described above.
Additional note: we are now seeing what looks like the same class of issue with Company knowledge / connectors. In the UI, Slack is enabled for the chat under Company knowledge. However, in the actual chat runtime, Slack is not exposed as an available connector/tool, and the assistant reports that it cannot access Slack even though the UI shows it as enabled.
This looks structurally similar to the Skills issue: the UI/backend state says a capability is enabled, but the runtime does not mount or expose the corresponding resource/tool. This may indicate a broader workspace-level propagation or enabled-state caching issue, not only an isolated Skills problem.
Thanks for checking on this @fredmyhr. Also appreciate the extra context around the connector escalation.
From what’s been shared so far, this does still look unresolved. The current issue seems broader than a simple connector outage since teams are also seeing inconsistent behavior with connected knowledge sources and natural-language routing/inference.
So at the moment:
- direct connector calls may still work normally (@Slack)
- connected knowledge sources and natural-language routing/inference seem to be where things are unstable
- engineering is apparently still adding tests to narrow down the root cause
- it may also be worth trying to reconnect/re-authenticate the Slack app to see if the behavior changes
There’s no update with the case status yet, but I’ll still share additional notes if applicable.
-Mark G.
