[macOS 26.901 / 0.153.4] Persistent Desktop task loses thread-management tools; CLI fallback remains backend-readable

What version of the Codex App are you using?

• Desktop bundle metadata: 26.901.51231, build 8109, bundle identifier com.openai.codex (read from Info.plist, not About dialog).
• Desktop bundled runtime: codex-cli 0.153.4.
• Separately installed CLI: codex-cli 0.153.4.

What subscription do you have?

Not independently verified during this diagnostic; omitted rather than inferred.

What platform is your computer?

Darwin 25.6.0 arm64 arm (macOS, local Desktop task).

What issue are you seeing?

A persistent local Desktop task could successfully use built-in task-management tools earlier in the conversation, but later its model-visible tool registry no longer contained create_thread, read_thread, list_threads, or send_message_to_thread. Basic app tools, including navigate_to_codex_page and read_thread_terminal, remained available. The task's instructions still refer to task-management operations.

An actual attempted call to the previously available tool failed before any backend authorization response:

TypeError: tools.mcp__codex_app__send_message_to_thread is not a function

Repeated enumeration of the currently exposed ALL_TOOLS confirmed that the management functions were absent. This is an absent callable-tool surface, not an observed permission-denied response. No tool-discovery/search capability that could expose these missing app tools was available in the affected turn.

What steps can reproduce the bug?

The initiating transition is not yet isolated; the following is an observed diagnostic sequence, not a deterministic fresh-install reproducer:

1. In an existing local Desktop project task, ask the agent to inspect or create another task.
2. Enumerate the currently available app tools. The management tools above are absent, while basic navigation tools remain.
3. Attempt the previously callable task-message tool; observe the TypeError above.
4. As a separate fallback experiment, run codex exec --json -C <new-git-worktree> <prompt>.
5. The CLI emits thread.started, turn.started, and actual work output. However, the user cannot find this task automatically under the expected Desktop project and reports difficulty reading it through Desktop.
6. navigate_to_codex_page returns {"navigated":true} for that ID. This does not establish that the task content rendered or that project membership was assigned.
7. A read-only App Server diagnostic successfully reads the same persisted task:

{"id":2,"method":"thread/read","params":{"threadId":"<redacted>","includeTurns":true}}

Sanitized result:

{"readSuccess":true,"source":"exec","cwd":"<new-git-worktree>","turnCount":1}

The original Desktop task has source vscode; the fallback task has source exec. Both use paginated history and are not archived. A read-only local metadata check returned null project_id for both, including the existing Desktop project task, so null alone is NOT evidence of the cause. No state/history database was modified.

What is the expected behavior?

• Supported Desktop task-management tools should remain available consistently, or the app should explicitly explain why they are unavailable and how to restore access.
• Instructions should not promise an app tool surface that the active turn cannot discover or call.
• Please clarify the supported path for creating a Desktop-visible, project-associated task. We do not assume codex exec must provide the same project association as the Desktop creation API.
• A navigation acknowledgement should not be interpreted as proof of readable content or successful project association; an actionable UI error would help distinguish these cases.

Additional information

This installation has records of 0.153.4 tasks beginning September 7, and successful task-management calls earlier in this persistent conversation on September 8. Consequently, we have NOT established that a CLI update caused the failure. Desktop update timing, model/provider routing, feature flags, and task restoration remain hypotheses requiring controlled comparison.

The local config selects gpt-6-astra and provider identifier openai-http; this identifier alone does not establish a third-party endpoint or the actual route used for every Desktop turn. No provider endpoint or credentials are attached. No model/provider A/B test was performed.

The task itself is readable through App Server, so we do NOT claim transcript loss/corruption. We also do not claim a filesystem-permission problem, a confirmed regression in a specific release, or that changing repository rules can restore missing system tools.

Related reports: #31366 (older-task tool exposure), #33637 (model-dependent exposure), #37075 (provider-dependent exposure), #41404 (browser policy affecting tools), #40865 (missing replacement tools). Please consolidate if this is the same defect; this report adds the current macOS 26.901/0.153.4 observations and the successful backend-read versus Desktop/CLI fallback distinction. Unlike #43742, no duplicate-ordinal/history-projection failure has been established here.

No raw transcripts, task IDs, private project names/paths, repository source, credentials, databases, or unredacted logs are attached. No app restart, downgrade, permission expansion, or state-database repair was performed as part of this diagnostic.

Start with the persistent Desktop task's ALL_TOOLS enumeration and compare the missing thread-management calls with the available basic app tools. Then compare codex exec --json output with App Server thread/read; done means identifying a deterministic transition or documenting the supported Desktop-visible project-task path and actionable failure.