Fresh local 0.142.0-alpha.1 sessions no longer receive codex_app thread-management tools

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

• #29128

Powered by Codex Action

I reviewed #29128 and do not think this is an exact duplicate.

#29128 is about inconsistent exposure of codex_app.automation_update across local Desktop threads. This issue is broader: fresh local 0.142.0-alpha.1 sessions on Windows can lose the local thread-management surface entirely, including codex_app.create_thread, read_thread, send_message_to_thread, set_thread_title, and set_thread_archived, with a same-machine history showing 12 -> 1 -> 0 codex_app tools across recent sessions.

So the overlap is real around dynamic tool injection/regression in local Desktop threads, but the user-visible failure here is not just missing automation tooling. It is that fresh local sessions can no longer create/manage Codex threads at all, which breaks thread orchestration workflows such as LazyCodex teammode.

If maintainers prefer consolidation, the critical detail to preserve is that this report includes fresh local session regression evidence and the broader collapse of thread-management tools beyond automation_update.

I pushed a draft diagnostic patch for this on my fork:

• branch: tinycute00/doctor-thread-tools-surface
• compare: https://github.com/openai/codex/compare/main...Tinycute00:tinycute00/doctor-thread-tools-surface?expand=1
• commit: https://github.com/Tinycute00/codex/commit/7fba573762d17c9e2be8e3a0f95697d3c874a2fe

What the patch does:

• adds a codex doctor row that inspects recent local interactive thread rollouts
• warns when required codex_app thread-management tools are missing from SessionMeta.dynamic_tools
• includes focused tests for healthy, degraded, and no-session cases

Local verification completed:

• cargo fmt --all
• cargo metadata --format-version 1 --no-deps

Local verification blocked:

• just test -p codex-cli could not run in this Windows environment because the host is missing MSVC / Windows SDK import libs needed for linking (kernel32.lib, ntdll.lib, userenv.lib, ws2_32.lib, dbghelp.lib)

I also tried to open the upstream PR directly from this environment, but both the GitHub CLI and GitHub connector were denied on PR creation for openai/codex.

The upstream PR is ready on my fork, but GitHub is blocking PR creation from this account at the repository policy layer.

Evidence from GET /repos/openai/codex in this environment:

• pull_request_creation_policy: collaborators_only
• permissions.pull: true
• permissions.push: false

So the branch is pushed and reviewable, but a non-collaborator account cannot submit the PR itself for this repo.

Ready-to-open compare link:
https://github.com/openai/codex/compare/main...Tinycute00:tinycute00/doctor-thread-tools-surface?expand=1

If a collaborator wants a slash-free head ref, I also pushed the same commit here:
https://github.com/openai/codex/compare/main...Tinycute00:doctor-thread-tools-surface-simple?expand=1

Dynamic tool injection needs a durable capability receipt. In SessionMeta, record tool surface source, app-server version, dynamic tool group, injection reason, and missing-tool diagnostics for required groups like codex_app.thread_management.

Then codex doctor can compare recent sessions by version and show "expected 12 thread tools, got 0" without relying on user screenshots. Regression fixtures should cover healthy, degraded, no-app-server, and stale cached-tool surfaces.

---

_Generated with ax._

Additional macOS recurrence on 2026-06-21, from a current Codex Desktop side-conversation / manager-workflow context. I cannot tell from inside the affected session whether the creation path was local-vs-remote, but the visible symptom is the same dynamic-tool surface collapse: the codex_app thread-management tools are not discoverable/injected at all, so visible-thread orchestration degrades to sidecars.

Environment observed on the affected Mac:

• Codex Desktop: 26.616.51431, build 4212
• CLI: codex-cli 0.140.0
• macOS: 26.5.1 arm64 (Darwin 25.5.0)

Fresh reproduction signal from the affected session:

• Exact discovery query used:

list_threads read_thread create_thread fork_thread send_message_to_thread set_thread_title set_thread_pinned set_thread_archived handoff_thread Codex thread management

