Codex Desktop: `thread_tools` gate does not restore task tools after re-enable

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

26.715.31251 (build 5538; bundled codex-cli 0.145.0-alpha.18)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

A local Codex Desktop task lost the complete first-class task/thread-management tool surface:

• create_thread
• fork_thread
• handoff_thread
• list_threads
• read_thread
• wait_threads
• send_message_to_thread
• set_thread_pinned
• set_thread_archived
• set_thread_title

This is not the “tool is advertised but no handler is registered” failure from #31119. The tools are absent from the task's dynamic-tool manifest entirely.

The affected local task currently has only these three persisted codex_app dynamic tools:

automation_update
read_thread_terminal
load_workspace_dependencies

The runtime tool registry presented to the agent matches that persisted state. However, the Desktop-provided instructions still explicitly tell the agent to use create_thread, list_threads, read_thread, wait_threads, and the other missing tools. This leaves the product in an internally inconsistent state.

Inspection of the installed signed app bundle maps the feature key to the remote gate as follows:

featureKey: thread_tools
gateName: 2395575782

The important recovery failure is:

1. A local task is persisted without the thread tools while the gate/tool manifest is unavailable.
2. A later Desktop startup log reports thread_tools in enabledFeatures.
3. Resuming the same affected task does not rehydrate or repair its persisted dynamic-tool manifest.
4. The task therefore remains unable to create or coordinate user-visible Codex tasks even though the current app process says the feature is enabled.

A separate local task on the same account had the full tool set available on 2026-07-13, so this is not an account that has never had the capability.

This blocks supported manager/worker workflows. A local CLI or app-server process is not an equivalent workaround because it does not create a genuine user-visible task in the Codex sidebar.

What steps can reproduce the bug?

The gate cannot be controlled through the public UI, but the observed sequence and an internal deterministic A/B reproduction are:

1. Start or resume a local Codex Desktop task while Statsig gate 2395575782 / feature thread_tools evaluates false or is otherwise omitted from the task's dynamic-tool manifest.
2. Ask the agent to list or create Codex tasks, for example: “Create a new user-visible Codex task.”
3. Observe that no first-class task tools are available; only automation_update, read_thread_terminal, and load_workspace_dependencies are persisted for the task.
4. Re-enable gate 2395575782 for the same account and restart Codex Desktop.
5. Confirm the Desktop startup log includes thread_tools in enabledFeatures.
6. Resume the same task and repeat the request.
7. Observe that the first-class task tools are still absent and the persisted manifest is unchanged.

For an internal regression test, create/resume tasks across an explicit gate sequence of ON -> OFF -> ON and verify both new and existing task manifests. The failure is specifically the existing-task OFF -> ON recovery path.

I can provide sanitized timestamps and additional local state evidence if maintainers need it. I have intentionally omitted private task IDs and filesystem paths from this public report.

What is the expected behavior?

When thread_tools is enabled and the Desktop host can service the calls:

• Existing local tasks should regain the supported first-class task-management tools on resume.
• The persisted dynamic-tool manifest should be refreshed or migrated when capability assignment changes.
• App instructions must not direct the agent to call tools that are absent.
• Feature-gate transitions should be atomic and version-compatible with the bundled CLI.
• The UI should expose an explicit capability status if task-management tools are intentionally unavailable.

A temporary remote-gate assignment should not permanently degrade a long-lived task.

Additional information

Related reports:

• #31119: tools are advertised but handlers disappear or calls have uncertain outcomes. This report is the distinct missing-manifest and failed-rehydration path.
• #29361: the opposite feature-gate/version-skew failure, where Desktop enabled thread_tools for a bundled CLI that rejected the feature key.
• #26907: thread-management tools omitted for remote-created tasks. This report reproduces on a local Desktop task and persists after the gate is enabled again.

Root-cause hypothesis: Desktop builds the dynamic-tool list from featureOverrides.thread_tools, persists it per task, and resumes existing tasks without rebuilding that list. If gate 2395575782 is false or temporarily unavailable when the manifest is written, that task remains stripped after the gate later evaluates true.