All installed ChatGPT Skills are visible but “not available in this session” across two workspaces

I am experiencing a regression bug affecting all of my custom ChatGPT Skills across two workspaces.

For example, one of my Skills is named thesis-literature-search-p5-json-perplex-split, but the issue is not limited to this single Skill. Every Skill I install shows the same behavior.

Symptom:

Any installed Skill appears in the Skill Gallery.

I can mention any Skill in chat using @skill-name (e.g., @thesis-literature-search-p5-json-perplex-split).

When I try to use any Skill, ChatGPT reports that the Skill is “not available in the current session.”

This has persisted for about one week. Previously, Skills worked normally in my workspace.

Key points:

I am the admin of Workspace 1 and have fully enabled Skills permissions. Skills in this workspace used to work before the issue started.

Workspace 1 details:

Workspace name: Luận văn 2026

Organization ID: org-QpzB0nKufRVomkMmX6nVExzf

Workspace ID: c2b12db9-b770-43a9-8e9c-2474b9d00409

My account: vanhunghvkt@gmail.com (@vanhunghvkt)

I also belong to Workspace 2 (I am not an admin there). The admin of that workspace has confirmed that Skills permissions are enabled there as well.

In both workspaces, for all installed Skills, all members see the same behavior:

Skills are visible in the Gallery.

Skills can be mentioned with @.

Skills cannot be invoked and are reported as “not available in this session”.

This strongly suggests a platform‑level or account‑level issue, not a local configuration or packaging issue for a single Skill.

I have already reported this issue 2–3 times, but it remains unresolved.

Steps to reproduce (for any installed Skill):

Open a new chat in Workspace 1 (or Workspace 2).

Type @skill-name and select an installed Skill from the mention list (for example, @thesis-literature-search-p5-json-perplex-split).

Attempt to invoke the Skill.

ChatGPT responds that the Skill is not available in the current session.

Request:

Please treat this as a regression bug and escalate it to the engineering team, because it affects all installed Skills, all members, and two separate workspaces, and it is not resolved by toggling permissions or reinstalling Skills.

If needed, I can provide screenshots showing:

Skills visible in the Gallery.

Successful @ mention for multiple Skills.

The “not available in this session” error message when trying to invoke any Skill.

Reference: Skills in ChatGPT – https://help.openai.com/en/articles/20001066-skills-in-chatgpt

Hi @vanhunghvkt, completely understand the confusion here, especially with the Skills appearing installed but still showing as unavailable in-session.

This has already been escalated to the engineering team, and we’ll keep the thread updated once we hear more from them.

If you notice anything else that seems relevant, feel free to add it here since it may help the investigation.

-Mark G.

Hello OpenAI Support Team,

I am following up on my previous reports about a regression affecting custom ChatGPT Skills in my workspaces.

I have now performed additional diagnostics and found evidence that may help your engineering team investigate the issue more precisely.

Summary of the original issue

For about one week, all custom Skills installed in my workspaces showed the following behavior:

  1. The Skill appeared correctly in the Skill Gallery.

  2. The Skill could be mentioned in chat using @skill-name.

  3. When attempting to invoke or use the Skill, ChatGPT reported that the Skill was “not available in the current session.”

This affected multiple Skills, all members, and two separate workspaces.

Example Skill:

thesis-literature-search-p5-json-perplex-split

However, the issue was not limited to this Skill. Every installed Skill showed the same behavior.

Workspace and account details

Workspace 1:

  • Workspace name: Luận văn 2026

  • Organization ID: org-QpzB0nKufRVomkMmX6nVExzf

  • Workspace ID: c2b12db9-b770-43a9-8e9c-2474b9d00409

  • My account: vanhunghvkt@gmail.com / @vanhunghvkt

  • Role: Admin

  • Skills permissions: Enabled

Workspace 2:

  • I am a member, not an admin.

  • The admin confirmed that Skills permissions are enabled.

  • The same issue occurred for all members there as well.

Because the issue affected all Skills, all members, and two workspaces, I originally believed this was a platform-level or account-level regression rather than a packaging problem in a single Skill.