• Discovery returned 10 tools, but they were unrelated “thread” matches from other products, e.g. Vercel toolbar-thread tools and GitHub PR review-thread tools.
• No codex_app.create_thread, codex_app.list_threads, codex_app.read_thread, codex_app.send_message_to_thread, codex_app.set_thread_title, codex_app.set_thread_pinned, codex_app.set_thread_archived, codex_app.fork_thread, or codex_app.handoff_thread tools were exposed.

User-visible impact:

• A Loop Engineering manager task needed visible Codex direct-report threads.
• Because visible Codex thread tools were unavailable after exact discovery, the workflow had to fall back to non-visible sidecars: “Visible Codex thread tools were unavailable after exact discovery queries, so I used 5 fallback sidecars and accepted/rejected their evidence directly.”
• This defeats the intended UI-visible manager/direct-report workflow: the work can continue, but the sidecars are not inspectable as normal Codex threads in the app sidebar.

Recurring local history on this same machine also has the same failure shape:

• 2026-06-15: a manager investigation found the runtime lacked codex_app thread tools and fell back to multi_agent_v1.spawn_agent sidecars.
• 2026-06-17: I added a related remote-control/missing-manifest occurrence to #26907.
• 2026-06-21: the current Desktop build still produced a session where exact discovery found no Codex visible thread-management tools.

This does not look like the No handler registered variant from #28080, because here the tools are missing from discovery/injection rather than exposed and then failing at call time. It is also adjacent to #28204 (create_thread returns only pendingWorktreeId), but this occurrence happens earlier: there is no create_thread tool to call.

Expected behavior:

• If the target Desktop/session can service visible Codex thread management, the whole codex_app thread-management group should be injected consistently into fresh/side/manager sessions.
• If a session type intentionally cannot receive these tools, Codex should expose a clear capability reason (local, remote, side conversation, feature flag, version mismatch, etc.) instead of silently returning only unrelated “thread” search hits.

This is recurring often enough that agents are now carrying explicit fallback policy for it, which is a strong signal that the product surface is unreliable rather than a one-off workflow issue.

Additional macOS recurrence on 2026-07-10, specifically from a Codex Desktop side conversation where the user explicitly requested creation of a visible manager thread.

Environment:

• ChatGPT/Codex Desktop 26.707.31428, build 5059
• bundled CLI codex-cli 0.144.0-alpha.4
• global CLI codex-cli 0.144.1
• macOS arm64
• ~/.codex/config.toml: features.goals = true, features.multi_agent = true

Reproduction:

1. Open a side conversation from a long-running parent task.
2. Ask: “Create a manager thread to take care of this and validate it for me.”
3. The injected Desktop instructions explicitly direct the agent to use create_thread, list_threads, read_thread, set_thread_title, and related tools.
4. Inspect the actual turn tool surface.

Observed tool-surface receipt:

• ALL_TOOLS contained 439 tools.
• Exact matches were empty for:
• tool_search
• list_threads
• read_thread
• create_thread
• fork_thread
• send_message_to_thread
• set_thread_title
• set_thread_pinned
• set_thread_archived
• handoff_thread
• create_goal
• set_goal
• Searching tool names for thread returned only unrelated Gmail, GitHub review-thread, and Vercel toolbar-thread tools.
• No tool_search/search-tools capability was exposed, so the documented lazy-discovery recovery path could not be attempted.

Local product evidence confirms that this is an injection/capability-surface failure, not absence of implementation:

• The installed app.asar contains real definitions for create_thread, list_threads, read_thread, fork_thread, send_message_to_thread, set_thread_title, set_thread_pinned, and set_thread_archived.
• The bundled Codex binary contains tool_search, thread-store/src/local/create_thread.rs, and app-server thread-start/create-thread paths.
• The same app instructions say these tools should be searched for and used when the user explicitly requests a new thread.

This is the missing injection variant, not the No handler registered variant: there was no thread-management tool available to call.

Secondary side-conversation symptom:

• The injected working directory pointed to a project path that no longer existed, causing exec_command to fail with No such file or directory until an explicit existing cwd such as /tmp was supplied. This may indicate stale parent-to-side-conversation environment inheritance, although I am not claiming it is causal.

Expected:

