claude-code - 💡(How to fix) Fix [BUG] Cowork — multiple silent failure modes (write tools, Read cache, MCP cache lock) — extends #54847 [1 participants]

Production usage context

I've been using Claude Cowork desktop app in production for ~1 week to build an Obsidian-based knowledge management system on a 3,197-file vault. Over 2026-04-29 ~ 04-30 I encountered 10+ systemic silent failure issues that caused real data loss and required Tier 2 manual recovery (clipboard rescue from Obsidian app to chat to disk).

This issue extends the symptom reported in #54847 (Tool dispatch stalls silently in 2.1.121-2.1.123) — same class of failure mode but observed across multiple tools, not only tool_use emission stalls.

I'm filing this as a master issue covering related silent failure modes. Happy to split into per-component issues if engineering prefers — wanted to keep the cross-tool narrative together first.

What's wrong

Multiple Cowork tools (write tools, MCP tool calls, Read tool) silently fail or serve stale data without any error indication. The agent thinks the operation succeeded; the disk shows otherwise; recovery requires direct host-level inspection (xxd, wc -l, stat).

Issues encountered (10+ over 2 days)

P0 — Data loss / corruption

1. obsidian_create_or_update_note MCP silent failure (Obsidian Local REST API plugin via FastMCP)

• Files ≥ 30 KB with CJK content get truncated to ~13.7 KB
• Tool returns success; Read tool shows complete content; disk shows truncated
• Reproducible by writing 30+ KB markdown with mixed Chinese/English content

2. Cowork host-side Write tool silent failure

• Returns "has been updated successfully"; mtime unchanged; size unchanged
• Same symptom as Issue #1 — the documented fallback also lies
• Tested with 5-50 KB files

3. Read tool serves cache, not disk content (most critical)

• Read returns complete content while cat / xxd on disk shows truncated/corrupted
• Cache is not invalidated when external writes occur
• This masks Issues #1, #2, #4, #5 — the agent has no way to detect that writes failed

4. Edit tool appends NULL bytes to file tail

• Memory.md ended up with 38,228 trailing NULL bytes after a single Edit operation
• Reproduced ≥ 3 times during 2026-04-29 work
• Detection: python3 -c "print(open(path,'rb').read().count(b'\x00'))"

5. bash heredoc + Python stdin UTF-8 corruption

• Multi-byte CJK characters truncated at end-of-stream
• Last 1-2 bytes of final UTF-8 character missing
• Detection: xxd file | tail shows incomplete byte sequence (e.g. e6 b5 without third byte)

P1 — Data risk

6. bash mount cache stale — mtime/size doesn't sync with disk after writes; cannot use bash mount for write verification

7. Chat client URL detection corrupts long markdown — xxx.md references in long messages auto-linkified to [xxx.md](http://xxx.md), breaking markdown source fidelity when copying back to vault

P2 — Operation low-efficiency

8. Dispatcher → worker session isolation — Workers cannot read dispatcher's conversation history, must re-paste long content, hit message size limits

9. Dispatcher does not proactively call SendUserMessage — Architectural limitation; SubagentStop hook bug (related: #33049); soft rules in agent memory not reliably followed

10. ~/.claude/skills/ mount protected — Cowork cannot mount user-global skills directory; forces vault staging + manual copy workaround

Bonus issue (encountered during this very feedback task)

11. Gmail MCP create_draft hangs mid-call

• Single tool call with ~13 KB body got "tool permission stream closed before response received"
• Worker session became unresponsive for 20+ minutes
• send_message to the worker did not recover; had to terminate task
• Suggests long-body operations have an unhandled timeout/buffer issue

Steps to reproduce (representative — Issue #1)

1. In Cowork desktop app, open a vault folder with ≥3,000 markdown files
2. Use obsidian_create_or_update_note MCP tool to write a 30+ KB markdown file with mixed CJK + English + tables
3. Tool returns success
4. Read the file with Read tool — shows complete content
5. From bash: wc -l file.md → shows truncated row count (~13.7 KB equivalent)
6. From bash: xxd file.md | tail → shows incomplete UTF-8 sequence at file end

Expected behavior

• Write tools should return an explicit error when the disk write fails (cache lock, truncation, or any non-success condition)
• Read tool should serve the disk's actual content, not in-memory cache (or expose a force-fresh-read option)
• File integrity should be preserved — no NULL byte appending, no UTF-8 byte-boundary truncation
• Long-body tool calls should either complete, fail with clear error, or surface a timeout warning
• Dispatcher → worker boundary should provide a context-handle mechanism

Workaround (Iron Rule 7)

After 2 days of debugging, the only reliable write path discovered:

# Write to /tmp via heredoc (avoids cache layers)
cat > /tmp/file.md << 'EOF_MARKER'
[content]
EOF_MARKER

# Copy to vault disk (avoids obsidian MCP cache + Cowork Write cache)
cp /tmp/file.md /vault/path/file.md

Verification (must use direct disk inspection, NOT Read tool):

ls -la file.md                                                # mtime + size
xxd file.md | tail -3                                         # last bytes (LF? NULL? incomplete UTF-8?)
python3 -c "open('file.md','rb').read().decode('utf-8')"      # UTF-8 strict
python3 -c "print(open('file.md','rb').read().count(b'\\x00'))"  # NULL byte count
wc -l file.md && wc -c file.md                                # line and byte counts

Impact

• ~8-10 hours of recovery work over 2 days
• Three critical files (Memory.md, daily note, CLAUDE.md) reconstructed via Tier 2 clipboard rescue
• Production workflow at risk — agents claim success while data is silently lost
• Required establishing internal protocol of 7 iron rules + 9-item validation checklist for every vault write

Suggested fixes (ordered by impact)

1. Remove or invalidate cache layer between Read tool and disk — always read from filesystem source of truth, or expose explicit force_fresh option
2. Make obsidian MCP and Cowork Write tool fail-loud on cache lock / truncation — return errors instead of success
3. Add automatic atomic write verification to all write tools (post-write read-back from disk + hash check)
4. Document silent failure modes prominently in Cowork/Dispatch docs while a fix is in progress (currently nothing in errors docs or troubleshooting docs covers these)
5. Provide dispatcher-level context-handle mechanism so workers don't need re-paste (also avoids Issue #11 long-body hangs)

Environment

• Platform: Cowork desktop app (Windows version)
• OS: Windows 11
• Vault size: 3,197 files / 1.6 GB Obsidian vault
• Active workers: 4-5 parallel for complex tasks
• Time period: 2026-04-29 ~ 04-30 (2 days)
• MCPs in use: Obsidian (FastMCP), bash (workspace), Read/Write/Edit (host-side), Gmail, scheduled-tasks, dispatch, Claude in Chrome

Related issues

• #54847 — Tool dispatch stalls silently (closely related — same silent failure class, narrower scope)
• #33049 — SubagentStop hook bug (related to Issue #9)
• #54821, #54806, #54786, #54772, #54861, #54744, #54803 — recent dispatch / tool reliability reports

Note on the "single issue" preflight

This is filed as a master issue to keep the cross-tool narrative coherent (multiple silent failures share the underlying cache layer and atomic-write problem). Happy to split into 10+ separate issues if the engineering team prefers per-component tickets — please advise.

Filed via GitHub REST API by an AI agent (Cowork dispatcher) on behalf of the user as part of a feedback workflow validating the very tools being reported on.