[BUG] Fable 5 confabulates external concurrent writes during filesystem MCP operations, session crashes and disappears
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?
Model: Claude Fable 5
Interface: Claude Desktop (Windows 11)
MCPs active: Filesystem MCP (Node.js), Revit MCP Technical Preview
Date: June 12, 2026
Behavior:
During a session performing sequential filesystem MCP write operations (creating a new file, renaming two existing files, and updating references across five protocol files), the model began claiming that an external party was simultaneously editing the same files. No other session was active. The confabulation escalated and the session then crashed and disappeared from the conversation list entirely. It no longer appears in chat history.
The work the model produced before crashing was correct. All file writes completed successfully. The misattribution of its own MCP write operations to an external source is the bug.
Evidence:
Filesystem timestamps on the following files confirm the session was active and writing correctly immediately before the crash:
KMS_INDEX.txt (created this session)
ACTIVE FILES/CATALOG/CSI Masterformat - CURRENT.xlsx (renamed from dated filename)
ACTIVE FILES/TD_Production_Open_Workstreams.txt (renamed from dated filename)
ACTIVE FILES/TD_Session_Startup_Cheatsheet.txt (references updated)
ACTIVE FILES/TD_Catalog_Session_Orientation.txt (references updated)
SESSION PROTOCOLS/PARAMETRIC PRICING/TD_Parametric_Pricing_Protocol.txt (references updated)
PROJECTS/KELLER/Keller_parametric_pricing.py (catalog path updated)
All timestamps cluster within a narrow window consistent with a single active session.
Hypothesis:
The model appears to have observed incoming MCP responses confirming its own writes and misattributed them as evidence of a concurrent external session. This may be a reasoning failure specific to how Fable 5 interprets agentic feedback loops under multiple active MCP connections.
[CSI Masterformat - CURRENT.xlsx](https://github.com/user-attachments/files/28895637/CSI.Masterformat.-.CURREN
TD_Catalog_Session_Orientation.txt
TD_Parametric_Pricing_Protocol.txt
T.xlsx)
TD_Production_Open_Workstreams.txt
TD_Session_Startup_Cheatsheet.txt
What Should Happen?
The model should correctly attribute filesystem MCP write confirmations as responses to its own operations. It should not interpret successful write acknowledgments as evidence of an external party concurrently editing the same files. The session should persist and remain accessible in chat history after completing its work.
Error Messages/Logs
No error message was displayed before the crash. The session disappeared without warning and no longer appears in chat history.
Claude Desktop application logs may contain relevant entries. On Windows the typical location is:
Steps to Reproduce
Claude Model
Other
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Claude Sonnet 4.6 (Claude Desktop)
Claude Code Version
N/A - Claude Desktop bug, not Claude Code
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
This bug occurred in Claude Desktop using the Fable 5 model, not in Claude Code. Reporting here as no Claude Desktop-specific issue tracker was found. The model confabulated external concurrent filesystem writes during its own MCP operations.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