Codex Desktop task inventory stops at 50 and agents fallback requires standalone install #41249

What version of the Codex App are you using?

ChatGPT/Codex Desktop 26.820.80927 (build 7271); Codex CLI 0.150.1.

What subscription do you have?

Not included because it is not material to this local reproduction.

What platform is your computer?

Darwin 25.6.0 arm64 arm — macOS 26.6.2 (build 25G83).

What issue are you seeing?

A Local Project task's app-exposed list_threads({limit: 50}) inventory returned exactly 50 mixed tasks, but that tool exposes no continuation cursor, exact-project filter, or completeness marker. It therefore cannot prove a complete project inventory.

The embedded terminal itself works. Direct ephemeral codex app-server --stdio access can paginate local Codex threads through thread/list, but that does not add pagination to the Desktop task tool and does not prove the separate ChatGPT Cloud Project inventory.

Separately, the advertised codex agents path fails for the working externally managed npm installation before it shows an inventory:

Error: managed standalone Codex install not found at [redacted]

This command requires the standalone install managed by the Codex installer, because the daemon starts and updates app-server from that fixed path.

This creates a two-part coverage gap: the Desktop wrapper stops at 50, while the convenient agent-dashboard fallback requires a different installation layout.

What steps can reproduce the bug?

1. Open a Codex-mode Local Project task in the macOS Desktop app.
2. Request the app-exposed task inventory with a limit of 50.
3. Observe exactly 50 returned items and no cursor, project filter, or terminal-completeness field in the exposed tool contract.
4. Confirm the embedded terminal is functional.
5. From that terminal, run codex agents using Codex CLI 0.150.1 installed through npm.
6. Observe the managed-standalone-path error before the dashboard loads.
7. As a control, start ephemeral codex app-server --stdio and call thread/list with cursors. Local Codex-thread pagination works, showing that Terminal/App Server availability and the two reported limitations are separate.

No logs, screenshots, diagnostics, local paths, account identifiers, private project identifiers, task titles, or legal material are attached.

What is the expected behavior?

• The Desktop task inventory should support exact-project filtering, opaque cursor pagination, and an explicit completeness/terminal marker.
• codex agents should work with a supported externally managed Codex executable, or expose a documented external executable/update-ownership mode.
• Local Codex-thread inventory and ChatGPT Cloud Project inventory should remain explicitly distinguishable rather than being inferred from one another.

Additional information

OpenAI feedback receipt ID: no-active-thread-01a0463b-d28e-7312-9363-fb81c9dbe198.

Overlapping reports were found before filing; this separate consolidated reproduction is being filed at the account owner's explicit request:

• Codex Desktop list_threads needs project-scoped cursor pagination for safe automations #39849 — Desktop list_threads needs project-scoped cursor pagination.
• Codex Desktop silently hides project conversations outside the global recent-50 window #21128 — older project conversations can fall outside the recent-50 window.
• Cannot use codex agents when brew install #41187 — codex agents fails with a non-standalone installation.
• Support externally managed app-server daemon executables #41188 — request for externally managed App Server daemon executable support.

Why this cannot be fully fixed inside a task:

• A task cannot add cursor or project-filter fields to the host-provided Desktop tool schema.
• The fixed managed-install path is upstream CLI/daemon bootstrap behavior; no supported external executable override was found.
• Direct App Server pagination is a Local-only partial workaround and does not prove Cloud Project coverage.
• Installing a second global distribution, adding a compatibility link, or replacing a persistent daemon would change user-wide installation/update ownership and is not necessary to reproduce the product gap.