Codex Desktop (macOS): Codex Security plugin detail opens blank after app/list pushes the full 2,402-app catalog

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.715.72359 (build 5718)

Embedded Chromium / Codex Framework: 150.0.7871.124

Bundled app-server user agent: Codex Desktop/0.145.0-alpha.30

Codex primary runtime: 26.715.12143

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.5.2, Apple silicon (arm64)

What issue are you seeing?

Opening Plugins → Codex Security in Codex Desktop can leave the plugin detail content completely blank. The rest of the app remains alive and authenticated, and the Codex Security plugin itself is installed, enabled, and readable through the app-server.

The failure correlates with the plugin detail route loading the global app directory. Codex Security references only three apps (Linear, GitHub, and Atlassian Rovo), but app/list emits a full merged-directory notification containing thousands of apps before the paginated response completes.

A standalone read-only app-server measurement using the same installed Desktop binary produced:

app/list request params: forceRefetch=false, limit=100

app/list/updated notification:
  elapsed: 131 ms
  entries: 2,402
  JSON line size: 3,154,987 bytes

app/list response:
  elapsed: 11,151 ms
  entries: 100
  nextCursor: "100"
  JSON line size: 126,701 bytes

The actual affected Desktop session showed the same latency pattern:

app/list durationMs=14146 errorCode=null
app/list durationMs=80 errorCode=null
app/list durationMs=67 errorCode=null
skills/list durationMs=265 errorCode=null

Immediately afterward, the renderer entered a UI/refetch loop:

thread/list responses: 22 during 07:37:59 UTC
thread/list responses: 23 during 07:38:00 UTC

The main-process log then repeatedly reported:

[desktop-notifications][global-error] ResizeObserver loop completed with undelivered notifications.

During the affected state, the primary renderer was measured at approximately 223% CPU and 1.1 GB RSS. There was no render-process-gone event and no relevant 401, 403, or 5xx response.

The backend/plugin data itself appears healthy. A direct plugin/read for remote plugin Plugin_1e648473be9c8191a91ac3947151af55 succeeded and returned:

plugin: codex-security@openai-curated-remote
version: 0.1.11
installed: true
enabled: true
skills: 12
apps: 3
mcpServers: ["codex-security"]

Authentication checks (getAuthStatus and account/read) also completed successfully at the incident time.

This makes the issue look like a Desktop plugin-detail rendering regression triggered by the global app-catalog update, rather than a Codex Security package, auth, entitlement, or service-backend failure.

What steps can reproduce the bug?

1. Use Codex Desktop 26.715.72359 on macOS with the Codex Security plugin installed and enabled.
2. Open the Plugins surface.
3. Select Codex Security.
4. Observe that the plugin detail content remains blank instead of showing the plugin header, starter prompts, skills, apps, and MCP information.
5. Inspect the Desktop main-process log around navigation.
6. Observe a slow first app/list request, full app/list/updated catalog delivery, repeated thread/list requests, and ResizeObserver loop errors.

The app-server payload/latency portion can be reproduced independently by initializing the bundled app-server and sending:

{"id":2,"method":"app/list","params":{"forceRefetch":false,"limit":100}}

Even though the requested page limit is 100, the preceding app/list/updated notification contains the entire merged catalog.

What is the expected behavior?

• The Codex Security detail page should render normally or show an explicit loading/error state.
• A plugin detail page that already knows its three connector IDs should preferably use app/read for those IDs rather than loading the complete global app directory.
• Receiving app/list/updated should not trigger an unbounded render/refetch loop.
• Pagination limits should remain meaningful to Desktop clients; a 100-item request should not require the renderer to ingest a multi-megabyte, 2,402-item update merely to render three plugin apps.
• The route should remain responsive while directory apps load, and repeated resize notifications should be bounded or deduplicated.

Additional information

The Codex Security manifest is valid and contains non-empty display metadata, descriptions, three starter prompts, a logo, 12 skills, three apps, and one MCP server. The shipped plugin detail implementation also has explicit loading, missing, and error states, so the completely blank result does not appear to be caused by missing README or display metadata.

Potential mitigation in the client:

1. Use app/read with the connector IDs from plugin/read for plugin-detail rendering.
2. Avoid replacing plugin-detail state with the full app/list/updated catalog.
3. Deduplicate or throttle app-list invalidations and resize-driven state updates.
4. Keep the plugin header/error state mounted while connector metadata is loading.

Related but not exact duplicates:

• #34890 concerns a broader macOS renderer OOM/reload loop under heavy multi-thread use. This report is scoped to a deterministic Codex Security plugin-detail path and the app/list catalog payload/latency.
• #32942 concerns restored-task MCP process fan-out and renderer reloads. This report does not require MCP startup or a renderer crash.
• #23795 is a Windows whole-app white-screen issue after login, not a macOS single-route plugin-detail failure.

Privacy note: local usernames, repository names, thread IDs, request IDs, complete logs, auth material, and signed asset URLs have been omitted. Sanitized timing summaries or selected log excerpts can be provided if maintainers need them.

completed Codex Security MCP items inspected: 13
server: codex-security
pluginId: codex-security@openai-curated-remote
items with appContext: 0
items routed to an Atlassian MCP server: 0