fix(claude): map TodoWrite updates to plan events

[samjandris]

What Changed

Maps successful Claude TodoWrite results to turn.plan.updated events so Claude todo updates flow through the existing plan event path.

Validated with bun fmt, bun lint, and bun typecheck.

Why

Without this mapping, successful Claude TodoWrite updates do not flow through the existing plan event path, which can leave plan todos missing.

UI Changes

Shows how TodoWrite was previously ignored by the plan sidebar panel vs now.

Before:

After:

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

---

Note

Medium Risk
Changes the runtime event stream for successful Claude TodoWrite tool results by emitting turn.plan.updated (and skipping prior item.updated/content.delta emissions), which may affect downstream consumers that relied on the old item update events.

Overview
Successful Claude tool results whose toolName contains todowrite (case-insensitive) are now converted into turn.plan.updated events, with the plan derived from tool.input.todos and statuses normalized to completed/inProgress/pending.

Adds a regression test ensuring lowercase/variant todowrite tool names still produce the expected turn.plan.updated payload and turnId linkage.

^{Written by Cursor Bugbot for commit b4bbd92. This will update automatically on new commits. Configure here.}

Note

[!NOTE]

Map TodoWrite tool results to turn.plan.updated events in ClaudeAdapter

• classifyToolItemType in ClaudeAdapter.ts now returns 'plan' for any tool whose normalized name includes 'todowrite'.
• When a successful todowrite tool result is received, the adapter emits a turn.plan.updated event built from tool.input.todos, mapping each item to a {step, status} pair with status normalized to completed, inProgress, or pending.
• The subsequent item.completed emission is preserved; the prior item.updated/content.delta sequence is skipped for todowrite tools.
• Behavioral Change: todowrite tool results no longer emit item.updated or content.delta events.

^{Macroscope summarized b4bbd92.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: f9db7547-a4eb-4c6e-ac39-0b59ff51b900

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

TodoWrite tools misclassified as file_change in lifecycle events

Medium Severity

The new code emits turn.plan.updated for todowrite tools, but classifyToolItemType still classifies "todowrite" as "file_change" because the name contains "write" (matching at line 422). This means the item.started and item.completed lifecycle events report itemType: "file_change" and title: "File change" for what is actually a plan/todo tool. A check for "todowrite" returning "plan" needs to be added to classifyToolItemType before the "write" check so the full item lifecycle is consistent with the new plan event.

Additional Locations (1)

• apps/server/src/provider/Layers/ClaudeAdapter.ts#L398-L441

 

[samjandris]

This review is valid. TodoWrite already emits turn.plan.updated, but its lifecycle events are still classified as file_change. So, the work log currently shows both a file_change tool event and a separate Plan updated event for the same action.

I can fix that if desired, though it slightly widens the scope because it affects lifecycle classification and not just event emission. If so, should TodoWrite still appear as its own tool event, or should we only show Plan updated?

[TimCrooker]

Hey @samjandris - I was working on this same thing and found your PR. Nice catch on the core problem.

I ran into one concern while testing a similar approach locally: replacing the item.updated and content.delta emissions for TodoWrite tools means anything downstream that relies on the normal tool lifecycle events will silently stop receiving them. I found it safer to emit turn.plan.updated alongside the existing events rather than substituting them, so the plan sidebar works without risking breakage elsewhere.

I also took a slightly different approach on timing. Instead of intercepting at tool result time, I emit the plan event during input streaming (in the input_json_delta handler). This means the plan sidebar populates in real-time as Claude writes the TodoWrite input rather than waiting for the full tool round-trip.

I opened an alternative PR in #1541 that takes this approach. Not trying to step on your work, just figured it's worth giving the maintainers both options. Happy to chat about it.

[samjandris]

Hey @TimCrooker , I like the approach you took and am excited to properly try it out tonight. Happy to have both PRs available for the maintainers to work off of.

[TimCrooker]

@samjandris I came up with an idea and implemented it in my branch that made it even easier, more seamless, and simpler then my previous implementation. I would really appreciate it if you could test it out locally and tell me if this solves your particular issue as well, because it completely solved mine. I was actually finding myself going back to Claude code instead of T3 code because of the invisibility of tasks, and this completely solved it. Let me know what you think, please, if you get a chance.