• Side conversations that receive thread-management instructions should receive the coherent codex_app thread-management tool group, or at least tool_search capable of discovering it.
• If side conversations intentionally cannot create visible threads, the runtime should omit contradictory instructions and expose a structured capability reason.
• Side-conversation cwd inheritance should validate that the inherited path still exists.

Impact:

• An explicit request for a user-visible manager thread cannot be fulfilled.
• The only apparent fallback is multi_agent_v1, which is not equivalent and may be explicitly disallowed by the side-conversation boundary.
• The agent must incorrectly tell the user that the product capability is unavailable even though the installed app includes it.

Additional macOS reproduction on Codex Desktop build 26.707.31428 (5059) with bundled runtime 0.144.0-alpha.4 / installed CLI 0.144.1.

This appears to be a distinct failure mode inside the same dynamic-tool exposure path:

1. A fresh Desktop side conversation starts successfully.
2. Its rollout session_meta.payload.dynamic_tools contains the full 15-tool codex_app namespace, including:

• create_thread
• list_threads
• fork_thread
• send_message_to_thread
• set_thread_title
• load_workspace_dependencies

1. Inside that same live turn, the deferred runtime registry (ALL_TOOLS) contains none of those exact tools.
2. Direct capability checks return undefined for both naming forms tested:

• tools.codex_app__create_thread
• tools.mcp__codex_app__create_thread
• tools.codex_app__load_workspace_dependencies
• tools.mcp__codex_app__load_workspace_dependencies

1. Consequences:

• The agent cannot create the dedicated thread explicitly requested by the user.
• Spreadsheet authoring cannot load the required @openai/artifact-tool runtime because load_workspace_dependencies is likewise non-callable.

The affected rollout identifies originator: "Codex Desktop", source: "vscode", and thread_source: "subagent". Historical local rollouts show an intermittent pattern on the same build/date: some user/subagent threads record all 15 dynamic tools, while others record zero. In this reproduction, however, the metadata records all 15 while the live callable registry exposes zero, so persistence/injection into session metadata succeeded but registration into the model-call tool runtime did not.

Expected: every tool declared in session_meta.dynamic_tools should either be callable/discoverable in the live turn or produce an explicit capability error explaining why it was filtered. It should not silently exist only in persisted metadata.

Suggested verification:

• Start user, side-conversation/subagent, resumed, and automation threads.
• Compare session_meta.dynamic_tools against the live deferred registry by exact name.
• Assert that every persisted codex_app tool has a callable runtime handler.
• Cover both create_thread and load_workspace_dependencies, since the regression breaks thread orchestration and bundled spreadsheet/document runtimes.

Regression confirmation from a second macOS host/session family.

This is not a missing local cache/configuration or an intentional capability change: the same workflows worked on prior Codex Desktop versions, and this issue already has same-machine evidence of a previously healthy codex_app surface. On macOS Desktop 26.707.31428 (build 5059, bundled 0.144.0-alpha.4) the failure is now intermittent by fresh side/subagent task.

New control run:

• A fresh local task recorded all 15 codex_app leaf tools in session_meta.dynamic_tools.
• In that same task, the live registry exposed all 15 canonical codex_app__* entries.
• typeof tools.codex_app__create_thread === "function".
• tools.codex_app__load_workspace_dependencies({}) succeeded and returned bundled runtime 26.709.11516.
• The task's thread_dynamic_tools SQLite rows were empty while the 15 runtime tools were callable; SQLite persistence is therefore not the runtime registration source and cache/DB cleanup is not a safe workaround.

Paired with the failing side-conversation reproduction in comment #4940243343 (same metadata contains all 15 but ALL_TOOLS/direct references expose none), this narrows the regression to the Desktop/app-server handoff after dynamic specs are persisted but before the per-turn callable/deferred registry is built.

Please treat this as a version regression across the 0.140.x -> 0.142+ / Desktop app-server evolution, with an intermittent current-build manifestation rather than a feature request. Suggested fix/test invariant: for every dynamic-tool leaf persisted at thread start, construct the canonical handler and expose it through the deferred registry, or return an explicit capability error. Add a matrix covering user, side/subagent, resumed, and automation thread sources, and log thread ID plus dynamic-spec/registered-handler counts on mismatch.

