›_ Codex Issues
Codex Issues / #24361

Bug: Skills/App listing shows 1000+ inaccessible ecosystem Apps after Desktop install/sync

Open 💬 6 comments Opened May 24, 2026 by TungOil
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What happened?

After installing/syncing the Codex Desktop app, the Codex skills/app listing started showing hundreds of unrelated ecosystem Apps as if they belonged in the local skills list. Examples include Korean marketplace/consumer apps such as:

  • 엘포인트 — [App] Pay and earn points at once!
  • 요기요 — [App] 배달할 때마다 포인트 적립
  • 운세박사 — [App] Free Saju & Fortune Reading
  • 전자랜드 — [App] 전문가가 고르고, 혜택은 더하고
  • 정통사주 - 띠별 오늘 운세 — [App] 띠와 출생연도를 바탕으로 보는 오늘의 운세
  • 칠성몰 — [App] 롯데칠성음료 공식 온라인몰
  • 카카오골프예약 — [App] Find golf courses & tee times

This is noisy and confusing because these are not installed local skills and are not accessible tools for the session.

Local evidence

The entries are coming from the local app directory cache:

~/.codex/cache/codex_app_directory/716cc53acea93e5f048d344078d63cf3d01e78ec.json

A local inspection showed:

connectors: 1151
isAccessible == true: 0
isAccessible == false: 1151

So the UI/listing appears to be surfacing the entire ecosystem directory, including inaccessible apps, instead of filtering to installed/accessible apps or separating them clearly from local skills.

Expected behavior

The skills list should show only actual local/session skills, or at minimum only installed/accessible apps. Inaccessible ecosystem-directory entries should not be displayed as available skills/apps in the working session.

Actual behavior

The listing is polluted with 1000+ unrelated [App] entries from ~/.codex/cache/codex_app_directory/*.json, even though every listed connector in that cache has isAccessible: false.

Environment

codex-cli 0.133.0
Codex Doctor v0.133.0 · linux-x86_64
Executable: /home/linuxbrew/.linuxbrew/bin/codex
Terminal: VS Code 1.107.0
CODEX_HOME: ~/.codex
Config: ~/.codex/config.toml
MCP servers: 0
Plugins enabled locally: github@openai-curated
Background app-server: not running (ephemeral mode)

codex doctor reports the install/config/state DBs as healthy. The only note is mixed auth signals due to ChatGPT login plus OPENAI_API_KEY, but the app directory cache issue appears unrelated.

Suspected regression

This started after installing the Codex Desktop app. It looks like Desktop/app-server sync populated the public Apps/Connectors directory cache, and the CLI/TUI listing path is not filtering out isAccessible: false ecosystem entries.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #24205
  • #24145

Powered by Codex Action

yui-stingray · 3 months ago

I checked the code path. The $ mention popup filters connectors to is_accessible && is_enabled, so the 1000+ inaccessible entries do not appear to be coming from mention generation itself. The app/list path merges cached directory apps with accessible apps, and there are tests covering inaccessible enabled directory apps in that response. If the Desktop UI is rendering that merged app/list data as the user-facing Skills/Apps list, the likely fix is to filter at the UI/consumer boundary, or split the API behavior for "all directory apps" versus "usable apps."

hickeyadamc · 3 months ago

I hit this too in Codex CLI v0.133.0.

Typing /skills surfaced a large number of unrelated [App] entries — examples included consumer apps like 123 Piano, 12Go, 12andus Astrology, 1800Flowers, 3-2-1 Go Stopwatch, 3Min API, 4Degrees, and 789 Sudoku — while my actual skills were buried in the list.

For my workflow, skills are not casual suggestions; they are part of my engineering environment and I treat them like code. Mixing unrelated app-directory entries into the skills surface makes /skills noisy enough to be operationally unusable.

The workaround that fixed it was:

codex features disable apps

But the expected behavior is that /skills remains dedicated to actual skills, and apps/connectors live under a separate namespace or are opt-in. Please do not populate the skills picker with public/consumer [App] entries by default.

yui-stingray · 3 months ago

I checked the current code paths, and I do not think the noisy [App] entries are coming from the backend skills/list result.

skills/list builds its response from skills_manager.skills_for_cwd(...), while model-visible app instructions are filtered to connectors that are both accessible and enabled.

The inaccessible [App] entries look more consistent with app/list: that path merges accessible apps with directory apps, and directory-loaded apps are kept with isAccessible = false. The existing tests also expect inaccessible directory-only apps to appear in app/list updates.

So if the /skills UI is rendering those entries, the likely fix is at the consumer/UI boundary that reads app-list data, not in skills/list itself. I can trace the exact call site next if that would help.

GRGAINZ · 3 months ago

+1 for me, I note if you turn on Mentions v2 in experimental and use @ instead of $ it doesn't render the unrelated plugins etc though.

ragtimelab · 1 day ago

I can reproduce a related current regression on macOS with codex-cli 0.149.1 (Intel, macOS 15.7.8) after connecting Spotify in Codex Desktop.

Reproduction

  1. Start a fresh Codex CLI TUI in either Ghostty or an Orca-hosted terminal.
  2. Type $spotify in the composer.
  3. The same two candidates appear in both terminals:

``text
Spotify [Plugin] Music and podcasts for you
Spotify [App] Explore a new way to discover music and podcasts, ...
``

  1. Selecting the [Plugin] candidate inserts the opaque internal mention $app-68de829bf7648191acd70a907364c67c; selecting [App] inserts $spotify.
  2. In the Codex Desktop composer, $spotify currently exposes only the friendly Spotify App candidate.

Current local state

  • apps, plugins, remote_plugin, and mentions_v2 are all stable and enabled.
  • The App Directory entry for connector_68de829bf7648191acd70a907364c67c (Spotify) has isAccessible: false and isEnabled: true.
  • The remote catalog contains plugin_asdk_app_68de829bf7648191acd70a907364c67c, display name Spotify, but its internal name is app-68de829bf7648191acd70a907364c67c. It has no skills and declares the Spotify connector as its required app.
  • The plugin wrapper is reported as not installed, while the Spotify connector is present. codex plugin list --json does not list Spotify as an installed or available local marketplace plugin.

This looks like the inaccessible-App issue recurring through the $ mention path in a newer CLI, with an additional ambiguity: an uninstalled remote plugin wrapper is suggested alongside its required App connector. I did not delete caches or disable apps, so the state above is preserved for diagnosis.

Expected behavior: the TUI should not surface the inaccessible connector or its uninstalled remote wrapper as separate usable $ candidates. If the connected app is intentionally available, it should be the single human-readable candidate rather than an opaque app-... wrapper plus an App row.