SDK MCP tools unavailable when resuming with empty streaming input (regression in 0.2.140)

[ncoop57]

Resuming a session with a pending deferred tool fails when the tool comes from an SDK MCP server and the resume passes an empty streaming input. Claude Code reports the tool as unavailable. It never re-invokes the tool. Passing a text prompt instead works.

0.2.139 works. 0.2.140 and later fail.

import anyio, dataclasses, tempfile
from claude_agent_sdk import (ClaudeAgentOptions, HookMatcher, ResultMessage,
                              create_sdk_mcp_server, query, tool)

ALLOW = []

@tool("flux", "Read the flux", {})
async def flux(args): return {"content": [{"type": "text", "text": "41.7 gauss"}]}

async def gate(inp, tool_use_id, ctx):
    dec = "allow" if ALLOW else "defer"
    return {"hookSpecificOutput": {"hookEventName": "PreToolUse", "permissionDecision": dec}}

async def no_prompt():
    return
    yield

opts = ClaudeAgentOptions(
    model="haiku", cwd=tempfile.mkdtemp(), setting_sources=[],
    mcp_servers={"probe": create_sdk_mcp_server("probe", tools=[flux])},
    allowed_tools=["mcp__probe__flux"],
    hooks={"PreToolUse": [HookMatcher(matcher="mcp__probe__flux", hooks=[gate])]})

async def run(prompt, **kw):
    async for m in query(prompt=prompt, options=dataclasses.replace(opts, **kw)):
        if isinstance(m, ResultMessage): return m

async def main():
    a = await run("Measure the flux.")
    print("leg 1:", a.stop_reason)
    ALLOW.append(True)
    b = await run(no_prompt(), resume=a.session_id)
    print("leg 2:", b.stop_reason, "| is_error:", b.is_error)

anyio.run(main)

Leg 1 defers the tool and ends with tool_deferred. Leg 2 resumes the session to re-invoke the deferred call. Output:

0.2.139  leg 2: end_turn                  is_error: False
0.2.140  leg 2: tool_deferred_unavailable is_error: True

On 0.2.140 the run also prints:

Task exception was never retrieved
future: <Task finished coro=<Query._handle_control_request() ...>
         exception=CLIConnectionError('ProcessTransport is not ready for writing')>
  File ".../claude_agent_sdk/_internal/query.py", line 580, in _handle_control_request
    await self.transport.write(json.dumps(success_response) + "\n")
  File ".../transport/subprocess_cli.py", line 1048, in write
    raise CLIConnectionError("ProcessTransport is not ready for writing")

Claude Code logs Deferred tool resume: tool '...' is no longer available (MCP server disconnected or tool removed). The failing run makes no API call. duration_api_ms is 0 and token usage is zero.

Other results:

• Replacing no_prompt() with a text prompt works on every version.
• Deferring a built-in tool such as Read the same way resumes correctly. Only SDK MCP tools fail.
• The Claude Code version does not matter. On 0.2.139 the resume works against CLI 2.1.232, 2.1.235 and 2.1.237. On 0.2.142 it fails against all three.

I have not confirmed the mechanism. The traceback shows the SDK failing to answer a control request from Claude Code after the input stream ends.

Environment: Claude Code 2.1.237, Python 3.13, Linux.

[tonydzi]

Your bisect holds and the mechanism is in stream_input, not in the MCP bridge. The short version: on 0.2.140 an empty prompt stream closes stdin before the gate that is supposed to keep it open, so the CLI's control request for the deferred tool arrives at a closed pipe.

The line. _internal/query.py:884-890:

if written:
    await self.wait_for_result_and_end_input()   # honors _has_bidirectional_needs()
else:
    # Nothing was sent, so no result will arrive to release the
    # hold; close immediately (mirrors the TypeScript SDK's
    # messageCount guard).
    await self.transport.end_input()             # bypasses the gate entirely

no_prompt() yields nothing, so written == 0 and the else branch runs. _has_bidirectional_needs() (:819) is never consulted, even though it returns True for your config. On 0.2.139 there was no written counter at all — wait_for_result_and_end_input() was called unconditionally, so the same empty stream held stdin open. That is the whole regression.

Isolated it away from the CLI so the lifecycle is observable without an API call — fake transport, Query.stream_input, record whether end_input() fires before any result:

config	stream	0.2.139	0.2.143
hooks / SDK MCP	empty	held open	closes stdin
can_use_tool	empty	closes stdin	closes stdin
hooks / SDK MCP	1 message	held open	held open
no bidi needs	1 message	closes	closes

Row 3 is the control: the gate itself still works on 0.2.143, so row 1 is the guard short-circuiting it, not a broken gate.

This accounts for the rest of your list. A string prompt never reaches stream_input — _internal/client.py:172-182 writes the message straight to the transport and calls wait_for_result_and_end_input() directly, with no written guard, which is why text prompts work on every version. Built-in tools like Read need no control-protocol round-trip, so a closed stdin costs them nothing; SDK MCP tools are served over that protocol and cannot be answered. And since the failure is entirely SDK-side, the CLI version genuinely does not matter — matching your 2.1.232/235/237 result. The ProcessTransport is not ready for writing traceback is the same event from the other end: the CLI did send the control request, and _handle_control_request had nowhere to write the reply.

Wider than the title. _has_bidirectional_needs() covers SDK MCP servers, hooks and can_use_tool, and the guard defeats all three — your repro happens to trip two, since it also installs a PreToolUse hook. Worth noting 0.2.140 added can_use_tool to that gate, but in the empty-stream path the addition is unreachable.

The premise to fix. The comment's reasoning — "nothing was sent, so no result will arrive" — is true for a fresh session and false on resume, where the CLI already has queued work and will produce a result on its own. So the guard needs to know that:

if written or (self._resumed and self._has_bidirectional_needs()):

with resumed=bool(options.resume or options.continue_conversation) threaded into Query; configured_options is already in scope at the construction site (_internal/client.py:135).

I checked the obvious way this could go wrong. Simply dropping the guard is not safe: a genuinely empty stream on a fresh session with bidirectional needs would then wait on _first_result_event with no timeout by design, i.e. hang forever — which is presumably why the guard was added. The _resumed condition keeps that case closing immediately. Both arms verified:

	resume	fresh
empty stream + bidi needs	held open	closes (no hang)
empty stream, no bidi needs	closes	closes

Full suite: 1485 passed, 5 skipped with the patch — and identical on unpatched main, which is the part worth flagging: nothing in the suite currently exercises an empty prompt stream with bidirectional needs, so CI stays green while this is live.

One limit I should be straight about: I verified the transport lifecycle, not your end-to-end run — I did not reproduce tool_deferred_unavailable against a live CLI, so the last link (closed stdin → MCP server disconnected) rests on your traceback and log line rather than my own measurement. If it's useful I can put the patch up as a PR with a regression test that pins the empty-stream-on-resume case.