Codex Desktop: is the empty $ skills picker a temporary upgrade issue?

Codex
, ,
1

Hi OpenAI team,

I’m trying to understand whether this is a known temporary upgrade issue in Codex Desktop’s skills system, or whether there is something wrong with my local setup.

Right now, all my skills, including the built-in system skills, are physically present and can be loaded directly, but the $ picker says no skills or apps exist. And no skills found in Plugins > Skills or Plugins > Manage either.

When I type $ in Codex Desktop, I see:

Loading skills and apps…
No skills or apps found

However, direct invocation works. For example, when I ask:

Use $skill-creator and tell me whether you can see the skill.

Codex responds that it can load:

~/.codex/skills/.system/skill-creator/SKILL.md

So the runtime can read the skill, but the picker/listing layer seems unable to enumerate it.

What I have checked

System skills exist on disk:

~/.codex/skills/.system/imagegen/SKILL.md
~/.codex/skills/.system/openai-docs/SKILL.md
~/.codex/skills/.system/plugin-creator/SKILL.md
~/.codex/skills/.system/skill-creator/SKILL.md
~/.codex/skills/.system/skill-installer/SKILL.md

Codex appears to be using the expected home directory:

PWD= ~/xxx
HOME= xxx
CODEX_HOME= ~/.codex

I also checked both user and project config files. I only found:

experimental_use_profile = false

I did not find any obvious skill-disabling config such as:

skills.bundled
skills.config
enabled = false
chronicle

My question

Current Codex docs now say personal skills live in ~/.agents/skills, instead of ~/.codex/skills. Is the current skills behavior a known glitch from the recent Codex app upgrade, or is it part of a planned migration?

More specifically:

  1. Should users expect the $ picker to currently list skills like system built-in $skill-creator and personal skills I created?

  2. If direct $skill-creator invocation works but the picker says “No skills or apps found,” is that a known UI/indexing bug?

  3. Is this expected to be fixed automatically in a future Codex Desktop update, or should users migrate custom skills manually to ~/.agents/skills?

  4. Is there a recommended cache/index reset for the picker specifically, without deleting ~/.codex or auth/session data?

I’m using the latest Codex Version 26.519.81530 (3178) on Mac

Thanks.

2

Welcome to the community and thanks for laying this out so clearly @irisa.

Based on the current docs, ~/.agents/skills is now the expected user-skill location, while bundled system skills should still be available in Codex. The weird part is that $skill-creator works by direct invocation, but the $ picker and Plugins UI show nothing. That feels more like a picker/indexing issue than a missing-skill issue.

I’d try moving or copying custom skills to:

~/.agents/skills

Then restart Codex. I wouldn’t delete ~/.codex just to test this, since that can wipe useful auth/session/config state.

Docs link for reference: Codex Skills

Curious if anyone on the same Mac version sees built-ins listed in the picker, since that would help separate migration behavior from a UI bug.

-Mark G.

3

Hello Mark,

Thanks for the reply! The problem is sorted now. Turns out it was some kind of compatibility clash with Codex’s “permission profile system.” (Is that a recent update, by the way?)

I caught it because one of my workspaces was basically locked down in Codex. Whenever I tried to pick up an old thread or start a new one, I kept getting this error message in that workspace:

failed to load configuration: filesystem glob path '**/*.p12' only supports 'deny' access; use an exact path or trailing '/**" for 'deny' subtree access.

ChatGPT 5.5 says it’s because **/*.p12 was set to none in the ~/.codex/config.toml file. That none value used to be fine, but the current Codex permission profiles can’t handle it, which completely choked the system. Once I changed none to deny, the workspace went back to normal, and the skill problem vanished too.

ChatGPT 5.5 also reckoned I should switch over to this new permission profile system and ditch the legacy sandbox setup, so I’m working on that now.

I hope this information helps others facing the same issue.

Oh, by the way—after Codex updated a few hours ago, I noticed some of my old chat threads have gone missing, or at least they’ve vanished from the sidebar. Pretty much anything older than 24 hours is gone. Fingers crossed it’s just a temporary glitch with the update and they’ll be back soon.

Cheers,

irisa

4

Thanks for sharing the follow-up, @irisa. That’s a really useful find.

The error you tracked down does line up with the newer Codex permission profile behavior. A few people have run into issues where legacy permission settings that were previously tolerated end up blocking workspace initialization after an update. Changing **/*.p12 from none to deny restoring the workspace is a helpful workaround for anyone seeing the same configuration error.

Good catch on the missing threads as well. If they disappeared shortly after an update and are only missing from the sidebar, there’s a decent chance it’s related to indexing or sync rather than the conversations being permanently gone.

As a next step, I'd suggest trying a full Codex restart first. If the older threads still don't reappear, try reinstalling/updating to ensure all components are in sync.

If the issue persists after that, please open a support ticket at support@openai.com and drop the case ID here. That will make it easier for the team to monitor what's happening and help troubleshoot further.

Please keep us posted on whether the missing conversations return after a restart.

-Mark G.

5

Hello Mark,

Thanks for your reply. The missing threads didn’t reappear after the full Codex restart (or a full mac restart), sorry. I’ve opened a support ticket. Case Number: 09594262

cheers,

irisa

6

Thanks for creating a case and sharing the details, @irisa.

This appears to be a current limitation following the recent update. We'll be forwarding this feedback to the team so they can review the behavior and evaluate improvements.

For now, the recommended workaround is:

• When a project/workspace is expanded, call thread/list with a server-side cwd filter, or add a server-side cddPrefix / projectRoot filter if child working directories should be included.

• Apply pagination after the project filter has been applied, not before.

• Avoid using the first global recent-thread page as the source of truth for a project's sidebar history.

If you're seeing anything different from the behavior described above, feel free to share additional examples.

-Mark G.