MCP tools disappear or become unsupported in existing long-running threads

Bug Report: MCP Tools Disappear Or Become Unsupported In Existing Long-Running Threads

Created: 2026-06-03

Summary

Configured MCP/app tools can work in a fresh or early thread, then later become unavailable or return unsupported call in the same existing thread. Starting a new thread may restore tool access, but that is not an acceptable workaround for workflows that depend on continuity.

This has been observed with Todoist and reportedly with several other tools/connectors, so the issue appears broader than one MCP server.

Environment

• App: Codex Desktop on macOS
• CLI/runtime: codex-cli 0.136.0-alpha.2
• OS: macOS 15.7.3, arm64
• Project: /Volumes/TravelerII/Projects/GeneralAssistant
• Config: /Users/brianwood/.codex/config.toml
• Relevant MCP server:
• todoist
• URL: https://ai.todoist.net/mcp
• codex mcp list reports enabled
• Auth: OAuth

codex doctor notes:

• State/log DBs healthy.
• Auth configured.
• MCP config warning only references an unrelated missing pencil stdio command.
• Todoist remains listed by codex mcp list as enabled with OAuth.

User Impact

This breaks long-running assistant workflows where the user expects to use tools from any active thread.

In this case, the user is building a Todoist-backed productivity workflow where task capture should work from any Codex thread. Requiring a fresh thread whenever MCP tools disappear defeats the purpose of an ongoing assistant and loses conversational/task-planning context.

The practical impact is high:

• Capture workflows become unreliable.
• The assistant may claim a tool is unavailable even though it is configured and works in fresh threads.
• The user cannot trust thread-local tool access after time passes, sleep/wake, or tool refresh.

Observed Behavior

1. A fresh/existing thread successfully exposed Todoist tools.
2. The thread used Todoist MCP successfully for:

• find_projects
• find_tasks
• add_tasks
• add_projects
• add_labels
• add_filters
• complete_tasks
• project_management

1. After several hours, including Mac sleep/wake and Codex restart, the same existing thread no longer had callable Todoist tools.
2. tool_search for Todoist-related queries returned Asana task tools instead of Todoist tools.
3. A direct read-only call to mcp__todoist.find_projects failed with:

unsupported call: mcp__todoistfind_projects

1. A direct write call to mcp__todoist.add_tasks also failed with:

unsupported call: mcp__todoistadd_tasks

1. Running:

/Applications/Codex.app/Contents/Resources/codex mcp list

still reported:

todoist  https://ai.todoist.net/mcp  enabled  OAuth

1. Attempting a CLI codex exec fallback did not work because the child session did not appear to inherit/access the Todoist OAuth state, reporting auth/handshake issues for the MCP server.

Expected Behavior

Existing long-running threads should reliably rehydrate configured MCP/app tools after:

• time passing,
• Mac sleep/wake,
• Codex app restart,
• heartbeat/automation messages,
• lazy tool discovery refreshes.

If a configured tool cannot be loaded into a thread, Codex should expose a clear reconnect/reload mechanism or a clear diagnostic explaining why the tool is unavailable.

At minimum, a tool that was previously callable in a thread should not later fail with a generic unsupported call while codex mcp list still reports the server as enabled and authenticated.

Evidence From This Session

Thread/session:

Todoist pilot thread
rollout: /Users/brianwood/.codex/sessions/2026/06/03/rollout-2026-06-03T06-08-51-019e8cf5-121a-7b62-88c2-c7b005cc819a.jsonl

Examples from the rollout:

• Early tool discovery exposed mcp__todoist.
• Earlier calls succeeded against Todoist, including find-projects and write operations.
• Later in the same rollout, the assistant emitted a function call:

namespace: mcp__todoist
name: add_tasks

but the runtime rejected it as unsupported.

Repro Shape

1. Configure an OAuth MCP server such as Todoist.
2. Start a fresh Codex Desktop thread.
3. Use tool_search to expose Todoist tools.
4. Successfully call Todoist tools such as find_projects and add_tasks.
5. Let the thread run for a while, ideally through Mac sleep/wake or a Codex restart.
6. Return to the same thread.
7. Ask for Todoist task capture or project listing.
8. Observe that Todoist tools are no longer exposed or direct calls fail as unsupported, despite codex mcp list still showing the server enabled with OAuth.

Scope Note

The user reports seeing the same pattern with multiple tools/connectors, not only Todoist. This suggests the root issue may be in:

• thread-local tool availability,
• lazy tool discovery,
• MCP rehydration after sleep/wake,
• existing-thread reconnect behavior,
• or tool namespace persistence across long-running sessions.

Desired Fix

Make configured MCP tools reliable in existing threads, or provide a first-class way to reload/reconnect tool namespaces in the current thread without starting over.

Useful behavior would include:

• reload tools / refresh MCP tools for the current thread;
• automatic MCP tool rehydration after restart/sleep-wake;
• clear error messages distinguishing:
• tool not configured,
• OAuth expired,
• MCP server unreachable,
• thread tool namespace not attached,
• deferred tool not loaded.

Workaround

Current workaround is to start a fresh thread or build a local API bridge outside MCP. Both are undesirable:

• Fresh threads lose continuity.
• API bridges duplicate what the MCP connector is intended to provide.