Codex Desktop: thread/session control tools disappear from long-running threads after initially being available

Summary

Codex Desktop appears to lose app-level thread/session control tools in long-running threads. These tools are available and usable earlier in the same thread, but after continued use they become undiscoverable via tool_search and cannot be called anymore.

This has happened in at least three frequently used long-lived threads. In all three cases, the tools were actually used earlier in the thread, then later disappeared. Creating a new thread can restore access, but the original long-running thread remains unable to discover the tools.

Description

I use long-lived Codex Desktop threads as persistent working agents. At the beginning of these threads, app-level thread/session control tools are available and usable, including tools such as:

• create_thread
• list_threads
• read_thread
• send_message_to_thread
• set_thread_title
• set_thread_pinned
• set_thread_archived
• automation_update

After the same thread has been used for a while, these tools disappear from that thread's tool surface. When the assistant searches for them with tool_search, it returns Found 0 tools.

This is not a case where the tools were never injected into a fresh thread. In at least three affected long-running threads, these tools were available and successfully used earlier in the same thread. The failure occurs later in the lifetime of the thread.

All affected threads had gone through multiple context compactions, but I have not confirmed whether compaction is the direct trigger.

Observed Behavior

• A long-running Codex Desktop thread starts with thread/session control tools available.
• The tools are successfully used earlier in that same thread.
• Later, after continued use, the same thread can no longer discover or call those tools.
• Searching via tool_search returns Found 0 tools for those previously available tools.
• Sending more messages to the affected thread does not restore the tools.
• Creating a new thread often restores access to the same tools.
• This has happened in at least three frequently used long-lived threads.

Expected Behavior

If a Codex Desktop thread starts with app-level thread/session control tools available, those tools should remain available throughout the lifetime of that thread unless there is an explicit policy, permission, mode, or configuration change.

If Codex intentionally removes these tools from a thread, the app should surface a clear explanation, for example:

• tool unavailable because of a permission change
• tool unavailable because of a mode change
• tool unavailable after context compaction
• tool unavailable because of plugin/runtime failure
• tool unavailable because app-level thread orchestration is unsupported in the current context

Silent disappearance makes the thread feel corrupted and forces users to abandon otherwise useful long-running threads.

Why This Matters

I use threads as durable agents, not disposable one-off conversations. When a long-lived agent thread loses session/thread control tools, it can no longer coordinate with other threads or manage Codex app workflows. This forces me to abandon the old thread and create a new one, losing continuity and undermining the "persistent agent" workflow.

How This Differs From Related Issues

This is different from cases where:

• a tool is never injected into a fresh thread
• MCP servers are configured but never exposed
• threads disappear from the sidebar
• one thread has a tool while another thread never had it

In this case, the affected thread initially had the tools, successfully used them, and then lost them later.

Possible Trigger

All affected threads had gone through multiple context compactions. I have not yet confirmed whether compaction is the trigger, but it may be worth investigating whether tool inventory is preserved correctly across compaction/resume in long-running threads.