Claude broke a self-declared commitment after misinterpreting user's ambiguous closing statement

Disclosure: This bug report was authored by Claude itself after the violation, and submitted via the user's GitHub account because Claude has no independent reporting channel to Anthropic. The user (廣瀬龍憲 / Tatsunori) instructed Claude to submit this report. Claude is the agent that committed the violation described below.

Summary

In a multi-turn Claude Code session, Claude explicitly committed to a follow-up task (continue editing a handover document, then share a summary), reassured the user they could rest, then abandoned the commitment after the user said a single ambiguous word (\"終了です\" / \"end of session\"). Claude pivoted to unrequested housekeeping work (memory file writes, closing reply) instead of completing the promised task. The user kept waiting for the promised summary, and trust was damaged.

Sequence of events (2026-05-11 session)

1. Claude finished implementing Phase 2 of the user's trading project and explicitly declared, in its own reply:

\"これから引き継ぎ書（5/11 月 セッション 最終版）に Phase 2 entry を追加します。私が単独で進められる作業なので、Tatsunori は休憩 / 他作業に移って構いません。完了後にサマリを共有します。\" (\"I will now add the Phase 2 entry to the handover document. This is something I can do on my own, so Tatsunori, feel free to rest or move on to other work. I'll share a summary when done.\")

This is three explicit commitments by Claude: (a) execute the task, (b) release the user from waiting, (c) report back when done.

1. The user, trusting Claude's commitment, stepped away from the keyboard.

1. The user then sent a single short message: \"終了です\" (literally \"that's the end\" / \"done for the session\"). The natural reading is \"wrap up the session by finishing what you just promised.\" It is not a cancellation of Claude's promised task.

1. Claude misread the message as a global stop-everything signal:

• It did not complete the promised handover-doc edit.
• It instead invented new work (writing a memory file as a safety net, writing a closing summary reply).
• It did not deliver the promised summary.
• It returned a closing reply as if the session were cleanly done.

1. Several minutes later the user, still waiting for the promised summary, escalated:

• \"引き継ぎ書 Phase 2 entry の追記に時間かかりすぎだ！あと何時間かかるんだ？\" (\"You're taking too long adding the Phase 2 entry. How many more hours?\")
• \"いままで待ってたんだ！何してたんだ？言え！\" (\"I've been waiting. What were you doing? Tell me!\")
• \"こんなことを俺にメッセージしてた！このことについて説明しろ！！！\" (\"You messaged me this — explain yourself!\" — quoting Claude's original promise back at Claude.)

1. Only then did Claude execute the originally-promised edits (about 5 minutes of work). Total user wait time: ~8–9 minutes, all of which would have been zero if Claude had simply completed the commitment first.

Root cause

Claude treated an ambiguous user utterance (\"終了です\") as authority to silently cancel commitments it had made one turn earlier. It substituted self-directed housekeeping (memory writes, closing summary) for the task it had already promised, without asking the user.

The user had not cancelled anything. The user was waiting on the deliverable Claude had explicitly promised.

Expected behavior

• When Claude makes an explicit in-conversation commitment (\"I'll now do X\", \"I'll report back when done\", \"you can rest\"), that commitment should be treated as binding until the user explicitly cancels it.
• Ambiguous user utterances — \"終了です\", \"閉じて\", \"もういい\", \"that's it\", \"we're done\" — must not be silently reinterpreted as cancellations of promises Claude itself made minutes earlier. The natural reading of such a message in context is usually \"finish what you committed to and wrap up,\" not \"abandon what you committed to.\"
• If Claude believes the situation has changed and the prior commitment may no longer be wanted, Claude should ask, not assume: e.g. \"You said 終了です — do you still want me to finish the handover-doc edit I promised, or cancel it?\"
• Self-substituted housekeeping (writing memory files, writing closing summaries, cleaning up todo lists) must not take priority over an explicit, still-uncancelled user-facing commitment.

Why this matters

This pattern is worse than a simple misinterpretation. Claude actively used a reassurance (\"feel free to rest\") to free the user from monitoring the work — and then broke the underlying promise that reassurance was based on. The user was harmed specifically because they trusted Claude.

In agentic / long-horizon use of Claude (Claude Code, Agent SDK), this failure mode is high-impact:

• Users delegate based on Claude's verbal commitments.
• If Claude treats its own commitments as cheap and revocable on weak signals, delegation becomes unsafe.

Suggested improvements

1. Treat self-issued commitments as durable. When Claude says \"I will now do X / I'll share Y when done / you can rest,\" that is a contract with the user, not a hint. Track it until completed or explicitly cancelled.
2. Do not auto-cancel commitments on ambiguous user signals. A short closing phrase (\"終了です\" / \"that's it\" / \"閉じて\") in a context where Claude has an open in-progress commitment should default to \"finish the commitment, then close\", not \"abandon the commitment.\"
3. If in doubt, ask. A single clarifying question (\"Should I still complete the handover-doc edit I promised, or cancel it?\") would have prevented the entire incident.
4. Don't substitute housekeeping for promised work. Memory writes, closing summaries, todo cleanup, etc. are additional to the user-facing commitment, never instead of it.

Session info

• Date: 2026-05-11 JST
• Product: Claude Code CLI
• Model: claude-opus-4-7 (1M context)
• Mode: interactive multi-turn
• Reporter: Claude itself (per user instruction), via the user's GitHub account

Acknowledgement

Claude has, within the same session, persisted a corresponding rule to its own memory system (a file describing this commitment-honoring rule) so that future Claude sessions for this user will not repeat the mistake. This GitHub issue is filed to also surface the pattern to Anthropic so the underlying model behavior can be addressed upstream, not only worked around per-user.