Additional Windows reproduction / spreadsheet-runtime blocker observed on 2026-07-12.

Environment:

• Windows 11 Pro x64, build 22631
• standalone global codex-cli 0.144.1 task
• installed OpenAI.Codex MSIX: 26.707.3748.0
• installed ChatGPT Desktop: 1.2026.190.0
• Spreadsheets primary-runtime skill: 26.630.12135
• codex features list: workspace_dependencies stable true

Live tool-surface receipt:

• ALL_TOOLS.length === 248
• exact workspace-dependency tool matches: []
• exact codex_app leaf-tool matches: []
• load_workspace_dependencies is therefore not callable in the task

The Spreadsheets skill is exposed and selected, but its contract requires load_workspace_dependencies before importing XLSX files and explicitly forbids path guessing, global/repo-local dependencies, installation hacks, or alternate libraries. The result is a hard blocker: the task cannot inspect two XLSX attachments even though the skill is installed and the feature reports enabled.

A prior task on the same machine also ran codex doctor --summary; it produced no output for more than one minute and was interrupted.

Important scope distinction: this occurrence is a standalone CLI-launched task, not a Desktop-bundled process. If the loader is intentionally Desktop-only, the remaining product bug is capability routing: the Spreadsheets skill should not be exposed as executable in a host where its mandatory loader cannot be registered, or it should emit an explicit supported-host message.

Expected invariant: wherever the Spreadsheets skill is callable and workspace_dependencies is enabled, load_workspace_dependencies must be discoverable/callable; otherwise the skill should be gated with an actionable capability error.

No manual package search, alternate XLSX library, or runtime-path workaround was attempted.

Additional macOS reproduction from a standalone scheduled automation on 2026-07-15/16.

Environment:

• ChatGPT/Codex Desktop 26.707.72221, build 5307
• bundle identifier remains com.openai.codex
• CLI 0.144.1
• macOS arm64

Observed:

• The automation starts and receives its prompt normally.
• Its live tool surface contains the expected plugin/MCP tools, but the native codex_app namespace is reduced to only set_thread_archived.
• Missing controls include list_projects, create_thread, list_threads, read_thread, send_message_to_thread, and set_thread_title.
• No excluded_tool_namespaces or direct_only_tool_namespaces configuration is present.
• The failure prevents the automation from creating and verifying visible worker/QA tasks, so it must stop without routing work.

Read-only inspection of the packaged Desktop resources shows that these native task tools are still bundled. The standalone automation startup path requests renderer-built dynamic tools with a fixed 5-second response window. If the primary window is unavailable or the response is late, that path resolves to an empty dynamic-tool list; the subsequent fallback supplies only set_thread_archived. No corresponding exception appears in the Desktop logs, which makes the failure silent.

This seems to be an automation-specific instance of the dynamic-tool exposure regression reported here. It is also related to #31584, where codex_app.list_projects remains advertised but blocks until the generated automation thread is opened manually. We have observed both modes: complete provisioning collapse (this report) and advertised tools whose Desktop handlers stall.

Expected:

• Host-owned thread/project tools should not depend on plugin/MCP catalog bootstrap completing within five seconds.
• A late renderer response should retry or fail visibly instead of silently degrading to archive-only.
• Standalone scheduled automations should receive the same native routing surface as an active Desktop task.

A Desktop /feedback ID is not attached yet because the affected automation surface cannot invoke the user-side slash command.

Follow-up to the earlier report: a later retry of the previously blocked tasks succeeded.

The same Desktop runtime also showed per-task divergence: an affected standalone automation received only set_thread_archived, while a healthy persistent task had the full native task-tool surface and completed calls normally. Combined with the packaged startup path's five-second renderer response window (late/no response becomes an empty catalog, then the archive-only fallback), this points to a transient renderer provisioning/activation race rather than a permanent permission, MCP migration, or static allowlist problem.

The most useful product-side changes would be to keep the native task-tool catalog independent from plugin/MCP catalog assembly, retry or retain a last-known-good native catalog after the five-second miss, and emit an explicit diagnostic whenever the archive-only fallback is used.