Task tools (TaskCreate/TaskUpdate/...) permanently lost mid-session after /login — 'MCP server disconnected'

Status Open

Maintainer reply None cached

Activity 3 comments · opened Jul 22, 2026

Summary

Built-in Task tools (TaskCreate/TaskUpdate/TaskList/TaskGet/TaskOutput/TaskStop) permanently disappear mid-session after running /login, with a misleading "MCP server disconnected" notice. They never reconnect for the lifetime of the session. Fresh sessions get them normally.

Environment

Claude Code v2.1.216, macOS (darwin 25.5.0), Homebrew install
Max subscription OAuth (interactive claude login)
Also reproduced on Linux hosts (Ubuntu) across a fleet after credential/OAuth token changes mid-session

Steps to reproduce

Start an interactive session; observe TaskCreate/TaskGet/TaskList/TaskOutput/TaskStop/TaskUpdate present in the deferred tools list.
Run /login mid-session (re-authenticate).
A system notice appears: the Task tools are "no longer available (their MCP server disconnected)"; ToolSearch for them returns no match from then on.

Expected

Task tools survive re-auth, or reconnect after it — like the rest of the built-in toolset does.

Actual

Tools are gone until the session is restarted. Headless probe (claude -p) in a fresh session confirms the tools are available product-side, so this is purely a mid-session re-auth issue.

Impact

Long-lived agent sessions (tmux fleets) that undergo token refresh/re-login lose task tracking permanently; Stop hooks that require TaskCreate/TaskUpdate lock those agents into repeated enforcement blocks. TodoWrite is likewise absent in the affected session, so there is no todo tool at all after the drop.

View original on GitHub ↗

3 Comments

otalrapha · 2 months ago

Independent confirmation on v2.1.217, Linux (WSL2 Ubuntu) — with a different trigger, which suggests the bug is broader than /login:

Our repro: no re-auth involved. An MCP connection dropped mid-session (transport blip), and the entire deferred batch was retired together — including the native TaskCreate/TaskGet/TaskList/TaskUpdate:

156 deferred tools are no longer available (MCP server disconnected):
  ..., TaskCreate, TaskGet, TaskList, TaskUpdate

ToolSearch for them returns empty for the rest of the session; a fresh session gets them back. So the common denominator seems to be any mid-session interruption of the deferred-tool transport (re-auth being one trigger, MCP drop another), not /login specifically.

Two data points from the public changelog that frame this:

2.1.186: "Fixed a misleading 'MCP server disconnected' notice for intentionally retired tools when resuming older sessions" — the misleading-label class was already acknowledged and fixed for the resume path. This issue is the mid-session sibling of that fix, still emitting the MCP-attributed label for native tools as of 2.1.217.
2.1.84: "Fixed cold-start race where core tools could be deferred without their bypass active" — confirms native/core tools ride the deferred path by design, which explains why they sink with the MCP batch.

One impact worth highlighting: the notice is injected into the conversation, so the model reads it too and concludes the native Task tools are MCP tools — in our session the model spent several turns trying to "reconnect" a nonexistent MCP server for TaskCreate. The misattribution actively derails triage for both the user and the model. Even before the reconnect behavior is fixed, correcting the label (distinguish native deferred tools from MCP tools) would stop that.

kouta-kun · 1 month ago

The same is happening for me on 2.1.238.

webby-box · 1 month ago

after /login, check that Task tools are still live before you leave a session running.

silent disconnect mid-fleet is how hung loops keep burning while you think the harness is healthy.