[BUG] ExitPlanMode doesn't return the plan as a tool result in v2.0.51

Status Fixed / completed
Maintainer reply ✓ Yes — ashwin-ant
Activity 7 comments · opened Nov 24, 2025 · closed Nov 26, 2025
💡 Likely answer: A maintainer (ashwin-ant, collaborator) responded on this thread — see the highlighted reply below.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

When asking Claude to make a plan using the Claude Agent SDK, the ExitPlanMode tool_use block has an empty input field.

This effectively means that Claude Code is not returning the plan to the user. Previously, the plan that Claude generated would be in this input field with format input: {"plan": "<some-plan-here>"}.

What Should Happen?

The Claude Agent SDK should return an input block with the resulting plan.

Error Messages/Logs

Full SDK logs: 

[2025-11-24T20:54:44.020Z] {
  "type": "assistant",
  "message": {
    "model": "claude-opus-4-5-20251101",
    "id": "msg_017e2j7Cgo6nPveSEXPFi49B",
    "type": "message",
    "role": "assistant",
    "content": [
      {
        "type": "tool_use",
        "id": "toolu_01DZVSfTvie8owEVhnS4EP7Y",
        "name": "ExitPlanMode",
        "input": {}
      }
    ],
    "stop_reason": null,
    "stop_sequence": null,
    "usage": {
      "input_tokens": 1,
      "cache_creation_input_tokens": 1108,
      "cache_read_input_tokens": 20452,
      "cache_creation": {
        "ephemeral_5m_input_tokens": 1108,
        "ephemeral_1h_input_tokens": 0
      },
      "output_tokens": 1,
      "service_tier": "standard"
    },
    "context_management": null
  },
  "parent_tool_use_id": null,
  "session_id": "b1eb90ac-9c78-4e64-8574-97a4929ca4e1",
  "uuid": "3f192f9f-7518-4eb1-8758-9bb1d86c517b"
}
[2025-11-24T20:54:44.048Z] [CC-SDK-STDERR]: 2025-11-24T20:54:44.048Z [ERROR] "ZodError: ZodError\n    at error (/$bunfs/root/claude:77:18464)\n    at parse (/$bunfs/root/claude:77:11726)\n    at w67 (/$bunfs/root/claude:4010:4667)\n    at async <anonymous> (/$bunfs/root/claude:4010:6182)\n    at async <anonymous> (/$bunfs/root/claude:4432:680)\n    at async <anonymous> (/$bunfs/root/claude:4435:1537)\n    at async Jt8 (/$bunfs/root/claude:2149:23658)\n    at processTicksAndRejections (native:7:39)"
[2025-11-24T20:54:44.048Z] [canUseTool] ExitPlanMode detected for session d638be6a-54ee-4483-b6a9-c931b30364cf

Steps to Reproduce

  1. Ask Claude Code to make a plan using the SDK with permissionMode: "plan"
  2. Notice that the tool_use block with name set to ExitPlanMode will have an empty input field

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.0.34

Claude Code Version

2.0.51

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Non-interactive/CI environment

Additional Information

The last version we tested on was v2.0.34. We have not bisected versions further than that.

View original on GitHub ↗

7 Comments

ashwin-ant collaborator · 9 months ago

Are you not seeing the plan input in SDK callbacks like canUseTool and PreToolUse hooks? The plan should still be there.

omidmogasemi · 9 months ago
Are you not seeing the plan input in SDK callbacks like canUseTool and PreToolUse hooks? The plan should still be there.

@ashwin-ant We do see it in canUseTool, but my understanding is the expected behavior is to receive relevant tool output (in this case, the plan) as part of the tool_use block. It seems odd to not include the actual tool output associated with that block for ExitPlanMode, but to include it for others.

This was also a surprising (undocumented) breaking change for us, given it used to exist in that block.

RonTuretzky · 9 months ago

this is such a critical blocker, please address 🙏

ashwin-ant collaborator · 9 months ago

We're working on a fix now.

ashwin-ant collaborator · 9 months ago

This should be fixed in 0.1.54 of the Agent SDK (and CC 2.0.54). Please let us know if you still see this issue!

omidmogasemi · 9 months ago

Thanks for the quick fix! Can confirm this is fixed in v0.1.54 :)

github-actions[bot] · 9 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.