New diagnostic result

After the original issue, I tried the following recovery process:

  1. I uploaded one of the non-working Skill ZIP files into ChatGPT.

  2. I asked ChatGPT to read the Skill content carefully and generate a prompt to recreate an identical Skill.

  3. I used the Skill Creator flow to recreate and repackage the Skill.

  4. I installed the newly recreated Skill.

  5. The newly recreated Skill worked successfully in the workspace.

Then I compared the original non-working Skill ZIP with the newly recreated working Skill ZIP.

Key finding

The Skill content was effectively the same:

  • Same root folder name: thesis-source-audit-v1/

  • Same SKILL.md content

  • Same agents/openai.yaml content

  • Same required Skill structure

  • Both packages passed the Skill Creator validation/package flow

However, there was one important difference:

The non-working ZIP used restrictive file permissions

In the non-working ZIP, most files had permissions similar to:

rw------- / 600

This included important files such as:

  • SKILL.md

  • agents/openai.yaml

In the working ZIP, files had normal readable permissions:

rw-r--r-- / 644

This suggests that the Skill may have been accepted into the Gallery and mention index, but the runtime/session Skill loader may not have been able to read the required files after extraction, depending on which user/process performs the session-level scan.

That would explain the observed behavior:

  • Skill is visible in Gallery

  • Skill appears in @skill-name mention list

  • Skill cannot be invoked

  • ChatGPT reports “not available in the current session”

Additional minor difference

There was also a minor line-ending difference in a CSV reference file:

  • Working ZIP: LF

  • Non-working ZIP: CRLF

I do not believe this was the primary issue because the Skill entrypoint and metadata files were otherwise identical. The file permission difference appears much more likely to affect session loading.

Why this may still indicate a platform issue

Even if restrictive file permissions contributed to the failure, the platform behavior is still problematic because:

  1. The Skill was accepted and shown in the Gallery.

  2. The Skill was available for @skill-name mention.

  3. The user received only a generic “not available in the current session” error.

  4. The validation/package flow did not surface the permission issue.

  5. Repackaging the same content with normalized permissions made the Skill work.

This suggests a possible gap between:

  • Upload-time validation

  • Gallery/index registration

  • Mention/autocomplete registration

  • Runtime/session Skill loading

Suggested engineering checks

Could the engineering team please check the following?

  1. Whether uploaded Skill ZIP files are normalized to safe readable permissions during ingestion.

  2. Whether SKILL.md and agents/openai.yaml are always readable by the runtime/session loader after extraction.

  3. Whether the Skill Gallery index and @mention index can become inconsistent with session-level Skill availability.

  4. Whether the validator should reject or warn about ZIP files where required files have restrictive permissions such as 600.

  5. Whether the “not available in the current session” error could include a more specific diagnostic reason, such as unreadable entrypoint, missing metadata, permission issue, failed extraction, or loader failure.

  6. Whether existing installed Skills in affected workspaces may need to be reprocessed or re-normalized server-side.

Expected behavior

If a Skill is visible in the Gallery and selectable via @skill-name, then it should either:

  • be available for invocation in the current session, or

  • show a specific actionable error explaining why it cannot be loaded.

Actual behavior

The Skill appears installed and selectable, but invocation fails with:

“not available in the current session”

Current workaround

Recreating or repackaging the same Skill through the Skill Creator flow appears to normalize the package and makes the Skill usable again.

However, this is only a workaround. It does not explain why previously installed Skills became unavailable, nor does it help users diagnose affected Skill packages.

Request

Please escalate this follow-up to the engineering team as a Skill ingestion / session-loader / package-permission issue.

I can provide both ZIP files for comparison:

  1. The original Skill ZIP that was visible in the Gallery but not available in session.

  2. The recreated Skill ZIP with the same content that works after installation.

I can also provide screenshots showing:

  • Skills visible in the Gallery

  • Successful @skill-name mention/autocomplete

  • The “not available in the current session” error

  • The working behavior after repackaging through Skill Creator

Thank you.